Incidentu smaguma klasifikācija DORA, NIS2 un GDPR vajadzībām

Incidenta zvans plkst. 02:17, kas kļūst par regulatīvu lēmumu

Ceturtdienas rītā plkst. 02:17 FinScale CISO Sāra redz pirmo brīdinājumu: anomāla API datplūsma, straujš neveiksmīgu autentifikācijas mēģinājumu pieaugums un maksājumu informācijas paneļa latentums virs 3000 ms. Dažu minūšu laikā klientu atbalsts ziņo par maksājumu statusa kļūdām. Mākoņpakalpojumu sniedzējs norāda, ka platformas mēroga incidenta nav. SOC redz aizdomīgus piekļuves marķierus no diviem ģeogrāfiskiem reģioniem. Produkta komanda apstiprina, ka informācijas panelis pēc 19 minūtēm atkal ir tiešsaistē, taču divpadsmit klienti jau ir atvēruši pieteikumus.

Plkst. 03:05 Sāra pievienojas krīzes sanāksmei kopā ar incidenta vadītāju, Juridisko dienestu, privātuma jautājumu koordinatoru, mākoņoperāciju vadītāju un izpildsponsoru. Tehniskais jautājums ir pietiekami skaidrs: kas notika ar API vārteju? Regulatīvie jautājumi ir sarežģītāki:

1. Vai tas ir DORA būtisks ar IKT saistīts incidents?
2. Vai tas ir NIS2 nozīmīgs incidents?
3. Vai pastāv GDPR personas datu aizsardzības pārkāpums, par kuru jāsniedz paziņojums?
4. Vai organizācija var pierādīt, kā tā nonāca pie šīm atbildēm?

Nepareiza atbilde var radīt regulatīvas sekas. Lēna atbilde var novest pie ziņošanas termiņa nokavēšanas. Nedokumentēta atbilde pēc vairākiem mēnešiem var neizturēt ISO/IEC 27001:2022 auditu.

Tas ir 2026. gada izaicinājums reaģēšanā uz incidentiem. Daudzām organizācijām ir incidentu reaģēšanas plāns, digitālās kriminālistikas procedūras, privātuma rokasgrāmatas un krīzes komunikācijas veidnes. Mazāk organizāciju uztur pamatotu incidentu smaguma klasifikācijas modeli, kas trokšņainu drošības notikumu pārvērš dokumentētā lēmumā DORA, NIS2, GDPR un ISO/IEC 27001:2022 pierādījumu prasību kontekstā.

Risinājums nav trīs atsevišķi sākotnējās izvērtēšanas procesi. Risinājums ir viens pārvaldīts smaguma modelis ar atsevišķiem regulatīvajiem slāņiem, izmērāmiem sliekšņiem, eskalācijas noteikumiem, lēmumu žurnāliem un pierādījumu vākšanas prasībām. Praktiski tas nozīmē, ka incidenta smagums nedrīkst būt marķējums, ko izvēlas spiediena apstākļos. Tam jābūt kontrolētam biznesa lēmumam, kas iztur regulatoru, auditoru, valdes locekļu, klientu un datu aizsardzības speciālista pārbaudi.

Kāpēc incidentu smaguma klasifikācija tagad ir valdes līmeņa kontroles pasākums

Incidentu klasifikācija agrāk galvenokārt bija tehniska: ļaunatūras smagums, skartie resursdatori, izmantotās ievainojamības un tas, vai notikusi datu eksfiltrācija. 2026. gadā tā ir arī juridiska, finanšu, reputācijas un līgumiska.

DORA padara digitālo darbības noturību par finanšu vienību pārvaldības pienākumu. Vadības institūcijai ir jānosaka, jāapstiprina un jāuzrauga IKT risku pārvaldības ietvars, kā arī jāsaglabā atbildība par to. Tas ietver IKT darbības nepārtrauktību, reaģēšanas un atjaunošanas plānus, būtisku incidentu ziņošanas kanālus, IKT trešo pušu risku un gūtās mācības.

NIS2 paaugstina pārvaldības prasības būtiskajām un svarīgajām vienībām. Article 20 prasa vadības institūcijām apstiprināt kiberdrošības risku pārvaldības pasākumus, uzraudzīt to ieviešanu un piedalīties apmācībā. Tas arī sasaista risku pārvaldības un incidentu ziņošanas trūkumus ar būtiskām uzraudzības sekām. Būtiskajām vienībām maksimālo administratīvo sodu pamatlīmenis var sasniegt vismaz EUR 10,000,000 vai 2 procentus no kopējā pasaules gada apgrozījuma, atkarībā no tā, kura summa ir lielāka. Svarīgajām vienībām pamatlīmenis ir vismaz EUR 7,000,000 vai 1,4 procenti no apgrozījuma, atkarībā no tā, kura summa ir lielāka.

GDPR pievieno citu skatpunktu. Personas datu aizsardzības pārkāpums neaprobežojas ar apstiprinātu publisku izpaušanu vai nozagtām datnēm. Tas ietver nejaušu vai nelikumīgu personas datu iznīcināšanu, nozaudēšanu, pārveidošanu, neatļautu izpaušanu vai piekļuvi tiem. Pārziņiem ir jāizvērtē risks fiziskām personām un jāspēj pierādīt pārskatatbildība par lēmumu paziņot vai nepaziņot.

ISO/IEC 27001:2022 šiem pienākumiem nodrošina pierādījumu pamatu. Punkti 4.1 līdz 4.4 prasa organizācijai izprast savu kontekstu, ieinteresēto pušu prasības, darbības jomu, saskarnes un atkarības. Punkti 5.1 līdz 5.3 prasa vadības apņemšanos, politiku, lomas, pienākumus un ziņošanu. Punkti 6.1.1 līdz 6.1.3 prasa uz risku balstītu plānošanu, risku izvērtēšanu, riska apstrādi un piemērojamības deklarāciju (SoA). Punkti 8.1 līdz 8.3 prasa darbības kontroles pasākumus, izmaiņu kontroli, saglabātus pierādījumus un atkārtotu izvērtēšanu, kad mainās riska apstākļi. ISO/IEC 27001:2022

Kad notiek incidenta zvans, jautājumam nevajadzētu būt: “Kurš uzskata, ka tas ir kritiski?” Jautājumam jābūt: “Ko mūsu apstiprinātie kritēriji, juridiskie aktivizējošie nosacījumi, pierādījumi un eskalācijas noteikumi prasa darīt tagad?”

Viens notikums, trīs regulatīvās klasifikācijas sistēmas

DORA, NIS2 un GDPR incidentiem nelieto vienu un to pašu terminoloģiju. Tas ir galvenais iemesls, kāpēc organizācijām pirmajā stundā rodas grūtības.

DORA Article 17 prasa finanšu vienībām izveidot ar IKT saistītu incidentu pārvaldības procesu, kas atklāj, pārvalda un ziņo par IKT incidentiem, reģistrē ar IKT saistītus incidentus un nozīmīgus kiberdraudus, novērš pamatcēloņus, izmanto agrīnās brīdināšanas indikatorus, kategorizē un klasificē incidentus, piešķir lomas, pārvalda komunikāciju, eskalē būtiskus incidentus augstākajai vadībai un atjauno drošu darbību.

DORA Article 18 prasa klasifikāciju, izmantojot tādus kritērijus kā skartie klienti, skartie darījumu partneri, darījumi, ilgums, dīkstāve, ģeogrāfiskais izplatījums, datu zudums, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, skarto pakalpojumu kritiskums un ekonomiskā ietekme. DORA Article 19 prasa ziņot par būtiskiem ar IKT saistītiem incidentiem un īstenot klientu komunikāciju, ja tiek skartas klientu finanšu intereses.

NIS2 Article 23 definē nozīmīgu incidentu kā tādu, kas ir izraisījis vai spēj izraisīt smagus darbības traucējumus vai finansiālus zaudējumus, vai ir ietekmējis vai spēj ietekmēt citas personas, radot ievērojamu materiālu vai nemateriālu kaitējumu. Tas prasa agrīnu brīdinājumu 24 stundu laikā pēc nozīmīgā incidenta apzināšanās, incidenta paziņojumu 72 stundu laikā, starpposma ziņojumus pēc pieprasījuma un galīgo ziņojumu viena mēneša laikā pēc incidenta paziņojuma. Ja piemērojams, skartie pakalpojumu saņēmēji jāinformē arī par pasākumiem vai tiesiskās aizsardzības līdzekļiem, ko tie var veikt.

GDPR uzdod privātuma riska jautājumu. Vai drošības pārkāpums izraisīja personas datu iznīcināšanu, nozaudēšanu, pārveidošanu, neatļautu izpaušanu vai piekļuvi tiem? Ja jā, pārzinim jāizvērtē risks fizisko personu tiesībām un brīvībām. Ja pārkāpums var radīt risku, parasti 72 stundu laikā pēc tā apzināšanās jāinformē uzraudzības iestāde. Ja tas var radīt augstu risku, skartās personas var būt jāinformē bez nepamatotas kavēšanās.

Tāpēc vienam incidentam ir nepieciešama vienlaicīga klasifikācija.

Finanšu vienībām DORA ir nozarei specifisks Savienības tiesību akts IKT risku pārvaldībai un incidentu ziņošanas pienākumiem, kas pārklājas ar NIS2. Tas nepadara NIS2 nebūtisku. Tā joprojām var būt nozīmīga sadarbībai, informācijas plūsmām, pakalpojumiem ārpus DORA tvēruma, nefinanšu grupas vienībām, mākoņpakalpojumiem, pārvaldītiem pakalpojumiem un klientu līgumiskajiem pienākumiem. Smaguma modelī jāreģistrē ne tikai iznākums, bet arī piemērojamības pamatojums.

Clarysec modelis: klasificējiet notikumu, nevis emociju

Clarysec sāk ar ISO/IEC 27002:2022 kontroles pasākumu 5.25 — informācijas drošības notikumu izvērtēšana un lēmuma pieņemšana — kā savstarpējās atbilstības enkuru. Zenith Controls: The Cross-Compliance Guide Zenith Controls šī tēma ir kartēta ierakstā “Informācijas drošības notikumu izvērtēšana un lēmuma pieņemšana” kontroles pasākumam 5.25, ko atbalsta “IS incidentu pārvaldības plānošana un sagatavošanās” kontroles pasākumam 5.24 un “Pierādījumu vākšana” kontroles pasākumam 5.28.

Svarīgākais atbilstības brīdis bieži nav ierobežošana. Tas ir lēmuma punkts, kurā drošības notikums kļūst par regulatīvu incidentu vai tiek pamatoti reģistrēts kā zemākas smaguma pakāpes notikums.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint apraksta šo brīdi fāzē “Kontroles pasākumi darbībā”, 23. solī:

“Ne katra anomālija ir katastrofa. Ne katrs brīdinājums norāda uz kompromitēšanu. Reālajā vidē drošības komandas un biznesa struktūrvienības pārpludina troksnis — pieteikšanās mēģinājumi, žurnālu anomālijas, nelieli politikas pārkāpumi, ēnu IT aktivitātes. Patiesais izaicinājums nav tikai atklāšanā, bet spējā atšķirt nekaitīgo no kaitīgā un zināt, kas prasa eskalāciju.”

Šis teikums precīzi raksturo operacionālo problēmu. SIEM brīdinājums automātiski nenozīmē DORA būtisku incidentu. Pagaidu nepieejamība automātiski nenozīmē NIS2 nozīmīgu incidentu. Aizdomīgs datubāzes vaicājums automātiski nenozīmē, ka par to jāpaziņo saskaņā ar GDPR. Katrs no tiem var kļūt ziņojams atkarībā no ietekmes, darbības jomas, datiem, skartajām pusēm un pierādījumiem.

Zenith Blueprint Riska pārvaldības fāzes 10. solī arī iesaka ietekmes definīcijas pielāgot biznesa mērogam un regulatīvajai ietekmei:

“Definējot ietekmi, ir lietderīgi līmeņus sasaistīt ar jūsu konkrēto biznesa mērogu. Piemēram, ‘Būtiska finansiālā ietekme = zaudējumi > $100k’ (pielāgojiet savam kontekstam). Ņemiet vērā arī regulatīvo ietekmi: piemēram, personas datu aizsardzības pārkāpums var automātiski būt ‘Būtisks’ vai ‘Smags’ GDPR sodu un paziņošanas prasību dēļ, pat ja tiešie finansiālie zaudējumi nav skaidri.”

Tas ir 2026. gada incidentu smaguma klasifikācijas projektēšanas princips: smagums ir biznesa ietekme plus juridiskā ietekme plus pierādījumu ticamība.

Praktiska incidentu smaguma taksonomija DORA, NIS2 un GDPR vajadzībām

Pamatotai taksonomijai jānošķir iekšējais smagums no regulatīvās klasifikācijas. Iekšējais smagums nosaka reaģēšanas steidzamību, resursu piešķiršanu un eskalāciju augstākajai vadībai. Regulatīvā klasifikācija nosaka paziņošanu, juridisko pārbaudi un ārējo komunikāciju.

Iekšējais smaguma līmenis nav galīgā regulatīvā atbilde. Tas ir darbības režīms. SEV 3 notikums pēc žurnālierakstu pārskatīšanas var kļūt par GDPR paziņojamu incidentu. SEV 2 nepieejamība var nebūt DORA būtisks incidents, ja ietekmes sliekšņi nav sasniegti. SEV 1 izspiedējprogrammatūras incidents vienlaikus var aktivizēt DORA, NIS2, GDPR, klientu līgumus un sadarbību ar tiesībaizsardzības iestādēm.

Detalizētāka klasifikācijas matrica palīdz komandai pāriet no brīdinājuma uz rīcību.

Modelim jābūt iestrādātam politikā, nevis atstātam krīzes sanāksmes skaļākajai balsij. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Pārvaldības prasību 5.3.1. punkts nosaka:

“Ģenerāldirektoram, ņemot vērā IT pakalpojumu sniedzēja ievadi, visi incidenti pēc smaguma pakāpes jāklasificē vienas stundas laikā pēc paziņojuma saņemšanas.”

Tā pati SME politika, Risku apstrāde un izņēmumi, 7.4.1. punkts, papildina:

“Ja ir iesaistīti klientu dati, ģenerāldirektoram jāizvērtē juridiskie paziņošanas pienākumi, pamatojoties uz GDPR, NIS2 vai DORA piemērojamību.”

Lielākām organizācijām uzņēmuma Incident Response Policy Incident Response Policy, Pārvaldības prasību 5.3. punkts formalizē to pašu pieeju:

“Incidentu klasifikācijai jāievēro daudzlīmeņu modelis:”

Politikas valodai ir nozīme, jo regulatori un auditori jautās, vai klasifikācijas kritēriji pastāvēja pirms incidenta. Pēc fakta izveidota matrica ir vājš pierādījums. Apstiprināta, apmācīta, vingrinājumos pārbaudīta un konsekventi izmantota matrica ir pamatota.

Lēmumu žurnāls: vissvarīgākais pierādījumu artefakts

Kad auditori, regulatori vai valdes locekļi pārskata incidentu, viņi reti jautā tikai: “Kas notika?” Viņi jautā: “Kad jūs to uzzinājāt, kurš nolēma, uz kādiem pierādījumiem balstoties, un kāpēc jūs nepaziņojāt agrāk?”

Tāpēc Clarysec iesaka smaguma lēmumu žurnālu katram SEV 3 un augstākam notikumam, kā arī jebkuram notikumam, kurā iesaistīti personas dati, kritiski pakalpojumi, finanšu klienti, pārvaldīti pakalpojumi, mākoņinfrastruktūra vai pārrobežu ietekme.

Tas tieši kartējas uz ISO/IEC 27001:2022. 8.1. punkts prasa procesus plānot, ieviest un kontrolēt, saglabājot pietiekamu dokumentētu informāciju, lai pierādītu, ka tie darbojās, kā plānots. 8.2. un 8.3. punkts prasa atkārtotu izvērtēšanu, kad notiek būtiskas izmaiņas, un riska apstrādes pierādījumu glabāšanu. A pielikuma kontroles pasākumi A.5.24 līdz A.5.28 veido incidentu pārvaldības pamatu: plānošana un sagatavošanās, notikumu izvērtēšana un lēmuma pieņemšana, reaģēšana, mācīšanās no incidentiem un pierādījumu vākšana.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Ievērošana un atbilstība, 8.3.2. punkts atbalsta modeļa GDPR pusi:

“Privātuma koordinators noteiks smaguma pakāpi, uzsāks ierobežošanas darbības un dokumentēs lietu”

Privātuma izvērtēšanai nav jāsākas tikai tad, kad regulatīvais termiņš kļūst neērts. Tai jābūt sākotnējās izvērtēšanas darbplūsmas daļai.

Praktisks piemērs: Sāras API incidenta klasificēšana

Atgriezīsimies pie FinScale. Tā ir B2B fintech platforma, kas izmanto mākoņinfrastruktūru, ārēju krāpšanas analītikas pakalpojumu sniedzēju un pārvaldītu drošības pakalpojumu sniedzēju. Dažās darbībās tā ir DORA aptverta finanšu vienība. Tā ir arī digitālo pakalpojumu sniedzējs ar NIS2 nozīmīgām operācijām vienā dalībvalstī. Tā apstrādā klientu personas datus kā pārzinis kontu pakalpojumiem un kā apstrādātājs dažiem uzņēmumu klientiem.

Plkst. 02:17 tiek konstatēta anomāla API datplūsma. Plkst. 02:35 tiek atvērts incidenta pieteikums. Plkst. 03:00 Sāra pabeidz sākotnējo izvērtēšanu kopā ar incidenta vadītāju.

Pirmkārt, tiek noteikts iekšējais smagums. Incidents 19 minūtes ietekmēja klientu informācijas paneļa pieejamību, ietvēra aizdomīgus piekļuves marķierus un skāra kritisku klientiem pieejamu funkciju. Tas tiek klasificēts kā SEV 3 vidējs līdz apstiprināšanai, ar eskalāciju incidenta vadītājam, privātuma jautājumu koordinatoram, Juridiskajam dienestam un pakalpojuma īpašniekam.

Otrkārt, tiek pabeigta DORA izvērtēšana. Komanda pārbauda skartos klientus, darījumu partnerus, darījumus, ilgumu, dīkstāvi, ģeogrāfisko izplatījumu, datu zudumu, kritiskumu un ekonomisko ietekmi. Neveiksmīgi vai pārveidoti darījumi nav apstiprināti. Dīkstāve ir ierobežota. Datu zudums nav pierādīts. Tomēr, tā kā var tikt ietekmēta kritiska finanšu pakalpojuma komponente un klientu finanšu intereses, incidents paliek DORA uzraudzībā un var tikt pārklasificēts.

Treškārt, tiek reģistrēta NIS2 izvērtēšana. Komanda atzīmē, ka DORA ir primārais nozarei specifiskais ziņošanas režīms aptvertās finanšu vienības pienākumiem. Tā arī pārbauda, vai incidents ietekmē pakalpojumus vai klientus ārpus DORA tvēruma. Šajā posmā nav apstiprināti smagi darbības traucējumi vai ievērojams kaitējums.

Ceturtkārt, tiek uzsākta GDPR izvērtēšana. Aizdomīgie marķieri varēja ļaut piekļūt klientu informācijas paneļa datiem. Privātuma jautājumu koordinators dokumentē datu kategorijas, skartos lietotājus, marķieru darbības jomu, pārskatītos žurnālierakstus, to, vai dati tika skatīti vai eksportēti, un drošības pasākumus, piemēram, marķieru derīguma termiņu un piekļuves kontroles pasākumus.

Plkst. 04:20 žurnālierakstu analīze rāda, ka divi marķieri tika izmantoti, lai piekļūtu informācijas paneļa metadatiem par 41 klientu, tostarp vārdiem, kontu ID un darījumu statusam, bet ne maksājumu autentifikācijas datiem vai identitātes dokumentiem. Komanda atjaunina incidentu uz SEV 2 būtisks, jo tika ietekmēta personas datu konfidencialitāte un var būt nepieciešama klientu komunikācija. Datu aizsardzības speciālists izvērtē GDPR risku fiziskām personām. DORA lēmums tiek pārskatīts, pamatojoties uz klientu ietekmi, darījumu ietekmi un ekonomisko ietekmi.

Tā ir modeļa praktiskā vērtība. Sākotnējā klasifikācija nav galīgs juridisks secinājums. Tas ir uz pierādījumiem balstīts lēmums, ko var atjaunināt, faktiem attīstoties.

Žurnālu reģistrēšana, uzraudzība un digitālās kriminālistikas pierādījumi: pierādīšanas slānis

Smaguma modelis bez pierādījumiem ir sanāksmes viedoklis. 2026. gada prasības paredz, ka klasifikāciju pamato žurnālieraksti, uzraudzība, saglabāti artefakti un pierādījumu glabāšanas ķēde.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Ievērošana un atbilstība, 8.3.4. punkts nosaka:

“Pārkāpumu izmeklēšana jāatbalsta ar pietiekamiem žurnāliem, lai izpildītu pārskatatbildības principu saskaņā ar GDPR un DORA”

Digitālās kriminālistikas apstrāde ir tikpat svarīga. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Pārvaldības prasību 5.3.1. punkts prasa:

“Katram incidentam jāuztur vienkāršs pierādījumu glabāšanas ķēdes žurnāls (piemēram, Excel datne vai veidnes dokuments).”

Uzņēmuma vidēm Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Pārvaldības prasību 5.5. punkts prasa:

“Visi iegūtie pierādījumi ir unikāli jāidentificē, jāmarķē un jāglabā drošā repozitorijā ar:”

Zenith Blueprint, fāze “Kontroles pasākumi darbībā”, 23. solis, skaidro, kāpēc tas ir svarīgi ISO/IEC 27002:2022 kontroles pasākumam 5.28:

“Kad notiek informācijas drošības incidents, viens no kritiskākajiem, bet bieži nepietiekami novērtētajiem reaģēšanas elementiem ir pierādījumi. Nevis žurnāli, nevis ekrānuzņēmumi, nevis brīvi apraksti, bet pienācīgi saglabāti, pierādījumu glabāšanas ķēdi ievērojoši, pret manipulācijām aizsargāti pierādījumi.”

Praktiskā pierādījumu pakotnē būtiskam vai potenciāli ziņojamam incidentam jāiekļauj:

• Incidenta pieteikums un laika skala
• Smaguma lēmumu žurnāls un pārklasificēšanas vēsture
• SIEM brīdinājumi, EDR brīdinājumi, mākoņvides žurnālieraksti un identitātes žurnālieraksti
• Datu piekļuves žurnālieraksti un eksportēšanas žurnālieraksti
• Skarto aktīvu un pakalpojumu uzskaites ieraksti
• Klientu, darījumu un ģeogrāfiskās ietekmes izvērtējums
• DORA, NIS2 un GDPR izvērtēšanas darba lapa
• Datu aizsardzības speciālista vai juridiskais izvērtējums
• Komunikācijas saskaņojumi un nosūtītie ziņojumi
• Pierādījumu glabāšanas ķēdes ieraksts
• Pamatcēloņa analīze
• Korektīvās darbības un gūtās mācības

Šī pierādījumu pakotne atbalsta arī ISO/IEC 27001:2022 A pielikuma kontroles pasākumus A.8.15 žurnālu reģistrēšana, A.8.16 uzraudzības darbības, A.5.28 pierādījumu vākšana, A.5.27 mācīšanās no informācijas drošības incidentiem, A.5.31 juridiskās, normatīvās, regulatīvās un līgumiskās prasības un A.5.34 privātums un personu identificējošas informācijas aizsardzība.

Savstarpējās atbilstības kartēšana: izveidojiet vienreiz, atbildiet daudziem auditoriem

Spēcīgākie incidentu smaguma modeļi tiek izveidoti vienreiz un kartēti daudzkārt. Zenith Controls ir veidots kā savstarpējās atbilstības kompass šim darbam. Šai tēmai galvenie ISO/IEC 27002:2022 ieraksti ir 5.24 informācijas drošības incidentu pārvaldības plānošana un sagatavošanās, 5.25 informācijas drošības notikumu izvērtēšana un lēmuma pieņemšana, 5.26 reaģēšana uz informācijas drošības incidentiem, 5.27 mācīšanās no informācijas drošības incidentiem un 5.28 pierādījumu vākšana.

Šie kontroles pasākumi dabiski sasaistās ar ISO/IEC 27001:2022 pārvaldības sistēmu. 4., 5., 6. un 8. punkts nosaka darbības jomu, līderību, riska kritērijus, apstrādi un darbības pierādījumus. ISO/IEC 27002:2022 nodrošina kontroles pasākumu ieviešanas valodu. ISO 22301 stilā veidota darbības nepārtrauktības domāšana atbalsta traucējumu sliekšņus, atjaunošanas prioritātes un krīzes pārvaldību. ISO/IEC 27035 stilā veidota incidentu pārvaldības prakse atbalsta strukturētu atklāšanu, ziņošanu, izvērtēšanu, reaģēšanu un mācīšanos. ISO/IEC 27701 stilā veidota privātuma pārvaldība atbalsta personas datu aizsardzības pārkāpuma lomas, pārziņa un apstrādātāja apsvērumus, privātuma pierādījumus un pārskatatbildību.

Tas pats modelis kartējas uz NIST Cybersecurity Framework 2.0. GOVERN funkcija prasa izprast un pārvaldīt juridiskos, regulatīvos, līgumiskos, privātuma un pilsonisko brīvību pienākumus. Tā arī paredz, ka tiek definēta riska apetīte, lomas, pilnvaras, politikas un pārraudzība. DETECT, RESPOND un RECOVER funkcijas atbalsta sākotnējo izvērtēšanu, analīzi, eskalāciju, ierobežošanu, atjaunošanu, komunikāciju un pilnveidi.

Ieguvums ir praktisks. Kad DORA uzraugs prasa būtiska ar IKT saistīta incidenta pamatojumu, NIS2 iestāde jautā par 24 stundu agrīnās brīdināšanas lēmumu, DPA jautā, kāpēc GDPR paziņojums tika vai netika sniegts, un ISO auditors jautā, vai IDPS darbojās, kā plānots, organizācija var atbildēt no viena un tā paša pierādījumu kopuma.

Kā auditori un regulatori pārbaudīs jūsu modeli

ISO/IEC 27001:2022 auditors parasti sāks ar darbības jomu un juridiskajām prasībām. Viņš jautās, vai DORA, NIS2, GDPR, klientu līgumi un IKT trešo pušu pienākumi tika identificēti kā ieinteresēto pušu prasības. Pēc tam viņš sekos pēdai uz riska kritērijiem, piemērojamības deklarāciju (SoA), incidentu procedūrām, darbības ierakstiem un pierādījumu glabāšanu. Viņš vēlas pierādījumus, ka klasifikācijas process netika izdomāts incidenta laikā.

DORA uzraugs vai iekšējā audita komanda meklēs dzīves cikla cilpu: incidentu pārvaldības procesu, agrīnās brīdināšanas indikatorus, klasifikācijas kritērijus, būtiska incidenta eskalāciju, klientu komunikāciju, pamatcēloni, galīgos ietekmes rādītājus, noturības testēšanu un vadības institūcijas pārraudzību. Viņi arī jautās, vai tika ņemtas vērā IKT trešo pušu atkarības, jo īpaši gadījumos, kad bija iesaistīti mākoņpakalpojumi, SaaS, pārvaldītā drošība vai ārpakalpojumu sniedzēji.

Uz NIS2 fokusēts auditors vai iestāde pārbaudīs, vai vienība spēj identificēt nozīmīgus incidentus, ievērot pakāpeniskos termiņus, komunicēt ar skartajiem pakalpojumu saņēmējiem un sniegt pierādījumus par pārrobežu ietekmes izvērtēšanu. Viņi sasaistīs incidentu apstrādi ar Article 21 risku pārvaldības pasākumiem, tostarp darbības nepārtrauktību, krīzes pārvaldību, piegādes ķēdes drošību, piekļuves kontroli, aktīvu pārvaldību un apmācību.

GDPR datu aizsardzības speciālists vai uzraudzības iestāde pārbaudīs, vai organizācija identificēja personas datus, lomas, datu subjektus, kategorijas, skartās sistēmas, pārkāpuma veidu un risku fiziskām personām. Viņi pārbaudīs, vai pārzinis var pierādīt pārskatatbildību un vai apstrādātāju paziņojumi pārziņiem bija savlaicīgi un pilnīgi.

ISACA vai COBIT 2019 stilā strādājošs auditors koncentrēsies uz pārvaldības pierādījumiem. Kurš apstiprināja smaguma taksonomiju? Kam pieder risks? Kāda metrika tiek ziņota vadībai? Kā tiek pārvaldīti izņēmumi? Kā gūtās mācības tiek pārvērstas kontroles pasākumu uzlabojumos?

Biežākie incidentu klasifikācijas kļūdu modeļi

Pirmā kļūda ir vienas etiķetes domāšana. Komandas klasificē notikumu kā augstu, vidēju vai zemu, bet atsevišķi neizvērtē DORA, NIS2 un GDPR aktivizējošos nosacījumus. Rezultāts ir smaguma marķējums, kas nespēj izskaidrot ziņošanas lēmumu.

Otrā kļūda ir apstiprināta pārkāpuma aizspriedums. Komandas gaida absolūtu pierādījumu par datu eksfiltrāciju, pirms iesaista privātuma vai juridiskos speciālistus. GDPR pārkāpuma izvērtēšana bieži sākas ar iespējamu neatļautu piekļuvi, nozaudēšanu, pārveidošanu vai izpaušanu, nevis tikai ar apstiprinātu datu publicēšanu.

Trešā kļūda ir laika atskaites neskaidrība. NIS2 un GDPR termiņi ir atkarīgi no apzināšanās un izvērtēšanas. Ja incidenta pieteikumā netiek fiksēts apzināšanās laiks, klasifikācijas laiks un eskalācijas laiks, organizācijai var būt grūti pierādīt savlaicīgumu.

Ceturtā kļūda ir digitālā kriminālistika pēc sakopšanas. Inženieri rotē atslēgas, pārbūvē resursdatorus un dzēš pagaidu pierādījumus, pirms tiek aktivizēts izmeklēšanas režīms. Tas var iznīcināt pierādījumus, kas nepieciešami regulatīvai, līgumiskai vai juridiskai pārbaudei.

Piektā kļūda ir piegādātāju aklums. DORA, NIS2 un NIST CSF 2.0 visi uzsver trešo pušu un piegādes ķēdes risku. Ja mākoņpakalpojumu sniedzējs, pārvaldīto pakalpojumu sniedzējs, maksājumu apstrādātājs, identitātes nodrošinātājs vai SaaS piegādātājs ir incidenta ķēdes daļa, klasifikācijas modelī jāiekļauj piegādātāja ietekme un līgumiskie paziņošanas pienākumi.

Clarysec ieviešanas kontrolsaraksts 2026. gadam

Lai ieviestu pamatotu incidentu smaguma klasifikācijas modeli, Clarysec iesaka šādu secību:

1. Apstipriniet regulatīvo piemērojamību DORA, NIS2, GDPR, klientu līgumu un nozares noteikumu griezumā.
2. Atjauniniet IDPS darbības jomu un ieinteresēto pušu prasības saskaņā ar ISO/IEC 27001:2022.
3. Definējiet iekšējos smaguma līmeņus ar izmērāmiem sliekšņiem dīkstāvei, datiem, klientiem, ģeogrāfijai, finansiālajiem zaudējumiem un kritiskumam.
4. Pievienojiet atsevišķus DORA, NIS2 un GDPR izvērtēšanas jautājumus incidenta pieteikuma darbplūsmai.
5. Definējiet eskalācijas aktivizējošos nosacījumus incidenta vadītājam, datu aizsardzības speciālistam, Juridiskajam dienestam, augstākajai vadībai un valdei.
6. Izveidojiet smaguma lēmumu žurnāla veidni.
7. Sasaistiet klasifikāciju ar pierādījumu vākšanas un pierādījumu glabāšanas ķēdes procedūrām.
8. Validējiet žurnālu reģistrēšanas pārklājumu identitātes, mākoņvides, lietojumprogrammu, datubāzu, tīkla un piegādātāju notikumiem.
9. Veiciet galda mācības DORA būtiska incidenta, NIS2 nozīmīga incidenta un GDPR pārkāpuma scenārijiem.
10. Iekļaujiet gūtās mācības riska apstrādē, piemērojamības deklarācijā (SoA), apmācībās un noturības testēšanā.

Zenith Blueprint, fāze “Kontroles pasākumi darbībā”, 16. solis, pastiprina šī modeļa cilvēkfaktora pusi: ziņojumi jāreģistrē, tiem jāveic sākotnējā izvērtēšana un tie jāeskalē saskaņā ar incidentu reaģēšanas plānu, un pat nelieli notikumi jāizseko, jo tendences atklāj kontroles pasākumu vājās vietas. Tas veicina zema sliekšņa ziņošanas domāšanu: “Ja šaubies, ziņo.”

Šis kultūras aspekts ir kritisks. Smaguma modelis nedarbojas, ja darbinieki kavē ziņošanu, jo baidās no pārmērīgas reakcijas. Mērķis ir ātra ziņošana, disciplinēta sākotnējā izvērtēšana un pamatota klasifikācija.

Pārvērtiet incidentu nenoteiktību auditam gatavos pierādījumos

2026. gadā incidentu smaguma klasifikācija vairs nav tikai SOC lēmums. Tas ir regulēts pārvaldības process, kam jāsasaista DORA būtiska ar IKT saistīta incidenta kritēriji, NIS2 nozīmīga incidenta sliekšņi, GDPR pārkāpuma risks un ISO/IEC 27001:2022 pierādījumi.

Incidentu laikā vislabāk darbosies nevis organizācijas ar visbiezāko reaģēšanas mapi. Vislabāk darbosies tās, kas var ātri atbildēt uz četriem jautājumiem un vēlāk pierādīt katru atbildi:

• Kas notika?
• Cik smags tas ir?
• Kuri regulatīvie pienākumi var būt piemērojami?
• Kādi pierādījumi pamato lēmumu?

Clarysec palīdz organizācijām izveidot šo tiltu, izmantojot politiku veidnes, smaguma taksonomijas, lēmumu žurnālus, galda scenārijus un savstarpējās atbilstības kartējumus. Sāciet ar incidentu politikām, validējiet savus riska kritērijus Zenith Blueprint Zenith Blueprint, un izmantojiet Zenith Controls Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus 5.24, 5.25, 5.26, 5.27 un 5.28 DORA, NIS2, GDPR, NIST CSF un audita prasību kontekstā.

Ja jūsu komanda pirmajā stundā nevar atbildēt uz jautājumu “Vai tas ir DORA būtisks, NIS2 nozīmīgs vai GDPR paziņojams incidents?”, nākamais solis nav vēl viens vispārīgs incidentu reaģēšanas plāns. Nākamais solis ir pamatots incidentu smaguma klasifikācijas darbības modelis, kas pārbaudīts pirms nākamā zvana plkst. 02:17.

Vai esat gatavi aizstāt paniku ar procesu? Lejupielādējiet Clarysec incidentu reaģēšanas un pierādījumu vākšanas politiku veidnes, pārskatiet savu pašreizējo smaguma taksonomiju pret Zenith Blueprint vai pieprasiet Clarysec gatavības izvērtēšanu, lai izveidotu auditam gatavu DORA, NIS2, GDPR un ISO/IEC 27001 incidentu klasifikācijas modeli.