Pentru incidentele semnificative, NIS2 introduce un mecanism etapizat de raportare: avertizare timpurie în maximum 24 de ore, notificarea incidentului în maximum 72 de ore și raport final, de regulă, în cel mult o lună de la notificare. Pregătirea reală înseamnă ca organizația să poată decide rapid dacă incidentul este semnificativ, cine îl escaladează, cine aprobă notificarea și ce dovezi susțin decizia.
01. Ce cere raportarea incidentelor conform NIS2
NIS2 stabilește un model etapizat de notificare pentru incidentele care au un impact semnificativ asupra furnizării serviciilor unei entități esențiale sau importante.
În România, mecanismul este reflectat în cadrul național de transpunere NIS2. Organizația trebuie să trateze aceste termene ca parte din procesul său operațional de incident response, nu ca pe o formalitate administrativă realizată după închiderea incidentului.
| Etapă | Termen | Obiectiv |
|---|---|---|
| Early warning | Maximum 24h | Semnalarea incidentului semnificativ și, unde este relevant, a caracterului malițios sau a posibilului impact transfrontalier. |
| Incident notification | Maximum 72h | Actualizarea informațiilor și evaluarea inițială a gravității, impactului și indicatorilor de compromitere disponibili. |
| Intermediate report | La solicitare | Actualizări relevante privind evoluția incidentului. |
| Final report | Maximum o lună de la notificarea incidentului | Descrierea incidentului, impactului, cauzei probabile și măsurilor de atenuare aplicate sau în curs. |
02. Incident semnificativ nu înseamnă orice alertă
Una dintre cele mai frecvente erori este confundarea volumului de alerte cu relevanța unui incident pentru NIS2.
Mii de tentative de phishing blocate nu reprezintă automat un incident semnificativ. În schimb, compromiterea unui singur cont cu privilegii administrative poate genera un risc major dacă permite acces la servicii critice, date sensibile sau alte identități.
Directiva consideră semnificativ un incident dacă acesta a provocat sau poate provoca perturbări operaționale grave ale serviciilor ori pierderi financiare pentru entitate sau dacă a afectat ori poate afecta alte persoane prin prejudicii materiale sau nonmateriale considerabile.
Evaluarea trebuie făcută în contextul organizației: serviciile afectate, durata, utilizatorii sau clienții, impactul economic, datele, dependențele și potențialul de propagare.
03. Procesul trebuie să funcționeze înainte de criză
Un proces matur separă detecția tehnică de declararea oficială a incidentului, dar le conectează printr-un flux de decizie trasabil.
Alertarea poate porni din EDR, SIEM, firewall, Microsoft 365, identitate, cloud, monitorizarea infrastructurii sau chiar dintr-o notificare primită de la un furnizor.
Triage-ul trebuie să stabilească rapid ce s-a întâmplat, ce active sunt implicate și dacă există indicii credibile de compromitere.
Urmează evaluarea impactului: ce serviciu este afectat, care este efectul actual și plauzibil, ce clienți sau procese pot fi afectați și dacă situația poate îndeplini criteriile unui incident semnificativ.
Este necesar un owner clar al incidentului, cu mandat pentru coordonarea IT, cybersecurity, legal, compliance, business continuity, comunicare și management.
Exemplu: compromiterea unui cont privilegiat Microsoft 365
Blocarea contului reprezintă doar prima măsură. Investigația trebuie să poată verifica autentificările, modificările de roluri, regulile de mail forwarding, aplicațiile OAuth, accesul la SharePoint și OneDrive și eventualele acțiuni laterale realizate de atacator.
În paralel, organizația trebuie să determine dacă sunt afectate servicii critice, informații sensibile, clienți sau alte obligații contractuale și de reglementare.
04. Ce trebuie să funcționeze în primele 24 de ore
Pregătirea pentru NIS2 poate fi verificată foarte simplu: poate organizația să execute următorul flux într-o zi, inclusiv într-o vineri seara?
24-hour readiness
Primele 10 acțiuni care trebuie să fie posibile.
Detectarea și înregistrarea momentului în care organizația ia cunoștință de incident.
Desemnarea rapidă a incident owner-ului.
Identificarea sistemelor, identităților și serviciilor potențial afectate.
Conservarea logurilor și artefactelor tehnice relevante.
Evaluarea impactului operațional și de business.
Aplicarea criteriilor interne pentru determinarea caracterului semnificativ al incidentului.
Escaladarea către management, legal și compliance conform matricei de responsabilități.
Stabilirea informațiilor confirmate și separarea lor de ipotezele aflate încă în investigație.
Luarea și documentarea deciziei privind raportarea.
Transmiterea avertizării prin canalul oficial aplicabil și păstrarea dovezii notificării.
05. Ce dovezi trebuie să rămână după incident
O procedură de incident response bine redactată nu demonstrează singură că procesul a funcționat.
Managementul, auditorii sau autoritățile trebuie să poată reconstrui ce s-a întâmplat și de ce au fost luate anumite decizii.
| Dovadă | Ce trebuie să demonstreze |
|---|---|
| Incident timeline | Detectare, confirmare, escaladare, decizie, notificare și închidere. |
| Technical evidence | Loguri, alerte, IoC-uri, investigații și configurațiile relevante. |
| Classification decision | Criteriile utilizate, impactul estimat, decidenții și aprobarea. |
| Notifications | Versiunile și momentele comunicărilor către autorități și alte părți relevante. |
| Remediation evidence | Revocări de acces, rotații de credențiale, patch-uri, restaurări și verificări ulterioare. |
Aici apar frecvent deficiențele reale de maturitate: retenție insuficientă a logurilor, privilegii permanente, backup-uri netestate, ownership neclar sau lipsa evidențelor privind deciziile luate.
06. Furnizorii pot decide dacă respectați termenul
Incident reporting expune foarte repede dependențele organizației de cloud providers, managed service providers, telecom, ERP, SaaS și alte servicii critice.
Dacă furnizorul detectează primul incidentul, contractul și procesul operațional trebuie să stabilească cine primește informația, prin ce canal și cât de repede.
O clauză generică de tipul „supplier shall notify customer of security incidents” este insuficientă dacă organizația are nevoie de date în câteva ore.
07. Testați raportarea, nu doar planul de răspuns
Un tabletop exercise este una dintre cele mai eficiente metode pentru verificarea procesului înainte de un incident real.
Scenariul trebuie să includă informații incomplete, presiune de timp și dependențe externe.
De exemplu: un atacator compromite un cont privilegiat, accesează informații din cloud, iar un furnizor confirmă doar parțial situația după câteva ore.
Echipa trebuie să decidă ce se știe, ce nu se știe, dacă incidentul poate fi semnificativ, cine aprobă notificarea și ce informații pot fi comunicate fără a prezenta ipotezele drept fapte.
| KPI de exercițiu | Ce măsurăm |
|---|---|
| Time to escalate | Timpul dintre detectare și escaladarea către owner-ul relevant. |
| Time to classify | Timpul necesar evaluării caracterului semnificativ. |
| Time to decision | Timpul până la decizia formală de notificare. |
| Evidence completeness | Dacă deciziile și datele utilizate sunt documentate. |
| Communication readiness | Dacă funcționează contactele, aprobările și canalele de notificare. |
Fiecare problemă identificată trebuie să primească un owner, un termen și o verificare a remedierii. Altfel, exercițiul produce observații, nu îmbunătățirea controlului.
08. De la incident response la control demonstrabil
Pregătirea pentru raportarea NIS2 nu începe cu formularul de notificare. Începe cu serviciile critice, identitățile, logging-ul, monitorizarea, furnizorii, responsabilitățile și capacitatea de a lua decizii sub presiune.
Modelul practic este:
Detect → Triage → Assess → Escalate → Decide → Notify → Evidence → Remediate.
Managementul nu trebuie să întrebe doar dacă există un incident response plan.
Întrebarea mai importantă este: putem demonstra că acest proces funcționează într-o situație reală și în interiorul termenelor aplicabile?
Aici se vede diferența dintre existența unei politici și existența unui control operațional.