Clasificarea severității incidentelor pentru DORA, NIS2 și GDPR

Apelul de incident de la 02:17 care devine o decizie de conformitate

La 02:17, într-o dimineață de joi, Sarah, CISO-ul FinScale, vede prima alertă: trafic API anormal, creșteri bruște ale autentificărilor eșuate și latență a tabloului de bord pentru plăți peste 3000 ms. În câteva minute, suportul pentru clienți raportează erori privind starea plăților. Furnizorul cloud afirmă că nu există un incident la nivelul întregii platforme. SOC observă token-uri de acces suspecte din două regiuni geografice. Echipa de produs confirmă că tabloul de bord este din nou online după 19 minute, dar doisprezece clienți au deschis deja tichete.

Până la 03:05, Sarah este în celula de criză împreună cu coordonatorul incidentului, consilierul juridic, responsabilul pentru confidențialitate, responsabilul operațiunilor cloud și sponsorul executiv. Întrebarea tehnică este relativ clară: ce s-a întâmplat cu gateway-ul API? Întrebările de conformitate sunt mai dificile:

1. Este acesta un incident major legat de TIC în sensul DORA?
2. Este acesta un incident semnificativ în sensul NIS2?
3. Există o încălcare a securității datelor cu caracter personal în sensul GDPR care impune notificare?
4. Poate organizația să demonstreze cum a ajuns la aceste răspunsuri?

Răspunsul greșit poate crea expunere în fața autorităților de reglementare. Răspunsul întârziat poate rata o fereastră de raportare. Răspunsul nedocumentat poate eșua la un audit ISO/IEC 27001:2022 câteva luni mai târziu.

Aceasta este provocarea răspunsului la incidente în 2026. Multe organizații au un plan de răspuns la incidente, proceduri de analiză forensică, playbook-uri de confidențialitate și modele de comunicare de criză. Mai puține au un model justificabil de clasificare a severității incidentelor, care transformă un eveniment de securitate zgomotos într-o decizie documentată în raport cu așteptările privind dovezile din DORA, NIS2, GDPR și ISO/IEC 27001:2022.

Soluția nu constă în trei procese separate de triaj. Soluția este un singur model de severitate guvernat, cu straturi de evaluare reglementară distincte, praguri măsurabile, reguli de escaladare, jurnale de decizie și cerințe de colectare a dovezilor. Practic, severitatea incidentului nu trebuie să fie o etichetă aleasă sub presiune. Trebuie să fie o decizie de business controlată, care rezistă examinării autorităților de reglementare, auditorilor, membrilor consiliului de administrație, clienților și DPO.

De ce clasificarea severității incidentelor este acum un control la nivelul consiliului de administrație

Clasificarea incidentelor era înainte în principal tehnică: severitatea programelor malware, gazdele afectate, vulnerabilitățile exploatate și dacă datele au fost exfiltrate. În 2026, ea este și juridică, financiară, societală și contractuală.

DORA transformă reziliența operațională digitală într-o obligație de guvernanță pentru entitățile financiare. Organul de conducere trebuie să definească, să aprobe, să supravegheze și să rămână responsabil pentru cadrul de management al riscurilor TIC. Aceasta include continuitatea activității TIC, planurile de răspuns și recuperare, canalele de raportare a incidentelor majore, riscul TIC asociat terților și lecțiile învățate.

NIS2 ridică miza guvernanței pentru entitățile esențiale și importante. Article 20 impune organelor de conducere să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire. De asemenea, corelează eșecurile în managementul riscurilor și raportarea incidentelor cu consecințe grave de supraveghere. Pentru entitățile esențiale, plafoanele amenzilor administrative maxime pot ajunge la cel puțin 10.000.000 EUR sau 2% din cifra de afaceri anuală totală la nivel mondial, oricare dintre valori este mai mare. Pentru entitățile importante, pragul de referință este de cel puțin 7.000.000 EUR sau 1,4% din cifra de afaceri, oricare dintre valori este mai mare.

GDPR adaugă o perspectivă diferită. O încălcare a securității datelor cu caracter personal nu se limitează la divulgarea publică confirmată sau la fișiere furate. Ea include distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat la date cu caracter personal, accidental ori ilegal. Operatorii trebuie să evalueze riscul pentru persoane și să demonstreze responsabilitatea pentru decizia de a notifica sau de a nu notifica.

ISO/IEC 27001:2022 oferă acestor obligații o coloană vertebrală de dovezi. Clauzele 4.1 până la 4.4 impun organizației să își înțeleagă contextul, cerințele părților interesate, domeniul de aplicare, interfețele și dependențele. Clauzele 5.1 până la 5.3 impun angajamentul conducerii, politica, rolurile, responsabilitățile și raportarea. Clauzele 6.1.1 până la 6.1.3 impun planificarea bazată pe risc, evaluarea riscurilor, tratarea riscurilor și o Declarație de aplicabilitate. Clauzele 8.1 până la 8.3 impun control operațional, controlul schimbărilor, dovezi păstrate și reevaluare atunci când condițiile de risc se schimbă. ISO/IEC 27001:2022

Când are loc apelul de incident, întrebarea nu trebuie să fie „Cine consideră că este critic?”. Întrebarea trebuie să fie „Ce ne impun criteriile aprobate, declanșatoarele juridice, dovezile și regulile de escaladare să facem acum?”.

Un eveniment, trei sisteme de clasificare reglementară

DORA, NIS2 și GDPR nu folosesc același limbaj pentru incidente. Acesta este motivul principal pentru care organizațiile întâmpină dificultăți în prima oră.

DORA Article 17 impune entităților financiare să stabilească un proces de gestionare a incidentelor legate de TIC care detectează, gestionează și notifică incidentele TIC, înregistrează incidentele legate de TIC și amenințările cibernetice semnificative, tratează cauzele-rădăcină, utilizează indicatori de avertizare timpurie, categorizează și clasifică incidentele, atribuie roluri, gestionează comunicările, escaladează incidentele majore către conducerea superioară și restabilește operațiunile securizate.

DORA Article 18 impune clasificarea pe baza unor criterii precum clienții afectați, contrapărțile afectate, tranzacțiile, durata, indisponibilitatea, răspândirea geografică, pierderea de date care afectează disponibilitatea, autenticitatea, integritatea sau confidențialitatea, criticitatea serviciilor afectate și impactul economic. DORA Article 19 impune raportarea incidentelor majore legate de TIC și comunicarea către clienți atunci când interesele financiare ale acestora sunt afectate.

NIS2 Article 23 definește un incident semnificativ ca fiind unul care a cauzat sau este capabil să cauzeze perturbări operaționale severe ori pierderi financiare sau care a afectat ori este capabil să afecteze alte persoane prin producerea unor prejudicii materiale sau nemateriale considerabile. Acesta impune o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință a incidentului semnificativ, o notificare a incidentului în termen de 72 de ore, rapoarte intermediare la cerere și un raport final în termen de o lună de la notificarea incidentului. După caz, destinatarii serviciilor afectați trebuie informați și cu privire la măsurile sau remediile pe care le pot lua.

GDPR pune o întrebare de risc privind protecția datelor. A cauzat o încălcare a securității distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat la date cu caracter personal? Dacă da, operatorul trebuie să evalueze riscul pentru drepturile și libertățile persoanelor fizice. Dacă încălcarea este susceptibilă să genereze un risc, autoritatea de supraveghere trebuie, în general, notificată în termen de 72 de ore de la luarea la cunoștință. Dacă este susceptibilă să genereze un risc ridicat, persoanele afectate pot trebui informate fără întârzieri nejustificate.

Prin urmare, un singur incident necesită clasificare simultană.

Pentru entitățile financiare, DORA este actul juridic al Uniunii specific sectorului pentru managementul riscurilor TIC și obligațiile de raportare a incidentelor care se suprapun cu NIS2. Aceasta nu face NIS2 irelevantă. NIS2 poate conta în continuare pentru cooperare, fluxuri de informații, servicii din afara perimetrului DORA, entități nefinanciare din grup, servicii cloud, servicii administrate și obligații contractuale față de clienți. Modelul de severitate trebuie să înregistreze nu doar rezultatul, ci și raționamentul privind aplicabilitatea.

Modelul Clarysec: clasificați evenimentul, nu emoția

Clarysec pornește de la controlul ISO/IEC 27002:2022 5.25, evaluarea și decizia privind evenimentele de securitate a informațiilor, ca ancoră de conformitate încrucișată. În Zenith Controls: The Cross-Compliance Guide Zenith Controls, acest subiect este mapat prin intrarea „Evaluarea și decizia privind evenimentele de securitate a informațiilor” pentru controlul 5.25, sprijinită de „Planificarea și pregătirea managementului incidentelor SI” pentru controlul 5.24 și „Colectarea dovezilor” pentru controlul 5.28.

Cel mai important moment de conformitate nu este adesea conținerea. Este bifurcația în care un eveniment de securitate devine incident reglementat sau este înregistrat în mod justificabil ca eveniment cu severitate mai redusă.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint descrie acest moment în faza Controale în acțiune, Pasul 23:

„Nu orice anomalie este un dezastru. Nu orice alertă semnalează o compromitere. În lumea reală, echipele de securitate și unitățile de business sunt copleșite de zgomot, tentative de autentificare, anomalii în jurnale, încălcări minore ale politicilor, activitate shadow IT. Provocarea reală nu constă doar în detectare, ci în distingerea elementelor inofensive de cele dăunătoare și în a ști ce necesită escaladare.”

Această frază surprinde problema operațională. O alertă SIEM nu este automat echivalentă cu un incident major DORA. O indisponibilitate temporară nu este automat echivalentă cu un incident semnificativ NIS2. O interogare suspectă a unei baze de date nu este automat notificabilă în temeiul GDPR. Fiecare poate deveni raportabilă în funcție de impact, domeniu, date, părți afectate și dovezi.

Zenith Blueprint, faza Managementul riscurilor, Pasul 10, recomandă, de asemenea, ca definițiile impactului să fie adaptate la dimensiunea activității și la expunerea reglementară:

„Atunci când definiți impactul, este prudent să corelați nivelurile cu dimensiunea specifică a activității dumneavoastră. De exemplu, «Impact financiar major = pierdere > 100k USD» (ajustați la contextul dumneavoastră). Luați în considerare și impactul reglementar: de exemplu, o încălcare a securității datelor cu caracter personal ar putea fi automat «Majoră» sau «Severă» din cauza amenzilor GDPR și a cerințelor de notificare, chiar dacă pierderea financiară directă este neclară.”

Acesta este principiul de proiectare pentru clasificarea severității incidentelor în 2026: severitatea înseamnă impact asupra activității plus impact juridic plus nivel de încredere în dovezi.

O taxonomie practică a severității incidentelor pentru DORA, NIS2 și GDPR

O taxonomie justificabilă trebuie să separe severitatea internă de clasificarea reglementară. Severitatea internă determină urgența răspunsului, alocarea resurselor și escaladarea către executivi. Clasificarea reglementară determină notificarea, revizuirea juridică și comunicarea externă.

Nivelul intern de severitate nu este răspunsul reglementar final. Este modul operațional. Un eveniment SEV 3 poate deveni notificabil în temeiul GDPR după revizuirea jurnalelor. O indisponibilitate SEV 2 poate să nu fie un incident major DORA dacă pragurile de impact nu sunt îndeplinite. Un incident ransomware SEV 1 poate declanșa simultan DORA, NIS2, GDPR, contracte cu clienții și coordonare cu organele de aplicare a legii.

O matrice de clasificare mai detaliată ajută echipa să treacă de la alertă la acțiune.

Modelul trebuie integrat în politică, nu lăsat la dispoziția celei mai puternice voci din celula de criză. Politica pentru IMM-uri Incident Response Policy-sme Incident Response Policy-sme - SME, Cerințe de guvernanță, clauza 5.3.1, prevede:

„Directorul general, cu contribuția furnizorului IT, trebuie să clasifice toate incidentele în funcție de severitate în termen de o oră de la notificare.”

Aceeași politică pentru IMM-uri, Tratarea riscurilor și excepții, clauza 7.4.1, adaugă:

„Atunci când sunt implicate date ale clienților, Directorul general trebuie să evalueze obligațiile legale de notificare pe baza aplicabilității GDPR, NIS2 sau DORA.”

Pentru organizații mai mari, Incident Response Policy la nivel enterprise Incident Response Policy, Cerințe de guvernanță, clauza 5.3, formalizează același concept:

„Clasificarea incidentelor trebuie să urmeze un model pe niveluri:”

Limbajul politicii contează deoarece autoritățile de reglementare și auditorii vor întreba dacă existau criterii de clasificare înainte de incident. O matrice inventată după fapt este o dovadă slabă. O matrice aprobată, predată, exersată și utilizată consecvent este justificabilă.

Jurnalul deciziilor: cel mai important artefact de dovadă

Atunci când auditorii, autoritățile de reglementare sau membrii consiliului de administrație revizuiesc un incident, rareori întreabă doar „Ce s-a întâmplat?”. Ei întreabă „Când ați știut, cine a decis, pe baza căror dovezi și de ce nu ați notificat mai devreme?”.

De aceea, Clarysec recomandă un jurnal al deciziilor de severitate pentru fiecare eveniment SEV 3 și peste, precum și pentru orice eveniment care implică date cu caracter personal, servicii critice, clienți financiari, servicii administrate, infrastructură cloud sau impact transfrontalier.

Acest lucru se mapează direct la ISO/IEC 27001:2022. Clauza 8.1 impune ca procesele să fie planificate, implementate și controlate, cu informații documentate suficiente păstrate pentru a arăta că au funcționat conform planului. Clauzele 8.2 și 8.3 impun reevaluarea atunci când apar schimbări semnificative și păstrarea dovezilor privind tratarea riscurilor. Controalele din Anexa A A.5.24 până la A.5.28 oferă coloana vertebrală a gestionării incidentelor: planificare și pregătire, evaluarea și decizia privind evenimentele, răspuns, învățare din incidente și colectarea dovezilor.

Politica pentru IMM-uri Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Aplicare și conformitate, clauza 8.3.2, sprijină partea GDPR a modelului:

„Responsabilul pentru confidențialitate va determina severitatea, va iniția acțiuni de conținere și va documenta cazul”

Evaluarea de confidențialitate nu trebuie să înceapă după ce ceasul reglementar devine inconfortabil. Ea aparține fluxului de lucru de triaj.

Exemplu practic: clasificarea incidentului API al lui Sarah

Revenim la FinScale. Este o platformă fintech B2B care utilizează infrastructură cloud, un furnizor extern de analiză a fraudelor și un furnizor de securitate administrată. Pentru anumite activități, este o entitate financiară vizată de DORA. Este, de asemenea, un furnizor de servicii digitale cu operațiuni relevante pentru NIS2 într-un stat membru. Prelucrează date cu caracter personal ale clienților ca operator pentru serviciile de cont și ca persoană împuternicită de operator pentru unii clienți enterprise.

La 02:17, este detectat trafic API anormal. La 02:35, este deschis tichetul de incident. La 03:00, Sarah finalizează triajul inițial cu coordonatorul incidentului.

În primul rând, se stabilește severitatea internă. Incidentul a afectat disponibilitatea tabloului de bord al clienților timp de 19 minute, a implicat token-uri de acces suspecte și a vizat o funcție critică expusă clienților. Este clasificat ca SEV 3 Moderat în așteptarea confirmării, cu escaladare către coordonatorul incidentului, responsabilul pentru confidențialitate, consilierul juridic și proprietarul serviciului.

În al doilea rând, se finalizează evaluarea DORA. Echipa verifică clienții afectați, contrapărțile, tranzacțiile, durata, indisponibilitatea, răspândirea geografică, pierderea de date, criticitatea și impactul economic. Nu sunt confirmate tranzacții eșuate sau modificate. Indisponibilitatea este limitată. Nu este dovedită nicio pierdere de date. Totuși, deoarece o componentă critică a serviciului financiar și interesele financiare ale clienților pot fi afectate, incidentul rămâne sub monitorizare DORA și poate fi reclasificat.

În al treilea rând, este înregistrată evaluarea NIS2. Echipa notează că DORA este regimul principal de raportare sectorială pentru obligațiile entității financiare vizate. De asemenea, verifică dacă incidentul afectează servicii sau clienți din afara perimetrului DORA. În această etapă nu este confirmată nicio perturbare operațională severă și niciun prejudiciu considerabil.

În al patrulea rând, începe evaluarea GDPR. Token-urile suspecte ar fi putut permite accesul la datele din tabloul de bord al clienților. Responsabilul pentru confidențialitate documentează categoriile de date, utilizatorii afectați, domeniul de aplicare al token-urilor, jurnalele revizuite, dacă datele au fost vizualizate sau exportate și măsurile de protecție, cum ar fi expirarea token-urilor și controalele de acces.

Până la 04:20, analiza jurnalelor arată că două token-uri au fost utilizate pentru a accesa metadatele din tabloul de bord pentru 41 de clienți, inclusiv nume, ID-uri de cont și starea tranzacțiilor, dar nu credențiale de plată sau documente de identitate. Echipa actualizează incidentul la SEV 2 Major deoarece confidențialitatea datelor cu caracter personal a fost afectată și comunicarea către clienți poate fi necesară. DPO evaluează riscul GDPR pentru persoane. Decizia DORA este revizuită pe baza impactului asupra clienților, impactului asupra tranzacțiilor și impactului economic.

Aceasta este valoarea practică a modelului. Clasificarea inițială nu este o concluzie juridică finală. Este o decizie bazată pe dovezi, care poate fi actualizată pe măsură ce faptele se dezvoltă.

Jurnalizare, monitorizare și dovezi forensice: stratul probator

Un model de severitate fără dovezi este o opinie de ședință. Așteptarea pentru 2026 este ca clasificarea să fie susținută de jurnale, monitorizare, artefacte conservate și lanț de custodie.

Politica pentru IMM-uri Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Aplicare și conformitate, clauza 8.3.4, prevede:

„Investigațiile privind încălcările trebuie susținute de jurnale adecvate pentru a îndeplini principiul responsabilității prevăzut de GDPR și DORA”

Gestionarea dovezilor forensice este la fel de importantă. Politica pentru IMM-uri Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Cerințe de guvernanță, clauza 5.3.1, impune:

„Trebuie menținut un jurnal simplu al lanțului de custodie (de ex., fișier Excel sau document șablon) pentru fiecare incident.”

Pentru medii enterprise, Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Cerințe de guvernanță, clauza 5.5, impune:

„Toate dovezile colectate trebuie identificate în mod unic, etichetate și stocate într-un depozit securizat cu:”

Zenith Blueprint, faza Controale în acțiune, Pasul 23, explică de ce acest lucru contează pentru controlul ISO/IEC 27002:2022 5.28:

„Atunci când are loc un incident de securitate a informațiilor, unul dintre cele mai critice, dar adesea trecute cu vederea, elemente ale răspunsului este dovada. Nu jurnale, nu capturi de ecran, nu narațiuni disparate, ci dovezi păstrate corespunzător, cu respectarea lanțului de custodie și rezistente la alterare.”

Un pachet practic de dovezi pentru un incident major sau potențial raportabil trebuie să includă:

• Tichetul de incident și cronologia
• Jurnalul deciziilor de severitate și istoricul reclasificărilor
• Alerte SIEM, alerte EDR, jurnale cloud și jurnale de identitate
• Jurnale de acces la date și jurnale de export
• Înregistrări din inventarul activelor și serviciilor afectate
• Evaluarea impactului asupra clienților, tranzacțiilor și geografiei
• Fișa de evaluare DORA, NIS2 și GDPR
• Evaluarea DPO sau juridică
• Aprobări ale comunicărilor și mesaje transmise
• Înregistrare a lanțului de custodie
• Analiza cauzei-rădăcină
• Acțiuni corective și lecții învățate

Acest pachet de dovezi sprijină, de asemenea, controalele din Anexa A la ISO/IEC 27001:2022 A.8.15 jurnalizare, A.8.16 activități de monitorizare, A.5.28 colectarea dovezilor, A.5.27 învățarea din incidentele de securitate a informațiilor, A.5.31 cerințe legale, statutare, de reglementare și contractuale și A.5.34 confidențialitatea și protecția informațiilor de identificare personală.

Mapare de conformitate încrucișată: construiți o dată, răspundeți mai multor auditori

Cele mai puternice modele de severitate a incidentelor sunt construite o singură dată și mapate de mai multe ori. Zenith Controls este conceput ca o busolă de conformitate încrucișată pentru această activitate. Pentru acest subiect, intrările de bază ISO/IEC 27002:2022 sunt 5.24 planificarea și pregătirea managementului incidentelor de securitate a informațiilor, 5.25 evaluarea și decizia privind evenimentele de securitate a informațiilor, 5.26 răspunsul la incidentele de securitate a informațiilor, 5.27 învățarea din incidentele de securitate a informațiilor și 5.28 colectarea dovezilor.

Aceste controale se leagă natural de sistemul de management ISO/IEC 27001:2022. Clauzele 4, 5, 6 și 8 definesc domeniul de aplicare, leadershipul, criteriile de risc, tratarea riscurilor și dovezile operaționale. ISO/IEC 27002:2022 oferă limbajul de implementare a controalelor. Gândirea de tip ISO 22301 privind continuitatea activității sprijină pragurile de perturbare, prioritățile de recuperare și managementul crizei. Practicile de gestionare a incidentelor de tip ISO/IEC 27035 sprijină detectarea, raportarea, evaluarea, răspunsul și învățarea structurate. Guvernanța confidențialității de tip ISO/IEC 27701 sprijină rolurile privind încălcarea securității datelor cu caracter personal, considerentele privind operatorul și persoana împuternicită de operator, dovezile de confidențialitate și responsabilitatea.

Același model se mapează la NIST Cybersecurity Framework 2.0. Funcția GOVERN impune ca obligațiile legale, de reglementare, contractuale, de confidențialitate și privind libertățile civile să fie înțelese și gestionate. De asemenea, aceasta așteaptă ca apetitul la risc, rolurile, autoritățile, politicile și supravegherea să fie definite. Funcțiile DETECT, RESPOND și RECOVER sprijină triajul, analiza, escaladarea, conținerea, restaurarea, comunicările și îmbunătățirea.

Beneficiul este practic. Când un supraveghetor DORA solicită raționamentul pentru incidentul major legat de TIC, o autoritate NIS2 întreabă despre decizia de avertizare timpurie în 24 de ore, o autoritate pentru protecția datelor întreabă de ce o notificare GDPR a fost sau nu efectuată, iar un auditor ISO întreabă dacă SMSI a funcționat conform planului, organizația poate răspunde din același set de dovezi.

Cum vor testa auditorii și autoritățile de reglementare modelul dumneavoastră

Un auditor ISO/IEC 27001:2022 va începe, de regulă, cu domeniul de aplicare și cerințele legale. Va întreba dacă DORA, NIS2, GDPR, contractele cu clienții și obligațiile TIC față de terți au fost identificate ca cerințe ale părților interesate. Apoi va urma pista către criteriile de risc, Declarația de aplicabilitate, procedurile de incident, înregistrările operaționale și păstrarea dovezilor. Auditorul caută dovada că procesul de clasificare nu a fost inventat în timpul incidentului.

Un supraveghetor DORA sau o echipă de audit intern va căuta o buclă de ciclu de viață: proces de gestionare a incidentelor, indicatori de avertizare timpurie, criterii de clasificare, escaladarea incidentelor majore, comunicarea către clienți, cauza-rădăcină, cifre finale de impact, testarea rezilienței și supravegherea organului de conducere. De asemenea, va întreba dacă dependențele TIC față de terți au fost luate în considerare, în special atunci când au fost implicați furnizori cloud, SaaS, securitate administrată sau externalizare.

Un auditor sau o autoritate concentrată pe NIS2 va testa dacă entitatea poate identifica incidente semnificative, respecta termenele etapizate, comunica cu destinatarii serviciilor afectați și furniza dovezi ale evaluării impactului transfrontalier. Va conecta gestionarea incidentelor la măsurile de management al riscurilor din Article 21, inclusiv continuitatea activității, managementul crizei, securitatea lanțului de aprovizionare, controlul accesului, managementul activelor și instruirea.

Un DPO sau o autoritate de supraveghere GDPR va examina dacă organizația a identificat datele cu caracter personal, rolurile, persoanele vizate, categoriile, sistemele afectate, tipul de încălcare și riscul pentru persoane. Va testa dacă operatorul poate demonstra responsabilitatea și dacă notificările persoanelor împuternicite de operator către operatori au fost transmise la timp și complet.

Un auditor de tip ISACA sau COBIT 2019 se va concentra pe dovezile de guvernanță. Cine a aprobat taxonomia severității? Cine deține riscul? Ce metrici sunt raportate către management? Cum sunt gestionate excepțiile? Cum sunt transformate lecțiile învățate în îmbunătățiri ale controalelor?

Tipare comune de eșec în clasificarea incidentelor

Primul eșec este gândirea cu o singură etichetă. Echipele clasifică un eveniment ca ridicat, mediu sau scăzut, dar nu evaluează separat declanșatoarele DORA, NIS2 și GDPR. Rezultatul este o etichetă de severitate care nu poate explica o decizie de raportare.

Al doilea eșec este biasul încălcării confirmate. Echipele așteaptă dovada absolută a exfiltrării înainte de a implica funcția de confidențialitate sau juridicul. Evaluarea încălcării GDPR începe adesea cu acces neautorizat, pierdere, modificare sau divulgare posibilă, nu doar cu publicarea confirmată a datelor.

Al treilea eșec este confuzia privind ceasul. Termenele NIS2 și GDPR depind de luarea la cunoștință și de evaluare. Dacă tichetul de incident nu capturează ora luării la cunoștință, ora clasificării și ora escaladării, organizația poate întâmpina dificultăți în a demonstra caracterul oportun.

Al patrulea eșec este analiza forensică după curățare. Inginerii rotesc chei, reconstruiesc gazde și șterg dovezi temporare înainte ca postura investigativă să fie declanșată. Acest lucru poate distruge dovezile necesare pentru revizuirea reglementară, contractuală sau juridică.

Al cincilea eșec este orbirea față de furnizori. DORA, NIS2 și NIST CSF 2.0 subliniază toate riscul asociat terților și lanțului de aprovizionare. Dacă un furnizor cloud, un furnizor de servicii administrate, un procesator de plăți, un furnizor de identitate sau un furnizor SaaS face parte din lanțul incidentului, modelul de clasificare trebuie să includă impactul asupra furnizorilor și obligațiile contractuale de notificare.

O listă de verificare Clarysec pentru implementare în 2026

Pentru a operaționaliza un model justificabil de clasificare a severității incidentelor, Clarysec recomandă următoarea secvență:

1. Confirmați aplicabilitatea reglementară pentru DORA, NIS2, GDPR, contractele cu clienții și regulile sectoriale.
2. Actualizați domeniul de aplicare al SMSI și cerințele părților interesate conform ISO/IEC 27001:2022.
3. Definiți niveluri interne de severitate cu praguri măsurabile pentru indisponibilitate, date, clienți, geografie, pierdere financiară și criticitate.
4. Adăugați întrebări separate de evaluare DORA, NIS2 și GDPR în fluxul tichetelor de incident.
5. Definiți declanșatoare de escaladare pentru coordonatorul incidentului, DPO, juridic, conducerea superioară și consiliul de administrație.
6. Creați un șablon pentru jurnalul deciziilor de severitate.
7. Corelați clasificarea cu procedurile de colectare a dovezilor și de lanț de custodie.
8. Validați acoperirea jurnalizării pentru evenimente de identitate, cloud, aplicații, baze de date, rețea și furnizori.
9. Rulați exerciții de tip tabletop pentru scenarii de incident major DORA, incident semnificativ NIS2 și încălcare GDPR.
10. Integrați lecțiile învățate în tratarea riscurilor, Declarația de aplicabilitate, instruire și testarea rezilienței.

Zenith Blueprint, faza Controale în acțiune, Pasul 16, consolidează latura umană a acestui model: raportările trebuie jurnalizate, triate, escalate prin Planul de răspuns la incidente, iar chiar și evenimentele minore trebuie urmărite, deoarece tendințele relevă puncte slabe ale controalelor. Promovează o mentalitate de raportare cu prag scăzut: „Când aveți îndoieli, raportați.”

Acest punct cultural este critic. Un model de severitate eșuează dacă angajații întârzie raportarea deoarece se tem de o reacție exagerată. Scopul este raportarea rapidă, triajul disciplinat și clasificarea justificabilă.

Transformați incertitudinea incidentelor în dovezi pregătite pentru audit

În 2026, clasificarea severității incidentelor nu mai este o decizie exclusiv SOC. Este un proces reglementat de guvernanță care trebuie să conecteze criteriile pentru incidente majore legate de TIC din DORA, pragurile pentru incidente semnificative din NIS2, riscul de încălcare GDPR și dovezile ISO/IEC 27001:2022.

Organizațiile care performează cel mai bine în timpul incidentelor nu vor fi cele cu cel mai gros dosar de răspuns. Vor fi cele care pot răspunde rapid la patru întrebări și pot demonstra ulterior fiecare răspuns:

• Ce s-a întâmplat?
• Cât de sever este?
• Ce obligații de reglementare se pot aplica?
• Ce dovezi susțin decizia?

Clarysec ajută organizațiile să construiască această punte prin șabloane de politici, taxonomii de severitate, jurnale de decizie, scenarii tabletop și mapări de conformitate încrucișată. Începeți cu politicile de incident, validați criteriile de risc în Zenith Blueprint Zenith Blueprint și utilizați Zenith Controls Zenith Controls pentru a mapa controalele ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 și 5.28 în raport cu așteptările DORA, NIS2, GDPR, NIST CSF și audit.

Dacă echipa dumneavoastră nu poate răspunde la întrebarea „Este acesta un incident major DORA, un incident semnificativ NIS2 sau notificabil în temeiul GDPR?” în prima oră, următorul pas nu este încă un plan generic de răspuns la incidente. Următorul pas este un model operațional justificabil de clasificare a severității incidentelor, testat înainte de următorul apel de la 02:17.

Sunteți gata să înlocuiți panica prin proces? Descărcați șabloanele Clarysec pentru politicile de răspuns la incidente și colectare a dovezilor, revizuiți taxonomia actuală de severitate în raport cu Zenith Blueprint sau solicitați o evaluare de pregătire Clarysec pentru a construi un model de clasificare a incidentelor DORA, NIS2, GDPR și ISO/IEC 27001 pregătit pentru audit.