ISO 27001 și NIS2 nu trebuie tratate ca două programe independente. ISO 27001 poate oferi structura de management pentru riscuri, controale, audit și îmbunătățire, iar cerințele NIS2 pot fi mapate peste același sistem. Diferențele de scope, management accountability, incident reporting și cerințele legale trebuie însă identificate și tratate explicit.
Pentru un board, discuția despre ISO 27001 versus NIS2 nu este una semantică.
Întrebarea relevantă este dacă organizația poate identifica un incident, limita propagarea, continua serviciile critice și demonstra autorităților, clienților sau auditorilor că măsurile aplicate funcționează.
O politică aprobată, o licență de securitate sau o certificare obținută într-un perimetru limitat nu reprezintă, singure, această demonstrație.
ISO/IEC 27001 și NIS2 se întâlnesc în multe zone operaționale, dar au natură, obiective și consecințe diferite.
Tratarea lor ca proiecte complet separate duce la dublarea documentației, a registrelor și a proceselor.
Tratarea NIS2 drept o simplă extensie a ISO 27001 poate produce problema opusă: obligații juridice și expuneri operaționale rămân fără owner sau fără evidence suficient.
01. ISO 27001 versus NIS2: diferența de fond
ISO/IEC 27001 este un standard internațional pentru stabilirea, implementarea, menținerea și îmbunătățirea continuă a unui sistem de management al securității informației — ISMS.
Organizația își definește domeniul de aplicare, analizează riscurile, stabilește modul de tratare, implementează controale, măsoară rezultatele și gestionează îmbunătățirea continuă.
Certificarea este, în mod obișnuit, voluntară, deși poate deveni o condiție comercială, contractuală sau impusă la nivel de grup.
NIS2 este, în schimb, un cadru legislativ european transpus în legislația statelor membre pentru entitățile care intră în domeniul său de aplicare.
Scopul său este creșterea nivelului comun de cybersecurity și resilience în Uniunea Europeană, inclusiv prin cybersecurity risk-management measures, management accountability și incident reporting.
Aplicabilitatea trebuie stabilită în funcție de sector, dimensiune, serviciile furnizate și situațiile prevăzute de cadrul relevant.
Vezi: cum verifici încadrarea organizației în NIS2 .
Două întrebări diferite
ISO 27001 întreabă, în esență:
Avem un sistem disciplinat de management al securității informației pentru scope-ul definit?
NIS2 adaugă o întrebare diferită:
Suntem în aria reglementată și putem demonstra că managementul, operațiunile și dependențele noastre reduc riscul cibernetic la nivelul cerut?
02. Ce se suprapune între ISO 27001 și NIS2
Ambele cadre folosesc o abordare bazată pe risc și se întâlnesc în numeroase zone operaționale.
Printre acestea se află:
- managementul activelor;
- controlul accesului;
- gestionarea vulnerabilităților;
- securitatea operațională;
- incident management;
- business continuity;
- supplier security;
- monitorizarea controalelor;
- audit și improvement.
O organizație care știe ce active susțin serviciile critice, cine deține privilegiile, ce loguri păstrează și cum validează recovery-ul pornește cu un avantaj semnificativ pentru ambele cadre.
Scope-ul rămâne însă critic
Suprapunerea nu înseamnă echivalență.
Scope-ul unui ISMS poate fi definit pentru anumite procese, locații, entități sau servicii.
Pentru readiness NIS2 trebuie verificat dacă acest scope acoperă efectiv serviciile, sistemele, entitățile juridice și furnizorii relevanți pentru obligațiile aplicabile.
Un serviciu critic operat în Microsoft 365, într-un cloud public sau printr-un furnizor extern nu devine irelevant doar pentru că infrastructura nu este găzduită intern.
Management accountability
NIS2 introduce explicit responsabilități pentru organele de conducere.
Managementul trebuie să aprobe măsurile de cybersecurity risk management și să supravegheze implementarea lor.
Delegarea execuției către IT sau către un furnizor extern nu elimină responsabilitatea de guvernanță.
Incident reporting
Pentru incidentele semnificative, NIS2 introduce un proces etapizat de raportare.
La nivelul directivei, acesta include:
- avertizare timpurie în termen de 24 de ore;
- notificarea incidentului în termen de 72 de ore;
- actualizări intermediare atunci când sunt necesare;
- raport final în termenul prevăzut de cadrul aplicabil.
Pentru a respecta aceste termene, organizația are nevoie de mai mult decât o procedură generică de incident management.
Sunt necesare criterii de clasificare, owneri de decizie, contacte validate, logging suficient și exerciții periodice.
03. De ce certificarea ISO nu înlocuiește pregătirea NIS2
Un ISMS bine operat poate reduce considerabil efortul de pregătire NIS2.
Poate furniza deja:
- registrul de risc;
- inventarul de active;
- politicile și responsabilitățile;
- procesul de internal audit;
- management review;
- procesul de corrective action;
- o parte din evidence-ul necesar.
Dar valoarea acestor elemente depinde de cât de bine funcționează în realitate.
Control declarat versus control verificabil
O politică poate cere MFA pentru accesul la distanță, dar configurația reală poate conține excluderi, conturi administrative insuficient protejate sau politici Conditional Access aplicate doar parțial.
Tehnologia instalată nu înseamnă automat control.
Același lucru este valabil pentru accesul privilegiat.
Analiza trebuie să verifice, după caz, dacă privilegiile permanente pot fi reduse prin PIM și acces Just-In-Time , dacă există conturi break-glass, cum sunt controlate excepțiile și dacă acțiunile administrative sunt înregistrate.
Backup versus recovery
Un RTO și un RPO documentate nu demonstrează capacitatea efectivă de recuperare.
Pentru serviciile critice, RTO și RPO trebuie validate prin exerciții și rezultate măsurabile.
Evidence-ul relevant poate include:
- scenariul testului;
- sistemele și datele acoperite;
- timpul efectiv de restaurare;
- abaterile față de obiective;
- erorile identificate;
- acțiunile corective;
- dovada retestării.
Pentru un serviciu critic trebuie evaluate și dependențele de identitate, DNS, conectivitate, SaaS și personal-cheie.
Supply-chain risk
Nici existența unor clauze standard de confidențialitate nu reprezintă singură un control suficient asupra furnizorilor.
Organizația trebuie să știe:
- ce furnizori susțin servicii critice;
- ce date și privilegii primesc;
- ce obligații de notificare au;
- cum se monitorizează accesul;
- care sunt dependențele concentrate;
- ce alternativă există dacă furnizorul devine indisponibil.
04. Cum construiești un singur program de control pentru ISO 27001 și NIS2
Punctul de plecare nu este alegerea dintre ISO 27001 și NIS2.
Este evaluarea expunerii reale și construirea unei surse comune de adevăr.
1. Stabilește perimetrul real
Verifică mai întâi dacă organizația intră în domeniul de aplicare NIS2 .
Apoi identifică:
- entitățile juridice relevante;
- serviciile critice;
- procesele;
- sistemele;
- datele;
- furnizorii și dependențele externe.
Compară acest perimetru cu scope-ul actual al ISMS.
Diferențele trebuie făcute vizibile, nu ascunse în formulări generale.
2. Evaluează controalele reale
Nu verifica doar documentația.
Pentru identity security, verifică:
- MFA;
- privileged roles;
- PIM/JIT;
- break-glass accounts;
- external access;
- joiner-mover-leaver;
- access reviews;
- admin logging.
Pentru Microsoft 365 și cloud, verificarea trebuie să acopere configurația efectivă, accesul la date, retenția, logging-ul, capacitatea de investigație și segregarea rolurilor.
3. Prioritizează după impact
Constatările trebuie prioritizate după:
- impactul asupra serviciilor;
- probabilitatea exploatării;
- expunerea;
- obligațiile aplicabile;
- controalele compensatorii;
- timpul realist de remediere.
Un backup netestat pentru un serviciu critic, un rol administrativ permanent sau lipsa logging-ului pentru sisteme relevante poate avea prioritate mai mare decât îmbunătățirea stilistică a unei politici.
4. Transformă finding-ul în acțiune
Fiecare măsură trebuie să aibă:
- owner;
- termen;
- resurse;
- dependențe;
- criteriu de acceptare;
- evidence necesar pentru închidere.
05. Dovezile care rezistă unei verificări
Într-un program matur, dovezile sunt produse în timpul operării normale.
Nu sunt fabricate cu câteva zile înainte de audit.
Pot include:
- rapoarte de access review;
- configurații exportate;
- rezultate de vulnerability management;
- teste de restaurare;
- minute de incident exercises;
- rapoarte de audit intern;
- supplier assessments;
- aprobări ale riscurilor reziduale;
- remediation tickets și closure evidence.
Vezi și: ce dovezi trebuie păstrate pentru audit și ISO 27001 .
Calitatea dovezii contează
Un screenshot fără dată, context, populație verificată sau legătură cu controlul are valoare limitată.
În schimb, un raport repetabil care arată acoperirea MFA, excepțiile aprobate, ownerul și acțiunile restante poate susține o concluzie de control.
Același principiu se aplică recovery-ului, privileged access, supplier risk sau monitoring-ului.
06. Ce trebuie să poată vedea managementul
Managementul nu are nevoie de două dashboard-uri: unul pentru ISO și unul pentru NIS2, dacă ambele descriu aceleași riscuri.
Are nevoie de o imagine comună asupra:
- serviciilor critice;
- riscurilor materiale;
- controalelor cheie;
- excepțiilor;
- riscurilor reziduale;
- finding-urilor deschise;
- ownerilor;
- termenelor;
- evidence-ului disponibil.
Această abordare permite organizației să distingă între un risc acceptat explicit, un risc tratat, unul transferat și unul rămas necontrolat.
Modelul poate fi păstrat simplu:
Assess → Prioritize → Implement → Evidence.
Assess stabilește perimetrul și expunerea.
Prioritize separă riscul material de zgomot.
Implement transformă recomandarea într-un control cu owner și termen.
Evidence demonstrează că măsura funcționează.
Nu ai nevoie de două programe de compliance. Ai nevoie de un sistem de control.
Pentru management, decizia utilă nu este dacă ISO 27001 este „mai bun” decât NIS2.
Întrebarea este dacă organizația poate explica, cu dovezi actuale:
- ce servicii protejează;
- ce riscuri materiale există;
- ce risc a fost acceptat;
- cine deține fiecare remediere;
- cum este investigat un incident;
- cât de repede poate fi recuperat un serviciu;
- ce evidence demonstrează eficacitatea controalelor.
Dacă răspunsul depinde de presupuneri, următorul pas nu este încă o politică.
Este o evaluare disciplinată a perimetrului, controalelor și dovezilor existente.
