Incidentų sunkumo klasifikavimas pagal DORA, NIS2 ir GDPR

02:17 incidento skambutis, tampantis reglamentavimo sprendimu

Ketvirtadienio rytą 02:17 Sarah, FinScale vyriausioji informacijos saugumo pareigūnė (CISO), pamato pirmąjį įspėjimą: neįprastą API srautą, staigų nesėkmingų autentifikavimo bandymų padidėjimą ir mokėjimų valdymo skydelio delsą, viršijančią 3000 ms. Po kelių minučių klientų aptarnavimo komanda praneša apie mokėjimo būsenos klaidas. Debesijos paslaugų teikėjas nurodo, kad visos platformos masto incidento nėra. SOC pastebi įtartinus prieigos raktus iš dviejų geografinių regionų. Produkto komanda patvirtina, kad valdymo skydelis po 19 minučių vėl veikia, tačiau dvylika klientų jau yra pateikę užklausas.

03:05 Sarah prisijungia prie krizių koordinavimo skambučio kartu su incidento vadovu, teisininku, privatumo koordinatoriumi, debesijos operacijų vadovu ir vykdomuoju rėmėju. Techninis klausimas pakankamai aiškus: kas nutiko API šliuzui? Reglamentavimo klausimai sudėtingesni:

1. Ar tai yra reikšmingas su IRT susijęs incidentas pagal DORA?
2. Ar tai yra reikšmingas incidentas pagal NIS2?
3. Ar įvyko GDPR asmens duomenų saugumo pažeidimas, apie kurį privaloma pranešti?
4. Ar organizacija gali įrodyti, kaip priėjo prie šių atsakymų?

Neteisingas atsakymas gali sukurti reglamentavimo riziką. Pavėluotas atsakymas gali lemti pranešimo termino praleidimą. Nedokumentuotas atsakymas po kelių mėnesių gali neatlaikyti ISO/IEC 27001:2022 audito.

Tai yra 2026 m. reagavimo į incidentus iššūkis. Daugelis organizacijų turi reagavimo į incidentus planą, kriminalistines procedūras, privatumo veiksmų planus ir krizių komunikacijos šablonus. Kur kas mažiau organizacijų turi pagrįstą incidentų sunkumo klasifikavimo modelį, kuris triukšmingą saugumo įvykį paverčia dokumentuotu sprendimu pagal DORA, NIS2, GDPR ir ISO/IEC 27001:2022 įrodymų lūkesčius.

Sprendimas nėra trys atskiri pirminio vertinimo procesai. Sprendimas – vienas valdomas sunkumo modelis su atskirais reglamentavimo sluoksniais, išmatuojamais slenksčiais, eskalavimo taisyklėmis, sprendimų žurnalais ir įrodymų rinkimo reikalavimais. Praktikoje incidento sunkumas neturi būti skubotai parinkta etiketė. Tai turi būti kontroliuojamas verslo sprendimas, atsparus reguliavimo institucijų, auditorių, valdybos narių, klientų ir duomenų apsaugos pareigūno (DAP) patikrai.

Kodėl incidentų sunkumo klasifikavimas dabar yra valdybos lygmens kontrolė

Incidentų klasifikavimas anksčiau dažniausiai buvo techninis: kenkimo programinės įrangos sunkumas, paveikti kompiuteriai, išnaudoti pažeidžiamumai ir tai, ar duomenys buvo eksfiltruoti. 2026 m. jis taip pat yra teisinis, finansinis, visuomeninis ir sutartinis.

DORA skaitmeninį operacinį atsparumą paverčia finansų sektoriaus subjektų valdysenos prievole. Tikimasi, kad valdymo organas apibrėš, patvirtins, prižiūrės IRT rizikos valdymo sistemą ir liks už ją atsakingas. Tai apima IRT veiklos tęstinumą, reagavimo ir atkūrimo planus, reikšmingų incidentų pranešimo kanalus, IRT trečiųjų šalių riziką ir įgytą patirtį.

NIS2 padidina valdysenos svarbą esminiams ir svarbiems subjektams. Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų mokymuose. Ji taip pat susieja rizikos valdymo ir pranešimo apie incidentus nesėkmes su rimtomis priežiūros pasekmėmis. Esminiams subjektams maksimalios administracinės baudos bazinis dydis gali siekti bent EUR 10,000,000 arba 2 procentus visos pasaulinės metinės apyvartos, atsižvelgiant į tai, kuri suma didesnė. Svarbiems subjektams bazinis dydis yra bent EUR 7,000,000 arba 1,4 procento apyvartos, atsižvelgiant į tai, kuri suma didesnė.

GDPR prideda kitą perspektyvą. Asmens duomenų saugumo pažeidimas neapsiriboja patvirtintu viešu atskleidimu ar pavogtais failais. Jis apima atsitiktinį ar neteisėtą asmens duomenų sunaikinimą, praradimą, pakeitimą, neteisėtą atskleidimą arba neteisėtą prieigą prie jų. Duomenų valdytojai turi įvertinti riziką fiziniams asmenims ir įrodyti atskaitomybę dėl sprendimo pranešti arba nepranešti.

ISO/IEC 27001:2022 šioms prievolėms suteikia įrodymų pagrindą. Clauses 4.1 to 4.4 reikalauja, kad organizacija suprastų savo kontekstą, suinteresuotųjų šalių reikalavimus, taikymo sritį, sąsajas ir priklausomybes. Clauses 5.1 to 5.3 reikalauja vadovybės įsipareigojimo, politikos, vaidmenų, atsakomybės ir ataskaitų teikimo. Clauses 6.1.1 to 6.1.3 reikalauja rizika grindžiamo planavimo, rizikos vertinimo, rizikos tvarkymo ir Taikytinumo pareiškimo (SoA). Clauses 8.1 to 8.3 reikalauja operacinės kontrolės, pakeitimų kontrolės, saugomų įrodymų ir pakartotinio vertinimo pasikeitus rizikos sąlygoms. ISO/IEC 27001:2022

Kai vyksta incidento skambutis, klausimas neturėtų būti: „Kas mano, kad tai kritiška?“ Klausimas turėtų būti: „Ką mūsų patvirtinti kriterijai, teisiniai aktyvikliai, įrodymai ir eskalavimo taisyklės reikalauja daryti dabar?“

Vienas įvykis, trys reglamentavimo klasifikavimo sistemos

DORA, NIS2 ir GDPR incidentams nevartoja tos pačios kalbos. Tai pagrindinė priežastis, kodėl organizacijoms sunku pirmąją valandą.

DORA Article 17 reikalauja, kad finansų sektoriaus subjektai nustatytų su IRT susijusių incidentų valdymo procesą, kuris aptiktų ir valdytų IRT incidentus bei apie juos praneštų, registruotų su IRT susijusius incidentus ir reikšmingas kibernetines grėsmes, šalintų pagrindines priežastis, naudotų ankstyvojo perspėjimo indikatorius, kategorizuotų ir klasifikuotų incidentus, priskirtų vaidmenis, valdytų komunikaciją, eskaluotų reikšmingus incidentus vyresniajai vadovybei ir atkurtų saugias operacijas.

DORA Article 18 reikalauja klasifikuoti pagal tokius kriterijus kaip paveikti klientai, paveiktos sandorio šalys, operacijos, trukmė, prastova, geografinė aprėptis, duomenų praradimas, paveikiantis prieinamumą, autentiškumą, vientisumą ar konfidencialumą, paveiktų paslaugų kritiškumas ir ekonominis poveikis. DORA Article 19 reikalauja pranešti apie reikšmingus su IRT susijusius incidentus ir komunikuoti su klientais, kai paveikiami jų finansiniai interesai.

NIS2 Article 23 reikšmingą incidentą apibrėžia kaip incidentą, kuris sukėlė arba gali sukelti didelį veiklos sutrikimą ar finansinius nuostolius, arba paveikė ar gali paveikti kitus asmenis sukeldamas didelę materialinę ar nematerialinę žalą. Ji reikalauja per 24 valandas nuo sužinojimo apie reikšmingą incidentą pateikti ankstyvąjį perspėjimą, per 72 valandas – pranešimą apie incidentą, pagal prašymą – tarpines ataskaitas, o per vieną mėnesį nuo pranešimo apie incidentą – galutinę ataskaitą. Kai taikoma, paveikti paslaugų gavėjai taip pat turi būti informuoti apie priemones ar sprendimus, kurių jie gali imtis.

GDPR kelia privatumo rizikos klausimą. Ar saugumo pažeidimas lėmė asmens duomenų sunaikinimą, praradimą, pakeitimą, neteisėtą atskleidimą arba neteisėtą prieigą prie jų? Jei taip, duomenų valdytojas turi įvertinti riziką fizinių asmenų teisėms ir laisvėms. Jei tikėtina, kad pažeidimas sukels riziką, priežiūros institucijai paprastai turi būti pranešta per 72 valandas nuo sužinojimo. Jei tikėtina, kad jis sukels didelę riziką, paveikti fiziniai asmenys gali turėti būti informuoti nepagrįstai nedelsiant.

Todėl vienam incidentui reikalingas vienalaikis klasifikavimas.

Finansų sektoriaus subjektams DORA yra sektorinis Sąjungos teisės aktas, reglamentuojantis IRT rizikos valdymą ir pranešimo apie incidentus prievoles, kurios persidengia su NIS2. Tai nereiškia, kad NIS2 tampa nereikšminga. Ji vis tiek gali būti svarbi bendradarbiavimui, informacijos srautams, paslaugoms už DORA perimetro, nefinansinėms grupės įmonėms, debesijos paslaugoms, valdomoms paslaugoms ir sutartinėms klientų prievolėms. Sunkumo modelis turi fiksuoti ne tik rezultatą, bet ir taikymo logiką.

Clarysec modelis: klasifikuokite įvykį, o ne emociją

Clarysec pradeda nuo ISO/IEC 27002:2022 kontrolės 5.25 – informacijos saugumo įvykių vertinimo ir sprendimo – kaip tarpstandartinės atitikties atskaitos taško. Zenith Controls: The Cross-Compliance Guide Zenith Controls šią temą susieja per įrašą „Informacijos saugumo įvykių vertinimas ir sprendimas“ dėl kontrolės 5.25, kurį palaiko „Informacijos saugumo incidentų valdymo planavimas ir pasirengimas“ dėl kontrolės 5.24 ir „Įrodymų rinkimas“ dėl kontrolės 5.28.

Svarbiausias atitikties momentas dažnai nėra suvaldymas. Tai kelio išsišakojimas, kai saugumo įvykis tampa reglamentavimo požiūriu reikšmingu incidentu arba kai jis pagrįstai užregistruojamas kaip mažesnio sunkumo įvykis.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint šį momentą aprašo etape „Kontrolės priemonės praktikoje“, 23 žingsnyje:

„Ne kiekviena anomalija yra katastrofa. Ne kiekvienas įspėjimas reiškia kompromitavimą. Realiame pasaulyje saugumo komandos ir verslo padaliniai skęsta triukšme: prisijungimo bandymuose, žurnalų anomalijose, mažareikšmiuose politikos pažeidimuose, šešėlinės IT veikloje. Tikrasis iššūkis yra ne vien aptikimas, o gebėjimas atskirti nepavojingą nuo pavojingo ir žinoti, kas reikalauja eskalavimo.“

Šis sakinys tiksliai nusako operacinę problemą. SIEM įspėjimas automatiškai nereiškia reikšmingo incidento pagal DORA. Laikinas paslaugos sutrikimas automatiškai nereiškia reikšmingo incidento pagal NIS2. Įtartina duomenų bazės užklausa automatiškai nereiškia, kad apie ją reikia pranešti pagal GDPR. Kiekvienas iš jų gali tapti praneštinas, priklausomai nuo poveikio, apimties, duomenų, paveiktų šalių ir įrodymų.

Zenith Blueprint, Rizikos valdymo etapo 10 žingsnyje, taip pat rekomenduoja poveikio apibrėžtis pritaikyti prie verslo masto ir reglamentavimo rizikos:

„Apibrėžiant poveikį, tikslinga lygius susieti su konkrečiu jūsų verslo mastu. Pavyzdžiui, „reikšmingas finansinis poveikis = nuostolis > 100 tūkst. USD“ (pritaikykite pagal savo kontekstą). Taip pat atsižvelkite į reguliacinį poveikį: pavyzdžiui, asmens duomenų saugumo pažeidimas automatiškai gali būti „reikšmingas“ arba „sunkus“ dėl GDPR baudų ir pranešimo reikalavimų, net jei tiesioginis finansinis nuostolis neaiškus.“

Tai yra 2026 m. incidentų sunkumo klasifikavimo projektavimo principas: sunkumas yra verslo poveikis plius teisinis poveikis plius įrodymų patikimumas.

Praktinė incidentų sunkumo taksonomija DORA, NIS2 ir GDPR kontekste

Pagrįsta taksonomija turi atskirti vidinį sunkumą nuo reglamentavimo klasifikavimo. Vidinis sunkumas lemia reagavimo skubumą, išteklių paskirstymą ir eskalavimą vykdomajai vadovybei. Reglamentavimo klasifikavimas lemia pranešimą, teisinę peržiūrą ir išorinę komunikaciją.

Vidinio sunkumo lygis nėra galutinis reglamentavimo atsakymas. Tai veikimo režimas. SEV 3 įvykis po žurnalų peržiūros gali tapti praneštinas pagal GDPR. SEV 2 paslaugos sutrikimas gali nebūti reikšmingas DORA incidentas, jei poveikio slenksčiai nepasiekti. SEV 1 išpirkos reikalaujančios programinės įrangos incidentas vienu metu gali aktyvuoti DORA, NIS2, GDPR, klientų sutartis ir koordinavimą su teisėsauga.

Išsamesnė klasifikavimo matrica padeda komandai pereiti nuo įspėjimo prie veiksmų.

Modelis turi būti įtvirtintas politikoje, o ne paliktas stipriausiam balsui krizės skambutyje. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Valdysenos reikalavimai, clause 5.3.1, nustato:

„Generalinis direktorius, gavęs IT paslaugų teikėjo įžvalgas, privalo per vieną valandą nuo pranešimo klasifikuoti visus incidentus pagal sunkumą.“

Ta pati SME politika, Rizikos tvarkymas ir išimtys, clause 7.4.1, papildo:

„Kai susiję klientų duomenys, generalinis direktorius privalo įvertinti teisines pranešimo prievoles pagal GDPR, NIS2 arba DORA taikymą.“

Didesnėms organizacijoms skirta įmonės Incident Response Policy Incident Response Policy, Valdysenos reikalavimai, clause 5.3, formalizuoja tą pačią koncepciją:

„Incidentų klasifikavimas turi būti vykdomas pagal pakopinį modelį:“

Politikos kalba svarbi, nes reguliavimo institucijos ir auditoriai klausia, ar klasifikavimo kriterijai egzistavo iki incidento. Po fakto sukurta matrica yra silpnas įrodymas. Patvirtinta, apmokyta, išbandyta ir nuosekliai taikyta matrica yra pagrįsta.

Sprendimų žurnalas: svarbiausias įrodymų artefaktas

Kai auditoriai, reguliavimo institucijos ar valdybos nariai peržiūri incidentą, jie retai klausia tik „kas įvyko?“. Jie klausia: „Kada sužinojote, kas priėmė sprendimą, kokiais įrodymais remiantis ir kodėl nepranešėte anksčiau?“

Todėl Clarysec rekomenduoja sunkumo sprendimų žurnalą kiekvienam SEV 3 ir aukštesnio lygio įvykiui, taip pat bet kuriam įvykiui, susijusiam su asmens duomenimis, kritinėmis paslaugomis, finansų sektoriaus klientais, valdomomis paslaugomis, debesijos infrastruktūra ar tarpvalstybiniu poveikiu.

Tai tiesiogiai susiejama su ISO/IEC 27001:2022. Clause 8.1 reikalauja, kad procesai būtų suplanuoti, įgyvendinti ir kontroliuojami, o pakankama dokumentuota informacija būtų saugoma siekiant parodyti, kad jie veikė kaip suplanuota. Clauses 8.2 ir 8.3 reikalauja pakartotinio vertinimo įvykus reikšmingiems pokyčiams ir rizikos tvarkymo įrodymų saugojimo. Annex A controls A.5.24 to A.5.28 sudaro incidentų valdymo pagrindą: planavimą ir pasirengimą, įvykių vertinimą ir sprendimą, reagavimą, mokymąsi iš incidentų ir įrodymų rinkimą.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Įgyvendinimas ir atitiktis, clause 8.3.2, palaiko modelio GDPR pusę:

„Privatumo koordinatorius nustatys sunkumą, inicijuos suvaldymo veiksmus ir dokumentuos bylą“

Privatumo vertinimas neturi prasidėti tik tada, kai reglamentavimo terminas tampa nepatogiai artimas. Jis turi būti pirminio vertinimo darbo eigos dalis.

Praktinis pavyzdys: Sarah API incidento klasifikavimas

Grįžkime prie FinScale. Tai B2B fintech platforma, naudojanti debesijos infrastruktūrą, išorinį sukčiavimo analizės teikėją ir valdomų saugumo paslaugų teikėją. Kai kurioms veikloms tai yra DORA taikomas finansų sektoriaus subjektas. Ji taip pat yra skaitmeninių paslaugų teikėja, vykdanti NIS2 aktualias operacijas vienoje valstybėje narėje. Ji tvarko klientų asmens duomenis kaip duomenų valdytoja paskyrų paslaugoms ir kaip duomenų tvarkytoja kai kuriems verslo klientams.

02:17 aptinkamas neįprastas API srautas. 02:35 atidaromas incidento įrašas. 03:00 Sarah kartu su incidento vadovu užbaigia pradinį pirminį vertinimą.

Pirmiausia nustatomas vidinis sunkumas. Incidentas 19 minučių paveikė klientų valdymo skydelio prieinamumą, apėmė įtartinus prieigos raktus ir palietė kritinę klientams skirtą funkciją. Kol laukiama patvirtinimo, jis klasifikuojamas kaip SEV 3 Vidutinis, eskaluojant incidento vadovui, privatumo koordinatoriui, teisininkui ir paslaugos savininkui.

Antra, atliekama DORA patikra. Komanda tikrina paveiktus klientus, sandorio šalis, operacijas, trukmę, prastovą, geografinę aprėptį, duomenų praradimą, kritiškumą ir ekonominį poveikį. Nepatvirtinta jokių nepavykusių ar pakeistų operacijų. Prastova ribota. Duomenų praradimas neįrodytas. Tačiau kadangi galėjo būti paveiktas kritinis finansinės paslaugos komponentas ir klientų finansiniai interesai, incidentas lieka stebimas pagal DORA ir gali būti perklasifikuotas.

Trečia, užfiksuojama NIS2 patikra. Komanda pažymi, kad DORA yra pagrindinis sektorinis pranešimo režimas finansų sektoriaus subjektui taikomoms prievolėms. Ji taip pat tikrina, ar incidentas paveikia paslaugas arba klientus už DORA perimetro. Šiame etape nepatvirtinta jokio sunkaus veiklos sutrikimo ar didelės žalos.

Ketvirta, pradedama GDPR patikra. Įtartini raktai galėjo suteikti prieigą prie klientų valdymo skydelio duomenų. Privatumo koordinatorius dokumentuoja duomenų kategorijas, paveiktus naudotojus, rakto apimtį, peržiūrėtus žurnalus, tai, ar duomenys buvo peržiūrėti arba eksportuoti, ir apsaugos priemones, tokias kaip rakto galiojimo pabaiga ir prieigos kontrolė.

04:20 žurnalų analizė parodo, kad du raktai buvo panaudoti prieigai prie 41 kliento valdymo skydelio metaduomenų, įskaitant vardus, paskyrų ID ir operacijų būseną, tačiau ne mokėjimo prisijungimo duomenis ar tapatybės dokumentus. Komanda atnaujina incidentą į SEV 2 Reikšmingas, nes buvo paveiktas asmens duomenų konfidencialumas ir gali reikėti komunikuoti su klientais. DAP įvertina GDPR riziką fiziniams asmenims. DORA sprendimas peržiūrimas pagal poveikį klientams, operacijoms ir ekonominį poveikį.

Tai yra praktinė modelio vertė. Pradinis klasifikavimas nėra galutinė teisinė išvada. Tai įrodymais grindžiamas sprendimas, kuris gali būti atnaujinamas vystantis faktams.

Žurnalų tvarkymas, stebėsena ir kriminalistiniai įrodymai: įrodymo sluoksnis

Sunkumo modelis be įrodymų yra susitikimo nuomonė. 2026 m. lūkestis – kad klasifikavimą pagrįstų žurnalai, stebėsena, išsaugoti artefaktai ir įrodymų saugojimo bei perdavimo grandinė.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Įgyvendinimas ir atitiktis, clause 8.3.4, nustato:

„Pažeidimų tyrimai turi būti pagrįsti pakankamais žurnalais, kad būtų laikomasi atskaitomybės principo pagal GDPR ir DORA“

Kriminalistinis tvarkymas yra ne mažiau svarbus. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Valdysenos reikalavimai, clause 5.3.1, reikalauja:

„Kiekvienam incidentui turi būti tvarkomas paprastas įrodymų saugojimo ir perdavimo grandinės žurnalas (pvz., Excel failas arba šabloninis dokumentas).“

Įmonės aplinkoms skirta Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Valdysenos reikalavimai, clause 5.5, reikalauja:

„Visi surinkti įrodymai turi būti unikaliai identifikuoti, paženklinti ir saugomi saugioje saugykloje su:“

Zenith Blueprint, Kontrolės priemonių praktikoje etapo 23 žingsnyje, paaiškina, kodėl tai svarbu ISO/IEC 27002:2022 kontrolei 5.28:

„Įvykus informacijos saugumo incidentui, vienas kritiškiausių, bet dažnai nuvertinamų reagavimo elementų yra įrodymai. Ne žurnalai, ne ekrano kopijos, ne laisvi pasakojimai, o tinkamai išsaugoti, įrodymų saugojimo ir perdavimo grandinę gerbiantys ir klastojimui atsparūs įrodymai.“

Praktinis įrodymų paketas dėl reikšmingo arba potencialiai praneštino incidento turėtų apimti:

• Incidento įrašą ir laiko juostą
• Sunkumo sprendimų žurnalą ir perklasifikavimo istoriją
• SIEM įspėjimus, EDR įspėjimus, debesijos žurnalus ir tapatybės žurnalus
• Duomenų prieigos žurnalus ir eksporto žurnalus
• Paveikto turto ir paslaugų apskaitos įrašus
• Klientų, operacijų ir geografijos poveikio vertinimą
• DORA, NIS2 ir GDPR patikros darbalapį
• DAP arba teisinį vertinimą
• Komunikacijos patvirtinimus ir išsiųstas žinutes
• Įrodymų saugojimo ir perdavimo grandinės įrašą
• Pagrindinės priežasties analizę
• Korekcinius veiksmus ir įgytą patirtį

Šis įrodymų paketas taip pat palaiko ISO/IEC 27001:2022 Annex A controls A.8.15 žurnalų tvarkymą, A.8.16 stebėsenos veiklas, A.5.28 įrodymų rinkimą, A.5.27 mokymąsi iš informacijos saugumo incidentų, A.5.31 teisinius, įstatyminius, reglamentavimo ir sutartinius reikalavimus bei A.5.34 privatumą ir asmenį identifikuojančios informacijos apsaugą.

Tarpstandartinis atitikties susiejimas: sukurkite vieną kartą, atsakykite daugeliui auditorių

Stipriausi incidentų sunkumo modeliai sukuriami vieną kartą ir susiejami daug kartų. Zenith Controls sukurtas kaip tarpstandartinės atitikties kompasas šiam darbui. Šiai temai pagrindiniai ISO/IEC 27002:2022 įrašai yra 5.24 informacijos saugumo incidentų valdymo planavimas ir pasirengimas, 5.25 informacijos saugumo įvykių vertinimas ir sprendimas, 5.26 reagavimas į informacijos saugumo incidentus, 5.27 mokymasis iš informacijos saugumo incidentų ir 5.28 įrodymų rinkimas.

Šios kontrolės priemonės natūraliai susiejamos su ISO/IEC 27001:2022 valdymo sistema. Clauses 4, 5, 6 ir 8 apibrėžia taikymo sritį, vadovavimą, rizikos kriterijus, tvarkymą ir operacinius įrodymus. ISO/IEC 27002:2022 suteikia kontrolės priemonių įgyvendinimo kalbą. ISO 22301 tipo veiklos tęstinumo mąstymas palaiko sutrikimų slenksčius, atkūrimo prioritetus ir krizių valdymą. ISO/IEC 27035 tipo incidentų valdymo praktikos palaiko struktūrizuotą aptikimą, pranešimą, vertinimą, reagavimą ir mokymąsi. ISO/IEC 27701 tipo privatumo valdysena palaiko asmens duomenų saugumo pažeidimų vaidmenis, duomenų valdytojo ir tvarkytojo aspektus, privatumo įrodymus ir atskaitomybę.

Tas pats modelis susiejamas su NIST Cybersecurity Framework 2.0. GOVERN funkcija reikalauja suprasti ir valdyti teisines, reglamentavimo, sutartines, privatumo ir pilietinių laisvių prievoles. Ji taip pat tikisi, kad bus apibrėžtas rizikos apetitas, vaidmenys, įgaliojimai, politikos ir priežiūra. DETECT, RESPOND ir RECOVER funkcijos palaiko pirminį vertinimą, analizę, eskalavimą, suvaldymą, atkūrimą, komunikaciją ir tobulinimą.

Nauda praktinė. Kai DORA priežiūros institucija prašo pagrindimo dėl reikšmingo su IRT susijusio incidento, NIS2 institucija klausia apie 24 valandų ankstyvojo perspėjimo sprendimą, duomenų apsaugos institucija klausia, kodėl GDPR pranešimas buvo arba nebuvo pateiktas, o ISO auditorius klausia, ar ISVS veikė kaip suplanuota, organizacija gali atsakyti remdamasi tuo pačiu įrodymų rinkiniu.

Kaip auditoriai ir reguliavimo institucijos testuos jūsų modelį

ISO/IEC 27001:2022 auditorius paprastai pradės nuo taikymo srities ir teisinių reikalavimų. Jis klaus, ar DORA, NIS2, GDPR, klientų sutartys ir IRT trečiųjų šalių prievolės buvo identifikuotos kaip suinteresuotųjų šalių reikalavimai. Tada jis seks pėdsaką į rizikos kriterijus, Taikytinumo pareiškimą (SoA), incidentų procedūras, operacinius įrašus ir įrodymų saugojimą. Jam reikia įrodymo, kad klasifikavimo procesas nebuvo sukurtas incidento metu.

DORA priežiūros institucija arba vidaus audito komanda ieškos gyvavimo ciklo kilpos: incidentų valdymo proceso, ankstyvojo perspėjimo indikatorių, klasifikavimo kriterijų, reikšmingo incidento eskalavimo, komunikacijos su klientais, pagrindinės priežasties, galutinių poveikio rodiklių, atsparumo testavimo ir valdymo organo priežiūros. Jie taip pat klaus, ar buvo įvertintos IRT trečiųjų šalių priklausomybės, ypač kai dalyvavo debesijos, SaaS, valdomo saugumo ar išorinių paslaugų teikėjai.

Į NIS2 orientuotas auditorius arba institucija tikrins, ar subjektas gali identifikuoti reikšmingus incidentus, laikytis etapinių terminų, komunikuoti su paveiktais paslaugų gavėjais ir pateikti tarpvalstybinio poveikio vertinimo įrodymus. Jie susies incidentų valdymą su Article 21 rizikos valdymo priemonėmis, įskaitant veiklos tęstinumą, krizių valdymą, tiekimo grandinės saugumą, prieigos kontrolę, turto valdymą ir mokymus.

GDPR DAP arba priežiūros institucija nagrinės, ar organizacija identifikavo asmens duomenis, vaidmenis, duomenų subjektus, kategorijas, paveiktas sistemas, pažeidimo tipą ir riziką fiziniams asmenims. Jie tikrins, ar duomenų valdytojas gali įrodyti atskaitomybę ir ar duomenų tvarkytojo pranešimai duomenų valdytojams buvo savalaikiai ir išsamūs.

ISACA arba COBIT 2019 tipo auditorius sutelks dėmesį į valdysenos įrodymus. Kas patvirtino sunkumo taksonomiją? Kam priklauso rizika? Kokie rodikliai teikiami vadovybei? Kaip tvarkomos išimtys? Kaip įgyta patirtis paverčiama kontrolės priemonių patobulinimais?

Dažni incidentų klasifikavimo nesėkmių modeliai

Pirmoji nesėkmė – mąstymas viena etikete. Komandos įvykį klasifikuoja kaip aukštą, vidutinį arba žemą, bet atskirai neįvertina DORA, NIS2 ir GDPR aktyviklių. Rezultatas – sunkumo etiketė, kuri negali paaiškinti pranešimo sprendimo.

Antroji nesėkmė – patvirtinto pažeidimo šališkumas. Komandos laukia absoliutaus duomenų eksfiltracijos įrodymo prieš įtraukdamos privatumo ar teisininkų funkciją. GDPR pažeidimo vertinimas dažnai prasideda nuo galimos neteisėtos prieigos, praradimo, pakeitimo ar atskleidimo, o ne tik nuo patvirtinto duomenų paskelbimo.

Trečioji nesėkmė – terminų painiava. NIS2 ir GDPR terminai priklauso nuo sužinojimo ir vertinimo. Jei incidento įrašas nefiksuoja sužinojimo laiko, klasifikavimo laiko ir eskalavimo laiko, organizacijai gali būti sunku įrodyti savalaikiškumą.

Ketvirtoji nesėkmė – kriminalistika po sutvarkymo. Inžinieriai periodiškai keičia raktus, perkuria kompiuterius ir ištrina laikinus įrodymus dar prieš aktyvuojant tyrimo režimą. Tai gali sunaikinti įrodymus, reikalingus reglamentavimo, sutartinei ar teisinei peržiūrai.

Penktoji nesėkmė – tiekėjų aklumas. DORA, NIS2 ir NIST CSF 2.0 pabrėžia trečiųjų šalių ir tiekimo grandinės riziką. Jei debesijos paslaugų teikėjas, valdomų paslaugų teikėjas, mokėjimų tvarkytojas, tapatybės teikėjas ar SaaS tiekėjas yra incidento grandinės dalis, klasifikavimo modelis turi apimti poveikį tiekėjui ir sutartines pranešimo prievoles.

Clarysec įgyvendinimo kontrolinis sąrašas 2026 m.

Siekdama įdiegti pagrįstą incidentų sunkumo klasifikavimo modelį, Clarysec rekomenduoja šią seką:

1. Patvirtinkite DORA, NIS2, GDPR, klientų sutarčių ir sektorinių taisyklių taikymą.
2. Atnaujinkite ISVS taikymo sritį ir suinteresuotųjų šalių reikalavimus pagal ISO/IEC 27001:2022.
3. Apibrėžkite vidinius sunkumo lygius su išmatuojamais prastovos, duomenų, klientų, geografijos, finansinių nuostolių ir kritiškumo slenksčiais.
4. Į incidento įrašo darbo eigą įtraukite atskirus DORA, NIS2 ir GDPR patikros klausimus.
5. Apibrėžkite eskalavimo aktyviklius incidento vadovui, DAP, teisininkams, vyresniajai vadovybei ir valdybai.
6. Sukurkite sunkumo sprendimų žurnalo šabloną.
7. Susiekite klasifikavimą su įrodymų rinkimo ir įrodymų saugojimo bei perdavimo grandinės procedūromis.
8. Patikrinkite žurnalavimo aprėptį tapatybės, debesijos, taikomųjų programų, duomenų bazių, tinklo ir tiekėjų įvykiams.
9. Vykdykite stalo pratybas DORA reikšmingo incidento, NIS2 reikšmingo incidento ir GDPR pažeidimo scenarijams.
10. Įgytą patirtį įtraukite į rizikos tvarkymą, Taikytinumo pareiškimą (SoA), mokymus ir atsparumo testavimą.

Zenith Blueprint, Kontrolės priemonių praktikoje etapo 16 žingsnyje, sustiprina žmogiškąją šio modelio pusę: pranešimai turi būti registruojami, vertinami pirminio vertinimo būdu, eskaluojami pagal reagavimo į incidentus planą, o net mažareikšmiai įvykiai turi būti sekami, nes tendencijos atskleidžia kontrolės priemonių trūkumus. Jis skatina žemo slenksčio pranešimo nuostatą: „Jei abejojate, praneškite.“

Šis kultūrinis aspektas yra kritinis. Sunkumo modelis žlunga, jei darbuotojai delsia pranešti, nes bijo perteklinės reakcijos. Tikslas – greitas pranešimas, disciplinuotas pirminis vertinimas ir pagrįstas klasifikavimas.

Paverskite incidento neapibrėžtumą auditui tinkamais įrodymais

2026 m. incidentų sunkumo klasifikavimas nebėra vien SOC sprendimas. Tai reguliuojamas valdysenos procesas, kuris turi susieti DORA reikšmingo su IRT susijusio incidento kriterijus, NIS2 reikšmingo incidento slenksčius, GDPR pažeidimo riziką ir ISO/IEC 27001:2022 įrodymus.

Organizacijos, geriausiai veikiančios incidentų metu, nebus tos, kurios turi storiausią reagavimo segtuvą. Tai bus organizacijos, galinčios greitai atsakyti į keturis klausimus ir vėliau pagrįsti kiekvieną atsakymą:

• Kas įvyko?
• Koks incidento sunkumas?
• Kokios reglamentavimo prievolės gali būti taikomos?
• Kokie įrodymai pagrindžia sprendimą?

Clarysec padeda organizacijoms nutiesti šį tiltą per politikų šablonus, sunkumo taksonomijas, sprendimų žurnalus, stalo pratybų scenarijus ir tarpstandartinius atitikties susiejimus. Pradėkite nuo incidentų politikų, patikrinkite savo rizikos kriterijus naudodami Zenith Blueprint Zenith Blueprint, ir naudokite Zenith Controls Zenith Controls, kad susietumėte ISO/IEC 27002:2022 controls 5.24, 5.25, 5.26, 5.27 ir 5.28 su DORA, NIS2, GDPR, NIST CSF ir audito lūkesčiais.

Jei jūsų komanda per pirmąją valandą negali atsakyti „Ar tai reikšmingas DORA incidentas, reikšmingas NIS2 incidentas arba pagal GDPR praneštinas pažeidimas?“, kitas žingsnis nėra dar vienas bendrinis reagavimo į incidentus planas. Kitas žingsnis – pagrįstas incidentų sunkumo klasifikavimo veiklos modelis, išbandytas prieš ateinant kitam 02:17 skambučiui.

Pasirengę pakeisti paniką procesu? Atsisiųskite Clarysec reagavimo į incidentus ir įrodymų rinkimo politikų šablonus, peržiūrėkite dabartinę savo sunkumo taksonomiją pagal Zenith Blueprint arba paprašykite Clarysec pasirengimo vertinimo, kad sukurtumėte auditui tinkamą DORA, NIS2, GDPR ir ISO/IEC 27001 incidentų klasifikavimo modelį.