Evaluare a riscurilor ISO 27001 pregătită pentru audit pentru NIS2 și DORA
Cafeaua de pe biroul Sarei se răcise.
În calitate de CISO al unei companii fintech aflate în expansiune rapidă, era obișnuită cu presiunea. Compania tocmai câștigase un partener bancar major, iar chestionarul de due diligence de pe ecranul ei ar fi trebuit să fie o formalitate. Primele întrebări erau familiare: furnizați Declarația de aplicabilitate ISO/IEC 27001:2022, transmiteți cel mai recent registru de riscuri, explicați metodologia de evaluare a riscurilor.
Apoi chestionarul și-a schimbat direcția.
Demonstrați modul în care programul dumneavoastră de management al riscurilor abordează DORA. Explicați nivelul de pregătire pentru Directiva NIS2, inclusiv responsabilitatea conducerii și măsurile privind riscul lanțului de aprovizionare. Furnizați dovezi că furnizorii critici de servicii TIC sunt evaluați, monitorizați și incluși în planurile de răspuns la incidente și de continuitate a activității.
Până luni dimineață, aceeași problemă ajunsese pe agenda comitetului de risc al consiliului de administrație. Audit de certificare ISO 27001 în opt săptămâni. Presiune DORA din partea clienților din sectorul financiar. Întrebări de clasificare NIS2 pentru o linie de servicii găzduită în cloud, aflată în extindere în UE. Achizițiile spuneau că revizuirile furnizorilor existau, dar dovezile erau dispersate între e-mailuri, dosare contractuale și un tabel cu furnizori. Juridicul spunea că maparea la cerințele de reglementare era încă în lucru. Ingineria spunea că registrul de riscuri era aproape finalizat.
Consiliul de administrație a pus singura întrebare care conta:
Putem demonstra că evaluarea riscurilor și planul de tratare a riscurilor sunt suficiente?
Aceasta este problema reală pentru companiile SaaS, fintech, de servicii administrate, cloud și platforme digitale. Nu dacă există un registru de riscuri. Nu dacă au fost copiate controalele din Anexa A într-un tabel. Problema este dacă organizația poate demonstra, sub presiunea auditului și a clienților, că procesul său de evaluare a riscurilor ISO 27001 este repetabil, bazat pe risc, aprobat de proprietarii riscurilor, legat de acțiuni de tratare, mapat la obligații legale și activ la nivel operațional.
Realizată corect, o singură evaluare a riscurilor ISO 27001 și un singur plan de tratare a riscurilor pot susține certificarea ISO/IEC 27001:2022, măsurile de management al riscurilor de securitate cibernetică prevăzute de NIS2 Article 21, cerințele DORA privind managementul riscurilor TIC, responsabilitatea GDPR, asigurarea privind furnizorii, pregătirea pentru incidente și raportarea către consiliul de administrație.
Realizată superficial, devine un tabel pe care auditorii îl vor demonta în treizeci de minute.
Acest ghid arată cum construiește Clarysec dovezi pregătite pentru audit privind evaluarea și tratarea riscurilor ISO 27001 folosind Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, politicile Clarysec și Zenith Controls: ghidul de conformitate transversală.
De ce evaluarea riscurilor ISO 27001 a devenit un nod central de conformitate
Peisajul de reglementare al UE converge către un principiu simplu: riscul de securitate cibernetică trebuie guvernat, documentat, testat și asumat.
ISO/IEC 27001:2022 funcționează deja în acest mod. Clauzele 4.1-4.4 impun organizației să înțeleagă contextul, părțile interesate, domeniul de aplicare al SMSI și interacțiunile dintre procese înainte de evaluarea riscurilor. Clauzele 6.1.2 și 6.1.3 impun un proces definit de evaluare și tratare a riscurilor de securitate a informației. Clauzele 8.2 și 8.3 impun organizației să efectueze evaluări ale riscurilor și să implementeze planul de tratare, păstrând informații documentate.
NIS2 și DORA fac aceeași logică bazată pe risc mai urgentă.
NIS2 Article 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire în domeniul securității cibernetice. Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale pentru gestionarea riscurilor la adresa rețelelor și sistemelor informatice. Aceste măsuri includ analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltarea securizată, managementul vulnerabilităților, evaluarea eficacității, igiena cibernetică, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor și autentificarea multifactor sau comunicațiile securizate, după caz.
DORA exercită o presiune similară asupra entităților financiare. Articles 5 și 6 impun organului de conducere să definească, să aprobe, să supravegheze și să rămână responsabil pentru mecanismele de management al riscurilor TIC. DORA cere un cadru documentat de management al riscurilor TIC, integrat în managementul general al riscurilor și susținut de politici, proceduri, protocoale, instrumente, Audit Intern, remediere, continuitate, testare, gestionarea incidentelor și guvernanța terților furnizori de servicii TIC.
Concluzia este practică și inevitabilă: registrul de riscuri nu mai este o fișă de lucru a echipei tehnice. Este dovadă de guvernanță.
Politica de management al riscurilor Enterprise a Clarysec formulează explicit această așteptare:
Trebuie menținut un proces formal de management al riscurilor, în conformitate cu ISO/IEC 27005 și ISO 31000, care să acopere identificarea, analiza, evaluarea, tratarea, monitorizarea și comunicarea riscurilor.
Din Politica Enterprise de management al riscurilor, secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.
Aceeași politică definește rezultatul pregătit pentru audit:
Menținerea unui registru de riscuri și a unui plan de tratare a riscurilor centralizate și supuse controlului versiunilor, care reflectă starea curentă a riscurilor, acoperirea controalelor și progresul măsurilor de atenuare.
Din Politica Enterprise de management al riscurilor, secțiunea „Obiective”, clauza de politică 3.3.
Această formulare, „starea curentă a riscurilor, acoperirea controalelor și progresul măsurilor de atenuare”, face diferența dintre un dosar static de conformitate și un program de risc defensabil.
Începeți cu domeniul de aplicare, obligațiile și criteriile de risc
Multe evaluări slabe ale riscurilor ISO 27001 încep cu o listă de verificare a controalelor. Ordinea este greșită.
ISO 27001 impune organizației să determine contextul, cerințele părților interesate, domeniul de aplicare al SMSI, responsabilitățile de leadership și planificarea riscurilor înainte de selectarea controalelor. ISO/IEC 27005:2022 consolidează acest lucru, recomandând organizațiilor să identifice cerințele de bază ale părților interesate înainte de evaluarea riscurilor. Aceste cerințe pot proveni din standarde ISO, reglementări sectoriale, legislație națională, contracte cu clienții, politici interne, activități anterioare de tratare și obligații ale furnizorilor.
Pentru o companie SaaS sau fintech orientată către UE, procesul de risc trebuie să înceapă cu un inventar al obligațiilor de conformitate.
| Sursa cerinței | De ce afectează evaluarea riscurilor ISO 27001 | Artefact de dovadă |
|---|---|---|
| ISO/IEC 27001:2022 Clauzele 4, 5, 6, 8, 9 și 10 | Definesc contextul, leadershipul, evaluarea riscurilor, tratarea riscurilor, controlul operațional, evaluarea performanței și îmbunătățirea | Domeniul de aplicare al SMSI, metodologia de risc, registrul de riscuri, planul de tratare, SoA, înregistrări ale revizuirilor de management |
| NIS2 Articles 20, 21 și 23 | Adaugă responsabilitatea conducerii, măsuri de securitate cibernetică pentru toate tipurile de pericole și așteptări privind raportarea incidentelor | Aprobarea consiliului de administrație, mapare Article 21, playbook de raportare a incidentelor, dovezi privind continuitatea |
| DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28 și 30 | Impun guvernanța riscurilor TIC, continuitate, backup și restaurare, ciclul de viață al incidentelor, testare și controale privind riscurile asociate terților furnizori de servicii TIC | Cadrul de risc TIC, teste BCP, registru al incidentelor, înregistrări ale testelor de reziliență, registrul furnizorilor TIC |
| GDPR Articles 3, 4, 5, 6, 9, 10, 25, 32, 33 și 34 | Impun responsabilitate, prelucrare legală a informațiilor, protecția datelor încă din faza de proiectare, securitate adecvată și evaluarea încălcărilor | Inventarul datelor, maparea temeiurilor juridice, înregistrări privind riscurile de confidențialitate, linkuri către DPIA, înregistrări ale evaluării încălcărilor |
| Contracte cu furnizorii și clienții | Transformă angajamentele comerciale în criterii de risc, controale, dovezi și termene-limită | Registrul contractelor, înregistrări de due diligence, drepturi de audit, SLA-uri, clauze de ieșire |
Pentru IMM-uri, Politica de conformitate juridică și de reglementare pentru IMM-uri a Clarysec stabilește punctul de plecare:
Directorul general trebuie să mențină un registru de conformitate simplu și structurat, care listează:
Din Politica de conformitate juridică și de reglementare pentru IMM-uri, secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.1.
Acest registru simplu este o punte între conformitate și managementul riscurilor. Dacă indică faptul că GDPR se aplică deoarece sunt prelucrate date cu caracter personal din UE, că NIS2 se poate aplica deoarece organizația furnizează servicii digitale sau administrate ori că DORA este relevant prin clienți din sectorul financiar, aceste obligații trebuie să influențeze criteriile de risc și prioritățile de tratare.
Zenith Blueprint este direct în această privință în faza de management al riscurilor, pasul 10, „Stabilirea criteriilor de risc și a matricei de impact”:
Luați în considerare și cerințele legale/de reglementare în criteriile de acceptare. Unele riscuri pot fi inacceptabile indiferent de probabilitate, din cauza legii.
Din Zenith Blueprint, faza de management al riscurilor, pasul 10.
Acesta oferă și o regulă practică pentru workshopuri:
„Orice risc care ar putea conduce la neconformitate cu legile aplicabile (GDPR etc.) nu este acceptabil și trebuie atenuat.”
Din Zenith Blueprint, faza de management al riscurilor, pasul 10.
Pentru fintech-ul Sarei, acest lucru schimbă modelul de scorare. O vulnerabilitate a API-ului unui furnizor poate avea probabilitate redusă, dar dacă exploatarea ar putea declanșa un incident major legat de TIC în sensul DORA, un incident semnificativ NIS2, o evaluare a încălcării conform GDPR, un eșec al SLA-ului clientului sau o escaladare la nivelul consiliului de administrație, impactul este ridicat sau critic. Expunerea de conformitate devine parte din logica riscului, nu un tabel separat.
Construiți un registru de riscuri pe care auditorii îl pot testa
Auditorii nu întreabă doar care sunt principalele riscuri. Ei testează dacă metoda este definită, repetabilă, trasabilă și aplicată.
Vor întreba:
- Cum ați identificat aceste riscuri?
- Ce active, servicii, furnizori, tipuri de date și procese au fost incluse în domeniul de aplicare?
- Ce criterii au fost folosite pentru probabilitate și impact?
- Cine deține fiecare risc?
- Ce controale existente reduc riscul?
- De ce a fost selectată decizia de tratare?
- Unde sunt dovezile că tratarea a fost realizată?
- Cine a aprobat riscul rezidual?
- Când va fi reevaluat riscul?
Politica de management al riscurilor pentru IMM-uri a Clarysec surprinde nivelul minim al unei înregistrări de risc pregătite pentru audit:
Fiecare înregistrare de risc trebuie să includă: descrierea, probabilitatea, impactul, scorul, proprietarul și planul de tratare.
Din Politica de management al riscurilor pentru IMM-uri, secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.2.
Pentru programele enterprise, faza de management al riscurilor din Zenith Blueprint, pasul 11, „Construirea și documentarea registrului de riscuri”, extinde structura. Recomandă coloane precum ID risc, activ, amenințare, vulnerabilitate, descrierea riscului, probabilitate, impact, nivel de risc, controale curente, proprietar de risc, decizie de tratare, plan de tratare sau controale și stare.
O înregistrare solidă de risc arată astfel:
| Câmp | Exemplu de înregistrare |
|---|---|
| ID risc | R-042 |
| Activ sau proces | Prelucrarea datelor clienților prin API-ul de plată al unui terț și baza de date de producție |
| Amenințare | Exploatarea unei vulnerabilități critice în API-ul furnizorului sau în serviciul cloud de bază de date suport |
| Vulnerabilitate | Vizibilitate limitată asupra managementului vulnerabilităților la furnizor, testare incompletă a restaurării și lipsa unui playbook testat pentru încălcări ale securității la furnizor |
| Descrierea riscului | Compromiterea unui furnizor sau a unui serviciu cloud ar putea expune date financiare, perturba serviciul, declanșa raportări către autorități și încălca contractele cu clienții |
| Controale curente | SSO, acces bazat pe roluri, contract cu furnizorul, jurnalizare în producție, backup-uri zilnice, revizuirea trimestrială a accesului |
| Probabilitate | Medie |
| Impact | Critic |
| Nivel de risc | Critic |
| Proprietar de risc | CTO și Head of Platform Engineering |
| Decizie de tratare | Atenuare |
| Mapare la cerințe de reglementare | Controale ISO 27001 Anexa A privind furnizorii, cloud, incidentele, jurnalizarea, accesul, continuitatea, backup-ul și conformitatea juridică; NIS2 Articles 20, 21 și 23; DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28 și 30; GDPR Articles 32, 33 și 34 |
| Dovezi | Due diligence privind furnizorul, solicitare privind drepturi de audit, raport de testare a restaurării, regulă de monitorizare SIEM, exercițiu tabletop pentru incidente, SoA actualizată, procese-verbale ale revizuirilor de management |
Aceasta este fundamental diferită de „risc asociat terților, ridicat, atenuare”. Versiunea pregătită pentru audit leagă activul, amenințarea, vulnerabilitatea, consecința, controalele curente, proprietarul, cerințele de reglementare, dovezile și guvernanța.
Transformați tratarea riscurilor într-un plan de dovezi
Un plan de tratare a riscurilor trebuie să răspundă la patru întrebări operaționale:
- Ce vom face?
- Cine deține acțiunea?
- Când va fi finalizată?
- Cum vom demonstra că a redus riscul?
ISO/IEC 27001:2022 Clauza 6.1.3 impune organizației să selecteze opțiunile de tratare, să determine controalele necesare, să le compare cu Anexa A pentru a evita omisiunile, să producă o Declarație de aplicabilitate, să formuleze un plan de tratare și să obțină aprobarea proprietarilor de risc pentru plan și riscurile reziduale. Clauza 8.3 impune apoi implementarea planului de tratare și păstrarea informațiilor documentate privind rezultatele.
Politica Enterprise de management al riscurilor face acest lucru practic:
Ofițerul de risc trebuie să se asigure că tratamentele sunt realiste, încadrate în timp și mapate la controalele ISO/IEC 27001 Anexa A.
Din Politica Enterprise de management al riscurilor, secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.2.
Politica pentru IMM-uri clarifică, de asemenea, că acceptarea nu este o scurtătură:
Acceptare: justificați de ce nu este necesară nicio acțiune suplimentară și înregistrați riscul rezidual.
Din Politica de management al riscurilor pentru IMM-uri, secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.
Acceptarea trebuie justificată față de criterii, aprobată de proprietarul corespunzător și monitorizată. În contextul NIS2 și DORA, riscul rezidual neaprobat poate deveni un eșec de guvernanță.
Un plan de tratare complet trebuie să conțină aceste câmpuri:
| Câmp de tratare | Scop în audit |
|---|---|
| ID risc | Leagă tratarea de riscul evaluat |
| Opțiune de tratare | Arată raționamentul: atenuare, evitare, transfer sau acceptare |
| Controale selectate | Conectează riscul la Anexa A, politici și măsuri tehnice de protecție |
| Factor de reglementare | Arată relevanța NIS2, DORA, GDPR, contractuală sau pentru client |
| Proprietar al acțiunii | Demonstrează responsabilitatea |
| Termen-limită | Face tratarea încadrată în timp |
| Dovezi de implementare | Arată că acțiunea a fost finalizată |
| Măsură de eficacitate | Arată dacă probabilitatea sau impactul a fost redus |
| Risc rezidual | Arată expunerea rămasă |
| Aprobare de către proprietarul riscului | Demonstrează acceptarea și guvernanța |
Pentru R-042 al Sarei, planul de tratare devine o listă de acțiuni de conformitate transversală.
| ID risc | Acțiune de tratare | Referință ISO/IEC 27001:2022 Anexa A | Relevanță NIS2 | Relevanță DORA | Proprietar | Dovezi |
|---|---|---|---|---|---|---|
| R-042 | Exercitarea drepturilor de audit asupra furnizorului și solicitarea dovezilor privind managementul vulnerabilităților | 5.19, 5.20, 5.21, 5.22, 5.31 | Article 21(2)(d) securitatea lanțului de aprovizionare | Articles 28 și 30 riscuri asociate terților furnizori de servicii TIC și contracte | CTO și responsabilul de achiziții | Solicitare de audit, răspunsul furnizorului, revizuirea contractului |
| R-042 | Implementarea monitorizării îmbunătățite pentru activități API anormale și activități privilegiate | 8.15, 8.16, 5.16, 5.17, 5.18 | Article 21(2)(i) controlul accesului și managementul activelor | Articles 6 și 17 risc TIC și gestionarea incidentelor | Manager SOC | Regulă SIEM, test de alertă, revizuirea accesului |
| R-042 | Testarea restaurării backup-urilor și definirea RTO și RPO la nivel de serviciu | 5.30, 8.13, 8.14 | Article 21(2)(c) continuitatea activității și backup | Articles 11 și 12 răspuns, recuperare, backup și restaurare | Head of Platform Engineering | Raport de restaurare, aprobare RTO și RPO |
| R-042 | Derularea unui exercițiu tabletop pentru încălcarea securității la furnizor | 5.24, 5.26, 5.27, 5.29 | Articles 21(2)(b) și 23 gestionarea și raportarea incidentelor | Articles 17, 18, 19 și 24 gestionarea, clasificarea, raportarea și testarea incidentelor | CISO | Înregistrare tabletop, lecții învățate, tracker de remediere |
| R-042 | Actualizarea SoA și aprobarea riscului rezidual | 5.4, 5.31, 5.35 | Article 20 responsabilitatea conducerii | Articles 5 și 6 guvernanță și cadru de risc TIC | CISO și proprietarul riscului | SoA actualizată, înregistrare de aprobare, procese-verbale ale revizuirilor de management |
Acest plan este puternic deoarece creează o linie directă de la un scenariu de risc la controalele ISO 27001, obligațiile NIS2, articolele DORA, proprietari și dovezi.
Folosiți mai eficient Declarația de aplicabilitate
Declarația de aplicabilitate este adesea tratată ca un artefact de certificare. Ar trebui să fie mai mult decât atât.
ISO/IEC 27001:2022 Clauza 6.1.3 impune ca SoA să includă controalele necesare, justificarea includerii, starea implementării și justificarea excluderilor. Îndrumările ISO/IEC 27005:2022 consolidează necesitatea de a compara controalele selectate cu ISO/IEC 27001 Anexa A pentru a evita omisiunile.
Într-un program pregătit pentru audit, SoA devine puntea dintre tratarea riscurilor și dovezile de conformitate transversală. Dacă un plan de tratare necesită MFA, jurnalizare, monitorizarea furnizorilor, restaurarea backup-urilor, dezvoltare securizată, escaladarea incidentelor sau planificarea ieșirii din cloud, SoA trebuie să arate că respectivele controale din Anexa A sunt incluse, justificate, implementate sau planificate și susținute prin dovezi.
Acest lucru ajută și la evitarea unui eșec frecvent în audit: registrul de riscuri spune un lucru, planul de tratare spune altul, iar SoA nu menționează nimic. Când aceste artefacte nu sunt aliniate, auditorii își pierd rapid încrederea.
Maparea tratării riscurilor ISO 27001 la NIS2, DORA și GDPR
ISO 27001 nu înlocuiește NIS2, DORA sau GDPR. Oferă un mecanism structurat pentru producerea dovezilor necesare acestora.
Cheia este integrarea mapării în procesul de risc, nu adăugarea ei ulterior.
| Dovezi privind tratarea riscurilor ISO 27001 | Relevanță NIS2 | Relevanță DORA | Relevanță GDPR |
|---|---|---|---|
| Criterii de risc cu scorare a impactului de reglementare | Susține măsurile proporționale de management al riscurilor de securitate cibernetică prevăzute de Article 21 | Susține Articles 4, 5 și 6 privind proporționalitatea, guvernanța și cadrul de risc TIC | Susține responsabilitatea și securitatea adecvată |
| Registru de riscuri cu proprietari și impact CIA | Susține supravegherea conducerii prevăzută de Article 20 și analiza riscurilor prevăzută de Article 21 | Susține managementul documentat al riscurilor TIC și asumarea responsabilității | Susține demonstrarea conștientizării riscurilor pentru datele cu caracter personal |
| Plan de tratare mapat la Anexa A | Susține măsurile Article 21 în zonele de incidente, continuitate, furnizori, acces, vulnerabilități și dezvoltare securizată | Susține controalele TIC, gestionarea incidentelor, continuitatea, testarea și reziliența față de terți | Susține măsurile tehnice și organizatorice prevăzute de Article 32 |
| Înregistrări privind riscul furnizorilor și controale contractuale | Susține Article 21(2)(d) securitatea lanțului de aprovizionare | Susține Articles 28 și 30 privind riscurile asociate terților furnizori de servicii TIC și cerințele contractuale | Susține măsurile de protecție pentru persoanele împuternicite și transferuri, acolo unde sunt aplicabile |
| Scenarii de incidente și playbook-uri de raportare | Susține fluxul de raportare a incidentelor semnificative prevăzut de Article 23 | Susține Articles 17, 18 și 19 privind gestionarea, clasificarea și raportarea incidentelor | Susține evaluarea notificării încălcărilor prevăzută de Articles 33 și 34 |
| Tratamente privind BCP, backup și recuperare | Susține Article 21(2)(c) privind continuitatea, backup-ul, recuperarea în caz de dezastru și managementul crizelor | Susține Articles 11 și 12 privind răspunsul, recuperarea, backup-ul și restaurarea | Susține disponibilitatea și reziliența atunci când sunt implicate date cu caracter personal |
| Revizuiri ale eficacității controalelor | Susține Article 21(2)(f) evaluarea eficacității | Susține Article 24 privind așteptările de testare și remediere | Susține responsabilitatea continuă |
Această mapare este deosebit de importantă acolo unde reglementările se suprapun. DORA este regimul sectorial specific de reziliență TIC pentru multe entități financiare, în timp ce NIS2 poate rămâne direct relevant pentru anumiți furnizori, pentru coordonare sau pentru entități din afara domeniului DORA. Un fintech poate avea nevoie de DORA drept cadru principal de reziliență TIC, în timp ce un furnizor de servicii administrate care susține acel fintech poate avea obligații directe NIS2.
Registrul de riscuri trebuie să poată arăta ambele părți ale acestei dependențe.
Folosiți Zenith Controls ca reper pentru conformitatea transversală
Clarysec folosește Zenith Controls ca ghid de conformitate transversală pentru a preveni eșecul frecvent în care controalele ISO, articolele de reglementare și întrebările de audit trăiesc în universuri separate. Nu creează un cadru de control separat. Mapează zonele de control ISO/IEC 27001:2022 și ISO/IEC 27002:2022 la alte standarde, așteptări de audit și perspective de conformitate.
Pentru evaluarea și tratarea riscurilor ISO 27001, aceste referințe sunt deosebit de importante:
| Referință ISO/IEC 27001:2022 Anexa A utilizată în Zenith Controls | De ce contează pentru evaluarea și tratarea riscurilor | Atribute capturate în Zenith Controls |
|---|---|---|
| 5.4 Responsabilități de management | Leagă proprietatea tratării riscurilor de guvernanță, claritatea rolurilor și responsabilitate | Control preventiv, susține confidențialitatea, integritatea și disponibilitatea, mapat la Identificare, guvernanță, guvernanță și ecosistem |
| 5.31 Cerințe legale, statutare, de reglementare și contractuale | Leagă registrul de conformitate de criteriile de risc, deciziile de tratare și includerea în SoA | Control preventiv, susține confidențialitatea, integritatea și disponibilitatea, mapat la Identificare, juridic și conformitate, guvernanță, ecosistem și protecție |
| 5.35 Revizuirea independentă a securității informației | Leagă Auditul Intern, auditul extern și asigurarea managementului de eficacitatea tratării | Control preventiv și corectiv, susține confidențialitatea, integritatea și disponibilitatea, mapat la Identificare și Protejare, asigurarea securității informației, guvernanță și ecosistem |
Lecția de conformitate transversală este simplă. Dacă obligațiile legale nu sunt în metoda de evaluare a riscurilor, scorarea este incompletă. Dacă scorarea este incompletă, prioritățile de tratare pot fi greșite. Dacă prioritățile sunt greșite, SoA și raportarea către consiliul de administrație devin nesigure.
Zenith Blueprint formulează aceeași idee în faza de management al riscurilor, pasul 14, „Politici de tratare a riscurilor și referințe reglementare încrucișate”. Recomandă organizațiilor să creeze un tabel de mapare care listează cerințele-cheie de securitate impuse de reglementări și controalele sau politicile corespunzătoare din SMSI. Acest lucru nu este obligatoriu pentru certificarea ISO 27001, dar este foarte util pentru a demonstra că securitatea este gestionată în context legal și contractual.
Ce vor întreba diferite categorii de auditori
Un auditor de certificare, un revizor orientat spre NIS2, un client orientat spre DORA, un revizor GDPR, un evaluator NIST sau un practician COBIT pot examina aceleași dovezi, dar vor pune întrebări diferite.
| Perspectiva auditorului | Întrebare tipică de audit | Dovezi așteptate |
|---|---|---|
| Auditor ISO 27001 | Este metoda de evaluare a riscurilor definită, repetabilă, aplicată și legată de tratare și SoA? | Metodologia de risc, criterii, registru, SoA, plan de tratare, aprobări ale riscurilor reziduale |
| Revizor orientat spre NIS2 | Măsurile de securitate cibernetică acoperă domeniile Article 21 și responsabilitatea conducerii? | Aprobări ale consiliului de administrație, mapare Article 21, playbook de incidente, dovezi privind continuitatea, dovezi privind riscul furnizorilor |
| Revizor orientat spre DORA | Este managementul riscurilor TIC documentat, guvernat, testat și extins la terții furnizori de servicii TIC? | Cadrul de risc TIC, procesul de clasificare a incidentelor, teste BCP, testarea rezilienței, registrul furnizorilor TIC |
| Revizor GDPR | Poate organizația demonstra securitatea adecvată și responsabilitatea pentru riscurile asupra datelor cu caracter personal? | Inventarul datelor, maparea temeiurilor juridice, procedura de evaluare a încălcărilor, dovezi privind tratarea riscurilor de confidențialitate |
| Evaluator orientat spre NIST | Sunt riscurile identificate, protejate, detectate, tratate prin răspuns și recuperate prin controale măsurabile? | Scenarii de risc, inventarul activelor, implementarea controalelor, monitorizare, înregistrări de răspuns și recuperare |
| Auditor COBIT sau ISACA | Este guvernanța riscurilor aliniată la obiectivele organizației, roluri, performanță, asigurare și raportarea către conducere? | Procese-verbale de guvernanță, RACI, KRI, constatări ale Auditului Intern, urmărirea remedierii, tablouri de bord de management |
De aceea contează arhitectura dovezilor. Aceeași înregistrare de risc trebuie să fie trasabilă de la obiectivul organizației la activ, amenințare, vulnerabilitate, control, proprietar, factor de reglementare, acțiune de tratare, rezultat al testului și decizie de management.
Politicile Clarysec sunt proiectate pentru a susține această arhitectură. Politica Enterprise de management al riscurilor prevede în secțiunea „Standarde și cadre de referință”:
Article 5: Impune un cadru documentat de management al riscurilor TIC, acoperit integral de structura acestei politici, inclusiv maparea SoA și KRI.
Acest lucru transformă politica dintr-un document static într-o dovadă de audit care arată că guvernanța riscurilor TIC a fost proiectată intenționat având DORA în vedere.
Constatări frecvente care compromit programele de risc
Când Clarysec revizuiește dovezile de evaluare și tratare a riscurilor ISO 27001, aceleași constatări apar în mod repetat.
În primul rând, criteriile de risc ignoră impactul juridic, de reglementare, contractual, asupra furnizorilor și asupra confidențialității. Acest lucru duce la scorare slabă. O încălcare a securității datelor cu caracter personal sau un eșec al unui furnizor critic poate fi evaluat ca mediu deoarece probabilitatea este scăzută, deși impactul GDPR, NIS2, DORA sau asupra clientului ar trebui să îl facă ridicat sau critic.
În al doilea rând, proprietarii de risc sunt generici. „IT” nu este proprietar de risc. Un proprietar de risc trebuie să fie un rol sau o persoană responsabilă pentru deciziile de tratare, buget, calendar și riscul rezidual.
În al treilea rând, planurile de tratare nu sunt încadrate în timp. „Îmbunătățirea monitorizării” nu este un plan. „Implementarea alertelor pentru sesiuni privilegiate în SIEM pentru conturile administrative de producție până la 30 iunie, deținută de Manager SOC, testată prin autentificare administrativă simulată, cu dovada alertei atașată” este un plan.
În al patrulea rând, SoA este deconectată de tratare. Dacă planul de tratare necesită monitorizarea furnizorilor, testarea backup-urilor, escaladarea incidentelor, MFA sau jurnalizare, SoA trebuie să reflecte controalele relevante și starea implementării.
În al cincilea rând, riscul rezidual nu este aprobat. ISO 27001 impune aprobarea de către proprietarul riscului a planului de tratare și a riscurilor reziduale. NIS2 și DORA fac acest lucru și mai important, deoarece responsabilitatea conducerii este explicită.
În al șaselea rând, riscul furnizorilor este tratat ca administrare a achizițiilor. Conform NIS2 Article 21(2)(d) și DORA Articles 28 și 30, riscul furnizorilor și al terților furnizori de servicii TIC trebuie să facă parte din managementul riscurilor, nu să fie un chestionar anual stocat izolat.
În al șaptelea rând, nu există dovezi privind eficacitatea. ISO 27001 Clauza 6.1.1 impune ca acțiunile planificate să fie evaluate pentru eficacitate. NIS2 include evaluarea eficacității în Article 21(2)(f). DORA așteaptă testare și remediere. Un control care există, dar nu este niciodată testat, reprezintă o dovadă slabă.
Politica de management al riscurilor pentru IMM-uri stabilește clar așteptarea:
Directorul general și coordonatorul de risc trebuie să se asigure că activitățile de management al riscurilor sunt pregătite pentru audit. Registrul de riscuri și acțiunile conexe fac obiectul auditului intern și extern.
Din Politica de management al riscurilor pentru IMM-uri, secțiunea „Aplicare și conformitate”, clauza de politică 8.2.1.
Raportarea către consiliul de administrație fără a sufoca executivii
NIS2, DORA și ISO 27001 indică toate responsabilitatea conducerii, însă consiliile de administrație nu au nevoie de fiecare rând din registrul de riscuri. Au nevoie de raportare utilă pentru decizie.
Un pachet bun de raportare a riscurilor către consiliu trebuie să arate:
- Riscuri ridicate și critice pe domenii
- Acțiuni de tratare restante
- Riscuri de reglementare care implică NIS2, DORA, GDPR sau contracte
- Riscuri ale furnizorilor care afectează servicii critice sau importante
- Tendințe ale incidentelor și ale incidentelor evitate la limită
- Riscuri reziduale în așteptarea acceptării
- Rezultatele testelor de eficacitate a controalelor
- Modificări semnificative ale domeniului de aplicare, furnizorilor, tehnologiei sau legislației
- Constatări ale Auditului Intern și acțiuni corective
Clarysec recomandă de obicei revizuiri operaționale lunare ale riscurilor și revizuiri de management trimestriale. Revizuirile lunare se concentrează pe livrarea tratamentelor. Revizuirile trimestriale se concentrează pe acceptare, finanțare, prioritizare, expunere de reglementare și decizii strategice de risc.
Acest ritm susține și îmbunătățirea continuă. Evaluările riscurilor trebuie actualizate atunci când apar incidente, vulnerabilități, active noi, schimbări tehnologice, schimbări de furnizori, schimbări legislative, schimbări ale obligațiilor față de clienți sau modificări ale apetitului la risc.
Calea de implementare Clarysec
Un program unificat de risc evită tabelele separate pentru ISO, NIS2, DORA, GDPR și asigurarea solicitată de clienți. Calea practică este:
- Confirmați domeniul de aplicare al SMSI, serviciile, activele, furnizorii, jurisdicțiile și obligațiile față de clienți.
- Construiți sau actualizați registrul de conformitate folosind Politica de conformitate juridică și de reglementare pentru IMM-uri, acolo unde este adecvat.
- Definiți metodologia de risc, criteriile de acceptare, scalele de probabilitate, scalele de impact și regulile privind impactul de reglementare.
- Construiți registrul de riscuri folosind faza de management al riscurilor din Zenith Blueprint și abordarea Clarysec pentru Risk Register and SoA Builder.
- Identificați riscuri bazate pe active și pe scenarii, inclusiv scenarii privind furnizorii, cloud, confidențialitatea, continuitatea, incidentele, vulnerabilitățile, dezvoltarea securizată și accesul.
- Scorați riscurile folosind criterii care includ impact juridic, de reglementare, contractual, operațional, asupra confidențialității, asupra furnizorilor și financiar.
- Selectați opțiunile de tratare: atenuare, evitare, transfer sau acceptare.
- Mapați controalele necesare la ISO/IEC 27001:2022 Anexa A și la îndrumările ISO/IEC 27002:2022.
- Creați sau actualizați Declarația de aplicabilitate.
- Mapați tratamentele la NIS2 Article 21, managementul riscurilor TIC și așteptările privind terții în DORA, responsabilitatea GDPR și obligațiile contractuale ale clienților.
- Colectați dovezi, validați eficacitatea controalelor și obțineți aprobarea riscului rezidual.
- Pregătiți un pachet de audit organizat pe risc, control, reglementare și artefact de dovadă.
- Introduceți rezultatele în revizuirea de management, Auditul Intern, acțiuni corective și îmbunătățire continuă.
Aceasta nu este documentație de dragul documentației. Este sistemul operațional pentru o guvernanță cibernetică defensabilă.
Construiți un pachet de tratare a riscurilor pregătit pentru audit
Povestea Sarei se încheie bine deoarece a încetat să trateze ISO 27001, NIS2 și DORA ca proiecte de conformitate separate. A folosit evaluarea riscurilor ISO 27001 ca motor central, a integrat obligațiile de reglementare în criteriile de risc, a mapat acțiunile de tratare la Anexa A și cerințele UE și a colectat dovezi pe care clienții, auditorii și consiliul de administrație le puteau înțelege.
Organizația dumneavoastră poate face același lucru.
Folosiți Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului pentru a defini criteriile de risc, a construi registrul de riscuri, a crea planul de tratare a riscurilor și a corela cerințele de reglementare.
Folosiți Zenith Controls: ghidul de conformitate transversală pentru a conecta zonele de control ISO/IEC 27001:2022 Anexa A cu perspectivele de guvernanță, conformitate juridică, asigurare și audit.
Folosiți Politica de management al riscurilor, Politica de management al riscurilor pentru IMM-uri și Politica de conformitate juridică și de reglementare pentru IMM-uri ale Clarysec pentru a standardiza proprietatea, registrele, deciziile de tratare și dovezile pregătite pentru audit.
Cel mai rapid pas practic este să luați primele zece riscuri și să le testați prin cinci întrebări:
- Este vizibil impactul de reglementare?
- Planul de tratare este încadrat în timp și are proprietar?
- Fiecare tratament este mapat la Anexa A și la SoA?
- Relevanța NIS2, DORA, GDPR sau pentru client este documentată acolo unde se aplică?
- Există dovezi că funcționează controlul?
Dacă răspunsul este nu, Clarysec vă poate ajuta să transformați registrul de riscuri într-un program defensabil de tratare a riscurilor și conformitate transversală, în care auditorii, autoritățile de reglementare, clienții și consiliile de administrație pot avea încredere.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
