Patch management bazat pe risc în medii enterprise, în contextul NIS2

Articol scris de Bogdan Agiu, O365 L2 Engineer

O companie aplică lunar actualizările și totuși, când un auditor sau un responsabil de securitate întreabă ce patch a fost instalat, pe ce active, la ce dată, cu ce rezultat și dacă serverele au fost repornite, răspunsul întârzie zile întregi. Patch-urile se instalează. Dovada că au funcționat lipsește.

 

Aici se vede diferența pe care o face NIS2. Patch management-ul bazat pe risc este un proces repetabil, nu o instalare punctuală de o dată pe lună. Pe scurt, înseamnă identificarea vulnerabilităților, prioritizarea lor după riscul real, testarea, instalarea și verificarea aplicării. Articolul tratează infrastructuri hibride, sisteme critice și active aflate în administrarea furnizorilor, nu o prezentare generală a tuturor obligațiilor NIS2.

 

Un lucru merită clarificat din start. Un patch trimis nu este un patch instalat. Un patch instalat nu înseamnă automat un patch activ. Iar un patch activ nu garantează că vulnerabilitatea a fost confirmată ca remediată. Diferența dintre aceste stări este exact zona în care programele reale de securitate câștigă sau pierd.

 

Reprezentare a inventarului de active IT enterprise și maparea suprafeței de atac într-o infrastructură hibridă

 

Ce cere NIS2 în privința vulnerabilităților și a patch-urilor

Directiva NIS2 nu îți spune să instalezi toate patch-urile imediat. Îți cere să poți demonstra un proces coerent prin care gestionezi vulnerabilitățile proporțional cu riscul. Formularea este deliberat flexibilă, pentru că o microîntreprindere importantă și un operator energetic esențial nu pot fi tratate identic.

 

Legătura cu articolul 21

Articolul 21 din Directivă cere măsuri tehnice, operaționale și organizaționale adecvate și proporționale cu riscurile, cu expunerea, cu dimensiunea entității și cu impactul posibil al unui incident. Gestionarea patch-urilor intră direct sub cerința privind securitatea achiziției, dezvoltării și întreținerii rețelelor și sistemelor informatice, care include explicit gestionarea și divulgarea vulnerabilităților. Textul integral este disponibil pe EUR-Lex, versiunea în limba română.

 

Ce aduce Regulamentul 2024/2690

Pentru anumite categorii, generalitatea Directivei devine concretă. Regulamentul de punere în aplicare 2024/2690 detaliază cerințe tehnice pentru furnizori cloud, centre de date, furnizori de servicii gestionate (MSP și MSSP), furnizori DNS și alte entități digitale.

Secțiunile dedicate securității în achiziție și întreținere cer ca procedurile de gestionare a patch-urilor să fie:

• aliniate cu managementul schimbărilor, al vulnerabilităților și al riscului;
• aplicate într-un interval de timp rezonabil, în funcție de gravitate;
• testate înainte de a ajunge în producție;
• obținute din surse de încredere, cu verificarea integrității;
• completate cu măsuri suplimentare atunci când un patch nu poate fi aplicat;
• documentate când se decide că patch-ul nu se instalează.

Textul complet se găsește în Regulamentul de punere în aplicare (UE) 2024/2690.

 

Cadrul românesc și guvernanța

În România, transpunerea s-a făcut prin OUG 155/2024, aprobată și modificată ulterior prin Legea 124/2025. Directoratul Național de Securitate Cibernetică (DNSC) este autoritatea care supraveghează și verifică respectarea măsurilor la nivel național. Documentele oficiale sunt pe Portalul Legislativ, pentru OUG 155/2024 și pentru Legea 124/2025. Termenele exacte de raportare, pragurile de sancțiune și procedurile de control naționale se schimbă periodic, așa că orice decizie operațională ar trebui verificată direct în textul în vigoare la momentul respectiv.

 

Cine răspunde pentru ce

Un program de patching nu are un singur proprietar. Funcționează doar când responsabilitățile sunt clare între echipa de vulnerability management, administratorii de infrastructură, proprietarii aplicațiilor și serviciilor, echipele cloud și DevOps, proprietarii sistemelor critice și un change advisory board care aprobă schimbările. Managementul aprobă și supraveghează riscul rezidual acceptat. Nu înseamnă că fiecare excepție tehnică trece nominal prin CISO, ci că deciziile cu impact rămân trasabile până la cineva responsabil.

 

Inventarierea activelor și maparea suprafeței de atac

Nu poți aplica un patch pe un server despre care nu știi că există. Pare o banalitate, dar aici cad cele mai multe programe. Inventarul incomplet transformă orice strategie de prioritizare într-o presupunere.

Vizibilitatea completă a activelor este fundația oricărui program de patch management bazat pe risc.

 

Principiul vizibilității complete

Suprafața de atac a unei organizații medii acoperă mult mai mult decât laptopurile angajaților. Un inventar serios include servere fizice și virtuale, hypervizoare, endpoint-uri, aplicații și middleware, echipamente de rețea și de securitate, firmware, containere și imagini, servicii IaaS, PaaS și SaaS, plus sisteme OT, ICS și IoT industrial. La acestea se adaugă activele administrate de furnizori, care deseori scapă complet din evidența internă.

Problema reală sunt activele uitate. Shadow IT apărut peste noapte. Sisteme legacy on-premises pe care nimeni nu le mai atinge. Active fără proprietar clar. Sisteme ieșite din suport, care nu mai primesc patch-uri. Și active omise din scanări sau din platforma de patching, deci invizibile exact acolo unde contează.

 

Descoperire continuă, nu o dată pe an

Inventarul creat cu o săptămână înainte de audit îmbătrânește imediat. De aceea abordarea matură combină mai multe surse de descoperire, fiecare cu puncte forte diferite:

• inventariere bazată pe agenți, precisă dar dependentă de instalare;
• scanări agentless, utile pentru active unde agentul nu poate rula;
• monitorizare pasivă a rețelei, care prinde dispozitive neînregistrate;
• date corelate din CMDB, EDR, scannere de vulnerabilități și platforme cloud.

Niciuna singură nu acoperă totul. Împreună, apropie inventarul de realitate.

 

Datele minime dintr-un registru de active

Un registru util nu conține doar nume de host. Pentru fiecare activ merită să ai identificator unic, proprietar tehnic și proprietar de business, sistem de operare, aplicații, firmware și versiuni, mediu (producție, test, dezvoltare sau backup), expunere la internet, serviciul susținut, criticitate operațională, tipul de date procesate, dependențe, fereastră de mentenanță, mecanism de actualizare, statut de suport și data ultimei verificări tehnice. Fără aceste câmpuri, prioritizarea de mai târziu nu are pe ce să se sprijine.

 

Cloud, on-premises și SBOM

Inventarul din cloud trebuie corelat cu cel local. Datele din Entra ID și Intune se aliniază cu Active Directory, cu serverele fizice și cu restul infrastructurii on-premises, altfel ai două adevăruri paralele despre aceeași organizație.

Un SBOM (Software Bill of Materials) extinde inventarul în interiorul aplicațiilor, acolo unde scannerele clasice nu văd. Îți arată librăriile open source, componentele din aplicațiile proprii, dependențele microserviciilor și software-ul livrat de terți. Adaugă apoi etichetare consecventă, pe active expuse la internet, interne, segmentate, air-gapped, IT, OT, IoT, critice și redundante. Etichetele astea devin materia primă a deciziilor de prioritizare.

 

Vizibilitatea activelor în practică

O platformă de monitorizare a posturii tehnice precum Security OptiApp poate inventaria active din medii Entra ID, Microsoft 365, Active Directory și servere, semnalând discrepanțele dintre ce crede organizația că administrează și ce apare efectiv în sisteme. Scopul este o singură sursă de adevăr, nu o colecție de dashboard-uri separate.

 

Prioritizarea bazată pe risc, dincolo de scorul de severitate

Dacă tratezi toate vulnerabilitățile critice la fel, risipești resurse pe unele care nu vor fi niciodată exploatate și întârzii la cele care contează cu adevărat. Prioritizarea bazată pe risc înseamnă să decizi ce repari întâi pornind de la context, nu doar de la un număr.

 

Riscul real combină severitatea tehnică, probabilitatea de exploatare și contextul intern.

 

De ce CVSS nu ajunge singur

Un scor CVSS ridicat îți spune cât de gravă ar fi exploatarea, nu cât de probabilă este în mediul tău. O vulnerabilitate critică pe un server izolat, fără expunere la internet și fără date sensibile, nu are aceeași urgență ca una medie pe un activ expus care susține un serviciu critic. CVSS v4.0 recunoaște asta și separă metricile de bază de cele Threat și Environmental, permițând o evaluare mai apropiată de situația ta reală. Documentația completă e pe FIRST, CVSS v4.0.

 

Cele trei surse de context

Un model de prioritizare solid nu se bazează pe o singură cifră. Combină severitatea tehnică cu probabilitatea de exploatare, cu dovada exploatării active și cu ce știi despre propria infrastructură.

Sursă	Ce măsoară	Cum o folosești
CVSS v4.0	Severitatea tehnică și impactul potențial	Punct de pornire
EPSS	Probabilitatea estimată de exploatare în următoarele 30 de zile	Strat predictiv
CISA KEV	Vulnerabilități cu exploatare confirmată în realitate	Semnal de urgență
Context intern	Expunere, criticitate, date, dependențe, controale existente	Decizia finală

EPSS este un model statistic întreținut de FIRST, care estimează șansa ca o vulnerabilitate să fie exploatată în curând, util tocmai pentru că majoritatea CVE-urilor nu ajung niciodată să fie atacate. Detalii pe EPSS, FIRST. Catalogul KEV al CISA listează vulnerabilitățile despre care există dovadă de exploatare activă, deci cele unde amânarea devine periculoasă. Îl găsești la CISA Known Exploited Vulnerabilities Catalog.

 

Criteriile care decid prioritatea

În practică, decizia pune laolaltă mai mulți factori. Severitatea vulnerabilității. Probabilitatea exploatării. Existența unui exploit public sau a unui proof of concept. Statutul de weaponization, adică dacă exploatarea a fost deja transformată într-o unealtă funcțională. Expunerea activului. Criticitatea serviciului susținut. Impactul asupra disponibilității, integrității și confidențialității. Controalele compensatorii deja active. Dependențele și riscul de întrerupere la aplicarea patch-ului. Și, nu în ultimul rând, dacă există patch disponibil și o cale de rollback.

 

O matrice orientativă

Prioritate	Context	Tratament intern propus
P0	Zero-day sau prezent în CISA KEV, activ expus, serviciu critic	Remediere sau mitigare în 24–72 de ore
P1	Vulnerabilitate critică, EPSS ridicat sau exploit public	Remediere în 7–14 zile
P2	Vulnerabilitate importantă, fără exploatare confirmată	Următorul ciclu de patching
P3	Risc redus, activ necritic sau expunere limitată	Ciclu normal, de regulă până la 30 de zile

Aceste intervale sunt exemple de politică internă, calibrate de fiecare organizație. NIS2 nu impune termene fixe universale. Cere un proces proporțional și justificabil, iar o matrice ca aceasta este exact felul în care justifici deciziile.

 

Testarea înainte de producție și prevenirea downtime-ului

Patch-ul care repară o vulnerabilitate, dar pică o aplicație critică, nu e o victorie. E un incident autoprodus. Testarea nu e o formalitate birocratică, ci pasul care separă patching-ul controlat de cel care generează panică la ora trei noaptea.

 

Un flux de testare și promovare controlată reduce riscul de regresie în producție.

 

Medii de test și grupuri-pilot

Un mediu de staging are valoare doar dacă seamănă cu producția. Asta înseamnă replicarea configurațiilor critice, nu o aproximare. Pentru endpoint-uri funcționează bine grupurile-pilot și inelele de distribuție: patch-ul ajunge întâi la un grup restrâns, apoi se extinde dacă nu apar probleme. Aplicațiile legacy merită o atenție specială, pentru că acolo apar cele mai multe incompatibilități. Testele funcționale, cele de performanță și verificarea autentificării și a integrărilor prind problemele înainte ca ele să ajungă la utilizatorul final.

 

Microservicii și containere

Într-un mediu containerizat, logica se schimbă. Nu aplici un patch pe un container care rulează, îl reconstruiești. Asta înseamnă actualizarea imaginilor de bază, scanarea imaginilor înainte de deploy și redeploy în loc de modificare manuală. Infrastructura imutabilă, deployment-ul blue-green și cel canary îți dau control fin asupra expunerii, iar rollback-ul la versiunea anterioară devine o operațiune de rutină, nu o urgență.

 

Criterii de promovare și de rollback

Înainte de instalare, definește clar ce înseamnă succes și ce declanșează revenirea. Fără asta, improvizezi sub presiune. Un set minim de criterii include:

• criterii de succes măsurabile pentru promovare;
• praguri de eroare peste care implementarea se oprește;
• indicatori concreți care declanșează rollback;
• persoana care aprobă revenirea;
• durata maximă acceptabilă de indisponibilitate;
• procedura de verificare după revenire.

Backup-ul și snapshot-ul nu se presupun funcționale. Se testează. Un snapshot pe care nimeni nu l-a restaurat vreodată este o speranță, nu un plan de recuperare.

 

Ferestre de instalare, automatizare și sisteme critice

Momentul instalării contează aproape la fel de mult ca patch-ul în sine. O fereastră prost aleasă transformă o actualizare de rutină într-o întrerupere de serviciu vizibilă pentru clienți.

 

Ferestre de mentenanță

Majoritatea organizațiilor lucrează pe cicluri săptămânale sau lunare, aliniate la ritmul producătorilor, inclusiv la Patch Tuesday acolo unde ecosistemul o impune. Pe lângă ferestrele planificate, ai nevoie de ferestre de urgență pentru vulnerabilitățile P0, de ferestre diferite pe clase de active, de comunicarea din timp a indisponibilității planificate și de coordonare cu furnizorii care administrează o parte din active.

 

Automatizare și orchestrare

Nu toate activele se tratează la fel. Workstation-urile și endpoint-urile suportă patching automatizat fără prea multe gânduri. Serverele cer patching orchestrat, cu pași controlați. Bazele de date au nevoie de aprobări suplimentare, pentru că o greșeală acolo are consecințe mari. Producția merită implementare controlată, cu oprire automată atunci când rata de eroare depășește pragul stabilit. Diferența dintre automatizare și haos este exact acest prag.

 

Cloud-native și on-premises

Mecanismele diferă substanțial între medii. On-premises, lucrezi cu agenți tradiționali de patching. În cloud, actualizezi prin AMI și golden images, faci redeploy la mașini virtuale, înlocuiești instanțe sau actualizezi clustere. Și, important, în IaaS, PaaS și SaaS granița de responsabilitate dintre client și furnizor se mută. Modelul de responsabilitate partajată nu e un detaliu contractual, ci determină cine aplică ce patch și cine răspunde dacă nu se aplică.

 

Sisteme cu disponibilitate ridicată

Acolo unde serviciul nu are voie să cadă, patching-ul se face fără oprire totală. Clustering-ul, redundanța și failover-ul fac posibile rolling updates: actualizezi nodurile pe rând, validezi fiecare nod înainte de a trece la următorul și extinzi implementarea doar dacă totul confirmă stabilitatea. E mai lent. Dar nu produce întreruperi.

 

OT, ICS și infrastructuri critice

Mediile industriale au reguli proprii și patching-ul naiv acolo poate fi periculos. PLC-urile și sistemele SCADA au ferestre rare de mentenanță, iar oprirea frecventă e deseori imposibilă din motive de proces. Multe actualizări cer aprobarea OEM, altfel îți pierzi garanția sau suportul. Testarea se face în laborator sau într-un mediu reprezentativ, nu direct pe linia de producție. Separarea IT și OT, procedurile stricte de change management și corelarea cu planurile de business continuity și IT BCP devin obligatorii. Când patch-ul întârzie, și adesea întârzie, măsurile compensatorii acoperă golul.

 

Excepții, risc acceptat și măsuri compensatorii

Uneori patch-ul nu se poate aplica. Nu e un eșec al programului, ci o realitate operațională. Întrebarea nu este dacă vei avea excepții, ci dacă le gestionezi transparent sau le ascunzi până la următorul incident.

 

Când o excepție este legitimă

Există situații în care amânarea sau neaplicarea unui patch e justificată: incompatibilitate demonstrată cu o aplicație critică, lipsa unui patch de la producător, un sistem critic fără fereastră de mentenanță disponibilă, un risc disproporționat de indisponibilitate, o componentă legacy fragilă, un sistem ieșit din suport sau un patch retras ori instabil raportat de producător. Cuvântul cheie este demonstrată. O excepție fără analiză în spate este doar o amânare mascată.

 

Registrul excepțiilor

Fiecare excepție are nevoie de o urmă scrisă care să reziste la o verificare. Un registru corect notează, pentru fiecare caz, activul și vulnerabilitatea, motivul neaplicării, analiza de impact, proprietarul deciziei, aprobarea relevantă, durata, data expirării, planul de remediere, riscul rezidual acceptat și măsurile compensatorii aplicate între timp. O excepție fără dată de expirare tinde să devină permanentă, iar o excepție permanentă este, de fapt, un risc pe care nimeni nu l-a mai reevaluat.

 

Măsuri compensatorii

Când nu poți repara direct, reduci expunerea prin alte mijloace:

• virtual patching prin WAF, IPS, IDS sau firewall;
• microsegmentare și restricționarea accesului;
• dezactivarea serviciului vulnerabil, dacă nu e esențial;
• jump server și monitorizare suplimentară;
• reguli dedicate în SIEM și în EDR sau XDR;
• izolarea activului și scanări mai frecvente.

Aceste măsuri cumpără timp. Nu înlocuiesc patch-ul definitiv, iar excepția se reevaluează periodic, nu se uită într-un fișier.

 

Verificarea aplicării și închiderea buclei de remediere

Instalarea unui patch nu încheie treaba. O încheie confirmarea că vulnerabilitatea chiar a dispărut. Aici se desparte un program care arată bine pe hârtie de unul care rezistă la o verificare reală.

 

Bucla închisă transformă instalarea patch-ului în dovadă verificabilă de remediere.

 

Fluxul closed-loop

patch disponibil → activ identificat → prioritate stabilită → testare → aprobare → instalare → restart, dacă e necesar → verificare versiune → rescanare → test funcțional → închiderea tichetului

Fiecare săgeată este un punct unde ceva poate să cadă. Un program matur nu presupune trecerea, o verifică.

 

De ce raportul de distribuție nu este suficient

Un dashboard care spune „95% conform” inspiră încredere și ascunde probleme. Discrepanțele apar exact unde nimeni nu se uită: patch instalat, dar sistemul nerepornit, deci inactiv. Activ raportat ca actualizat, dar cu versiune greșită. Activ omis complet din grupul de implementare. Vulnerabilitate reapărută după actualizare. Patch aplicat pe un sistem, dar nu și pe componentele dependente. Serviciu picat după instalare și nesesizat până la prima reclamație. Raportul de distribuție îți spune ce a trimis platforma, nu ce s-a întâmplat efectiv pe activ.

 

Verificări post-instalare

Confirmarea reală combină mai multe verificări: versiunea instalată, starea serviciului, logurile relevante, rescanarea vulnerabilității, testarea funcțiilor critice, detectarea unei eventuale regresii și confirmarea că activul este inclus în politica aplicabilă. Dacă rescanarea arată că vulnerabilitatea e în continuare deschisă, rezultatul reintră în ciclul de remediere. Nu se închide tichetul doar pentru că instalarea a raportat succes.

 

Dovezi operaționale

Dovada nu se improvizează înaintea unui audit, se produce din proces. Materialul util include exportul din platforma de patch management, rezultatele de rescanare înainte și după, tichetul de schimbare, aprobările, logurile de instalare, rezultatele testelor, evidența rollback-ului, registrul excepțiilor și acceptarea documentată a riscului rezidual. Când aceste piese există deja, o verificare externă devine o prezentare, nu un maraton de câteva nopți.

 

Dovada tehnică, organizată

 

În zona de verificare, o platformă de monitorizare a posturii tehnice precum Security OptiApp poate urmări evoluția configurațiilor și poate organiza dovezile într-o formă reutilizabilă, astfel încât întrebarea „ce putem demonstra acum?” să aibă un răspuns rapid. Rolul este de a susține echipa, nu de a înlocui procesul sau controlul.

 

Indicatorii de progres, raportarea și checklist-ul operațional

Fără măsurători, nu știi dacă programul se îmbunătățește sau doar se agită. Indicatorii potriviți îți arată unde pierzi timp și unde rămâi expus, iar raportarea bună traduce datele tehnice în decizii de business.

 

Indicatori de performanță (KPI)

• Mean Time to Patch, timpul mediu de la publicare la remediere;
• Patch Compliance Rate, procentul activelor conforme;
• procentul activelor care respectă SLA-ul intern;
• timpul de la publicarea patch-ului la evaluare;
• timpul de la aprobare la instalare;
• rata instalărilor eșuate;
• Patch Rollback Rate;
• procentul patch-urilor verificate post-instalare.

 

Indicatori de risc (KRI)

• vulnerabilități exploatate rămase deschise;
• active critice încă expuse;
• vulnerabilități care au depășit SLA-ul;
• excepții expirate și neremediate;
• active fără proprietar sau fără suport;
• sisteme neacoperite de scanare;
• vulnerabilități recurente.

Raportarea către board nu se face în limbaj tehnic. Se face în întrebări de business: ce servicii critice rămân expuse, care este riscul rezidual acceptat, ce excepții au depășit termenul, unde depindem de furnizori pentru remediere și ce resurse lipsesc pentru a închide golurile. Un CIO poate răspunde la astfel de întrebări. Un dashboard de CVE-uri, mai greu.

 

Checklist operațional

• inventarul acoperă on-premises, cloud, containere, OT și active de furnizori;
• fiecare activ are proprietar și nivel de criticitate;
• prioritizarea combină CVSS, EPSS, KEV și contextul intern;
• patch-urile sunt testate înainte de producție;
• există ferestre standard și ferestre de urgență;
• sistemele critice au rollback și redundanță;
• excepțiile sunt documentate și limitate în timp;
• măsurile compensatorii sunt aplicate acolo unde patch-ul întârzie;
• instalarea este verificată prin rescanare și test funcțional;
• KPI și KRI ajung la management;
• dovezile sunt păstrate într-o formă reutilizabilă.

 

Este suficient CVSS pentru prioritizare?

Nu. CVSS îți dă severitatea tehnică, dar nu probabilitatea de exploatare și nici contextul tău. Pentru decizii bune, îl combini cu EPSS, cu CISA KEV și cu expunerea reală a activului.

 

Ce facem când un sistem critic nu poate fi actualizat?

Documentezi excepția cu analiză de impact și dată de expirare, aplici măsuri compensatorii, de la segmentare la virtual patching, și reevaluezi periodic. Excepția rămâne temporară prin design.

 

Cum demonstrăm că patch-ul este activ?

Prin verificarea versiunii, confirmarea repornirii dacă era necesară și rescanarea vulnerabilității. Un raport de distribuție arată intenția de instalare, nu rezultatul.

 

Care este diferența dintre patch instalat și vulnerabilitate remediată?

Un patch poate fi instalat fără restart, pe versiune greșită sau pe un sistem izolat de componentele sale dependente. Vulnerabilitatea e remediată doar când rescanarea o confirmă închisă. Un program de patch management bazat pe risc nu se judecă după câte patch-uri ai aplicat, ci după cât de repede poți demonstra ce ai reparat, ce ai amânat conștient și de ce. Dacă mâine un auditor, un partener sau propriul management întreabă care este starea reală a vulnerabilităților critice, răspunsul ar trebui să vină din proces, nu dintr-o cursă contra cronometru. Întrebarea pe care merită să ți-o pui acum nu este dacă aplici patch-uri, ci dacă poți dovedi că funcționează.

 

Despre Echipa Optimizor

Articol redactat de echipa Optimizor, specializată în servicii IT gestionate, securitate și conformitate pentru organizații medii și mari, cu expertiză în ecosistemul Microsoft, guvernanța identității și managementul vulnerabilităților în medii hibride. Optimizor este furnizor de servicii IT gestionate și dezvoltator al platformei Security OptiApp pentru monitorizarea posturii tehnice.

 

Analiza se bazează exclusiv pe surse primare legislative și tehnice oficiale, fără ajustări favorabile. Afirmațiile privind legislația românească, rolul DNSC, termenele de raportare și sancțiunile se verifică în textul în vigoare la momentul deciziei, întrucât cadrul normativ se poate modifica.

 

Surse

1. Directiva (UE) 2022/2555 (NIS2). Parlamentul European și Consiliul UE, 2022. eur-lex.europa.eu
2. Regulamentul de punere în aplicare (UE) 2024/2690. Comisia Europeană, 2024. eur-lex.europa.eu
3. NIS2 Technical Implementation Guidance. ENISA, 2025. enisa.europa.eu
4. Guide to Enterprise Patch Management Planning, SP 800-40 Rev. 4. NIST, 2022. csrc.nist.gov
5. Common Vulnerability Scoring System v4.0. FIRST, 2023. first.org/cvss/v4.0
6. Exploit Prediction Scoring System (EPSS). FIRST. first.org/epss
7. Known Exploited Vulnerabilities Catalog. CISA. cisa.gov
8. OUG 155/2024. Portal Legislativ România, 2024. legislatie.just.ro
9. Legea 124/2025. Portal Legislativ România, 2025. legislatie.just.ro