G Ghid · ISO 27001

ISO 27001: gestionarea vulnerabilităților tehnice

Controlul A.8.8 din ISO 27001 cere să identifici, prioritizezi cu CVSS și remediezi vulnerabilitățile tehnice. Ghid practic: scanare, patch, legătura cu NIS2.

Elena Tudor
Elena Tudor
Specialist ISO 27001 & GDPR
7 min citire Publicat 3 iun. 2026
ISO 27001: gestionarea vulnerabilităților tehnice

Controlul A.8.8 din ISO 27001 îți cere să identifici vulnerabilitățile tehnice ale sistemelor tale și să le tratezi înainte să fie exploatate. Practic, ții un inventar de active, scanezi periodic, prioritizezi după gravitate și aplici patch-urile la timp.

Este unul dintre controalele tehnologice din Anexa A (categoria A.8) și unul dintre cele mai verificate la audit, pentru că aici se vede dacă firma chiar gestionează riscul sau doar are documente.

Problema: peste 40.000 de vulnerabilități noi într-un an

În 2024 s-au publicat 40.009 vulnerabilități CVE, cu aproape 39% mai multe decât în 2023. Asta înseamnă o medie de circa 108 vulnerabilități noi în fiecare zi, în software pe care firmele îl folosesc zilnic: sisteme de operare, servere web, biblioteci, aplicații cloud.

CVE (Common Vulnerabilities and Exposures) este catalogul public în care fiecare vulnerabilitate cunoscută primește un cod unic, de exemplu CVE-2024-3094. Furnizorii și cercetătorii raportează acolo problemele, iar tu poți verifica dacă produsele tale sunt afectate.

O singură vulnerabilitate necorectată e suficientă. Multe dintre incidentele ransomware gestionate de DNSC în România au pornit de la sisteme neactualizate, cu un patch disponibil de luni de zile. Controlul A.8.8 există ca să nu ajungi în acea statistică.

Ce cere controlul A.8.8 din ISO 27001

A.8.8 (Managementul vulnerabilităților tehnice) cere trei lucruri: să obții informații despre vulnerabilitățile sistemelor pe care le folosești, să evaluezi cât de expusă e firma și să iei măsuri concrete, adică patch, reconfigurare, izolare sau acceptarea documentată a riscului.

În versiunea ISO/IEC 27001:2022, controlul comasează două controale vechi din ediția 2013: A.12.6.1 (vulnerabilități tehnice) și A.18.2.3 (verificarea conformității tehnice). Noutatea din 2022 este accentul pe proces continuu în loc de patching reactiv, plus atenția pe serviciile cloud, unde responsabilitatea e împărțită între tine și furnizor.

Standardul îl clasifică drept control preventiv și detectiv: previi exploatarea prin actualizări și detectezi problemele prin scanare. Auditorul cere dovezi pentru ambele, dincolo de politica scrisă.

Procesul de gestionare a vulnerabilităților în cinci pași

  1. Fă inventarul activelor: ce sisteme, aplicații, versiuni și biblioteci folosești. Fără inventar, nu știi ce să scanezi.
  2. Stabilește sursele de informații: baza de date CVE/NVD, alertele DNSC și buletinele furnizorilor (Microsoft, distribuțiile Linux, producătorii de echipamente).
  3. Scanează periodic, cu un instrument dedicat, pentru a găsi problemele din sistemele tale.
  4. Prioritizează după gravitate, folosind scorul CVSS și contextul tău (un server expus la internet contează mai mult decât unul intern).
  5. Remediază: aplici patch-ul, schimbi configurarea sau, dacă nu se poate imediat, aplici o măsură temporară și documentezi decizia.

Pasul 4 se ratează cel mai des. Firmele scanează, obțin o listă de 800 de probleme, apoi se blochează fiindcă le tratează pe toate la fel.

Scanarea vulnerabilităților: internă și externă

Ai nevoie de două perspective, pentru că un atacator le are pe amândouă.

  • Scanarea externă verifică ce vede cineva din afară: porturi deschise, servicii expuse, certificate expirate, aplicații web accesibile public.
  • Scanarea internă verifică ce ar putea exploata un atacator care a trecut deja de perimetru sau un angajat rău intenționat: servere interne, stații de lucru, drepturi configurate greșit.

Frecvența o stabilești prin evaluarea de risc. În practică, scanarea variază între săptămânal și trimestrial: sistemele critice și cele expuse la internet se scanează mai des, restul mai rar. Pe lângă scanarea programată, rulezi una suplimentară după orice schimbare majoră, adică un server nou, o aplicație nouă sau o migrare în cloud.

Prioritizarea cu scorul CVSS

CVSS (Common Vulnerability Scoring System) dă fiecărei vulnerabilități un scor de la 0 la 10, în funcție de cât de ușor și cât de grav poate fi exploatată. Versiunea actuală, CVSS v4.0, a fost publicată în noiembrie 2023. Scorul te ajută să decizi ce repari întâi.

SeveritateScor CVSSTermen de remediere (bună practică)
Critică9.0-10.024-72 de ore
Ridicată7.0-8.97 zile
Medie4.0-6.930 de zile
Scăzută0.1-3.990 de zile sau acceptarea riscului

Termenele din tabel sunt practică de piață, nu o cerință legală fixă. Le adaptezi la contextul tău: o vulnerabilitate medie pe un server cu date de clienți poate urca în prioritate, iar una critică pe un sistem izolat, fără acces la internet, poate coborî. Scorul CVSS e punctul de plecare, iar decizia finală o iei tu, pe baza riscului real.

Patch management și remedierea

Remedierea înseamnă de obicei un patch, dar nu mereu. Uneori furnizorul nu a publicat încă o corecție, sau patch-ul ar opri un sistem de producție. Atunci aplici o măsură temporară: izolezi sistemul, închizi un serviciu, adaugi o regulă de firewall. Tot remediere se numește, dacă o documentezi.

Ai un SRL cu 18 angajați care dezvoltă software pentru clienți din Germania. Clientul cere certificare ISO 27001. Rulezi scanarea lunară și găsești 240 de probleme. Trei sunt critice, una fiind pe serverul web expus la internet, cu scor CVSS 9.8. Conform politicii, echipa aplică patch-ul critic în 48 de ore, programează cele 20 ridicate în următoarea săptămână și pune restul într-un registru cu termene. La audit arăți logul de scanare, ticketele de remediere și deciziile pentru ce nu ai patch-uit imediat. Asta trece controlul A.8.8.

Legătura cu NIS2 și rolul DNSC

Dacă firma ta intră sub NIS2, managementul vulnerabilităților devine obligatoriu. NIS2 a fost transpusă în România prin OUG 155/2024, aprobată cu modificări prin Legea 124/2025, și include managementul vulnerabilităților printre măsurile obligatorii de securitate cibernetică.

DNSC (Directoratul Național de Securitate Cibernetică) emite alerte de securitate și coordonează divulgarea vulnerabilităților între cei care le raportează și furnizori. Tot DNSC primește notificările și agreează termenele de remediere pentru entitățile reglementate.

Amenzile sub NIS2 ajung până la 10 milioane EUR sau 2% din cifra de afaceri anuală pentru entitățile esențiale. Un control A.8.8 funcțional acoperă o parte din aceste cerințe, însă verifică în comparația ISO 27001 vs NIS2 ce mai trebuie completat. Procesul se leagă direct de planul de tratare a riscului și de gestionarea incidentelor: scanarea găsește problema, planul de tratare decide ce faci, iar procedura de incidente intră în joc dacă vulnerabilitatea a fost deja exploatată.

Întrebări frecvente

Cât de des trebuie să scanez vulnerabilitățile?

Frecvența o stabilești prin evaluarea de risc. În practică, sistemele critice și cele expuse la internet se scanează săptămânal sau lunar, restul trimestrial. Suplimentar, scanezi după orice schimbare majoră de infrastructură.

A.8.8 cere un anumit instrument de scanare?

Nu. ISO 27001 nu impune un produs anume. Cere doar să ai un proces care găsește, prioritizează și remediază vulnerabilitățile, plus dovezi că funcționează.

Ce înseamnă scorul CVSS?

CVSS este un sistem care notează gravitatea unei vulnerabilități de la 0 la 10. Peste 9.0 e critică, între 7.0 și 8.9 e ridicată. Scorul te ajută să decizi ce repari prima dată.

Elena Tudor
Scris de
Elena Tudor
Specialist ISO 27001 & GDPR

Elena este specializată în securitatea informației și protecția datelor. Ajută companiile IT și fintech să obțină certificarea ISO 27001 și să demonstreze conformitatea GDPR.

Vezi toate articolele