NIS2 și managementul vulnerabilităților: de la descoperire la dovadă, și de ce răspunde conducerea

„Avem un scaner” nu e același lucru cu „gestionăm vulnerabilitățile”. NIS2 face diferența asta explicită. Directiva (UE) 2022/2555, transpusă în România prin OUG 155/2024 și Legea 124/2025 (detalii în articolul nostru NIS2 în România), nu îți cere o unealtă, îți cere o buclă închisă și dovedită: găsești, prioritizezi, repari, re-testezi, dovedești. Iar prin Articolul 20, pune conducerea să răspundă pentru asta.

Acest material e informativ, nu consultanță juridică: pentru situația ta, verifică la DNSC și cu un consultant.

Ce cere NIS2, de fapt, la vulnerabilități

Două prevederi contează direct:

• Articolul 21(2)(e) cere securitate în achiziția, dezvoltarea și mentenanța sistemelor, inclusiv tratarea și divulgarea vulnerabilităților. Nu „scanează”, ci „tratează”, adică du constatarea până la capăt.
• Articolul 21(2)(f) cere proceduri care evaluează dacă măsurile funcționează. O vulnerabilitate reparată pe hârtie, dar nere-testată, nu trece acest test.

Observă ce lipsește din nou: numele vreunui produs. Legea descrie un proces cu rezultat verificabil, nu un raft de magazin.

Bucla, nu scanarea

Un scaner îți dă o listă. Managementul vulnerabilităților e ce faci cu ea. Bucla pe care o cere, implicit, NIS2:

1. Găsești tot ce expui, inclusiv ce nimeni nu-și mai amintește. Suprafața reală include subdomenii uitate, servicii de test rămase online, containere și dependențe, nu doar ce e în inventarul oficial.
2. Prioritizezi după risc real, nu după lungimea listei. Următoarea secțiune detaliază.
3. Repari, cu un proprietar și un termen clar pentru fiecare constatare. O vulnerabilitate fără proprietar nu se rezolvă, migrează de la un raport la altul.
4. Re-testezi, ca să confirmi că remedierea chiar a închis problema, nu doar că cineva a bifat „rezolvat”.
5. Dovedești, păstrând pista de audit. Fără pasul ăsta, tot ce ai făcut înainte e invizibil pentru un auditor.

Pașii 4 și 5 sunt exact cei pe care organizațiile îi sar, și exact cei pe care NIS2 îi cere la (f). Am dezvoltat ideea separat, fiindcă e valabilă dincolo de NIS2, în controlul care trece testul.

Prioritizarea: nu toate vulnerabilitățile sunt egale

Cea mai frecventă greșeală e tratarea listei în ordinea scorului CVSS. Scorul e util, dar incomplet. O prioritizare care rezistă unei verificări ține cont de:

• expunere: un serviciu accesibil de pe internet contează mai mult decât unul izolat în rețeaua internă;
• exploatare activă: vulnerabilitățile deja exploatate în sălbăticie se tratează primele, indiferent de scor;
• impact asupra afacerii: ce proces se oprește dacă sistemul cade.

Un scor „mediu” pe un serviciu public, exploatat activ, e mai urgent decât un „critic” pe un sistem fără cale de acces. Prioritizarea e locul unde securitatea întâlnește realitatea operațională, nu un clasament automat.

Dovada și pista de audit

La o verificare DNSC, întrebarea nu e „aveți un scaner?”, ci „arătați-mi bucla”. Concret, pentru o constatare trebuie să poți arăta: când a fost găsită, cine a fost proprietarul, ce termen a avut, când și cum a fost reparată, și dovada re-testării care confirmă închiderea. Plus excepțiile, înregistrate cu motiv și termen, nu derogări tăcute.

O politică de management al vulnerabilităților fără aceste urme e o afirmație. Pista de audit o transformă în control. Diferența asta decide un audit.

Articolul 20: de ce răspunde conducerea

Aici e partea pe care mulți o ratează. NIS2 nu lasă securitatea doar în curtea echipei IT. Articolul 20 cere ca organele de conducere ale entităților esențiale și importante să aprobe măsurile de gestionare a riscurilor, să supravegheze implementarea lor și să urmeze formare de specialitate. Conducerea poate răspunde pentru neîndeplinirea obligațiilor.

Efectul practic e că managementul vulnerabilităților urcă de la un tichet IT la o responsabilitate de board. Un patch întârziat nu mai e doar o problemă tehnică; devine o decizie pe care cineva din conducere a aprobat-o sau a ignorat-o, cu urme. Sancțiunile din Legea 124/2025 (până la 7 milioane euro sau 1,4% din cifra de afaceri pentru entități importante, până la 10 milioane euro sau 2% pentru cele esențiale) au acum și un destinatar clar.

Ce faci concret, proporțional cu riscul

Fără a cumpăra nimic anume, ordinea care rezistă unei verificări:

1. Descoperire continuă, nu o scanare anuală, și inclusiv a expunerii pe care nu o aveai în inventar.
2. Prioritizare pe risc (expunere, exploatare activă, impact), nu pe scorul brut.
3. Proprietar și termen pentru fiecare constatare.
4. Re-testare care confirmă remedierea.
5. Pistă de audit strânsă pe măsură ce lucrezi, nu cu o zi înainte de control.
6. Raportare către conducere, ca Articolul 20 să fie îndeplinit, nu doar invocat.

Ce reținem

NIS2 tratează managementul vulnerabilităților ca pe un proces cu rezultat dovedit, nu ca pe o unealtă. Găsirea e doar începutul; valoarea e în ce urmează, reparare, re-testare, dovadă, și în faptul că cineva din conducere răspunde de bucla asta. Cine se oprește la „avem un scaner” are o listă. Cine închide și dovedește bucla are un control, și, întâmplător, și conformitate.

Vrei să știi cum arată bucla ta de management al vulnerabilităților față de ce cere NIS2, și unde se rupe? Scrie-ne și pornim de la o evaluare.

Surse

• EUR-Lex: Directiva (UE) 2022/2555 (NIS2), Articolele 20 și 21
• DNSC, Directoratul Național de Securitate Cibernetică
• ENISA: baza de date europeană a vulnerabilităților (EUVD)