Sancțiuni NIS2 în România: amenzi, răspunderea conducerii și riscul real

O organizație care nu poate demonstra cine deține ownership-ul unui risc, când a fost testat backupul sau cum a răspuns la un incident nu are doar o problemă tehnică.

Are o expunere de conformitate și de guvernanță.

Întrebarea „ce sancțiuni aduce NIS2?” trebuie analizată din această perspectivă: nu doar valoarea unei amenzi, ci ansamblul de măsuri care poate afecta managementul, operațiunile, reputația și relațiile comerciale ale organizației.

NIS2 ridică standardul de responsabilitate pentru entitățile esențiale și importante din sectoarele și serviciile care intră în domeniul său de aplicare.

În România, cadrul principal este reprezentat de Ordonanța de urgență nr. 155/2024, aprobată și modificată prin Legea nr. 124/2025, împreună cu actele normative subsecvente.

Aplicabilitatea concretă depinde de încadrarea organizației, activitatea și serviciile furnizate, dimensiune și situațiile speciale prevăzute de cadrul legal.

01. Sancțiuni NIS2 în România: care sunt pragurile financiare

La nivel european, Directiva NIS2 cere statelor membre să prevadă sancțiuni administrative efective, proporționale și cu efect de descurajare.

Pentru încălcarea cerințelor privind măsurile de management al riscului de securitate cibernetică și raportarea incidentelor, directiva stabilește praguri pentru limitele maxime ale amenzilor.

Entități esențiale

Directiva cere ca limita maximă disponibilă să fie de cel puțin:

• 10.000.000 EUR; sau
• 2% din cifra de afaceri anuală mondială totală a întreprinderii din exercițiul financiar precedent;

fiind relevantă valoarea mai mare.

Entități importante

Pentru entitățile importante, directiva stabilește o limită maximă de cel puțin:

• 7.000.000 EUR; sau
• 1,4% din cifra de afaceri anuală mondială totală;

fiind, de asemenea, relevantă valoarea mai mare.

În România, cadrul sancționator actual din OUG nr. 155/2024, astfel cum a fost modificată prin Legea nr. 124/2025, include pentru anumite categorii de contravenții aceleași plafoane de ordinul milioanelor de euro și al procentului din cifra de afaceri anuală mondială.

Legislația națională prevede însă mai multe categorii de contravenții și intervale de sancțiuni, astfel încât nu orice abatere conduce automat la plafonul maxim.

Vezi textul actualizat: OUG nr. 155/2024, forma actualizată .

02. Sancțiuni NIS2 și măsuri de supraveghere: nu este vorba doar despre amenzi

Concentrarea exclusivă pe cuantumul amenzii ratează o parte importantă a mecanismului NIS2.

Autoritățile competente pot utiliza instrumente de supraveghere, verificare și corecție pentru a determina remedierea unei situații de neconformitate.

În România, cadrul legal permite, în condițiile prevăzute de OUG nr. 155/2024, măsuri precum:

• solicitarea de informații și documente;
• verificări și activități de control;
• audituri ad-hoc;
• stabilirea unor termene de remediere;
• implementarea recomandărilor rezultate din audit;
• solicitarea respectării unor măsuri de management al riscului și obligații de raportare;
• publicarea anumitor încălcări în condițiile legii;
• informarea persoanelor care pot fi afectate de o amenințare cibernetică semnificativă.

Normele privind supravegherea, verificarea și controlul au fost detaliate ulterior prin Ordinul DNSC nr. 3/2025.

Acesta stabilește cadrul procedural pentru activitățile de supraveghere și control și pentru constatarea, notificarea și sancționarea abaterilor.

Pentru anumite situații privind entitățile esențiale, atunci când măsurile anterioare nu sunt suficiente, cadrul național permite inclusiv demersuri către autoritățile competente pentru suspendarea temporară a unor certificări sau autorizări ori pentru impunerea unei interdicții temporare de exercitare a anumitor funcții de conducere.

Din perspectiva businessului, astfel de măsuri pot deveni mai relevante decât valoarea efectivă a unei amenzi.

Pot afecta continuitatea serviciului, relația cu clienții, condițiile contractuale și evaluările realizate de parteneri.

03. Răspunderea conducerii nu este simbolică

NIS2 mută explicit cybersecurity risk management la nivelul conducerii organizației.

Articolul 20 al directivei prevede că organele de conducere ale entităților esențiale și importante trebuie să aprobe măsurile de management al riscului prevăzute de NIS2 și să supravegheze implementarea acestora.

Membrii organelor de conducere trebuie, de asemenea, să beneficieze de formare care să le permită să înțeleagă riscurile și practicile de cybersecurity risk management.

Această cerință schimbă întrebarea pe care boardul și directorii executivi trebuie să o adreseze.

Nu este suficient:

„Avem firewall, EDR și backup?”

Întrebările utile sunt:

• care sunt riscurile materiale pentru serviciile critice;
• cine deține fiecare risc și fiecare acțiune de remediere;
• ce riscuri reziduale au fost acceptate;
• ce investiții au fost prioritizate;
• ce dovezi confirmă că măsurile funcționează;
• ce constatări sunt încă deschise și de ce.

Un raport matur pentru management nu este o listă de vulnerabilități fără context.

Pentru fiecare constatare materială trebuie să existe o legătură între activ, scenariu, impact, control, owner, termen și evidence.

04. Raportarea incidentelor: 24 de ore nu înseamnă 24 de ore pentru investigație completă

NIS2 introduce un proces etapizat pentru raportarea incidentelor semnificative.

În cadrul directivei, acesta include:

• o avertizare timpurie în maximum 24 de ore de la luarea la cunoștință a incidentului semnificativ;
• o notificare a incidentului în maximum 72 de ore;
• rapoarte intermediare atunci când sunt solicitate sau necesare;
• un raport final în termen de o lună de la notificarea incidentului, cu regulile speciale aplicabile incidentelor încă în desfășurare.

Aceste termene sunt dificile tocmai pentru că organizația nu va deține toate informațiile în primele ore.

Obiectivul nu este certitudinea absolută înainte de raportare.

Organizația trebuie să aibă un proces care permite:

• detectarea și clasificarea rapidă;
• evaluarea preliminară a impactului;
• escaladarea către persoanele potrivite;
• păstrarea cronologiei și a deciziilor;
• obținerea rapidă a logurilor și altor dovezi;
• coordonarea comunicării interne și externe.

Un plan de răspuns la incidente credibil stabilește înainte de incident cine decide, cine investighează, cine comunică și cine menține jurnalul oficial al evenimentului.

Procesele trebuie corelate și cu business continuity, GDPR, crisis communication și managementul furnizorilor.

Dacă incidentul pornește de la un furnizor cloud sau dintr-un cont Microsoft 365 compromis, organizația trebuie să știe ce loguri poate accesa, cine are dreptul să le extragă și cât timp sunt păstrate.

05. Unde apar frecvent neconformitățile

Expunerea nu apare de obicei dintr-o singură deficiență spectaculoasă.

Se acumulează din controale parțiale, ownership neclar și lipsa verificării periodice.

Identitate și privilegii

Inventarul incomplet de conturi, rolurile administrative permanente, offboarding-ul lent și lipsa access reviews pot menține acces inutil la sisteme importante.

În mediile Microsoft, utilizarea PIM și a accesului Just-In-Time poate reduce expunerea asociată privilegiilor permanente, atunci când arhitectura și licențierea permit.

Backup și recovery

Existența copiilor de siguranță nu demonstrează capacitatea reală de recuperare.

Pentru serviciile critice trebuie stabilite RTO și RPO , iar restaurarea trebuie testată și documentată.

Evidence-ul poate include:

• scenariul de test;
• data și sistemele testate;
• timpul efectiv de restaurare;
• diferențele față de RTO/RPO;
• problemele identificate;
• planul și ownerul remedierii.

Logging și monitorizare

Colectarea de loguri fără retenție adecvată, corelare și responsabilitate pentru monitorizare nu garantează capacitatea de detectare.

Dacă organizația nu poate reconstrui cine a accesat un sistem critic, de unde, cu ce privilegiu și ce acțiuni a executat, investigația și raportarea vor fi afectate.

Furnizori

Un chestionar completat o dată pe an nu este, singur, un control de supply-chain risk.

Furnizorii critici trebuie identificați și evaluați în funcție de acces, date, criticitatea serviciului, continuitate și impactul unei indisponibilități.

Contractele și procesele operaționale trebuie să prevadă, în funcție de risc, cerințe de securitate, notificarea incidentelor, revocarea accesului, subcontractarea și mecanisme de escaladare.

06. Cum reduceți expunerea prin control demonstrabil

Reducerea riscului de sancțiuni nu începe cu redactarea accelerată a unui nou set de politici.

Începe cu stabilirea domeniului de aplicare, a serviciilor critice și a diferențelor dintre controalele declarate și cele care funcționează efectiv.

Primul pas este verificarea încadrării organizației în domeniul NIS2 .

Apoi, assessment-ul trebuie să acopere riscurile care pot produce impact material.

În multe organizații, acestea includ:

• identitatea și accesul privilegiat;
• expunerea serviciilor către internet;
• vulnerabilitățile exploatabile;
• backup și recovery;
• logging și monitoring;
• incident response;
• furnizorii critici;
• ownership și risk acceptance.

Ordinea exactă trebuie stabilită în funcție de arhitectură, amenințări, expunere și impact, nu prin aplicarea mecanică a unui checklist.

Fiecare măsură trebuie transformată într-un control operațional.

Asta înseamnă:

• owner nominalizat;
• frecvență de verificare;
• criteriu de eficacitate;
• proces de gestionare a excepțiilor;
• termen de remediere;
• evidence verificabil.

Dovezile pot include rezultate ale testelor de restaurare, rapoarte de access review, aprobări pentru excepții, registre de risc actualizate, minute de management review și exerciții documentate de răspuns la incidente.

Amenda este doar unul dintre semnalele de risc pentru management

Sancțiunea financiară este importantă, dar nu ar trebui să fie singurul motiv pentru care organizația tratează NIS2.

Întrebarea mai utilă este:

Putem explica, cu date și dovezi, de ce serviciile noastre critice rămân controlate atunci când apare un incident?

Putem demonstra cine deține riscul?

Putem arăta când a fost testat recovery-ul?

Știm ce privilegii sunt active și de ce?

Putem reconstrui rapid un incident din logurile disponibile?

Putem demonstra că managementul urmărește riscurile materiale și remedierea lor?

Dacă răspunsurile sunt incomplete, momentul potrivit pentru a corecta ownership-ul, controalele și evidence-ul este înainte ca autoritatea, un client sau un incident real să testeze aceeași lipsă.