NIS2 și răspunderea conducerii: ce trebuie să facă administratorii

Prima directivă NIS lăsa securitatea cibernetică, de cele mai multe ori, în seama departamentului IT. NIS2 schimbă explicit asta. Articolul 20 din Directiva (UE) 2022/2555 cere statelor membre să se asigure că organele de conducere ale entităților esențiale și importante:

• aprobă măsurile de gestionare a riscurilor în materie de securitate cibernetică luate în temeiul Art. 21;
• supraveghează punerea lor în aplicare;
• pot fi trase la răspundere pentru încălcarea acestor obligații.

Al doilea alineat adaugă o obligație de instruire: membrii organelor de conducere trebuie să urmeze cursuri de formare, iar entitățile sunt încurajate să ofere periodic o formare similară angajaților, astfel încât aceștia să dobândească suficiente cunoștințe pentru a identifica riscurile și a evalua practicile de gestionare a lor.

În România, cerințele vin prin OUG 155/2024, aprobată cu modificări prin Legea 124/2025. Contextul general — cine intră sub lege și ce categorii există — este în ghidul complet NIS2 pentru România.

Directiva nu se referă la șeful IT, ci la persoanele care conduc entitatea: administratorii, membrii consiliului de administrație sau ai directoratului, directorii cu atribuții de conducere — în funcție de forma de organizare a companiei. Formularea exactă și persoanele vizate se stabilesc prin legea națională și prin actele constitutive ale fiecărei societăți.

Asta nu înseamnă că administratorii trebuie să configureze firewall-uri. Înseamnă că trebuie să înțeleagă riscurile suficient cât să pună întrebări bune, să aloce resurse și să decidă în cunoștință de cauză când acceptă un risc.

O structură care funcționează bine în companiile medii: un responsabil de securitate (intern sau extern) raportează direct conducerii, nu doar prin directorul IT, iar securitatea apare ca punct fix pe ordinea de zi a ședințelor de conducere. Așa, informația despre riscuri ajunge nefiltrată la cei care răspund pentru ea, iar deciziile de buget se iau pe baza ei, nu după un incident.

Directiva introduce două pârghii care țintesc conducerea, nu doar compania. Prima este principiul general din Art. 20: membrii organului de conducere pot fi trași la răspundere pentru încălcarea obligațiilor de gestionare a riscurilor. A doua apare în regimul de supraveghere al entităților esențiale (Art. 32): dacă măsurile dispuse nu sunt aplicate în termen, autoritățile pot cere interzicerea temporară a exercitării funcțiilor de conducere pentru o persoană responsabilă, la nivel de director general sau reprezentant legal, până la remedierea deficiențelor.

Separat, entitatea ca atare riscă amenzi care, conform directivei, pot ajunge cel puțin până la 10 milioane EUR sau 2% din cifra de afaceri globală anuală pentru entitățile esențiale și 7 milioane EUR sau 1,4% pentru cele importante. Formele concrete de răspundere și sumele aplicabile în România sunt cele din legea națională — nu presupuneți automat cel mai rău sau cel mai blând scenariu.

Directiva nu prescrie o programă. Scopul declarat este ca membrii conducerii să poată identifica riscurile și evalua practicile de gestionare a lor, precum și impactul acestora asupra serviciilor entității. O instruire utilă pentru un board acoperă:

1. Obligațiile NIS2 ale entității: încadrare, măsurile Art. 21, raportarea către DNSC.
2. Principalele amenințări pentru sectorul vostru — de exemplu ransomware și phishing asistat de AI.
3. Rolul conducerii într-un incident: cine decide raportarea, comunicarea, oprirea serviciilor.
4. Cum se citește un raport de risc și ce întrebări se pun echipei tehnice.
5. Acceptarea formală a riscurilor reziduale și documentarea deciziei.

Păstrați dovada: cine a urmat instruirea, când, ce a acoperit și rezultatul unei evaluări scurte. Repetați-o periodic — amenințările și propria infrastructură se schimbă.

Frecvențele de mai sus nu sunt prescrise de directivă; sunt un punct de plecare rezonabil. Ce contează este ritmul să fie consecvent și deciziile să fie consemnate.

O atenție specială merită acceptarea riscurilor. Nu orice risc poate fi redus imediat: un sistem vechi care nu poate primi MFA, un furnizor fără alternativă, un buget care nu acoperă tot. Acceptarea este legitimă, dar trebuie să fie o decizie explicită a conducerii, cu motivul, durata și măsurile compensatorii notate. Un risc tolerat în tăcere de ani de zile este exact ce arată prost într-o analiză după incident.

• Ce active critice avem și cine este proprietarul fiecăruia?
• Avem MFA pe accesul la distanță și pe toate conturile de administrator? Care sunt excepțiile și de ce?
• Când am restaurat ultima dată un backup de test și cât a durat?
• Câte vulnerabilități critice sunt deschise de peste 30 de zile?
• Care furnizori au acces la sistemele noastre și cum îl controlăm?
• Dacă mâine la 3 dimineața avem un incident, cine trimite avertizarea timpurie la DNSC în 24 de ore?

Răspunsurile la aceste întrebări se leagă direct de controalele tehnice din Art. 21 și de procedura de notificare DNSC.

Semnalele de alarmă sunt ușor de recunoscut: răspunsuri de tipul „cred că da”, cifre care nu pot fi verificate, excepții fără termen sau un singur om care știe tot. Nu e nevoie de cunoștințe tehnice pentru a cere ca fiecare răspuns să vină cu o dovadă și cu o dată.