NIS2 a trecut din „directivă UE la orizont” în „regulator la ușa ta” în momentul în care România a transpus-o prin Legea 124/2025. Sumarul de cinci pagini pe care l-a citit CIO-ul în 2023 nu mai este suficient — inspectorii DNSC citesc același Articol 21 pe care îl citești și tu, și se așteaptă ca modelul de operare al securității să arate cum descrie directiva.
Acest articol e versiunea pe care ne-ar fi plăcut să o primim înainte de primul audit NIS2. Presupune că știi deja că directiva există. Se concentrează pe ce cere practic Articolul 21, Articolul 23 și prevederile despre organul de conducere — și ce probă rezistă când vine inspectorul.
Articolul 21 în termeni operaționali
Articolul 21 listează zece „măsuri tehnice, operaționale și organizatorice adecvate și proporționale”. Tradus într-un program de securitate, asta înseamnă minim:
- Un program de management al vulnerabilităților care rulează pe un ciclu, cu prioritizare documentată și remediere cu termen. Scanări anuale într-un PDF nu satisfac asta.
- Un proces documentat de răspuns la incidente cu roluri nominale, rotații de on-call și playbook-uri testate. Directiva folosește expresia „politici și proceduri pentru a evalua eficacitatea” — adică o politică IR statică e insuficientă; trebuie să poți arăta că a fost exersată.
- Securitatea lanțului de aprovizionare: un inventar al furnizorilor critici de ICT, evaluarea posturii lor de securitate și clauze contractuale care îți permit să le ceri același lucru. Articolul 21(2)(d) e neambiguu aici.
- Practici de igienă cibernetică și awareness pentru personal, cu prezență și evaluare documentate. Click-through-ul de e-learning, după cititul nostru, nu e suficient.
- Politici de criptografie și control de acces care se potrivesc criticității activelor, inclusiv MFA pe accesul privilegiat. Formularea nu mandatează algoritmi specifici; mandatează proporționalitate, lucru pe care îl va sonda auditorul.
Ceasul de 24 de ore — Articolul 23 raportare incidente
Trei termene, un incident:
- Alertă timpurie în 24 de ore de la conștientizare. E o notificare, nu un raport complet. Best practice: un template de o pagină pre-agreat cu DNSC pe care îl poți trage dintr-un tabletop.
- Notificare în 72 de ore, inclusiv evaluare inițială a severității și impactului. Redactarea de la zero sub presiunea incidentului e brutală; ai un template care preia din timeline-ul forensic.
- Raport final în 1 lună, inclusiv cauză rădăcină și remediere. Auditorul îl va citi față de politica ta IR. Inconsistențele apar rapid.
Alerta timpurie de 24 de ore e clauza pe care o subestimează majoritatea organizațiilor. Până înțelegi incidentul suficient ca să scrii o notificare reală, deja ești în întârziere.
Răspunderea personală a organului de conducere
Articolul 20 face organul de conducere — membrii board-ului, directorii executivi — personal răspunzător pentru conformitatea cu Articolul 21 și pentru aprobarea măsurilor de management al riscului. Transpunerea română păstrează asta cu dinți. În angajamentele noastre cu entități din sectorul public și privat mare, această clauză singură mișcă mai mult buget decât a făcut orice argument tehnic în cinci ani de muncă pre-NIS2 pe GDPR.
Ce cer în realitate inspectorii DNSC
Bazat pe inspecțiile DNSC pe care le-am sprijinit ca consultant tehnic — fără a numi entitățile implicate:
- Registrul de active. Nu un dump CMDB — un registru care clasifică activele pe criticitate de business și leagă fiecare unul de un proprietar. Dacă registrul de active are servere fără proprietar, inspecția se oprește acolo pentru câteva ore.
- Backlog-ul de vulnerabilități pe vechime. Time-since-discovery și time-since-fix-deployment, segmentat pe severitate. Am văzut afirmații „100% findings critice remediate” demontate în cinci minute printr-un sample query pe dashboard-ul SLA.
- Loguri de răspuns la incidente din ultimele douăsprezece luni — chiar dacă nu ai avut incidente. Absența incidentelor trebuie să fie vizibilă: alertele care s-au declanșat și au fost închise ca benigne contează tot ca probă că programul funcționează.
- Matricea de training: cine a făcut ce training, când și cu ce scor. Atenție la răspunsul „toți au făcut e-learning-ul”; inspectorii moderni întreabă ce roluri au primit training pe rol, inclusiv organul de conducere.
- O listă a terților ICT critici, cu clauzele contractuale care satisfac Articolul 21(2)(d), și un sample de evaluări recente. Ăsta e gap-ul cel mai frecvent pe care îl observăm.
Programul de doi ani care supraviețuiește unei inspecții
Un program NIS2 defensabil nu e un proiect — e un program care rulează continuu și produce probă ca efect lateral. Cadența minim viabilă pe doi ani:
- Trimestru 1: baseline registru de active + scanare inițială de vulnerabilități + IR playbook v1 + briefing organul de conducere.
- Trimestru 2: evaluare furnizori critici + primul tabletop IR + ciclu de remediere 1.
- Trimestru 3: pentest pe cluster-ul de active cu cel mai mare risc + training v1 + KPI publicate.
- Trimestru 4: review program de vulnerabilități + follow-up furnizori + re-briefing organul de conducere cu metrici.
- Anul 2 oglindește anul 1 cu red team mai profund, breadth mai mare pe furnizori și training complet pe rol.
Unde se potrivește Sandline
Rulăm layer-ul tehnic al acestui program — evaluare de vulnerabilități pe Centraleyezer, pentest legat de clauze specifice ale Articolului 21, retainer-uri IR cu template-uri de raportare aliniate NIS2 și training-ul care satisface Articolul 21(2)(g). Nu vom fi DPO-ul tău și nu îți vom scrie cartea de guvernanță; vom produce proba pe care o citește auditorul.