Razvrščanje resnosti incidentov za DORA, NIS2 in GDPR

Klic ob incidentu ob 02:17, ki postane regulativna odločitev

Ob 02:17 v četrtek zjutraj Sarah, vodja informacijske varnosti pri FinScale, vidi prvo opozorilo: nenormalen promet API, porast neuspelih avtentikacij in zakasnitev plačilne nadzorne plošče nad 3000 ms. V nekaj minutah služba za podporo strankam poroča o napakah pri statusu plačil. Ponudnik storitev v oblaku sporoči, da ni incidenta na ravni celotne platforme. SOC zazna sumljive dostopne žetone iz dveh geografskih regij. Produktna ekipa potrdi, da je nadzorna plošča po 19 minutah ponovno na voljo, vendar je dvanajst strank že odprlo zahtevke.

Do 03:05 je Sarah na kriznem konferenčnem klicu z vodjo incidenta, pravnim svetovalcem, koordinatorjem za zasebnost, vodjo operacij v oblaku in izvršnim sponzorjem. Tehnično vprašanje je razmeroma jasno: kaj se je zgodilo s prehodom API? Regulativna vprašanja so zahtevnejša:

1. Ali gre za večji incident, povezan z IKT, po DORA?
2. Ali gre za pomemben incident po NIS2?
3. Ali gre za kršitev varstva osebnih podatkov po GDPR, ki zahteva obveščanje?
4. Ali lahko organizacija dokaže, kako je prišla do teh odgovorov?

Napačen odgovor lahko povzroči regulativno izpostavljenost. Počasen odgovor lahko pomeni zamujen rok za poročanje. Nedokumentiran odgovor lahko več mesecev pozneje pade na presoji ISO/IEC 27001:2022.

To je izziv odzivanja na incidente v letu 2026. Številne organizacije imajo načrt odzivanja na incidente, forenzične postopke, priročnike za zasebnost in predloge za krizno komuniciranje. Manj jih ima dokazljivo utemeljen model razvrščanja resnosti incidentov, ki hrupen varnostni dogodek pretvori v dokumentirano odločitev glede na pričakovana dokazila po DORA, NIS2, GDPR in ISO/IEC 27001:2022.

Rešitev niso trije ločeni postopki triaže. Rešitev je en upravljan model resnosti z ločenimi regulativnimi razširitvami, merljivimi pragovi, pravili eskalacije, dnevniki odločitev in zahtevami za zbiranje dokazil. V praksi resnost incidenta ne sme biti oznaka, izbrana pod pritiskom. Biti mora nadzorovana poslovna odločitev, ki vzdrži pregled regulatorjev, presojevalcev, članov upravljalnega organa, strank in pooblaščene osebe za varstvo podatkov (DPO).

Zakaj je razvrščanje resnosti incidentov zdaj kontrola na ravni upravljalnega organa

Razvrščanje incidentov je bilo nekoč pretežno tehnično: resnost zlonamerne programske opreme, prizadeti gostitelji, izkoriščene ranljivosti in vprašanje, ali je prišlo do eksfiltracije podatkov. Leta 2026 je to tudi pravno, finančno, družbeno in pogodbeno vprašanje.

DORA digitalno operativno odpornost postavlja kot obveznost upravljanja za finančne subjekte. Od upravljalnega organa se pričakuje, da opredeli, odobri in nadzira okvir upravljanja IKT-tveganj ter zanj ostane odgovoren. To vključuje neprekinjeno poslovanje na področju IKT, načrte odziva in obnovitve, kanale za poročanje o večjih incidentih, tveganja tretjih oseb na področju IKT in pridobljene izkušnje.

NIS2 zvišuje upravljavska pričakovanja za bistvene in pomembne subjekte. Article 20 zahteva, da upravljalni organi odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo njihovo izvajanje in se udeležujejo usposabljanja. Neuspehe pri upravljanju tveganj in poročanju o incidentih povezuje tudi z resnimi nadzornimi posledicami. Za bistvene subjekte lahko izhodiščne najvišje upravne globe dosežejo najmanj 10.000.000 EUR ali 2 odstotka skupnega svetovnega letnega prometa, kar je višje. Za pomembne subjekte je izhodišče najmanj 7.000.000 EUR ali 1,4 odstotka prometa, kar je višje.

GDPR dodaja drugačen pogled. Kršitev varstva osebnih podatkov ni omejena na potrjeno javno razkritje ali ukradene datoteke. Vključuje nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih. Upravljavci morajo oceniti tveganje za posameznike in dokazati odgovornost za odločitev, ali bodo obvestilo podali ali ne.

ISO/IEC 27001:2022 tem obveznostim zagotavlja dokazno podlago. Klavzule 4.1 do 4.4 od organizacije zahtevajo razumevanje konteksta, zahtev zainteresiranih strani, obsega, vmesnikov in odvisnosti. Klavzule 5.1 do 5.3 zahtevajo zavezanost vodstva, politiko, vloge, odgovornosti in poročanje. Klavzule 6.1.1 do 6.1.3 zahtevajo načrtovanje na podlagi tveganj, oceno tveganja, obravnavo tveganja in Izjavo o uporabnosti. Klavzule 8.1 do 8.3 zahtevajo operativni nadzor, nadzor sprememb, hranjena dokazila in ponovno oceno ob spremembi pogojev tveganja. ISO/IEC 27001:2022

Ko pride do klica ob incidentu, vprašanje ne sme biti: »Kdo meni, da je to kritično?« Vprašanje mora biti: »Kaj nam naša odobrena merila, pravni sprožilci, dokazila in pravila eskalacije nalagajo zdaj?«

En dogodek, trije regulativni sistemi razvrščanja

DORA, NIS2 in GDPR za incidente ne uporabljajo istega jezika. To je glavni razlog, da imajo organizacije težave v prvi uri.

DORA Article 17 zahteva, da finančni subjekti vzpostavijo proces upravljanja incidentov, povezanih z IKT, ki zaznava, upravlja in priglaša incidente IKT, evidentira incidente, povezane z IKT, in pomembne kibernetske grožnje, obravnava temeljne vzroke, uporablja indikatorje zgodnjega opozarjanja, kategorizira in razvršča incidente, dodeljuje vloge, upravlja komunikacije, eskalira večje incidente višjemu vodstvu in ponovno vzpostavi varno poslovanje.

DORA Article 18 zahteva razvrščanje z uporabo meril, kot so prizadete stranke, prizadete nasprotne stranke, transakcije, trajanje, čas izpada, geografska razširjenost, izguba podatkov, ki vpliva na razpoložljivost, avtentičnost, celovitost ali zaupnost, kritičnost prizadetih storitev in gospodarski vpliv. DORA Article 19 zahteva poročanje o večjih incidentih, povezanih z IKT, in komuniciranje s strankami, kadar so prizadeti njihovi finančni interesi.

NIS2 Article 23 opredeljuje pomemben incident kot incident, ki je povzročil ali lahko povzroči hude operativne motnje ali finančno izgubo, ali je vplival ali lahko vpliva na druge s povzročitvijo znatne materialne ali nematerialne škode. Zahteva zgodnje opozorilo v 24 urah od seznanitve s pomembnim incidentom, obvestilo o incidentu v 72 urah, vmesna poročila na zahtevo in končno poročilo v enem mesecu od obvestila o incidentu. Kadar je ustrezno, je treba prizadete prejemnike storitev obvestiti tudi o ukrepih ali pravnih sredstvih, ki jih lahko sprejmejo.

GDPR zastavlja vprašanje tveganja za zasebnost. Ali je varnostna kršitev povzročila uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih? Če da, mora upravljavec oceniti tveganje za pravice in svoboščine posameznikov. Če je verjetno, da bo kršitev povzročila tveganje, je treba nadzorni organ praviloma obvestiti v 72 urah od seznanitve. Če je verjetno, da bo povzročila veliko tveganje, bo morda treba brez nepotrebnega odlašanja obvestiti prizadete posameznike.

Posamezen incident zato potrebuje sočasno razvrščanje.

Za finančne subjekte je DORA sektorsko specifičen pravni akt Unije za upravljanje IKT-tveganj in obveznosti poročanja o incidentih, ki se prekrivajo z NIS2. To ne pomeni, da je NIS2 nepomembna. Še vedno je lahko pomembna za sodelovanje, tokove informacij, storitve zunaj obsega DORA, nefinančne subjekte v skupini, storitve v oblaku, upravljane storitve in pogodbene obveznosti do strank. Model resnosti mora evidentirati ne le izid, temveč tudi logiko uporabljivosti.

Clarysecov model: razvrstite dogodek, ne čustev

Clarysec izhaja iz kontrole ISO/IEC 27002:2022 5.25, presoja in odločanje o dogodkih informacijske varnosti, kot sidra za čezokvirno skladnost. V Zenith Controls: The Cross-Compliance Guide Zenith Controls je ta tema preslikana prek vnosa »Presoja in odločanje o dogodkih informacijske varnosti« za kontrolo 5.25, podprta z »Načrtovanje in priprava upravljanja incidentov informacijske varnosti« za kontrolo 5.24 in »Zbiranje dokazil« za kontrolo 5.28.

Najpomembnejši trenutek skladnosti pogosto ni zajezitev. To je razpotje, na katerem varnostni dogodek postane regulativni incident ali pa je dokazljivo utemeljeno evidentiran kot dogodek nižje resnosti.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ta trenutek opisuje v fazi Controls in Action, korak 23:

»Ni vsaka anomalija katastrofa. Vsako opozorilo ne pomeni kompromitacije. V resničnem svetu so varnostne ekipe in poslovne enote preplavljene s šumom, poskusi prijave, anomalijami v dnevnikih, manjšimi kršitvami politike in dejavnostjo shadow IT. Pravi izziv ni samo zaznavanje, temveč razlikovanje neškodljivega od škodljivega in razumevanje, kaj zahteva eskalacijo.«

Ta stavek zajame operativni problem. Opozorilo SIEM ne pomeni samodejno večjega incidenta po DORA. Začasen izpad ne pomeni samodejno pomembnega incidenta po NIS2. Sumljiva poizvedba v podatkovno bazo ne pomeni samodejno dogodka, ki ga je treba prijaviti po GDPR. Vsak lahko postane prijavljiv glede na vpliv, obseg, podatke, prizadete strani in dokazila.

Zenith Blueprint, faza Risk Management, korak 10, prav tako priporoča, da se opredelitve vpliva prilagodijo obsegu poslovanja in regulativni izpostavljenosti:

»Pri opredeljevanju vpliva je smiselno ravni povezati s konkretnim obsegom vašega poslovanja. Na primer: ‘Velik finančni vpliv = izguba > 100k USD’ (prilagodite svojemu kontekstu). Upoštevajte tudi regulativni vpliv: kršitev varstva osebnih podatkov je lahko na primer samodejno ‘velika’ ali ‘huda’ zaradi glob GDPR in zahtev glede obveščanja, tudi če neposredna finančna izguba ni jasna.«

To je načelo zasnove za razvrščanje resnosti incidentov v letu 2026: resnost je poslovni vpliv plus pravni vpliv plus zaupanje v dokazila.

Praktična taksonomija resnosti incidentov za DORA, NIS2 in GDPR

Dokazljivo utemeljena taksonomija mora ločiti interno resnost od regulativne razvrstitve. Interna resnost usmerja nujnost odziva, dodeljevanje virov in eskalacijo izvršnemu vodstvu. Regulativna razvrstitev usmerja obveščanje, pravni pregled in zunanjo komunikacijo.

Raven interne resnosti ni končni regulativni odgovor. Je način delovanja. Dogodek SEV 3 lahko po pregledu dnevnikov postane prijavljiv po GDPR. Izpad SEV 2 morda ni večji incident po DORA, če pragovi vpliva niso doseženi. Incident izsiljevalske programske opreme SEV 1 lahko hkrati sproži DORA, NIS2, GDPR, pogodbe s strankami in usklajevanje z organi pregona.

Podrobnejša matrika razvrščanja ekipi pomaga preiti od opozorila k ukrepanju.

Model mora biti vgrajen v politiko, ne prepuščen najmočnejšemu glasu na kriznem konferenčnem klicu. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Zahteve upravljanja, klavzula 5.3.1, določa:

»Generalni direktor mora ob prispevku ponudnika IT v eni uri od obvestila razvrstiti vse incidente po resnosti.«

Ista politika SME, Obravnava tveganj in izjeme, klavzula 7.4.1, dodaja:

»Kadar so vključeni podatki strank, mora generalni direktor oceniti zakonske obveznosti obveščanja na podlagi uporabljivosti GDPR, NIS2 ali DORA.«

Za večje organizacije enterprise Incident Response Policy Incident Response Policy, Zahteve upravljanja, klavzula 5.3, formalizira isti koncept:

»Razvrščanje incidentov mora slediti večstopenjskemu modelu:«

Jezik politike je pomemben, ker bodo regulatorji in presojevalci vprašali, ali so merila razvrščanja obstajala pred incidentom. Matrika, izmišljena naknadno, je šibko dokazilo. Matrika, ki je odobrena, vključena v usposabljanja, preverjena z vajami in dosledno uporabljena, je dokazljivo utemeljena.

Dnevnik odločitev: najpomembnejši dokazni artefakt

Ko presojevalci, regulatorji ali člani upravljalnega organa pregledujejo incident, redko vprašajo samo: »Kaj se je zgodilo?« Vprašajo: »Kdaj ste vedeli, kdo je odločil, na podlagi katerih dokazil in zakaj niste obvestili prej?«

Zato Clarysec priporoča dnevnik odločitev o resnosti za vsak dogodek SEV 3 in višje ter za vsak dogodek, ki vključuje osebne podatke, kritične storitve, finančne stranke, upravljane storitve, infrastrukturo v oblaku ali čezmejni vpliv.

To se neposredno preslika v ISO/IEC 27001:2022. Klavzula 8.1 zahteva, da so procesi načrtovani, implementirani in nadzorovani ter da se hrani dovolj dokumentiranih informacij za dokaz, da so delovali po načrtu. Klavzuli 8.2 in 8.3 zahtevata ponovno oceno ob pomembnih spremembah in hrambo dokazil o obravnavi tveganja. Kontrole iz Priloge A A.5.24 do A.5.28 zagotavljajo hrbtenico upravljanja incidentov: načrtovanje in priprava, presoja in odločanje o dogodku, odziv, učenje iz incidentov in zbiranje dokazil.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Uveljavljanje in skladnost, klavzula 8.3.2, podpira GDPR stran modela:

»Koordinator za zasebnost bo določil resnost, začel ukrepe zajezitve in dokumentiral primer«

Presoja zasebnosti se ne sme začeti šele, ko regulativni rok postane neprijeten. Sodi v delovni tok triaže.

Praktični primer: razvrščanje Sarahinega API incidenta

Vrnimo se k FinScale. Gre za B2B fintech platformo, ki uporablja infrastrukturo v oblaku, zunanjega ponudnika analitike goljufij in ponudnika upravljanih varnostnih storitev. Za nekatere dejavnosti je finančni subjekt, zajet z DORA. Je tudi ponudnik digitalnih storitev z operacijami, relevantnimi za NIS2, v eni državi članici. Osebne podatke strank obdeluje kot upravljavec za storitve računov in kot obdelovalec za nekatere poslovne stranke.

Ob 02:17 je zaznan nenormalen promet API. Ob 02:35 je odprt zapis incidenta. Ob 03:00 Sarah z vodjo incidenta zaključi začetno triažo.

Najprej se določi interna resnost. Incident je 19 minut vplival na razpoložljivost nadzorne plošče za stranke, vključeval sumljive dostopne žetone in se dotaknil kritične funkcije, namenjene strankam. Do potrditve je razvrščen kot SEV 3 Zmerno, z eskalacijo vodji incidenta, koordinatorju za zasebnost, pravnemu svetovalcu in lastniku storitve.

Drugič, zaključeno je preverjanje DORA. Ekipa preveri prizadete stranke, nasprotne stranke, transakcije, trajanje, čas izpada, geografsko razširjenost, izgubo podatkov, kritičnost in gospodarski vpliv. Potrjenih ni neuspelih ali spremenjenih transakcij. Čas izpada je omejen. Izguba podatkov ni dokazana. Ker pa sta lahko prizadeti komponenta kritične finančne storitve in finančni interesi strank, incident ostane pod spremljanjem DORA in se lahko ponovno razvrsti.

Tretjič, evidentirano je preverjanje NIS2. Ekipa zabeleži, da je DORA primarni sektorsko specifični režim poročanja za obveznosti zajetega finančnega subjekta. Preveri tudi, ali incident vpliva na storitve ali stranke zunaj obsega DORA. V tej fazi ni potrjene hude operativne motnje ali znatne škode.

Četrtič, začne se preverjanje GDPR. Sumljivi žetoni so morda omogočili dostop do podatkov na nadzorni plošči strank. Koordinator za zasebnost dokumentira kategorije podatkov, prizadete uporabnike, obseg žetonov, pregledane dnevnike, ali so bili podatki ogledani ali izvoženi, ter varovalne ukrepe, kot so potek veljavnosti žetonov in kontrole dostopa.

Do 04:20 analiza dnevnikov pokaže, da sta bila dva žetona uporabljena za dostop do metapodatkov nadzorne plošče za 41 strank, vključno z imeni, identifikatorji računov in statusom transakcij, vendar brez plačilnih poverilnic ali osebnih dokumentov. Ekipa incident posodobi na SEV 2 Veliko, ker je bila prizadeta zaupnost osebnih podatkov in bo morda potrebna komunikacija s strankami. DPO oceni tveganje GDPR za posameznike. Odločitev DORA se ponovno pregleda na podlagi vpliva na stranke, transakcijskega vpliva in gospodarskega vpliva.

To je praktična vrednost modela. Začetna razvrstitev ni končni pravni sklep. Je odločitev, vodena z dokazili, ki se lahko posodablja, ko se razvijajo dejstva.

Beleženje, spremljanje in forenzična dokazila: dokazni sloj

Model resnosti brez dokazil je mnenje s sestanka. Pričakovanje v letu 2026 je, da razvrščanje podpirajo dnevniki, spremljanje, ohranjeni artefakti in veriga skrbništva.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Uveljavljanje in skladnost, klavzula 8.3.4, določa:

»Preiskave kršitev morajo biti podprte z ustreznimi dnevniki za izpolnitev načela odgovornosti po GDPR in DORA«

Enako pomembno je forenzično ravnanje. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Zahteve upravljanja, klavzula 5.3.1, zahteva:

»Za vsak incident je treba vzdrževati preprost dnevnik verige skrbništva (npr. Excelova datoteka ali predloga dokumenta).«

Za enterprise okolja Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Zahteve upravljanja, klavzula 5.5, zahteva:

»Vsa zbrana dokazila morajo biti enolično identificirana, označena in shranjena v varnem repozitoriju z:«

Zenith Blueprint, faza Controls in Action, korak 23, pojasnjuje, zakaj je to pomembno za kontrolo ISO/IEC 27002:2022 5.28:

»Ko pride do incidenta informacijske varnosti, je eden najkritičnejših, a pogosto spregledanih elementov odziva dokazilo. Ne dnevniki, ne posnetki zaslona, ne ohlapni opisi, temveč pravilno ohranjena dokazila, ki spoštujejo verigo skrbništva in so odporna proti poseganju.«

Praktični paket dokazil za večji ali potencialno prijavljiv incident mora vključevati:

• Zapis incidenta in časovnico
• Dnevnik odločitev o resnosti in zgodovino ponovne razvrstitve
• Opozorila SIEM, opozorila EDR, dnevnike v oblaku in dnevnike identitet
• Dnevnike dostopa do podatkov in dnevnike izvoza
• Vnose evidenc prizadetih sredstev in storitev
• Oceno vpliva na stranke, transakcije in geografijo
• Delovni list preverjanja DORA, NIS2 in GDPR
• Oceno DPO ali pravne službe
• Odobritve komunikacij in poslana sporočila
• Zapis verige skrbništva
• Analizo temeljnega vzroka
• Korektivne ukrepe in pridobljene izkušnje

Ta paket dokazil podpira tudi kontrole iz Priloge A ISO/IEC 27001:2022 A.8.15 beleženje, A.8.16 dejavnosti spremljanja, A.5.28 zbiranje dokazil, A.5.27 učenje iz incidentov informacijske varnosti, A.5.31 zakonske, statutarne, regulativne in pogodbene zahteve ter A.5.34 zasebnost in varstvo osebno določljivih podatkov.

Preslikava čezokvirne skladnosti: zgradite enkrat, odgovorite številnim presojevalcem

Najmočnejši modeli resnosti incidentov so zgrajeni enkrat in večkrat preslikani. Zenith Controls je zasnovan kot kompas čezokvirne skladnosti za to delo. Za to temo so ključni vnosi ISO/IEC 27002:2022 5.24 načrtovanje in priprava upravljanja incidentov informacijske varnosti, 5.25 presoja in odločanje o dogodkih informacijske varnosti, 5.26 odziv na incidente informacijske varnosti, 5.27 učenje iz incidentov informacijske varnosti in 5.28 zbiranje dokazil.

Te kontrole se naravno povezujejo s sistemom upravljanja ISO/IEC 27001:2022. Klavzule 4, 5, 6 in 8 opredeljujejo obseg, vodstvo, merila tveganja, obravnavo in operativna dokazila. ISO/IEC 27002:2022 zagotavlja jezik za implementacijo kontrol. Razmišljanje o neprekinjenem poslovanju po vzoru ISO 22301 podpira pragove motenj, prioritete obnovitve in krizno upravljanje. Prakse upravljanja incidentov po vzoru ISO/IEC 27035 podpirajo strukturirano zaznavanje, poročanje, presojo, odziv in učenje. Upravljanje zasebnosti po vzoru ISO/IEC 27701 podpira vloge pri kršitvah varstva osebnih podatkov, vidike upravljavca in obdelovalca, dokazila o zasebnosti in odgovornost.

Isti model se preslika v NIST Cybersecurity Framework 2.0. Funkcija GOVERN zahteva, da so zakonske, regulativne in pogodbene obveznosti ter obveznosti glede zasebnosti in državljanskih svoboščin razumljene in upravljane. Pričakuje tudi opredeljen apetit po tveganju, vloge, pooblastila, politike in nadzor. Funkcije DETECT, RESPOND in RECOVER podpirajo triažo, analizo, eskalacijo, zajezitev, obnovitev, komunikacije in izboljšave.

Korist je praktična. Ko nadzornik DORA zahteva utemeljitev večjega incidenta, povezanega z IKT, organ NIS2 sprašuje o odločitvi glede 24-urnega zgodnjega opozorila, nadzorni organ za varstvo podatkov vpraša, zakaj je bilo ali ni bilo podano obvestilo po GDPR, presojevalec ISO pa vpraša, ali je ISMS deloval po načrtu, lahko organizacija odgovori iz istega nabora dokazil.

Kako bodo presojevalci in regulatorji preverjali vaš model

Presojevalec ISO/IEC 27001:2022 bo običajno začel z obsegom in zakonskimi zahtevami. Vprašal bo, ali so bile DORA, NIS2, GDPR, pogodbe s strankami in obveznosti tretjih oseb na področju IKT opredeljene kot zahteve zainteresiranih strani. Nato bo sledil sledi v merila tveganja, Izjavo o uporabnosti, postopke za incidente, operativne evidence in hrambo dokazil. Želel bo dokaz, da proces razvrščanja ni bil izmišljen med incidentom.

Nadzornik DORA ali skupina za notranjo revizijo bo iskala zanko življenjskega cikla: proces upravljanja incidentov, indikatorje zgodnjega opozarjanja, merila razvrščanja, eskalacijo večjih incidentov, komuniciranje s strankami, temeljni vzrok, končne podatke o vplivu, testiranje odpornosti in nadzor upravljalnega organa. Vprašali bodo tudi, ali so bile upoštevane odvisnosti od tretjih oseb na področju IKT, zlasti kadar so bili vključeni oblak, SaaS, upravljana varnost ali ponudniki zunanjega izvajanja.

Presojevalec ali organ, osredotočen na NIS2, bo preverjal, ali lahko subjekt identificira pomembne incidente, izpolni fazne časovne roke, komunicira s prizadetimi prejemniki storitev in predloži dokazila o presoji čezmejnega vpliva. Obravnavanje incidentov bo povezal z ukrepi za obvladovanje tveganj iz Article 21, vključno z neprekinjenim poslovanjem, kriznim upravljanjem, varnostjo dobavne verige, nadzorom dostopa, upravljanjem sredstev in usposabljanjem.

DPO po GDPR ali nadzorni organ bo preveril, ali je organizacija identificirala osebne podatke, vloge, posameznike, na katere se nanašajo podatki, kategorije, prizadete sisteme, vrsto kršitve in tveganje za posameznike. Preverjal bo, ali lahko upravljavec dokaže odgovornost in ali so bila obvestila obdelovalca upravljavcem pravočasna in popolna.

Presojevalec v slogu ISACA ali COBIT 2019 se bo osredotočil na dokazila upravljanja. Kdo je odobril taksonomijo resnosti? Kdo je lastnik tveganja? Kateri kazalniki se poročajo vodstvu? Kako se obravnavajo izjeme? Kako se pridobljene izkušnje pretvorijo v izboljšave kontrol?

Pogosti vzorci napak pri razvrščanju incidentov

Prva napaka je razmišljanje z eno samo oznako. Ekipe dogodek razvrstijo kot visok, srednji ali nizek, vendar ločeno nikoli ne ocenijo sprožilcev DORA, NIS2 in GDPR. Rezultat je oznaka resnosti, ki ne more pojasniti odločitve o poročanju.

Druga napaka je pristranskost potrjene kršitve. Ekipe čakajo na absolutni dokaz eksfiltracije podatkov, preden vključijo zasebnost ali pravno službo. Presoja kršitve po GDPR se pogosto začne z možnim nepooblaščenim dostopom, izgubo, spremembo ali razkritjem, ne šele s potrjeno objavo podatkov.

Tretja napaka je zmeda glede časovnice. Časovni roki NIS2 in GDPR so odvisni od seznanitve in presoje. Če zapis incidenta ne zajame časa seznanitve, časa razvrstitve in časa eskalacije, bo organizacija morda težko dokazala pravočasnost.

Četrta napaka je forenzika po čiščenju. Inženirji zamenjajo ključe, ponovno zgradijo gostitelje in izbrišejo začasna dokazila, preden se sproži preiskovalni pristop. To lahko uniči dokaze, potrebne za regulativni, pogodbeni ali pravni pregled.

Peta napaka je slepota za dobavitelje. DORA, NIS2 in NIST CSF 2.0 vsi poudarjajo tveganja tretjih oseb in dobavne verige. Če je ponudnik storitev v oblaku, ponudnik upravljanih storitev, obdelovalec plačil, ponudnik identitet ali dobavitelj SaaS del verige incidenta, mora model razvrščanja vključevati vpliv dobavitelja in pogodbene obveznosti obveščanja.

Clarysecov kontrolni seznam implementacije za 2026

Za operacionalizacijo dokazljivo utemeljenega modela razvrščanja resnosti incidentov Clarysec priporoča naslednje zaporedje:

1. Potrdite regulativno uporabljivost glede DORA, NIS2, GDPR, pogodb s strankami in sektorskih pravil.
2. Posodobite obseg ISMS in zahteve zainteresiranih strani po ISO/IEC 27001:2022.
3. Opredelite interne ravni resnosti z merljivimi pragovi za čas izpada, podatke, stranke, geografijo, finančno izgubo in kritičnost.
4. Dodajte ločena vprašanja za preverjanje DORA, NIS2 in GDPR v delovni tok zapisa incidenta.
5. Opredelite sprožilce eskalacije za vodjo incidenta, DPO, pravno službo, višje vodstvo in upravljalni organ.
6. Ustvarite predlogo dnevnika odločitev o resnosti.
7. Povežite razvrščanje z zbiranjem dokazil in postopki verige skrbništva.
8. Preverite pokritost beleženja za dogodke identitet, oblaka, aplikacij, podatkovnih baz, omrežja in dobaviteljev.
9. Izvedite namizne vaje za scenarije večjega incidenta DORA, pomembnega incidenta NIS2 in kršitve po GDPR.
10. Pridobljene izkušnje vključite v obravnavo tveganja, Izjavo o uporabnosti, usposabljanje in testiranje odpornosti.

Zenith Blueprint, faza Controls in Action, korak 16, krepi človeško plat tega modela: prijave je treba zabeležiti v dnevnik, triažirati, eskalirati prek načrta odzivanja na incidente, spremljati pa je treba tudi manjše dogodke, ker trendi razkrivajo šibkosti kontrol. Spodbuja miselnost poročanja z nizkim pragom: »Če ste v dvomih, prijavite.«

Ta kulturni vidik je ključen. Model resnosti ne uspe, če zaposleni odlašajo s poročanjem, ker se bojijo pretiranega odziva. Cilj so hitro poročanje, disciplinirana triaža in dokazljivo utemeljena razvrstitev.

Negotovost incidenta pretvorite v dokazila, pripravljena za presojo

Leta 2026 razvrščanje resnosti incidentov ni več odločitev samo za SOC. Je reguliran proces upravljanja, ki mora povezati merila večjih incidentov, povezanih z IKT, po DORA, prage pomembnih incidentov po NIS2, tveganje kršitev po GDPR in dokazila ISO/IEC 27001:2022.

Organizacije, ki se med incidenti najbolje odzovejo, ne bodo tiste z najdebelejšim fasciklom za odziv. To bodo tiste, ki lahko hitro odgovorijo na štiri vprašanja in vsak odgovor pozneje tudi dokažejo:

• Kaj se je zgodilo?
• Kako resno je?
• Katere regulativne obveznosti se lahko uporabijo?
• Katera dokazila podpirajo odločitev?

Clarysec pomaga organizacijam zgraditi ta most s predlogami politik, taksonomijami resnosti, dnevniki odločitev, namiznimi scenariji in preslikavami čezokvirne skladnosti. Začnite s politikami za incidente, preverite svoja merila tveganja v Zenith Blueprint Zenith Blueprint in uporabite Zenith Controls Zenith Controls za preslikavo kontrol ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 in 5.28 čez DORA, NIS2, GDPR, NIST CSF in revizijska pričakovanja.

Če vaša ekipa v prvi uri ne more odgovoriti na vprašanje »Ali je to večji incident po DORA, pomemben incident po NIS2 ali dogodek, ki ga je treba prijaviti po GDPR?«, naslednji korak ni še en generični načrt odzivanja na incidente. Naslednji korak je dokazljivo utemeljen operativni model razvrščanja resnosti incidentov, preizkušen pred naslednjim klicem ob 02:17.

Ste pripravljeni paniko zamenjati s procesom? Prenesite Clarysecove predloge politik za odziv na incidente in zbiranje dokazil, preglejte svojo trenutno taksonomijo resnosti glede na Zenith Blueprint ali zahtevajte Clarysecovo presojo pripravljenosti za vzpostavitev modela razvrščanja incidentov po DORA, NIS2, GDPR in ISO/IEC 27001, pripravljenega za presojo.