Conform articolului 20 din Directiva NIS2, organismele de conducere ale entităților esențiale și importante vizate trebuie să aprobe măsurile de management al riscului de securitate cibernetică prevăzute la articolul 21, să supravegheze implementarea acestora și să urmeze formare. Directiva prevede și posibilitatea angajării răspunderii pentru încălcări, în condițiile legislației aplicabile.
Obligațiile boardului prevăzute de Directiva NIS2 nu se reduc la aprobarea unei politici de securitate sau la primirea unui raport anual de la IT.
Pentru organizațiile vizate, conducerea trebuie să poată demonstra că a înțeles riscul cibernetic material, a aprobat măsuri proporționale și a supravegheat aplicarea lor.
Când apare un incident, întrebarea nu va fi doar dacă exista o tehnologie implementată.
Contează cine avea responsabilitatea controlului, ce măsură a funcționat, ce excepție a fost acceptată și ce dovezi existau înainte de incident.
NIS2 mută cybersecurity din zona exclusiv tehnică în zona de guvernanță.
Este o schimbare relevantă pentru directorii generali, membrii consiliilor de administrație și administratorii care decid asupra bugetelor, apetitului la risc, furnizorilor critici și continuității afacerii.
01. De ce NIS2 schimbă agenda boardului
Articolul 20 din Directiva (UE) 2022/2555 introduce cerințe explicite privind rolul organismelor de conducere în managementul riscului de securitate cibernetică.
În practică, boardul trebuie să trateze riscul cibernetic ca risc operațional, financiar și de continuitate, nu ca subiect tehnic raportat izolat.
O indisponibilitate a sistemelor de producție, compromiterea unui cont privilegiat Microsoft 365 sau un atac asupra unui furnizor poate opri facturarea, livrarea, accesul la date sau prestarea serviciilor către clienți.
Impactul nu este definit exclusiv de severitatea tehnică a unei alerte, ci de efectul asupra serviciului critic, obligațiilor contractuale, fluxului de numerar și reputației.
Boardul nu trebuie să administreze tehnologia
Membrii conducerii nu trebuie să decidă configurația unui firewall sau regula de retenție dintr-un SIEM.
Trebuie însă să se asigure că măsurile relevante există acolo unde riscul le justifică, au responsabili desemnați, sunt verificate și produc dovezi.
Tehnologia instalată nu înseamnă automat control eficient.
02. Obligațiile boardului conform Directivei NIS2
Aprobarea măsurilor de management al riscului
Articolul 20 cere organismelor de conducere să aprobe măsurile de management al riscului de securitate cibernetică adoptate pentru conformarea cu articolul 21.
Pentru ca această aprobare să fie utilă, organizația are nevoie de un cadru clar de identificare, evaluare, tratare și acceptare a riscurilor.
Definirea apetitului la risc și a limitelor de toleranță reprezintă o practică de guvernanță care susține aceste decizii.
O aprobare reală nu este o formulare generică de tipul „securitatea este o prioritate”.
Ea trebuie să se traducă în decizii verificabile:
- Care sunt serviciile și procesele critice?
- Ce RTO și RPO sunt acceptate de business?
- Ce identități și sisteme necesită MFA?
- Unde este justificat accesul privilegiat temporar prin PIM sau JIT ?
- Ce riscuri necesită aprobare executivă înainte de acceptare?
- Ce investiții sunt necesare pentru reducerea riscurilor materiale?
Proporționalitatea măsurilor
Articolul 21 urmărește măsuri tehnice, operaționale și organizatorice adecvate și proporționale cu riscurile.
Nu toate entitățile au nevoie de aceeași arhitectură de securitate.
Măsurile trebuie evaluate în raport cu expunerea, dimensiunea organizației, probabilitatea și severitatea incidentelor, precum și impactul potențial.
Boardul trebuie să prevină două erori: subinvestiția bazată pe presupunerea că organizația este prea mică pentru a fi țintă și investiția fără prioritizare în instrumente care nu reduc riscul material.
Supravegherea implementării și eficacității
După aprobare, obligația de supraveghere continuă.
Conducerea are nevoie de vizibilitate asupra stării controalelor, excepțiilor, incidentelor și planurilor de remediere.
Un dashboard cu procente verzi nu este suficient dacă nu arată ce active sau procese rămân expuse.
Raportarea trebuie să distingă între activitate și eficacitate.
„Am implementat MFA” descrie o activitate.
„Conturile privilegiate și accesurile externe relevante sunt protejate prin MFA, iar excepțiile au aprobare și termen de remediere” reprezintă o afirmație de control care poate fi verificată.
Formarea membrilor organismului de conducere
Articolul 20 prevede formarea membrilor organismelor de conducere pentru a dobândi cunoștințe și competențe suficiente identificării riscurilor și evaluării practicilor de management al riscului de securitate cibernetică.
Această formare nu trebuie redusă la o sesiune formală de awareness.
Membrii boardului trebuie să poată interpreta consecințele unei excepții și să pună întrebările potrivite în timpul unui incident.
Nu trebuie să devină specialiști SOC. Trebuie însă să înțeleagă diferența dintre:
- un backup existent și o restaurare testată;
- logging disponibil și investigație posibilă;
- un contract de furnizare și controlul riscului furnizorului;
- o politică aprobată și o măsură aplicată efectiv.
Ca bună practică, organizația ar trebui să păstreze evidențele formării: materiale, participanți, tematică, dată și rezultate relevante.
03. Ce trebuie să ceară boardul managementului
Un model eficient de raportare pornește de la servicii critice și scenarii de întrerupere, nu de la lista produselor de securitate.
Managementul ar trebui să prezinte periodic registrul de risc, modificările de expunere, stadiul măsurilor, excepțiile și dovezile de testare.
Identitate și acces privilegiat
Pentru identitate, raportarea ar trebui să includă acoperirea MFA, conturile administrative cu privilegii permanente, accesurile externe, conturile inactive și rezultatele recertificărilor.
Acolo unde sunt utilizate PIM și JIT, boardul poate solicita indicatori privind reducerea privilegiilor permanente, excepțiile și activările cu risc.
Continuitate și recuperare
Pentru continuitate, managementul trebuie să poată explica ce aplicații au RTO/RPO aprobate, când s-a testat ultima restaurare și ce dependențe pot bloca recuperarea.
Un test reușit pentru un fișier nu demonstrează automat capacitatea de recuperare a unui serviciu critic.
Detecție și răspuns
Indicatorii relevanți pot include acoperirea logging-ului pentru activele critice, retenția adecvată, funcționarea alertelor, timpul de escaladare și rezultatele exercițiilor de răspuns.
Important nu este doar câte alerte au fost generate, ci dacă incidentele semnificative pot fi identificate, investigate și escaladate la timp.
Riscul furnizorilor critici
Dacă un operator cloud, un integrator sau un furnizor SaaS gestionează date ori procese critice, contractul nu înlocuiește evaluarea.
Boardul ar trebui să ceară vizibilitate asupra dependențelor, obligațiilor de notificare, drepturilor de audit, planurilor de continuitate și concentrării riscului într-un singur furnizor.
Patru întrebări pentru fiecare risc material
- Care este impactul asupra serviciului?
- Cine este responsabil pentru control și pentru remediere?
- Care este termenul asumat?
- Ce dovadă demonstrează că măsura funcționează?
Dacă răspunsul rămâne la nivel de intenție, eficacitatea controlului nu este demonstrată.
04. Incidentul: momentul în care guvernanța este testată
Articolul 23 din Directiva NIS2 stabilește un regim de raportare pentru incidentele semnificative.
Ca repere generale, directiva prevede:
- 24 de ore: avertizare timpurie, fără întârzieri nejustificate, de la luarea la cunoștință a incidentului semnificativ.
- 72 de ore: notificarea incidentului, fără întârzieri nejustificate, cu particularități pentru anumite categorii de furnizori.
- O lună: raport final, în condițiile și de la momentul prevăzute de articolul 23.
Aplicarea concretă trebuie verificată în legislația națională, în reglementările sectoriale relevante și în raport cu autoritatea competentă.
Nu orice eveniment de securitate declanșează automat aceste termene. Contează clasificarea incidentului și criteriile de semnificație aplicabile.
Ce trebuie stabilit înainte de incident
Boardul nu trebuie să gestioneze operațional incidentul.
Trebuie însă să se asigure că organizația dispune de criterii de clasificare, responsabilități, trasee de escaladare, canale de comunicare și acces la consiliere juridică.
De asemenea, trebuie să existe un plan de răspuns la incidente care să poată fi executat în condiții reale.
Ce informații sunt necesare în timpul incidentului
- serviciul și procesele afectate;
- impactul confirmat și incertitudinile;
- măsurile de limitare aplicate;
- obligațiile de notificare identificate;
- deciziile care necesită aprobare;
- riscul rezidual și scenariile de recuperare.
De ce contează exercițiile tabletop
Un plan de răspuns netestat cu managementul rămâne o capacitate nedemonstrată.
Exercițiile tabletop pot expune ambiguități privind oprirea unui serviciu, aprobarea comunicării externe, contactarea furnizorilor și păstrarea cronologiei deciziilor.
05. De la politică la dovadă verificabilă
Multe deficiențe de securitate apar nu pentru că organizația nu are politici, ci pentru că acestea nu se reflectă în configurații, responsabilități și verificări operaționale.
O regulă privind accesul privilegiat, fără inventar de conturi administrative, revizuire periodică și loguri de utilizare, nu demonstrează controlul efectiv al riscului.
Un proces de backup fără teste documentate de restaurare nu demonstrează recuperabilitatea.
Assess — evaluarea expunerii
Sunt analizate serviciile critice, activele, dependențele, riscurile și controalele existente.
Evaluarea trebuie să stabilească unde există diferențe între măsurile declarate și cele aplicate.
Prioritize — riscurile care contează
Constatările sunt prioritizate în funcție de impact, expunere, obligații și capacitatea de recuperare.
Nu toate deficiențele justifică aceeași urgență sau investiție.
Implement — măsuri cu responsabilitate
Pentru fiecare risc material, se stabilesc măsuri proporționale, responsabil, termen, resurse și dependențe.
Excepțiile și acceptările de risc trebuie documentate și aprobate la nivelul corespunzător.
Evidence — demonstrarea eficacității
Dovezile pot include configurații, aprobări, rapoarte de test, jurnale, rezultate de recertificare, verificări independente și înregistrări ale excepțiilor.
Pentru management, aceste dovezi trebuie să permită verificarea progresului și a eficacității măsurilor aprobate.
Metodologia Assess → Prioritize → Implement → Evidence reprezintă un cadru practic de execuție, nu o succesiune impusă textual de Directiva NIS2.
06. Cum ar trebui să arate următoarea ședință de board
O ședință dedicată riscului cibernetic nu trebuie să devină o prezentare tehnică despre instrumente și licențe.
O agendă practică poate urmări cinci subiecte:
- Riscuri materiale: principalele scenarii care pot afecta serviciile și operațiunile.
- Starea controalelor: ce funcționează, ce nu a fost verificat și unde există excepții.
- Remedieri: responsabili, termene, blocaje și resurse necesare.
- Reziliență: rezultate ale testelor de restaurare, continuitate și răspuns la incidente.
- Decizii: riscuri acceptate, investiții aprobate și măsuri care necesită escaladare.
Frecvența raportării trebuie adaptată profilului de risc, schimbărilor relevante și nevoilor de supraveghere.
Pentru riscurile materiale, conducerea trebuie să poată urmări evoluția de la o ședință la alta.
Concluzie: NIS2 cere guvernanță demonstrabilă
Rizea Networks abordează NIS2, securitatea Microsoft 365, continuitatea și guvernanța furnizorilor ca părți ale unui sistem coerent de management al riscului.
Pentru board, valoarea nu este un dosar mai gros de politici.
Este capacitatea de a vedea expunerea, de a decide informat și de a demonstra că măsurile aprobate sunt aplicate și verificate.
Următoarea ședință de board este un test simplu.
Dacă managementul nu poate prezenta cele mai mari riscuri cibernetice, responsabilii lor, termenele de remediere și dovezile de eficacitate, prioritatea nu este încă o politică.
Este construirea unui sistem de control care poate fi susținut prin fapte în fața unei întreruperi, a unui auditor sau a autorității competente.