Ghid NIS2 pentru companiile din România

---

NIS2 este denumirea uzuală a Directivei (UE) 2022/2555↗, adoptată pe 14 decembrie 2022 ca succesoare a primei directive NIS din 2016. Directiva transformă securitatea cibernetică din opțiune în obligație legală pentru companiile care țin în funcțiune economia și serviciile esențiale, cu termene, autorități de supraveghere și amenzi.

Statele membre aveau termen până la 17 octombrie 2024 să transpună directiva în legislația națională. România a făcut-o cu o întârziere de aproximativ două luni și jumătate, prin OUG nr. 155/2024↗, publicată în Monitorul Oficial nr. 1332 din 31 decembrie 2024 și intrată în vigoare în aceeași zi. Ordonanța a fost ulterior aprobată, cu modificări, prin Legea nr. 124/2025↗ din 7 iulie 2025.

Faza „legea există, dar nu se aplică încă” s-a terminat. Autoritatea competentă, DNSC (Directoratul Național de Securitate Cibernetică), a emis ordinele de punere în aplicare: Ordinul nr. 1/2025 (procesul de înregistrare și notificare) și Ordinul nr. 2/2025 (metodologia de stabilire a nivelului de risc), ambele în vigoare din 20 august 2025, urmate de Ordinul nr. 3/2025 din 27 noiembrie 2025, care stabilește normele de supraveghere, verificare și control. Termenul de înregistrare a expirat, mecanismele de evaluare rulează, iar controalele au acum o bază procedurală completă.

---

NIS2 se sprijină pe trei piloni:

• Strategii naționale de securitate cibernetică: fiecare stat membru trebuie să aibă o strategie clară, coordonată la nivel de țară, care să crească nivelul de securitate în regiune.
• Cooperare strategică și schimb de informații: directiva pune accent pe colaborarea dintre state și pe schimbul de date despre incidente, construind o apărare colectivă împotriva amenințărilor.
• Sectoare-cheie: NIS2 acoperă sectoarele critice pentru viața publică — energie, sănătate, transport, infrastructură digitală — și le obligă să mențină apărări solide.

---

Prima directivă NIS împărțea entitățile în operatori de servicii esențiale (OES) și furnizori de servicii digitale (DSP). NIS2 renunță la această distincție și clasifică entitățile după criticitatea sectorului:

• Entități esențiale — cele din sectoarele „foarte critice”.
• Entități importante — cele din celelalte sectoare critice.

Diferența dintre categorii nu schimbă lista obligațiilor tehnice: ambele trebuie să respecte aceleași cerințe de securitate și de raportare. Diferă intensitatea supravegherii și plafonul sancțiunilor:

• Entitățile esențiale sunt supravegheate proactiv (ex ante și ex post): inspecții, verificări aleatorii, audituri, solicitări de informații.
• Entitățile importante sunt supravegheate reactiv (ex post), la indicii de neconformitate.
• Amenzi administrative de până la 10 milioane EUR sau 2% din cifra de afaceri anuală mondială.

NIS2 aduce și obligații noi față de NIS1: practici specifice de management al riscului cibernetic, o raportare a incidentelor în etape și o securitate consolidată a lanțului de aprovizionare.

---

NIS2 acoperă 18 sectoare, împărțite în două anexe ale directivei:

• Anexa I (11 sectoare de criticitate ridicată): energie, transport, sector bancar, infrastructuri ale pieței financiare, sănătate, apă potabilă, ape uzate, infrastructură digitală, gestionarea serviciilor TIC (între întreprinderi), administrație publică și spațiu.
• Anexa II (șapte alte sectoare critice): servicii poștale și de curierat, gestionarea deșeurilor, produse chimice, alimente, producție, furnizori digitali (piețe online, motoare de căutare, platforme de socializare) și cercetare.

Ca regulă generală, directiva se aplică entităților din sectoarele vizate care depășesc plafonul unei întreprinderi mici: aproximativ 50 de angajați sau o cifră de afaceri și/sau un bilanț total de 10 milioane EUR, potrivit Recomandării Comisiei 2003/361/CE. Încadrarea nu se reduce însă la numărul de angajați: se calculează inclusiv cu datele întreprinderilor partenere sau legate, unde este cazul.

Clasificarea în entități esențiale sau importante urmează Art. 3 din directivă↗:

Statele membre au fost obligate să întocmească un registru național al entităților acoperite până pe 17 aprilie 2025. În România, înregistrarea s-a făcut prin platformele NIS2@RO și ATHENA.

---

Dincolo de clasificare, directiva impune patru mari categorii de obligații:

• Managementul riscurilor și consolidarea securității: măsuri pentru a reduce riscurile cibernetice, inclusiv gestionarea incidentelor, securizarea lanțului de aprovizionare și protejarea rețelelor.
• Răspunderea conducerii: organele de conducere răspund pentru supravegherea și aprobarea măsurilor de securitate și trebuie formate în acest domeniu.
• Raportarea incidentelor: un proces clar, în etape, pentru incidentele care pot afecta semnificativ serviciile sau utilizatorii.
• Continuitatea activității: planuri de continuitate și recuperare pentru a menține operațiunile esențiale și a relua rapid activitatea după incidente majore.

---

Nucleul tehnic al NIS2 este Art. 21(2) din directivă↗, preluat în OUG 155/2024: zece familii de măsuri minime, proporționale cu riscul, pe care fiecare entitate trebuie să le implementeze:

• Politici de analiză a riscurilor și de securitate a sistemelor informatice;
• Gestionarea incidentelor;
• Continuitatea activității: backup, recuperare în caz de dezastru, managementul crizelor;
• Securitatea lanțului de aprovizionare, inclusiv relația cu furnizorii direcți;
• Securitatea în achiziția, dezvoltarea și mentenanța rețelelor și sistemelor, inclusiv gestionarea și divulgarea vulnerabilităților;
• Politici și proceduri pentru evaluarea eficacității măsurilor de management al riscului;
• Igienă cibernetică de bază și instruirea personalului;
• Politici privind criptografia și, unde e cazul, criptarea;
• Securitatea resurselor umane, controlul accesului și gestionarea activelor;
• Autentificare multifactor, comunicații securizate și sisteme de comunicații de urgență.

Două dintre aceste puncte se leagă direct de testarea de securitate:

---

Nu, nu în mod explicit. Directiva (UE) 2022/2555 nu folosește sintagma „test de penetrare” nicăieri în textul ei. Art. 21 cere entităților esențiale și importante să ia măsuri „adecvate și proporționale” de natură tehnică, operațională și organizatorică pentru gestionarea riscului cibernetic, iar Art. 21(2)(f) cere specific „politici și proceduri pentru evaluarea eficacității măsurilor de management al riscului”.

În practică, testarea — inclusiv pentest-ul — este modul standard prin care entitățile dovedesc această obligație. Dacă intri sub incidența NIS2, trebuie să poți arăta că măsurile tale chiar funcționează. Un pentest este cea mai comună cale prin care entitățile esențiale și importante fac asta, chiar dacă directiva nu-l numește niciodată.

O pagină de furnizor care afirmă sec „NIS2 cere pentest” este inexactă și este exact tipul de exagerare pe care motoarele de răspuns le penalizează din ce în ce mai mult. Răspunsul corect este și cel util: nu există o obligație nominală, dar există o obligație de gestionare a riscului pe care testarea de securitate este modul standard de a o dovedi.

---

Pentru incidentele semnificative, NIS2 impune o cascadă de raportare (Art. 23 din directivă), iar în România canalul este PNRISC, Platforma Națională de Raportare a Incidentelor de Securitate Cibernetică:

Cele trei termene se cumulează; niciunul nu îl înlocuiește pe cel anterior. Rapoartele se transmit CSIRT-ului național sau autorității competente, iar unde incidentul are impact transfrontalier, CSIRT-ul sau autoritatea competentă informează celelalte state membre afectate. Obligațiile NIS2 se aplică de la 18 octombrie 2024, deși unele state au transpus directiva mai târziu, deci aceste termene sunt deja active în cea mai mare parte a UE. PNRISC servește raportarea incidentelor, iar NIS2@RO și ATHENA înregistrarea și comunicarea administrativă, două fluxuri separate pe care companiile le confundă des.

---

Aici OUG 155/2024 merge mai departe decât minimul directivei și e partea pe care multe companii o descoperă târziu. Art. 11 alin. (5)–(6) și Art. 57–59 din ordonanță↗ instituie un regim de audit de securitate cibernetică obligatoriu:

• Audituri periodice, cu frecvență stabilită prin ordin al directorului DNSC (pe internet circulă cifre precise de tipul „o dată la X ani”; la data scrierii acestui articol nu există un număr confirmat, așa că tratează astfel de afirmații cu rezervă);
• Audituri ad-hoc, dispuse după incidente semnificative, modificări majore ale infrastructurii sau suspiciuni de neconformitate;
• Auditurile pot fi efectuate doar de auditori atestați de DNSC, înscriși în lista publică LASC (dnsc.ro↗), cu reguli stricte de independență: auditorul nu poate presta în mod curent servicii de securitate pentru entitate, nu poate avea un contract în derulare sau încheiat cu mai puțin de un an înainte pentru sistemul auditat și nu poate efectua mai mult de trei audituri consecutive la aceeași entitate;
• Separat de audit, dacă o activitate de supraveghere sau control produce o notă de constatare, Art. 47 alin. (5) cere un plan de remediere în cel mult 15 zile lucrătoare. Entitatea trebuie apoi să dovedească implementarea măsurilor în cel mult cinci zile de la termenul asumat. Acest termen nu trebuie prezentat drept efect automat al oricărui raport de audit.

În practică, auditorul verifică dacă măsurile din Art. 21 există și funcționează, iar entitatea rămâne cu un plan de remediere cu termene raportate autorității. Companiile care ajung la audit fără să-și fi testat vreodată sistemele află lista de probleme în timpul auditului, în cel mai scump și mai stresant moment posibil.

---

Regimul de sancțiuni din OUG 155/2024↗, modificată prin Legea 124/2025, urmează plafoanele minime din Art. 34 din directivă↗, care funcționează ca praguri de bază — statele membre pot stabili plafoane naționale mai mari:

Dincolo de amenzi, NIS2 atribuie obligații directe organelor de conducere. Conform Art. 20 din directivă, acestea aprobă măsurile de management al riscului, supraveghează implementarea și pot răspunde pentru încălcări. OUG 155/2024 cere și formare profesională acreditată. Există însă o nuanță națională importantă: Art. 50 alin. (4), introdus prin Legea 124/2025, precizează că adunarea generală a acționarilor și consiliul de administrație nu sunt „organe de conducere” în sensul ordonanței. Fiecare entitate trebuie să identifice exact persoanele și funcțiile vizate în propria structură, cu sprijin juridic, nu să atribuie automat această calitate întregului consiliu.

---

1. Verifică dacă intri sub incidență. Parcurge cele 18 sectoare și pragurile de mărime. Ține cont de entitățile care intră indiferent de mărime și de faptul că poți intra sub incidență și indirect, ca furnizor critic al unei entități acoperite.
2. Rezolvă înregistrarea. Dacă te încadrezi și nu ai notificat DNSC, fă-o acum prin NIS2@RO: mai bine mai târziu decât niciodată. Dacă ai notificat, urmărește etapele: decizia de identificare, ENIRE@RO, autoevaluarea de maturitate.
3. Fă o analiză de conformitate (gap assessment) pe Art. 21. Ia cele zece familii de măsuri și evaluează onest unde ești: ce politici există doar pe hârtie, ce controale nu au fost niciodată testate, unde lipsesc MFA, backup testat sau proces de gestionare a vulnerabilităților.
4. Testează-ți sistemele înainte s-o facă altcineva. Un pentest sau un audit de cod pe aplicațiile critice poate identifica vulnerabilități și poate contribui la dovezile tehnice pentru Art. 21(2)(e) și (f). Cu o platformă automată precum AISafe Labs poți repeta testarea după remedieri și păstra un istoric al rezultatelor. Auditorul stabilește cum folosește aceste rezultate în auditul statutar. Pentru buget și alegerea soluției, vezi ghidul despre pentest în România în 2026↗.
5. Pregătește fluxul de incidente. Definește ce înseamnă „incident semnificativ” pentru tine, cine raportează prin PNRISC și cum respecți cascada de 24 de ore, 72 de ore și o lună, inclusiv în weekend.
6. Pune conducerea în temă. Prezintă conducerii obligațiile, răspunderea personală și planul de conformare, apoi programează instruirile cerute.
7. Construiește dosarul de audit din mers. Politici, rapoarte de testare, dovezi de remediere, procese-verbale de instruire, adunate continuu, nu reconstituite în panică atunci când DNSC anunță auditul.

---

AISafe Labs rulează un pentest complet pe aplicațiile web și API-urile tale și produce un raport care leagă fiecare constatare de măsurile relevante din Art. 21(2), cu dovezi reproductibile pentru constatările ridicate și critice și remedieri gata pentru echipa ta de dezvoltare. Rezultatele vin în ore, nu în săptămâni.

• Constatări mapate la măsurile relevante de management al riscului din Art. 21(2);
• Dovezi reproductibile de exploatare pentru constatările ridicate și critice;
• Remedieri gata pentru dezvoltatori și o fereastră de retestare;
• Livrare în ore, cu validare reală a vulnerabilităților într-un mediu izolat.

Raportăm doar vulnerabilități validate: fiecare posibilă vulnerabilitate trece printr-o etapă de exploatare reală într-un mediu izolat, iar ce nu se reproduce nu ajunge în raport. Rapoartele conțin pași de reproducere, severitate justificată și rezumat executiv. Le poți pune la dispoziția unui auditor atestat DNSC, care le evaluează în raport cu scopul și metodologia auditului.

Auditul statutar nu îl facem noi. Legea îl rezervă auditorilor înscriși în lista LASC, iar rolul nostru se oprește la testarea tehnică și la datele care intră în planul de remediere. Raportul AISafe Labs nu stabilește clasificarea ta de entitate esențială sau importantă și nu te certifică, prin el însuși, față de directivă.

După primul audit rămânem pe proiect: facem review de securitate la fiecare Pull Request, față de modelul de amenințări construit în audit, și monitorizăm continuu endpointurile și permisiunile descoperite. Dosarul tău rămâne astfel actual între audituri. Ne integrăm cu GitHub, GitLab, Jira, Linear și cu pipeline-ul tău CI/CD.

Îți poți face gratuit cont în aplicația AISafe↗, cu audituri de cod pe un singur proiect; restul capabilităților intră în planurile plătite.