Ce dovezi trebuie să poată prezenta o companie pentru conformitatea NIS2?

Poți avea firewall, antivirus, backup, MFA și politici de securitate.

Dar întrebarea importantă este alta:

Poți demonstra că măsurile de securitate există, sunt aplicate și funcționează?

Pentru conformitatea NIS2, aceasta este diferența dintre o companie care „face securitate” și una care poate demonstra că își gestionează riscurile de securitate cibernetică.

NIS2 cere organizațiilor vizate să implementeze măsuri tehnice, operaționale și organizaționale adecvate și proporționale cu riscurile. În România, cadrul a fost transpus prin OUG nr. 155/2024, ulterior aprobată prin Legea nr. 124/2025. Raportul DNSC privind piața serviciilor vCISO evidențiază legătura dintre guvernanță, managementul riscurilor, conformitate și responsabilitatea managementului.

Așadar, managementul ar trebui să se întrebe nu doar:

„Avem măsurile necesare?”

ci:

„Dacă mâine ni se cer dovezile, ce putem prezenta?”

Important: NIS2 stabilește domeniile și rezultatele de securitate care trebuie gestionate. Forma exactă a documentelor și dovezilor depinde de riscurile, dimensiunea, activitatea și obligațiile aplicabile fiecărei organizații. Nu toate exemplele de mai jos reprezintă documente obligatorii, în aceeași formă, pentru toate companiile.

Ce înseamnă, de fapt, o dovadă NIS2?

Pentru fiecare control important ar trebui să existe un lanț simplu și verificabil:

1. Regula

Ce am stabilit că trebuie făcut?

2. Implementarea

Ce am făcut efectiv?

3. Dovada

Cum demonstrăm că măsura există, este aplicată și funcționează?

De exemplu:

Regulă: datele critice trebuie salvate zilnic.

Implementare: există o soluție de backup configurată pentru serverele critice.

Dovadă: rapoartele de backup arată execuții reușite, iar un test recent demonstrează că datele pot fi restaurate.

Acest principiu — Regulă → Implementare → Dovadă — poate fi aplicat aproape tuturor domeniilor relevante pentru NIS2.

ENISA oferă, prin ghidul său de implementare tehnică NIS2, recomandări practice și exemple care ajută companiile să transforme cerințele de securitate în măsuri verificabile și dovezi concrete.

1. Evaluarea documentată a riscurilor

Unul dintre primele lucruri pe care o companie trebuie să le poată demonstra este că își cunoaște riscurile.

Nu este suficient ca IT Managerul să știe informal că „serverul acesta este critic” sau că „backup-ul reprezintă o problemă”.

Ar trebui să existe un proces documentat prin care organizația identifică și evaluează riscurile importante.

În funcție de complexitate, pot exista informații despre:

• • active și procese importante;
  • amenințări și vulnerabilități relevante;
  • probabilitate și impact;
  • nivelul riscului;
  • măsurile existente;
  • acțiunile necesare;
  • responsabilul pentru risc;
  • riscul rezidual;

Managementul riscului presupune identificarea, analiza, prioritizarea, tratarea și monitorizarea riscurilor, nu doar întocmirea unei liste de probleme tehnice.

Dovezi posibile: registru de riscuri, rapoarte de evaluare, planuri de tratare, responsabilități și aprobări ale riscurilor reziduale.

2. Politicile și procedurile de securitate

O politică descărcată de pe internet și păstrată într-un folder nu demonstrează că organizația lucrează conform acesteia.

Documentația trebuie să reflecte realitatea companiei.

În funcție de activitate și risc, pot exista politici și proceduri privind:

• • securitatea informațiilor;
  • controlul accesului;
  • administrarea conturilor;
  • backup și restaurare;
  • managementul vulnerabilităților;
  • gestionarea actualizărilor de securitate;
  • răspunsul la incidente;
  • criptografia;
  • relația cu furnizorii;
  • onboarding și offboarding;
  • continuitatea activității;

Dovezi posibile: politici aprobate, proceduri operaționale, versiuni actualizate, data ultimei revizuiri, responsabili și înregistrări ale aplicării lor.

3. Dovada implicării managementului

Unele dintre cele mai importante dovezi NIS2 nu sunt tehnice: ele arată că managementul a fost informat, a luat decizii și a urmărit riscurile.

Securitatea cibernetică nu mai poate fi tratată exclusiv ca o problemă a departamentului IT.

Managementul trebuie să înțeleagă riscurile relevante, să aprobe anumite măsuri și să urmărească implementarea acestora.

Compania ar trebui să poată demonstra că managementul:

• • primește informații despre principalele riscuri;
  • cunoaște măsurile critice neimplementate;
  • aprobă deciziile importante;
  • urmărește progresul;
  • cunoaște riscurile reziduale relevante;
  • participă la instruirea necesară;

Raportul DNSC privind piața vCISO evidențiază tocmai această evoluție: securitatea devine o problemă de guvernanță și responsabilitate managerială, iar rolul CISO/vCISO creează legătura dintre riscul tehnic și decizia de business.

Dovezi posibile: rapoarte către management, minute ale ședințelor, aprobări, decizii privind bugetele, acceptări de risc și evidențe ale instruirii.

Un bun punct de plecare pentru orice consiliu de administrație este lista celor 10 întrebări esențiale despre riscul cibernetic pentru management.

4. Activele și controlul accesului

Ce trebuie să știi că ai

Este dificil să protejezi ceea ce nu știi că există.

Organizația trebuie să știe care sunt sistemele, informațiile și serviciile relevante pentru funcționarea business-ului.

În funcție de companie, acestea pot include:

• • servere;
  • stații de lucru;
  • echipamente de rețea;
  • aplicații;
  • servicii cloud;
  • baze de date;
  • conturi privilegiate;
  • informații sensibile;
  • sisteme furnizate de terți;

Pentru activele importante trebuie înțeles și impactul asupra business-ului dacă devin indisponibile, sunt compromise sau datele sunt pierdute.

Cine are acces la ce

Controlul accesului trebuie tratat separat și verificabil.

Un angajat poate primi acces la un folder pentru un proiect, apoi își schimbă rolul, dar drepturile rămân. Un colaborator primește acces temporar, dar nimeni nu îl mai retrage.

Pentru a demonstra controlul accesului, nu este suficient ca organizația să spună că „folosește parole și MFA”.

Trebuie să existe un proces de acordare, revizuire și retragere a accesului.

Dovezi posibile: inventare hardware și software, liste de servicii cloud, diagrame de rețea, clasificarea activelor, liste de utilizatori și drepturi, aprobări pentru acces, revizuiri periodice ale permisiunilor, evidențe privind conturile privilegiate și dezactivarea conturilor.

Diferența este simplă:

„Avem MFA” este o afirmație.

„Acestea sunt sistemele protejate prin MFA, utilizatorii acoperiți și rapoartele care confirmă configurarea” este o dovadă.

5. Continuitatea activității, backup-ul și recuperarea

„Avem backup” este una dintre cele mai frecvente afirmații întâlnite în evaluările de securitate.

Dar existența unui backup nu demonstrează că datele pot fi recuperate.

Organizația ar trebui să știe:

• • ce date sunt salvate;
  • cât de frecvent;
  • unde sunt păstrate;
  • cine verifică execuția;
  • cât timp sunt reținute;
  • când a fost făcut ultimul test de restaurare;
  • dacă restaurarea a reușit;
  • cât durează recuperarea sistemelor importante;

O politică de backup nu demonstrează că backup-ul funcționează. Un test de restaurare reușit oferă o dovadă mult mai relevantă.

Dar backup-ul reprezintă doar o parte a continuității.

Managementul trebuie să știe și ce se întâmplă dacă un sistem important nu mai funcționează pentru câteva ore sau câteva zile.

Pentru procesele critice este util să existe claritate privind:

• • ordinea recuperării;
  • dependențele dintre sisteme;
  • responsabilitățile;
  • timpul acceptabil de indisponibilitate;
  • cantitatea de date care poate fi pierdută;
  • alternativele temporare de lucru;

Dovezi posibile: rapoarte de backup, rezultate ale testelor de restaurare, planuri de continuitate, scenarii de recuperare și rezultate ale exercițiilor.

6. Gestionarea incidentelor

În timpul unui incident nu este momentul potrivit pentru a decide cine izolează sistemele, cine contactează managementul, cine vorbește cu furnizorii sau cine stabilește dacă incidentul trebuie raportat.

Organizația ar trebui să aibă un proces clar de răspuns la incidente.

Dovezi posibile:

• • plan de răspuns;
  • roluri și responsabilități;
  • matrice de escaladare;
  • contacte de urgență;
  • registrul incidentelor;
  • cronologia incidentelor;
  • rapoarte post-incident;
  • acțiuni rezultate din lecțiile învățate;
  • rezultate ale exercițiilor de simulare;

Un plan aflat într-un folder demonstrează existența unui document.

Un exercițiu în care oamenii au folosit planul demonstrează mult mai bine capacitatea organizației de a răspunde.

7. Securitatea furnizorilor

O companie poate avea controale bune intern și, în același timp, să depindă critic de un furnizor insuficient securizat.

De aceea, trebuie să știe:

• • ce furnizori susțin servicii importante;
  • la ce date și sisteme au acces;
  • ce s-ar întâmpla dacă furnizorul ar deveni indisponibil;
  • ce obligații de securitate are;
  • cum este evaluat;
  • ce se întâmplă dacă apare un incident;

Dovezi posibile: registrul furnizorilor, evaluări de risc, chestionare de securitate, contracte, acorduri de nivel al serviciilor (SLA), clauze de securitate și revizuiri periodice.

8. Instruirea angajaților și a managementului

Conștientizarea de securitate cibernetică nu înseamnă doar bifarea anuală a unui curs.

Compania trebuie să poată demonstra că oamenii relevanți cunosc responsabilitățile și riscurile care îi privesc.

Dovezi posibile: participări la training, materiale utilizate, rezultate ale testelor, simulări, instruiri specifice rolurilor și instruirea managementului.

Mai important decât numărul de cursuri este să existe o relație între riscurile companiei, comportamentele oamenilor și activitățile de instruire.

9. Vulnerabilități, monitorizare și eficacitatea controalelor

Identificare și remediere

Afirmații precum „sistemele sunt actualizate” sau „monitorizăm infrastructura” trebuie să poată fi verificate.

Organizația trebuie să aibă un mod prin care:

• • identifică vulnerabilitățile;
  • stabilește importanța lor;
  • prioritizează remedierea;
  • aplică actualizări;
  • tratează excepțiile;
  • monitorizează evenimentele relevante;
  • investighează alertele importante;

Scopul nu este obținerea unui raport fără vulnerabilități.

Scopul este existența unui proces repetabil prin care problemele relevante sunt identificate, prioritizate și tratate în funcție de risc.

Verificarea eficacității

Implementarea unui control nu demonstrează automat că acel control este eficient.

De aceea, organizația trebuie să poată verifica periodic, de exemplu:

• • backup-ul poate fi restaurat?
  • MFA este activ acolo unde trebuie?
  • conturile foștilor angajați sunt dezactivate?
  • vulnerabilitățile critice sunt tratate la timp?
  • planul de răspuns la incidente funcționează?
  • permisiunile privilegiate sunt revizuite?
  • acțiunile corective au fost finalizate?

Dovezi posibile: rapoarte de vulnerabilități, evidențe ale gestionării actualizărilor, jurnale de sistem, alerte EDR sau firewall, tichete de intervenție, audituri, indicatori de performanță și de risc (KPI, KRI), teste și planuri de remediere.

Nu toate companiile au nevoie de un SOC complex sau de aceeași tehnologie.

Măsurile trebuie să fie adecvate și proporționale cu riscul organizației.

„Dosarul NIS2” nu trebuie să fie un dosar

Una dintre cele mai frecvente greșeli este construirea conformității în jurul unui volum mare de documente.

Mai util este un registru al dovezilor, care creează legătura dintre risc, control și ceea ce poate fi demonstrat.

Structura poate fi foarte simplă:

Cerință → Risc → Control → Responsabil → Dovadă → Ultima verificare → Status

De exemplu:

Backup → Pierderea datelor → Backup zilnic + copie izolată → IT Manager → Raport backup + test restaurare → 15.07.2026 → OK

Pentru o companie de dimensiune medie, nu este obligatoriu să pornești de la o platformă complexă de guvernanță, risc și conformitate.

Important este ca dovada să existe, să poată fi găsită și să fie legată de un risc și de un responsabil.

Scopul registrului nu este să producă mai multă documentație, ci să permită companiei să găsească rapid dovada relevantă atunci când apare un audit, un incident, o solicitare din partea unui client sau o decizie de management.

Ce ar trebui să vadă managementul?

CEO-ul sau CFO-ul nu au nevoie să studieze sute de jurnale de sistem sau rapoarte tehnice.

Au nevoie de informații care permit luarea deciziilor.

De exemplu:

• • principalele riscuri deschise;
  • măsurile critice neimplementate;
  • responsabilii;
  • termenele;
  • controalele verificate;
  • incidentele relevante;
  • excepțiile;
  • riscul rezidual;
  • deciziile care necesită buget sau aprobare;

Managementul riscului devine util atunci când informația tehnică este transformată în informație pentru business și decizie.

În plus, după un incident important, întrebarea nu va fi doar:

„Ce tehnologie avea compania?”

Pot deveni la fel de importante întrebări precum:

Ce riscuri erau cunoscute?

Managementul fusese informat?

Ce măsuri au fost aprobate?

Ce risc fusese acceptat?

Ce dovezi există că măsurile stabilite au fost aplicate?

De aceea, demonstrarea conformității este și o problemă de responsabilitate managerială demonstrabilă — adică dovada unei supravegheri reale, nu doar de documentație IT.

Testul celor patru întrebări

Pentru fiecare măsură importantă de securitate, încearcă să răspunzi la patru întrebări:

1. Ce risc reduce?

2. Cine răspunde de ea?

3. Cum știm că funcționează?

4. Unde este dovada?

Dacă răspunsurile sunt clare și pot fi demonstrate, organizația începe să construiască nu doar securitate, ci și conformitate demonstrabilă.

Dacă răspunsurile există doar în mintea IT Managerului, în conversații sau în presupuneri, există încă o problemă de guvernanță.

Concluzie

NIS2 nu ar trebui redusă la producerea unui set mare de politici.

O organizație matură trebuie să poată demonstra că:

riscul a fost identificat,

managementul îl cunoaște,

există un responsabil,

controlul a fost implementat,

iar eficacitatea lui poate fi demonstrată.

Problema reală nu este doar să nu poți arăta un document, ci să nu poți demonstra că riscul a fost cunoscut, că managementul a luat o decizie și că măsura stabilită a fost verificată.

Un prim pas practic este construirea unei hărți simple:

Cerință → Risc → Control → Dovadă

Aceasta este diferența dintre:

„Credem că suntem în regulă.”

și

„Putem demonstra cum gestionăm riscul cibernetic.”

---

Dacă nu ești sigur unde s-ar situa compania ta pe această hartă, primul pas nu este să scrii politici, ci să afli exact unde sunt găurile din sistemul actual.

Un audit poate descoperi neconformități invizibile înainte să devină incidente — exact așa cum arată acest caz real de audit, unde lipsa incidentelor nu însemna că infrastructura era sigură.

Programează o evaluare gratuită și află, în urma unui audit inițial, care sunt riscurile pe care le poți demonstra deja și care rămân doar afirmații.