Incidente

24 de ore, 72 de ore, 30 de zile: cum funcționează raportarea incidentelor sub NIS2

Dintre toate obligațiile NIS2, raportarea incidentelor stârnește cele mai multe emoții. „Cum să scriem un raport în 24 de ore, când nici nu știm încă ce s-a întâmplat?" — auzim întrebarea asta la aproape fiecare client nou. Vestea bună: legea nu cere ce cred majoritatea că cere. Să o luăm pe rând.

Întâi: ce este un „incident semnificativ"?

Nu orice eveniment de securitate se raportează. OUG 155/2024 cere raportarea incidentelor semnificative — cele care au cauzat sau pot cauza perturbări operaționale grave ale serviciilor ori pierderi financiare pentru entitate, sau care au afectat ori pot afecta alte persoane fizice sau juridice, cauzând prejudicii materiale sau morale considerabile. Criteriile de semnificație au fost detaliate și prin modificările aduse de Legea 124/2025.

Traducere practică: un laptop pierdut și recuperat sau o tentativă de phishing blocată de filtre nu declanșează, de regulă, lanțul de raportare. Un ransomware care v-a criptat serverele de producție — da, categoric. Zona gri dintre extreme e exact motivul pentru care merită să aveți criterii interne de clasificare stabilite înainte de incident, nu în toiul lui.

Etapa 1 — avertizarea timpurie, în 24 de ore

Din momentul în care ați luat cunoștință de un incident semnificativ, aveți 24 de ore pentru o avertizare timpurie către DNSC. Și aici e neînțelegerea cea mare: avertizarea timpurie nu e un raport de investigație. Legea cere, în esență, să spuneți că s-a întâmplat ceva serios și, dacă e cazul, dacă bănuiți o acțiune ilicită sau răuvoitoare ori un posibil impact transfrontalier. Atât.

Nimeni nu vă cere cauza-rădăcină la ora 3 dimineața. Vi se cere semnalul. Diferența dintre o organizație pregătită și una nepregătită nu e capacitatea de analiză rapidă, ci faptul că prima știe dinainte cine transmite avertizarea, pe ce canal și cu ce informații minime.

Etapa 2 — raportarea incidentului, în 72 de ore

La 72 de ore de la luarea la cunoștință, transmiteți o raportare care actualizează avertizarea timpurie și prezintă o evaluare inițială: gravitatea, impactul și, acolo unde există, indicatorii de compromitere. E în continuare o evaluare inițială — „din ce știm până acum" este o formulare perfect legitimă la această etapă.

Dacă echipa națională de răspuns la incidente vă solicită între timp actualizări, legea prevede și rapoarte intermediare, la cerere.

Etapa 3 — raportul final, în cel mult 30 de zile

Aici vine partea de substanță: descrierea detaliată a incidentului, gravitatea și impactul, tipul amenințării sau cauza-rădăcină probabilă, măsurile de atenuare aplicate și în curs și, dacă e cazul, impactul transfrontalier. Dacă incidentul e încă în desfășurare la termen, se transmite un raport privind progresele, iar cel final la o lună după gestionarea completă.

Cum arată pregătirea, practic

Din audituri, procedurile de raportare care chiar funcționează au câteva trăsături comune:

• Roluri nominale, cu înlocuitori. „Departamentul IT raportează" nu e un rol; „Ana, iar în lipsa ei Mihai" este. Incidentele au un talent aparte de a se produce în concedii.
• Criterii de clasificare scrise. O grilă simplă care spune ce e „semnificativ" pentru organizația dumneavoastră, ca decizia de raportare să nu fie o dezbatere de la zero, sub presiune.
• Șabloane pregătite pentru fiecare etapă, cu câmpurile cerute de lege deja structurate. La 2 noaptea, un formular pe jumătate completat valorează enorm.
• Un exercițiu pe an, minim. O simulare de două ore scoate la iveală mai multe probleme decât zece revizuiri de procedură. Includem astfel de exerciții în serviciile de însoțire pe termen lung.

Și un aspect care se uită frecvent: raportarea către DNSC nu vă scutește de alte obligații paralele. Dacă incidentul implică date personale, notificarea către autoritatea de protecție a datelor curge separat, pe termenul ei propriu. Procedurile bune tratează ambele fluxuri împreună.