Amenzile NIS2 ajung la 10.000.000 EUR pentru entitatile esentiale din Romania, iar evaluarea riscurilor de securitate a informatiei e prima cerinta pe care o verifica DNSC. Acelasi lucru il verifica si auditorul ISO 27001 la certificare. Clauza 6.1.2 din ISO 27001 cere o metodologie documentata de evaluare a riscurilor. Fara ea, nu obtii certificarea si nu demonstrezi conformitatea cu NIS2.
Problema: de ce pica firmele la evaluarea riscurilor
Cele mai frecvente greseli la auditul de certificare ISO 27001 tin de evaluarea riscurilor. Auditorul deschide registrul de riscuri si gaseste una din aceste situatii:
- Riscuri copiate dintr-un template generic, fara legatura cu activitatea firmei
- Lipsa completa a criteriilor de acceptare (nu stii ce nivel de risc tolerezi)
- Nicio legatura intre riscurile identificate si controalele selectate din Anexa A
- Evaluarea facuta o singura data si niciodata revizuita
Oricare din aceste situatii inseamna neconformitate. Clauza 6.1.2 din ISO 27001:2022 cere o metodologie documentata, repetabila si adaptata firmei tale.
Ce cere standardul la clauzele 6.1.2 si 8.2
Clauza 6.1.2 din SR EN ISO/IEC 27001:2023 stabileste cinci cerinte concrete pentru evaluarea riscurilor:
- Defineste criteriile de evaluare: cum masori consecintele si probabilitatea fiecarui risc
- Identifica riscurile care pot afecta confidentialitatea, integritatea sau disponibilitatea informatiilor
- Atribuie un proprietar pentru fiecare risc (persoana cu autoritate sa decida tratarea)
- Evalueaza consecintele si probabilitatea fiecarui risc pe scala ta
- Stabileste ce nivel de risc e acceptabil si ce depaseste pragul de toleranta
Standardul nu impune o metoda anume. Poti folosi ISO 27005 ca referinta, dar nu e obligatoriu. Ce conteaza e sa fie consistenta, documentata si sa produca rezultate comparabile de fiecare data cand o aplici.
Clauza 8.2 cere sa refaci evaluarea la intervale planificate sau cand apar schimbari semnificative. Ai migrat pe un nou furnizor cloud? Refaci evaluarea. Ai angajat 20 de oameni? Refaci evaluarea.
Metodologia activ-amenintare-vulnerabilitate
Cea mai folosita abordare in practica e modelul activ-amenintare-vulnerabilitate. Functioneaza asa:
Activul este orice are valoare pentru firma ta: un server, o baza de date cu clienti, laptopurile angajatilor, codul sursa al aplicatiei, conturile de email.
Amenintarea este evenimentul care poate provoca daune: atac ransomware, incendiu in sala de servere, angajat care pleaca cu date, eroare umana la configurarea unui firewall.
Vulnerabilitatea este slabiciunea care permite amenintarii sa se materializeze: lipsa backup-ului, absenta autentificarii in doi pasi, angajati care nu au fost instruiti sa recunoasca phishing-ul.
Un risc exista doar cand toate trei se intalnesc. Ai un server (activ) care poate fi afectat de ransomware (amenintare) pentru ca nu ai backup offline (vulnerabilitate). Asta e un risc concret, nu unul generic.
Matrice de risc pentru securitatea informatiei
Dupa ce ai identificat riscurile, le evaluezi pe doua axe: probabilitate si impact. Tabelul de mai jos arata o matrice 3x3, cea mai practica pentru firme sub 100 de angajati.
| Probabilitate / Impact | Scazut (1) | Mediu (2) | Ridicat (3) |
|---|---|---|---|
| Ridicata (3) | 3 (moderat) | 6 (ridicat) | 9 (critic) |
| Medie (2) | 2 (scazut) | 4 (moderat) | 6 (ridicat) |
| Scazuta (1) | 1 (scazut) | 2 (scazut) | 3 (moderat) |
Scorul se calculeaza prin inmultirea probabilitatii cu impactul. Pragul de acceptare il stabilesti tu. Multi aleg pragul la 4: riscurile cu scor sub 4 le accepti, restul le tratezi.
Exemplu concret: o firma de software din Cluj cu 35 de angajati si un produs SaaS evalueaza riscul de pierdere a datelor clientilor din cauza unui atac ransomware. Probabilitate: 2 (medie, au antivirus dar nu au segmentat reteaua). Impact: 3 (ridicat, pierderea datelor inseamna pierderea clientilor si posibila amenda GDPR). Scor: 6. Depaseste pragul de 4, deci riscul trebuie tratat.
Tratarea riscurilor si legatura cu SoA
Riscurile care depasesc pragul de acceptare au patru optiuni de tratare:
- Reduci riscul prin implementarea unui control (ex: backup zilnic criptat pe locatie separata)
- Eviti riscul prin eliminarea activitatii care il genereaza (ex: nu mai stochezi date pe servere locale)
- Accepti riscul in mod constient, cu aprobarea managementului (ex: riscul e de scor 5, costul controlului ar fi disproportionat)
- Transferi riscul (ex: asigurare cibernetica, externalizare catre un furnizor certificat)
Pentru fiecare risc pe care decizi sa il reduci, selectezi unul sau mai multe controale din cele 93 din Anexa A. Aceasta selectie se documenteaza in Declaratia de Aplicabilitate (SoA), unde justifici de ce ai inclus sau exclus fiecare control.
Practic, evaluarea de risc e motorul care pune in miscare tot SMSI-ul. Fara ea, selectia controalelor din Anexa A e arbitrara, iar SoA nu are fundament.
Legatura cu NIS2 si cerintele DNSC
OUG 155/2024 (transpunerea Directivei NIS2, aprobata prin Legea 124/2025) cere entitatilor esentiale si importante din Romania sa evalueze riscurile de securitate cibernetica. Ordinul DNSC 2/2025 stabileste o metodologie proprie prin instrumentul ENIRE@RO, care clasifica entitatile in trei niveluri: Basic, Important, Essential.
Daca firma ta intra sub incidenta NIS2, evaluarea de riscuri ISO 27001 acopera o parte din cerintele DNSC. Amenzile pentru neconformitate ajung la 10.000.000 EUR pentru entitati esentiale. O evaluare de riscuri facuta corect conform ISO 27001 nu te scuteste automat de cerintele NIS2, dar te pune intr-o pozitie mult mai buna la verificarea DNSC.
Greseli frecvente si cum le eviti
O firma de servicii financiare din Bucuresti cu 45 de angajati a facut evaluarea de riscuri cu un consultant extern care a livrat un document de 80 de pagini. La auditul de supraveghere, responsabilul SMSI nu a putut explica cum s-au stabilit scorurile de risc. Auditorul a emis neconformitate minora: daca echipa ta nu intelege metodologia, evaluarea nu e functionala.
Trei reguli practice:
Pastreaza matricea simpla. O matrice 3x3 sau 5x5 e suficienta. Matricele cu 10 niveluri de probabilitate si 10 de impact creeaza complexitate inutila.
Implica proprietarii de risc in evaluare. Administratorul de retea stie mai bine decat directorul general care e probabilitatea unui atac pe VPN. Proprietarul de risc trebuie sa fie persoana care intelege si poate decide.
Revizuieste la fiecare schimbare. Clauza 8.2 nu cere doar revizuire anuala. Daca ai migrat pe Azure, ai schimbat furnizorul de hosting sau ai trecut la munca remote, riscurile s-au schimbat. Refaci evaluarea pe zonele afectate, nu pe tot registrul.