Klasifikacija ozbiljnosti incidenata za DORA, NIS2 i GDPR

Poziv u 02:17 zbog incidenta koji postaje regulatorna odluka

U četvrtak u 02:17 ujutro Sarah, CISO FinScalea, vidi prvo upozorenje: abnormalan API promet, nagli porast neuspjelih autentifikacija i latenciju nadzorne ploče za plaćanja iznad 3000 ms. U nekoliko minuta korisnička podrška prijavljuje pogreške u statusu plaćanja. Pružatelj usluga u oblaku navodi da nema incidenta na razini cijele platforme. SOC uočava sumnjive pristupne tokene iz dviju geografskih regija. Tim proizvoda potvrđuje da je nadzorna ploča ponovno dostupna nakon 19 minuta, ali dvanaest korisnika već je otvorilo prijave.

Do 03:05 Sarah je na kriznom pozivu s voditeljem incidenta, pravnim savjetnikom, koordinatorom za privatnost, voditeljem operacija u oblaku i izvršnim sponzorom. Tehničko je pitanje dovoljno jasno: što se dogodilo s API pristupnikom? Regulatorna su pitanja teža:

1. Je li ovo veliki incident povezan s IKT-om prema DORA?
2. Je li ovo značajan incident prema NIS2?
3. Postoji li povreda osobnih podataka prema GDPR-u koja zahtijeva obavješćivanje?
4. Može li organizacija dokazati kako je došla do tih odgovora?

Pogrešan odgovor može stvoriti regulatornu izloženost. Spor odgovor može dovesti do propuštanja roka za prijavu. Nedokumentiran odgovor može pasti na reviziji prema ISO/IEC 27001:2022 nekoliko mjeseci kasnije.

To je izazov odgovora na incidente u 2026. Mnoge organizacije imaju plan odgovora na incidente, forenzičke postupke, operativne upute za privatnost i predloške krizne komunikacije. Manje ih ima dokaziv model klasifikacije ozbiljnosti incidenata koji bučan sigurnosni događaj pretvara u dokumentiranu odluku kroz DORA, NIS2, GDPR i dokazna očekivanja prema ISO/IEC 27001:2022.

Rješenje nisu tri odvojena postupka trijaže. Rješenje je jedan upravljani model ozbiljnosti s odvojenim regulatornim slojevima, mjerljivim pragovima, pravilima eskalacije, zapisnicima odluka i zahtjevima za prikupljanje dokaza. U praksi, ozbiljnost incidenta ne smije biti oznaka odabrana pod pritiskom. Ona mora biti kontrolirana poslovna odluka koja može izdržati provjeru regulatora, revizora, članova upravljačkog tijela, korisnika i DPO-a.

Zašto je klasifikacija ozbiljnosti incidenata sada kontrola na razini upravljačkog tijela

Klasifikacija incidenata ranije je uglavnom bila tehnička: ozbiljnost zlonamjernog softvera, pogođeni poslužitelji, iskorištene ranjivosti i pitanje jesu li podaci izneseni. U 2026. ona je također pravna, financijska, društvena i ugovorna.

DORA digitalnu operativnu otpornost postavlja kao obvezu upravljanja za financijske subjekte. Od upravljačkog tijela očekuje se da definira, odobri, nadzire i ostane odgovorno za okvir upravljanja IKT rizicima. To uključuje neprekidnost poslovanja u području IKT-a, planove odgovora i oporavka, kanale za prijavljivanje velikih incidenata, rizik trećih strana u području IKT-a i naučene lekcije.

NIS2 podiže upravljačke zahtjeve za ključne i važne subjekte. Article 20 zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i pohađaju osposobljavanje. Također povezuje neuspjehe u upravljanju rizicima i prijavljivanju incidenata s ozbiljnim nadzornim posljedicama. Za ključne subjekte osnovice najvećih upravnih novčanih kazni mogu dosegnuti najmanje 10.000.000 EUR ili 2 posto ukupnog svjetskog godišnjeg prometa, ovisno o tome što je veće. Za važne subjekte osnovica je najmanje 7.000.000 EUR ili 1,4 posto prometa, ovisno o tome što je veće.

GDPR dodaje drukčiju perspektivu. Povreda osobnih podataka nije ograničena na potvrđeno javno otkrivanje ili ukradene datoteke. Ona uključuje slučajno ili nezakonito uništenje, gubitak, izmjenu, neovlašteno otkrivanje osobnih podataka ili neovlašten pristup osobnim podacima. Voditelji obrade moraju procijeniti rizik za pojedince i dokazati odgovornost za odluku o obavješćivanju ili neobavješćivanju.

ISO/IEC 27001:2022 tim obvezama daje dokaznu osnovu. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije svoj kontekst, zahtjeve zainteresiranih strana, opseg, sučelja i ovisnosti. Točke 5.1 do 5.3 zahtijevaju predanost vodstva, politiku, uloge, odgovornosti i izvješćivanje. Točke 6.1.1 do 6.1.3 zahtijevaju planiranje temeljeno na riziku, procjenu rizika, obradu rizika i Izjavu o primjenjivosti. Točke 8.1 do 8.3 zahtijevaju operativnu kontrolu, kontrolu promjena, čuvanje dokaza i preispitivanje kada se promijene uvjeti rizika. ISO/IEC 27001:2022

Kada se dogodi poziv zbog incidenta, pitanje ne bi trebalo biti: „Tko misli da je ovo kritično?” Trebalo bi biti: „Što naši odobreni kriteriji, pravni okidači, dokazi i pravila eskalacije zahtijevaju da učinimo sada?”

Jedan događaj, tri regulatorna sustava klasifikacije

DORA, NIS2 i GDPR ne koriste isti jezik za incidente. To je ključni razlog zbog kojeg se organizacije muče tijekom prvog sata.

DORA Article 17 zahtijeva od financijskih subjekata uspostavu procesa upravljanja incidentima povezanima s IKT-om koji otkriva, obrađuje i prijavljuje IKT incidente, evidentira incidente povezane s IKT-om i značajne kibernetičke prijetnje, rješava temeljne uzroke, koristi pokazatelje ranog upozorenja, kategorizira i klasificira incidente, dodjeljuje uloge, upravlja komunikacijama, eskalira velike incidente višem rukovodstvu i vraća sigurne operacije.

DORA Article 18 zahtijeva klasifikaciju primjenom kriterija kao što su pogođeni klijenti, pogođene druge ugovorne strane, transakcije, trajanje, nedostupnost, geografska rasprostranjenost, gubitak podataka koji utječe na dostupnost, autentičnost, cjelovitost ili povjerljivost, kritičnost pogođenih usluga i ekonomski učinak. DORA Article 19 zahtijeva prijavljivanje velikih incidenata povezanih s IKT-om i komunikaciju s klijentima kada su pogođeni njihovi financijski interesi.

NIS2 Article 23 definira značajan incident kao incident koji je prouzročio ili može prouzročiti ozbiljan operativni poremećaj ili financijski gubitak, ili je utjecao ili može utjecati na druge uzrokujući znatnu materijalnu ili nematerijalnu štetu. Zahtijeva rano upozorenje u roku od 24 sata od saznanja za značajan incident, obavijest o incidentu u roku od 72 sata, međurješća na zahtjev i završno izvješće u roku od jednog mjeseca od obavijesti o incidentu. Kada je primjenjivo, pogođeni primatelji usluga također moraju biti obaviješteni o mjerama ili pravnim sredstvima koje mogu poduzeti.

GDPR postavlja pitanje rizika za privatnost. Je li povreda sigurnosti uzrokovala uništenje, gubitak, izmjenu, neovlašteno otkrivanje osobnih podataka ili pristup osobnim podacima? Ako jest, voditelj obrade mora procijeniti rizik za prava i slobode fizičkih osoba. Ako je vjerojatno da će povreda prouzročiti rizik, nadzorno tijelo u pravilu mora biti obaviješteno u roku od 72 sata od saznanja. Ako je vjerojatno da će prouzročiti visok rizik, pogođene osobe možda treba obavijestiti bez nepotrebnog odgađanja.

Jedan incident stoga treba istodobnu klasifikaciju.

Za financijske subjekte DORA je sektorski specifičan pravni akt Unije za upravljanje IKT rizicima i obveze prijavljivanja incidenata koje se preklapaju s NIS2. To ne čini NIS2 nevažnim. NIS2 i dalje može biti relevantan za suradnju, tokove informacija, usluge izvan perimetra DORA-e, nefinancijske subjekte u grupi, usluge u oblaku, upravljane usluge i ugovorne obveze prema klijentima. Model ozbiljnosti treba evidentirati ne samo ishod nego i logiku primjenjivosti.

Clarysecov model: klasificirajte događaj, ne emociju

Clarysec polazi od kontrole ISO/IEC 27002:2022 5.25, procjene i odluke o događajima informacijske sigurnosti, kao sidra za usklađenost kroz više okvira. U Zenith Controls: The Cross-Compliance Guide Zenith Controls, ova je tema mapirana kroz unos „Procjena i odluka o događajima informacijske sigurnosti” za kontrolu 5.25, uz potporu unosa „Planiranje i priprema upravljanja incidentima informacijske sigurnosti” za kontrolu 5.24 i „Prikupljanje dokaza” za kontrolu 5.28.

Najvažniji trenutak usklađenosti često nije obuzdavanje. To je raskrižje na kojem sigurnosni događaj postaje regulatorni incident ili se dokazivo evidentira kao događaj niže ozbiljnosti.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint opisuje taj trenutak u fazi Kontrole u praksi, korak 23:

„Nije svaka anomalija katastrofa. Ne znači svako upozorenje kompromitaciju. U stvarnom svijetu sigurnosni timovi i poslovne jedinice zatrpani su šumom, pokušajima prijave, anomalijama u dnevničkim zapisima, manjim kršenjima politike i neodobrenim IT aktivnostima. Pravi izazov nije samo u otkrivanju, nego u razlikovanju bezopasnoga od štetnoga i u prepoznavanju onoga što zahtijeva eskalaciju.”

Ta rečenica sažima operativni problem. SIEM upozorenje ne znači automatski veliki incident prema DORA. Privremeni prekid usluge ne znači automatski značajan incident prema NIS2. Sumnjiv upit prema bazi podataka ne znači automatski prijavljivu povredu prema GDPR-u. Svaki od tih događaja može postati prijavljiv ovisno o utjecaju, opsegu, podacima, pogođenim stranama i dokazima.

Zenith Blueprint, faza Upravljanje rizicima, korak 10, također preporučuje da se definicije utjecaja prilagode poslovnoj veličini i regulatornoj izloženosti:

„Pri definiranju utjecaja razumno je povezati razine s vašom konkretnom poslovnom veličinom. Primjerice, ‘Veliki financijski učinak = gubitak > 100.000 USD’ (prilagodite svojem kontekstu). Uzmite u obzir i regulatorni učinak: primjerice, povreda osobnih podataka može automatski biti ‘velika’ ili ‘ozbiljna’ zbog kazni i zahtjeva obavješćivanja prema GDPR-u, čak i ako izravan financijski gubitak nije jasan.”

To je načelo oblikovanja za klasifikaciju ozbiljnosti incidenata u 2026.: ozbiljnost je poslovni utjecaj plus pravni utjecaj plus pouzdanost dokaza.

Praktična taksonomija ozbiljnosti incidenata za DORA, NIS2 i GDPR

Dokaziva taksonomija treba razdvojiti internu ozbiljnost od regulatorne klasifikacije. Interna ozbiljnost određuje hitnost odgovora, raspodjelu resursa i eskalaciju prema izvršnom rukovodstvu. Regulatorna klasifikacija određuje obavješćivanje, pravni pregled i vanjsku komunikaciju.

Interna razina ozbiljnosti nije konačan regulatorni odgovor. Ona je način rada. Događaj SEV 3 može postati prijavljiv prema GDPR-u nakon pregleda dnevničkih zapisa. Prekid usluge SEV 2 možda nije veliki incident prema DORA ako pragovi utjecaja nisu dosegnuti. Ransomware incident SEV 1 može istodobno aktivirati DORA, NIS2, GDPR, ugovore s klijentima i koordinaciju s tijelima kaznenog progona.

Detaljnija klasifikacijska matrica pomaže timu prijeći s upozorenja na djelovanje.

Model treba biti ugrađen u politiku, a ne prepušten najglasnijoj osobi na kriznom pozivu. Politika odgovora na incidente za MSP Politika odgovora na incidente za MSP, Zahtjevi upravljanja, točka 5.3.1, navodi:

„Glavni direktor, uz doprinos pružatelja IT usluga, mora klasificirati sve incidente prema ozbiljnosti u roku od jednog sata od obavijesti.”

Ista politika za MSP, Obrada rizika i iznimke, točka 7.4.1, dodaje:

„Kada su uključeni podaci klijenata, glavni direktor mora procijeniti pravne obveze obavješćivanja na temelju primjenjivosti GDPR-a, NIS2 ili DORA.”

Za veće organizacije, korporativna Politika odgovora na incidente Politika odgovora na incidente, Zahtjevi upravljanja, točka 5.3, formalizira isti koncept:

„Klasifikacija incidenata mora slijediti višerazinski model:”

Jezik politike važan je zato što će regulatori i revizori pitati jesu li kriteriji klasifikacije postojali prije incidenta. Matrica izrađena naknadno slab je dokaz. Matrica koja je odobrena, obuhvaćena obukom, uvježbana i dosljedno korištena jest dokaziva.

Zapisnik odluka: najvažniji dokazni artefakt

Kada revizori, regulatori ili članovi upravljačkog tijela pregledavaju incident, rijetko pitaju samo: „Što se dogodilo?” Pitaju: „Kada ste znali, tko je odlučio, na temelju kojih dokaza i zašto niste ranije obavijestili?”

Zato Clarysec preporučuje zapisnik odluka o ozbiljnosti za svaki događaj SEV 3 i viši te za svaki događaj koji uključuje osobne podatke, kritične usluge, financijske klijente, upravljane usluge, infrastrukturu u oblaku ili prekogranični učinak.

To se izravno mapira na ISO/IEC 27001:2022. Točka 8.1 zahtijeva da procesi budu planirani, implementirani i kontrolirani te da se čuva dovoljno dokumentiranih informacija za dokaz da su se odvijali kako je planirano. Točke 8.2 i 8.3 zahtijevaju preispitivanje kada nastupe značajne promjene i čuvanje dokaza obrade rizika. Kontrole iz Priloga A A.5.24 do A.5.28 čine okosnicu upravljanja incidentima: planiranje i priprema, procjena događaja i odluka, odgovor, učenje iz incidenata i prikupljanje dokaza.

Politika zaštite podataka i privatnosti za MSP Politika zaštite podataka i privatnosti za MSP, Provedba i usklađenost, točka 8.3.2, podupire GDPR stranu modela:

„Koordinator za privatnost utvrdit će ozbiljnost, pokrenuti radnje obuzdavanja i dokumentirati predmet.”

Procjena privatnosti ne smije početi tek kada regulatorni rok postane neugodan. Ona pripada u radni tok trijaže.

Praktični primjer: klasifikacija Sarahina API incidenta

Vratimo se na FinScale. Riječ je o B2B fintech platformi koja koristi infrastrukturu u oblaku, vanjskog pružatelja analitike prijevara i pružatelja upravljanih sigurnosnih usluga. Za neke aktivnosti FinScale je financijski subjekt obuhvaćen DORA-om. Ujedno je pružatelj digitalnih usluga s operacijama relevantnima za NIS2 u jednoj državi članici. Obrađuje osobne podatke korisnika kao voditelj obrade za usluge računa i kao izvršitelj obrade za neke korporativne klijente.

U 02:17 otkriven je abnormalan API promet. U 02:35 otvorena je prijava incidenta. U 03:00 Sarah dovršava početnu trijažu s voditeljem incidenta.

Prvo se utvrđuje interna ozbiljnost. Incident je utjecao na dostupnost korisničke nadzorne ploče tijekom 19 minuta, uključivao je sumnjive pristupne tokene i zahvatio kritičnu funkciju dostupnu korisnicima. Klasificiran je kao SEV 3 Umjereno do potvrde, uz eskalaciju voditelju incidenta, koordinatoru za privatnost, pravnom savjetniku i vlasniku usluge.

Drugo, dovršava se provjera DORA. Tim provjerava pogođene klijente, druge ugovorne strane, transakcije, trajanje, nedostupnost, geografsku rasprostranjenost, gubitak podataka, kritičnost i ekonomski učinak. Nisu potvrđene neuspjele ili izmijenjene transakcije. Nedostupnost je ograničena. Gubitak podataka nije dokazan. Međutim, budući da mogu biti pogođeni komponenta kritične financijske usluge i financijski interesi klijenata, incident ostaje pod praćenjem prema DORA-i i može biti reklasificiran.

Treće, evidentira se provjera NIS2. Tim bilježi da je DORA primarni sektorski režim prijavljivanja za obveze obuhvaćenog financijskog subjekta. Također provjerava utječe li incident na usluge ili korisnike izvan perimetra DORA-e. U ovoj fazi nije potvrđen ozbiljan operativni poremećaj ni znatna šteta.

Četvrto, pokreće se provjera GDPR-a. Sumnjivi tokeni možda su omogućili pristup podacima korisničke nadzorne ploče. Koordinator za privatnost dokumentira kategorije podataka, pogođene korisnike, opseg tokena, pregledane dnevničke zapise, je li podacima pristupljeno ili su izvezeni te zaštitne mjere kao što su istek tokena i kontrole pristupa.

Do 04:20 analiza dnevničkih zapisa pokazuje da su dva tokena korištena za pristup metapodacima nadzorne ploče za 41 korisnika, uključujući imena, ID-jeve računa i status transakcija, ali bez vjerodajnica za plaćanje ili identifikacijskih dokumenata. Tim ažurira incident na SEV 2 Veliko jer je pogođena povjerljivost osobnih podataka i možda će biti potrebna komunikacija s korisnicima. DPO procjenjuje rizik prema GDPR-u za pojedince. Odluka prema DORA ponovno se razmatra na temelju utjecaja na klijente, utjecaja na transakcije i ekonomskog učinka.

To je praktična vrijednost modela. Početna klasifikacija nije konačan pravni zaključak. To je odluka utemeljena na dokazima koja se može ažurirati kako se činjenice razvijaju.

Zapisivanje događaja, praćenje i forenzički dokazi: dokazni sloj

Model ozbiljnosti bez dokaza samo je mišljenje iz sastanka. Očekivanje za 2026. jest da klasifikaciju podupiru dnevnički zapisi, praćenje, očuvani artefakti i lanac nadzora.

Politika zapisivanja događaja i praćenja za MSP Politika zapisivanja događaja i praćenja za MSP, Provedba i usklađenost, točka 8.3.4, navodi:

„Istrage povreda moraju biti poduprte odgovarajućim dnevničkim zapisima radi ispunjavanja načela odgovornosti prema GDPR-u i DORA.”

Forenzičko postupanje jednako je važno. Politika prikupljanja dokaza i forenzike za MSP Politika prikupljanja dokaza i forenzike za MSP, Zahtjevi upravljanja, točka 5.3.1, zahtijeva:

„Za svaki incident mora se voditi jednostavan dnevnik lanca nadzora (npr. Excel datoteka ili predložak dokumenta).”

Za korporativna okruženja, Politika prikupljanja dokaza i forenzike Politika prikupljanja dokaza i forenzike, Zahtjevi upravljanja, točka 5.5, zahtijeva:

„Svi prikupljeni dokazi moraju biti jedinstveno identificirani, označeni i pohranjeni u sigurnom repozitoriju s:”

Zenith Blueprint, faza Kontrole u praksi, korak 23, objašnjava zašto je to važno za kontrolu ISO/IEC 27002:2022 5.28:

„Kada se dogodi incident informacijske sigurnosti, jedan od najkritičnijih, a često zanemarenih elemenata odgovora jesu dokazi. Ne dnevnički zapisi, ne snimke zaslona, ne slobodni opisi, nego pravilno očuvani dokazi s očuvanim lancem nadzora i otpornošću na neovlaštene izmjene.”

Praktičan paket dokaza za veliki ili potencijalno prijavljivi incident trebao bi uključivati:

• Prijavu incidenta i vremenski slijed
• Zapisnik odluka o ozbiljnosti i povijest reklasifikacije
• SIEM upozorenja, EDR upozorenja, dnevničke zapise u oblaku i dnevničke zapise identiteta
• Dnevničke zapise pristupa podacima i izvoza podataka
• Unose u popisu pogođene imovine i usluga
• Procjenu utjecaja na korisnike, transakcije i geografiju
• Radni list za provjeru DORA, NIS2 i GDPR
• Procjenu DPO-a ili pravnih poslova
• Odobrenja komunikacija i poslane poruke
• Zapis lanca nadzora
• Analizu temeljnog uzroka
• Korektivne radnje i naučene lekcije

Ovaj paket dokaza također podupire kontrole iz Priloga A norme ISO/IEC 27001:2022: A.8.15 zapisivanje događaja, A.8.16 aktivnosti praćenja, A.5.28 prikupljanje dokaza, A.5.27 učenje iz incidenata informacijske sigurnosti, A.5.31 pravne, zakonske, regulatorne i ugovorne zahtjeve te A.5.34 privatnost i zaštitu osobnih podataka koji omogućuju identifikaciju osobe.

Mapiranje usklađenosti kroz više okvira: izgradite jednom, odgovorite mnogim revizorima

Najjači modeli ozbiljnosti incidenata izrađuju se jednom i mapiraju više puta. Zenith Controls osmišljen je kao kompas za usklađenost kroz više okvira za ovaj rad. Za ovu temu ključni unosi ISO/IEC 27002:2022 jesu 5.24 planiranje i priprema upravljanja incidentima informacijske sigurnosti, 5.25 procjena i odluka o događajima informacijske sigurnosti, 5.26 odgovor na incidente informacijske sigurnosti, 5.27 učenje iz incidenata informacijske sigurnosti i 5.28 prikupljanje dokaza.

Te se kontrole prirodno povezuju sa sustavom upravljanja prema ISO/IEC 27001:2022. Točke 4, 5, 6 i 8 definiraju opseg, vodstvo, kriterije rizika, obradu rizika i operativne dokaze. ISO/IEC 27002:2022 daje jezik za provedbu kontrola. Razmišljanje o neprekidnosti poslovanja u stilu ISO 22301 podupire pragove poremećaja, prioritete oporavka i krizno upravljanje. Prakse upravljanja incidentima u stilu ISO/IEC 27035 podupiru strukturirano otkrivanje, prijavljivanje, procjenu, odgovor i učenje. Upravljanje privatnošću u stilu ISO/IEC 27701 podupire uloge u povredi osobnih podataka, razmatranja voditelja obrade i izvršitelja obrade, dokaze privatnosti i odgovornost.

Isti se model mapira na NIST Cybersecurity Framework 2.0. Funkcija GOVERN zahtijeva da pravne, regulatorne i ugovorne obveze te obveze u području privatnosti i građanskih sloboda budu razumljive i upravljane. Također očekuje definiranje apetita za rizik, uloga, ovlasti, politika i nadzora. Funkcije DETECT, RESPOND i RECOVER podupiru trijažu, analizu, eskalaciju, obuzdavanje, vraćanje podataka, komunikacije i poboljšanje.

Prednost je praktična. Kada nadzorno tijelo prema DORA zatraži obrazloženje velikog incidenta povezanog s IKT-om, nadležno tijelo za NIS2 pita o odluci o ranom upozorenju u roku od 24 sata, tijelo za zaštitu podataka pita zašto je obavijest prema GDPR-u podnesena ili nije podnesena, a ISO revizor pita je li ISMS radio kako je planirano, organizacija može odgovoriti iz istog skupa dokaza.

Kako će revizori i regulatori testirati vaš model

Revizor prema ISO/IEC 27001:2022 obično će početi od opsega i pravnih zahtjeva. Pitat će jesu li DORA, NIS2, GDPR, ugovori s klijentima i obveze trećih strana u području IKT-a identificirani kao zahtjevi zainteresiranih strana. Zatim će slijediti trag prema kriterijima rizika, Izjavi o primjenjivosti, postupcima za incidente, operativnim zapisima i čuvanju dokaza. Žele dokaz da postupak klasifikacije nije izmišljen tijekom incidenta.

Nadzorno tijelo prema DORA ili tim unutarnje revizije tražit će petlju životnog ciklusa: proces upravljanja incidentima, pokazatelje ranog upozorenja, kriterije klasifikacije, eskalaciju velikih incidenata, komunikaciju s klijentima, temeljni uzrok, konačne brojke utjecaja, testiranje otpornosti i nadzor upravljačkog tijela. Također će pitati jesu li razmotrene ovisnosti o trećim stranama u području IKT-a, osobito kada su uključeni oblak, SaaS, upravljana sigurnost ili pružatelji vanjsko ugovorenih usluga.

Revizor ili nadležno tijelo usmjereno na NIS2 testirat će može li subjekt identificirati značajne incidente, ispuniti fazne rokove, komunicirati s pogođenim primateljima usluga i dostaviti dokaze o procjeni prekograničnog učinka. Povezat će postupanje s incidentima s mjerama upravljanja rizikom iz Article 21, uključujući neprekidnost poslovanja, krizno upravljanje, sigurnost opskrbnog lanca, kontrolu pristupa, upravljanje imovinom i osposobljavanje.

DPO prema GDPR-u ili nadzorno tijelo ispitat će je li organizacija identificirala osobne podatke, uloge, ispitanike, kategorije, pogođene sustave, vrstu povrede i rizik za pojedince. Testirat će može li voditelj obrade dokazati odgovornost i jesu li obavijesti izvršitelja obrade voditeljima obrade bile pravodobne i potpune.

Revizor u stilu ISACA ili COBIT 2019 usredotočit će se na dokaze upravljanja. Tko je odobrio taksonomiju ozbiljnosti? Tko je vlasnik rizika? Koje se metrike prijavljuju upravi? Kako se obrađuju iznimke? Kako se naučene lekcije pretvaraju u poboljšanja kontrola?

Uobičajeni obrasci neuspjeha u klasifikaciji incidenata

Prvi je neuspjeh razmišljanje u jednoj oznaci. Timovi klasificiraju događaj kao visok, srednji ili nizak, ali nikada odvojeno ne procijene okidače za DORA, NIS2 i GDPR. Rezultat je oznaka ozbiljnosti koja ne može objasniti odluku o prijavi.

Drugi je neuspjeh pristranost prema potvrđenoj povredi. Timovi čekaju apsolutni dokaz iznošenja podataka prije uključivanja privatnosti ili pravnih poslova. Procjena povrede prema GDPR-u često počinje mogućim neovlaštenim pristupom, gubitkom, izmjenom ili otkrivanjem, a ne samo potvrđenom objavom podataka.

Treći je neuspjeh zbrka oko rokova. Rokovi prema NIS2 i GDPR ovise o saznanju i procjeni. Ako prijava incidenta ne bilježi vrijeme saznanja, vrijeme klasifikacije i vrijeme eskalacije, organizacija može teško dokazati pravodobnost.

Četvrti je neuspjeh forenzika nakon čišćenja. Inženjeri rotiraju ključeve, ponovno izgrađuju poslužitelje i brišu privremene dokaze prije nego što se aktivira istražni pristup. Time se može uništiti dokaz potreban za regulatorni, ugovorni ili pravni pregled.

Peti je neuspjeh sljepoća za dobavljače. DORA, NIS2 i NIST CSF 2.0 naglašavaju rizik trećih strana i opskrbnog lanca. Ako su pružatelj usluga u oblaku, pružatelj upravljanih usluga, procesor plaćanja, pružatelj identiteta ili SaaS dobavljač dio lanca incidenta, model klasifikacije mora uključivati utjecaj dobavljača i ugovorne obveze obavješćivanja.

Clarysecov kontrolni popis za implementaciju u 2026.

Za uspostavu dokazivog modela klasifikacije ozbiljnosti incidenata Clarysec preporučuje sljedeći slijed:

1. Potvrdite regulatornu primjenjivost kroz DORA, NIS2, GDPR, ugovore s klijentima i sektorska pravila.
2. Ažurirajte opseg ISMS-a i zahtjeve zainteresiranih strana prema ISO/IEC 27001:2022.
3. Definirajte interne razine ozbiljnosti s mjerljivim pragovima za nedostupnost, podatke, korisnike, geografiju, financijski gubitak i kritičnost.
4. Dodajte odvojena pitanja za provjeru DORA, NIS2 i GDPR u radni tok prijave incidenta.
5. Definirajte okidače eskalacije za voditelja incidenta, DPO-a, pravne poslove, više rukovodstvo i upravljačko tijelo.
6. Izradite predložak zapisnika odluka o ozbiljnosti.
7. Povežite klasifikaciju s prikupljanjem dokaza i postupcima lanca nadzora.
8. Provjerite obuhvat zapisivanja događaja za identitet, oblak, aplikacije, baze podataka, mrežu i događaje dobavljača.
9. Provedite stolne vježbe za scenarije velikog incidenta prema DORA, značajnog incidenta prema NIS2 i povrede prema GDPR-u.
10. Ugradite naučene lekcije u obradu rizika, Izjavu o primjenjivosti, osposobljavanje i testiranje otpornosti.

Zenith Blueprint, faza Kontrole u praksi, korak 16, naglašava ljudsku stranu ovog modela: prijave treba evidentirati, trijažirati, eskalirati kroz plan odgovora na incidente, a čak i manje događaje treba pratiti jer trendovi otkrivaju slabosti kontrola. Promiče kulturu prijavljivanja s niskim pragom: „Ako ste u dvojbi, prijavite.”

Ta je kulturna točka ključna. Model ozbiljnosti ne uspijeva ako zaposlenici odgađaju prijavljivanje jer se boje pretjerane reakcije. Cilj su brzo prijavljivanje, disciplinirana trijaža i dokaziva klasifikacija.

Pretvorite neizvjesnost incidenta u dokaze spremne za reviziju

U 2026. klasifikacija ozbiljnosti incidenata više nije odluka isključivo SOC-a. To je regulirani proces upravljanja koji mora povezati kriterije velikog incidenta povezanog s IKT-om prema DORA, pragove značajnog incidenta prema NIS2, rizik povrede prema GDPR-u i dokaze prema ISO/IEC 27001:2022.

Organizacije koje najbolje postupaju tijekom incidenata neće biti one s najdebljim registratorom za odgovor. Bit će to one koje mogu brzo odgovoriti na četiri pitanja i kasnije dokazati svaki odgovor:

• Što se dogodilo?
• Koliko je ozbiljno?
• Koje se regulatorne obveze mogu primijeniti?
• Koji dokazi podupiru odluku?

Clarysec pomaže organizacijama izgraditi taj most kroz predloške politika, taksonomije ozbiljnosti, zapisnike odluka, scenarije stolnih vježbi i mapiranja usklađenosti kroz više okvira. Počnite s politikama za incidente, provjerite svoje kriterije rizika u Zenith Blueprint Zenith Blueprint i upotrijebite Zenith Controls Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 i 5.28 kroz DORA, NIS2, GDPR, NIST CSF i revizijska očekivanja.

Ako vaš tim ne može odgovoriti na pitanje „Je li ovo veliki incident prema DORA, značajan incident prema NIS2 ili prijavljivo prema GDPR-u?” u prvom satu, sljedeći korak nije još jedan generički plan odgovora na incidente. Sljedeći korak je dokaziv operativni model klasifikacije ozbiljnosti incidenata, testiran prije sljedećeg poziva u 02:17.

Spremni ste zamijeniti paniku procesom? Preuzmite Clarysecove predloške politika odgovora na incidente i prikupljanja dokaza, pregledajte svoju trenutačnu taksonomiju ozbiljnosti u odnosu na Zenith Blueprint ili zatražite Clarysecovu procjenu spremnosti kako biste izgradili model klasifikacije incidenata prema DORA, NIS2, GDPR i ISO/IEC 27001 spreman za reviziju.