SoA ISO 27001 pentru pregătirea NIS2 și DORA
Este ora 08:30 într-o zi de luni, iar Elena, director pentru securitatea informației al unui furnizor B2B FinTech SaaS aflat în creștere rapidă, deschide o solicitare urgentă din partea consiliului de administrație. Compania tocmai a obținut certificarea ISO/IEC 27001:2022, însă un potențial client bancar important din UE adresează întrebări mai exigente decât cele din chestionarul obișnuit de securitate.
Nu întreabă doar dacă organizația criptează datele, utilizează autentificare multifactor sau deține un raport de testare de penetrare. Vor să știe dacă platforma SaaS susține obligațiile lor DORA, dacă furnizorul ar putea intra în domeniul de aplicare NIS2 ca serviciu TIC sau ca dependență de infrastructură digitală și dacă Declarația de aplicabilitate ISO 27001 poate justifica fiecare control inclus, fiecare control exclus și fiecare dovadă.
Consiliul adresează întrebarea pe care fiecare CISO, responsabil de conformitate și fondator SaaS o aude tot mai des:
Poate SoA ISO 27001 să demonstreze pregătirea pentru NIS2 și DORA?
Elena știe că răspunsul greșit ar fi lansarea a trei programe separate de conformitate: unul pentru ISO 27001, unul pentru NIS2 și unul pentru DORA. Acest lucru ar genera dovezi duplicate, responsabili de control cu atribuții conflictuale și o mobilizare permanentă înaintea fiecărei evaluări din partea clienților. Răspunsul corect este utilizarea SMSI existent ca sistem operațional pentru conformitate, cu Declarația de aplicabilitate, sau SoA, ca document principal de trasabilitate.
SoA nu este doar un tabel pentru certificarea ISO. Într-un mediu al UE axat pe securitate cibernetică și reziliență operațională, aceasta este locul în care o organizație demonstrează de ce există controalele, de ce excluderile sunt justificabile, cine răspunde pentru fiecare control, ce dovezi susțin implementarea și cum setul de controale acoperă NIS2, DORA, GDPR, contractele cu clienții și tratamentul intern al riscurilor.
Politica enterprise Clarysec privind securitatea informației Politica de securitate a informației prevede:
SMSI trebuie să includă limite definite ale domeniului de aplicare, o metodologie de evaluare a riscurilor, obiective măsurabile și controale documentate justificate în Declarația de aplicabilitate (SoA).
Această cerință, din clauza de politică 6.1.2 a Politicii de securitate a informației, reprezintă fundamentul unei abordări pregătite pentru audit. SoA trebuie să devină puntea dintre obligații, riscuri, controale, dovezi și decizii de management.
De ce NIS2 și DORA au schimbat sensul noțiunii de „aplicabil”
O SoA ISO/IEC 27001:2022 tradițională pornește adesea de la o întrebare simplă: „Care controale din Anexa A se aplică Planului de tratament al riscurilor?” Întrebarea rămâne corectă, însă nu mai este suficientă pentru furnizorii SaaS, cloud, de servicii administrate, fintech, tehnologie financiară și lanțuri de aprovizionare critice.
NIS2 ridică nivelul de bază pentru managementul riscurilor de securitate cibernetică la nivelul entităților esențiale și importante din UE. Aceasta acoperă sectoare precum infrastructura digitală, furnizorii de servicii de cloud computing, furnizorii de servicii de centre de date, rețelele de livrare de conținut, furnizorii de servicii administrate, furnizorii de servicii de securitate administrate, sectorul bancar și infrastructurile piețelor financiare. Statele membre trebuie să identifice entitățile esențiale și importante și furnizorii de servicii de înregistrare a numelor de domeniu, iar mulți furnizori de tehnologie care anterior tratau reglementarea securității cibernetice ca pe o problemă a clientului sunt acum fie direct în domeniul de aplicare, fie expuși prin cerințe contractuale transferate pe lanț.
NIS2 Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale în domenii precum analiza riscurilor, politicile de securitate, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și dezvoltarea securizată, evaluarea eficacității controalelor, igiena cibernetică, instruirea, criptografia, securitatea resurselor umane, controlul accesului, politica de management al activelor și autentificarea, după caz. NIS2 Article 23 adaugă așteptări privind raportarea etapizată a incidentelor, inclusiv avertizare timpurie, notificare, actualizări și raport final pentru incidente semnificative.
DORA, Digital Operational Resilience Act, se aplică începând cu 17 ianuarie 2025 și se concentrează asupra entităților financiare și a ecosistemului lor de risc TIC. Acoperă managementul riscurilor TIC, raportarea incidentelor legate de TIC, raportarea incidentelor operaționale sau de securitate privind plățile pentru anumite entități, testarea rezilienței operaționale digitale, schimbul de informații privind amenințările cibernetice, managementul riscului TIC asociat terților, acordurile contractuale și supravegherea furnizorilor terți critici de servicii TIC.
Pentru entitățile financiare care sunt și entități esențiale sau importante în temeiul NIS2, DORA funcționează ca regim sectorial specific pentru obligații echivalente de management al riscurilor TIC și de raportare a incidentelor. Însă pentru furnizorii SaaS, furnizorii cloud, MSP și furnizorii MDR care deservesc clienți financiari, realitatea practică este că așteptările DORA ajung prin achiziții, contracte, drepturi de audit, obligații de suport pentru incidente, planificare de ieșire, transparența subcontractanților și dovezi de reziliență.
Aceasta schimbă discuția despre SoA. Întrebarea nu mai este: „Conține Anexa A acest control?” Întrebarea mai bună este:
Putem demonstra că selecția controalelor este bazată pe risc, ține cont de obligații, este proporțională, are responsabili desemnați, este implementată, monitorizată, susținută prin dovezi și aprobată?
ISO 27001 este traducătorul universal pentru NIS2 și DORA
ISO/IEC 27001:2022 este valoros deoarece este un standard de sistem de management, nu o simplă listă de verificare. Acesta impune ca SMSI să fie integrat în procesele organizației și dimensionat în funcție de nevoile acesteia. Prin aceasta, devine un traducător universal eficace pentru cerințe de conformitate suprapuse.
Clauzele 4.1 până la 4.4 impun organizației să își înțeleagă contextul, să identifice părțile interesate, să determine cerințele relevante și să definească domeniul de aplicare al SMSI. Pentru un furnizor FinTech SaaS precum compania Elenei, cerințele acestor părți interesate pot include clienți din UE, clienți financiari afectați de DORA, expunere sectorială NIS2, obligații de operator de date și persoană împuternicită în temeiul GDPR, dependențe cloud externalizate, interfețe cu furnizorii și așteptări ale consiliului de administrație.
Clauzele 6.1.1 până la 6.1.3 impun planificarea riscurilor și oportunităților, un proces repetabil de evaluare a riscurilor de securitate a informației, un proces de tratament al riscurilor, compararea cu Anexa A și o Declarație de aplicabilitate care identifică controalele incluse, stadiul implementării și justificările excluderilor.
Aici SoA devine o înregistrare a deciziilor privind controalele. Un control poate fi inclus deoarece tratează un risc, satisface o cerință legală, îndeplinește un contract cu clientul, susține un obiectiv al organizației sau reprezintă o cerință de bază de igienă a securității. Un control poate fi exclus numai după ce organizația l-a evaluat în mod conștient, l-a considerat nerelevant pentru domeniul de aplicare al SMSI, a documentat justificarea și a obținut aprobarea corespunzătoare.
Politica enterprise Clarysec privind managementul riscurilor Politica de management al riscurilor prevede:
O Declarație de aplicabilitate (SoA) trebuie să reflecte toate deciziile de tratament și trebuie actualizată ori de câte ori acoperirea controalelor este modificată.
Această cerință, din clauza de politică 5.4 a Politicii de management al riscurilor, este critică pentru pregătirea NIS2 și DORA. Un nou client reglementat, o nouă dependență cloud, o nouă obligație de raportare a incidentelor sau un nou risc de concentrare la nivel de furnizor pot modifica aplicabilitatea controalelor.
Începeți cu Registrul de conformitate, nu cu lista de controale
O SoA slabă pornește de la Anexa A și întreabă: „Ce controale avem deja?” O SoA solidă pornește de la realitatea operațională a organizației și întreabă: „Ce obligații, servicii, riscuri, date, furnizori și clienți trebuie să acopere SMSI?”
ISO/IEC 27005:2022 susține această abordare prin accentul pus pe cerințele părților interesate, criteriile de risc și necesitatea de a lua în considerare standardele, regulile interne, legile, reglementările, contractele și controalele existente. De asemenea, subliniază că neaplicabilitatea sau neconformitatea trebuie explicată și justificată.
Politica SME Clarysec privind conformitatea juridică și de reglementare Politica de conformitate juridică și de reglementare-sme - SME reflectă același principiu operațional:
GM trebuie să mențină un Registru de conformitate simplu și structurat care să listeze:
Această cerință provine din clauza 5.1.1 a Politicii de conformitate juridică și de reglementare-sme. Pentru o organizație mai mică, registrul poate fi simplu. Pentru o organizație enterprise, acesta trebuie să fie mai detaliat. Logica este aceeași: obligațiile trebuie să fie vizibile înainte de a putea fi mapate.
Politica enterprise Clarysec privind conformitatea juridică și de reglementare Politica de conformitate juridică și de reglementare este explicită:
Toate obligațiile legale și de reglementare trebuie mapate la politici, controale și responsabili specifici în cadrul Sistemului de management al securității informației (SMSI).
Aceasta este clauza de politică 6.2.1 din Politica de conformitate juridică și de reglementare. Ea reprezintă coloana vertebrală de guvernanță pentru utilizarea unei Declarații de aplicabilitate ISO 27001 în scopul pregătirii pentru conformitatea cu NIS2 și DORA.
| Câmp din registru | Exemplu de intrare | De ce contează pentru SoA |
|---|---|---|
| Sursa obligației | NIS2 Article 21 | Determină includerea controalelor privind analiza riscurilor, gestionarea incidentelor, continuitatea, securitatea furnizorilor, criptografia, controlul accesului, managementul activelor și instruirea |
| Justificarea aplicabilității | Furnizor SaaS care susține clienți financiari și clienți din sectoare esențiale din UE | Arată de ce NIS2 este luată în considerare chiar dacă statutul juridic final depinde de desemnarea de către statul membru |
| Responsabil de control | Șeful operațiunilor de securitate | Susține responsabilitatea și deținerea dovezilor |
| Control ISO/IEC 27001:2022 mapat | Controale A.5.24 până la A.5.28 privind gestionarea incidentelor | Leagă obligația legală de selecția controalelor din Anexa A |
| Sursa dovezilor | Planul de răspuns la incidente, eșantioane de tichete, analiză post-incident, exercițiu de raportare | Simplifică eșantionarea în audit |
| Decizie SoA | Aplicabil | Creează trasabilitate între obligație, risc, control și dovezi |
Construiți criterii de risc care reflectă reziliența, confidențialitatea, furnizorii și reglementarea
Multe justificări SoA eșuează deoarece modelul de scorare a riscurilor este prea îngust. Acesta măsoară probabilitatea și impactul tehnic, dar nu surprinde expunerea de reglementare, criticitatea serviciului, prejudiciul adus clientului, dependența de furnizor, impactul asupra protecției datelor cu caracter personal sau perturbarea operațională sistemică.
NIS2 nu vizează doar confidențialitatea. Se concentrează pe prevenirea și minimizarea impactului incidentelor asupra serviciilor și destinatarilor serviciilor. DORA definește funcțiile critice sau importante în funcție de măsura în care o perturbare ar afecta semnificativ performanța financiară, continuitatea serviciilor sau conformitatea cu reglementările. GDPR adaugă responsabilitate, integritate, confidențialitate, pregătire pentru încălcări și prejudicii pentru persoanele vizate.
Politica SME Clarysec privind managementul riscurilor Politica de management al riscurilor-sme - SME oferă un minim practic:
Fiecare intrare de risc trebuie să includă: descriere, probabilitate, impact, scor, responsabil și plan de tratament.
Aceasta este clauza 5.1.2 din Politica de management al riscurilor-sme. Pentru pregătirea NIS2 și DORA, Clarysec extinde acest minim cu câmpuri precum sursa obligației, serviciul afectat, categoria de date, dependența de furnizor, responsabilul de business, impactul de reglementare, riscul rezidual, stadiul tratamentului și sursa dovezilor.
| ID risc | Scenariu de risc | Factorul obligației | Controale de tratament | Justificare SoA |
|---|---|---|---|---|
| R-021 | O indisponibilitate a platformei cloud împiedică accesul clienților la dashboardurile reglementate de analiză a fraudelor | NIS2 Article 21, dependență DORA a clientului, SLA contractual | A.5.29, A.5.30, A.8.13, A.8.15, A.8.16 | Aplicabil deoarece continuitatea serviciului, backup-ul, jurnalizarea, monitorizarea și pregătirea TIC reduc perturbarea operațională și susțin obligațiile de reziliență ale clienților |
| R-034 | Un incident de securitate care implică date cu caracter personal din UE nu este detectat, escaladat sau raportat în termenele impuse | responsabilitate GDPR, NIS2 Article 23, obligații DORA de suport pentru incidente | A.5.24 până la A.5.28, A.8.15, A.8.16 | Aplicabil deoarece gestionarea etapizată a incidentelor, colectarea dovezilor, lecțiile învățate, jurnalizarea și monitorizarea susțin fluxurile de notificare către clienți și autorități |
| R-047 | O vulnerabilitate la nivelul unui subcontractant critic afectează livrarea securizată a serviciilor către clienți financiari | securitatea lanțului de aprovizionare conform NIS2 Article 21, risc TIC asociat terților conform DORA | A.5.19 până la A.5.23, A.5.31, A.5.36 | Aplicabil deoarece riscul asociat furnizorilor, cerințele contractuale, guvernanța cloud, obligațiile de conformitate și respectarea politicilor sunt necesare pentru asigurarea dependențelor TIC |
Observați formularea. O justificare solidă nu spune doar „implementat”. Ea explică de ce controlul este aplicabil în contextul de business, de reglementare și de risc al organizației.
Mapați domeniile NIS2 și DORA la controalele ISO 27001:2022
După stabilirea Registrului de conformitate și a criteriilor de risc, activitatea practică este maparea domeniilor de reglementare la controalele din Anexa A. Această mapare nu dovedește conformitatea de una singură, dar oferă auditorilor și clienților un index clar pentru testarea dovezilor.
| Aria cerinței de reglementare | Referință NIS2 | Referință DORA | Exemple de controale ISO/IEC 27001:2022 |
|---|---|---|---|
| Guvernanță și responsabilitatea managementului | Article 20 | Article 5 | A.5.1, A.5.2, A.5.31, A.5.35, A.5.36 |
| Cadru de gestionare a riscurilor | Article 21(1) | Article 6 | Clauzele ISO 27001 6.1.1 până la 6.1.3, A.5.7, A.5.31, A.5.36 |
| Gestionarea și raportarea incidentelor | Article 23 | Articles 17 to 19 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16 |
| Continuitatea activității și reziliență | Article 21(2)(c) | Articles 11 and 12 | A.5.29, A.5.30, A.8.13, A.8.14, A.8.15, A.8.16 |
| Lanțul de aprovizionare și riscul asociat terților | Article 21(2)(d), Article 21(3) | Articles 28 to 30 | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Achiziție și dezvoltare securizate | Article 21(2)(e) | Article 9 | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 |
| Testare și eficacitatea controalelor | Article 21(2)(f) | Articles 24 to 27 | A.5.35, A.5.36, A.8.8, A.8.29, A.8.34 |
| Controlul accesului și politica de management al activelor | Article 21(2)(i) | Article 9(4)(d) | A.5.9, A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3 |
| Criptografie și criptare | Article 21(2)(h) | Article 9(4)(d) | A.8.24 |
Pentru Elena, această mapare a schimbat discuția cu consiliul de administrație. În loc să prezinte NIS2 și DORA ca proiecte separate, a putut arăta suprapunerea: guvernanță, managementul riscurilor, incidente, continuitate, furnizori, testare, controlul accesului și criptografie.
Cele trei controale ISO de care depinde fiecare SoA NIS2 și DORA
În Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec tratează trei controale ISO/IEC 27002:2022 ca fiind centrale pentru guvernanța SoA pregătită pentru audit în context NIS2 și DORA. Acestea sunt controale ISO, îmbogățite cu atribute de conformitate transversală în ghidul Zenith Controls.
| Control ISO/IEC 27002:2022 | Denumirea controlului | Atribute Zenith Controls | De ce contează pentru guvernanța SoA |
|---|---|---|---|
| 5.31 | Cerințe legale, statutare, de reglementare și contractuale | Preventiv, CIA, identificare, juridic și conformitate, guvernanță, ecosistem, protecție | Stabilește baza obligațiilor care determină includerea controalelor și atribuirea responsabililor |
| 5.35 | Revizuirea independentă a securității informației | Preventiv și corectiv, CIA, identificare și protecție, asigurarea securității informației, guvernanță, ecosistem | Oferă asigurare că deciziile SoA și dovezile de implementare pot rezista unei revizuiri independente |
| 5.36 | Conformitatea cu politicile, regulile și standardele pentru securitatea informației | Preventiv, CIA, identificare și protecție, juridic și conformitate, asigurarea securității informației, guvernanță, ecosistem | Conectează SoA la conformitatea operațională, respectarea politicilor și monitorizare |
Aceste controale nu sunt izolate. Ele se conectează direct la controalele privind relațiile cu furnizorii A.5.19 până la A.5.23, controalele de gestionare a incidentelor A.5.24 până la A.5.28, controalele de continuitate A.5.29 și A.5.30, controlul de confidențialitate A.5.34, managementul vulnerabilităților A.8.8, managementul configurației A.8.9, backup-ul informațiilor A.8.13, jurnalizarea A.8.15, activitățile de monitorizare A.8.16, criptografia A.8.24, controalele de dezvoltare securizată A.8.25 până la A.8.29 și managementul schimbărilor A.8.32.
Valoarea Zenith Controls constă în faptul că ajută echipele să evite tratarea SoA ca artefact al unui singur standard. Controlul 5.31 susține maparea juridică și contractuală. Controlul 5.35 susține auditul intern, revizuirea independentă și asigurarea oferită managementului. Controlul 5.36 susține conformitatea operațională cu politicile, procedurile, standardele și cerințele de control.
Folosiți Zenith Blueprint pentru a construi, testa și apăra SoA
În Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec plasează construirea SoA în faza de management al riscurilor, pasul 13: Planificarea tratamentului riscurilor și Declarația de aplicabilitate. Blueprint indică organizațiilor să utilizeze foaia SoA din șablonul „Risk Register and SoA Builder.xlsx”, să decidă dacă fiecare dintre cele 93 de controale din Anexa A este aplicabil și să bazeze decizia pe tratamentul riscurilor, cerințele legale și contractuale, relevanța domeniului de aplicare și contextul organizației.
Blueprint precizează:
SoA este, în esență, un document-punte: leagă evaluarea/tratamentul riscurilor de controalele efective pe care le aveți.
Această propoziție surprinde modelul operațional. SoA face legătura între obligații, riscuri, politici, controale, dovezi și concluzii de audit.
Zenith Blueprint indică, de asemenea, echipelor să facă trimitere încrucișată la reglementări în notele SoA, acolo unde este cazul. Dacă un control este implementat pentru GDPR, NIS2 sau DORA, acest lucru trebuie să apară în Registrul de riscuri sau în notele SoA. Ulterior, la pasul 24, Blueprint solicită organizațiilor să actualizeze SoA după implementare și să o verifice încrucișat cu Planul de tratament al riscurilor. La pasul 30, Pregătirea certificării, revizuire finală și audit simulat, Blueprint îndrumă echipele să confirme că fiecare control aplicabil din Anexa A are dovezi precum o politică, procedură, raport, plan sau înregistrare de implementare.
Această succesiune transformă SoA într-un instrument viu de conformitate:
- Pasul 13 o construiește pe baza tratamentului riscurilor și a obligațiilor.
- Pasul 24 o testează față de realitatea implementării.
- Pasul 30 o apără prin revizuirea finală a dovezilor și audit simulat.
Cum să redactați justificări de includere pe care auditorii le pot urmări
Un control trebuie inclus atunci când există cel puțin un factor justificabil: tratamentul riscurilor, cerință legală, cerință contractuală, relevanță pentru domeniul de aplicare, igienă de securitate de bază, așteptare de asigurare din partea clientului sau obiectiv de reziliență aprobat de management.
O formulă utilă este:
Aplicabil deoarece [risc sau obligație] afectează [serviciu, activ, date sau proces], iar acest control furnizează [rezultat preventiv, de detectare, corectiv sau de reziliență], dovedit prin [politică, înregistrare, test, raport sau rezultat generat de sistem].
| Arie de control | Justificare slabă | Justificare pregătită pentru audit |
|---|---|---|
| Gestionarea incidentelor | Implementat | Aplicabil deoarece NIS2 Article 23 și așteptările DORA privind ciclul de viață al incidentelor impun detecție, clasificare, escaladare, suport pentru raportare, comunicări, analiza cauzei principale, colectarea dovezilor și lecții învățate pentru incidente care afectează clienți reglementați |
| Securitatea furnizorilor | Necesar | Aplicabil deoarece găzduirea cloud, furnizorii de suport și serviciile MDR afectează disponibilitatea serviciului și confidențialitatea datelor, iar NIS2 Article 21 plus așteptările DORA privind riscul TIC asociat terților impun verificare prealabilă, măsuri contractuale de protecție, monitorizare, revizuirea subcontractanților și planificare de ieșire |
| Criptografie | În uz | Aplicabil deoarece datele clienților, secretele de autentificare, backup-urile și datele financiare reglementate necesită măsuri de protecție a confidențialității și integrității în temeiul NIS2, DORA, GDPR, contractelor cu clienții și tratamentului intern al riscurilor |
| Revizuire independentă | Da | Aplicabil deoarece managementul, clienții și auditorii necesită asigurare că controalele SMSI, deciziile SoA, dovezile și mapările de reglementare sunt revizuite periodic în mod independent |
Pentru un furnizor fintech SaaS, un rând SoA ar putea arăta astfel:
| Câmp SoA | Exemplu de intrare |
|---|---|
| Control | A.5.19 Gestionarea securității informației în relațiile cu furnizorii |
| Aplicabilitate | Da |
| Justificare | Aplicabil deoarece găzduirea cloud, instrumentele de suport și serviciile MDR afectează confidențialitatea, disponibilitatea, detectarea incidentelor și asigurarea clienților reglementați. Susține așteptările NIS2 privind lanțul de aprovizionare, așteptările DORA privind riscul TIC asociat terților pentru clienții financiari, responsabilitatea persoanei împuternicite conform GDPR și cerințele contractuale de audit. |
| Stadiul implementării | Implementat și monitorizat |
| Responsabil | Șeful managementului furnizorilor |
| Dovezi | Registrul furnizorilor, listă de verificare pentru evaluarea prealabilă, clauze contractuale de securitate, înregistrări ale revizuirii anuale, rapoarte SOC sau de asigurare, revizuirea subcontractanților, plan de ieșire pentru furnizori critici |
| Riscuri asociate | R-047, R-021, R-034 |
| Politici asociate | Politica de securitate privind terții și furnizorii, Politica de conformitate juridică și de reglementare, Politica de management al riscurilor |
| Frecvența revizuirii | Anual și la schimbarea furnizorului, incident major, client reglementat nou sau extinderea serviciului |
Aceasta este pregătită pentru audit deoarece conectează controlul la context, risc, obligație, implementare, responsabilitate și dovezi.
Cum să justificați excluderile fără a crea expunere în audit
Excluderile nu sunt eșecuri. Excluderile slab justificate sunt eșecuri.
ISO/IEC 27001:2022 impune ca SoA să justifice controalele excluse din Anexa A. ISO/IEC 27005:2022 consolidează faptul că neaplicabilitatea trebuie explicată și justificată. Politica enterprise Clarysec privind securitatea informației prevede:
Baza de referință poate fi adaptată; cu toate acestea, excluderile trebuie documentate cu aprobare formală și justificare în SoA.
Aceasta este clauza 7.2.2 a Politicii de securitate a informației.
Politica Clarysec privind securitatea informației pentru SME Politica de securitate a informației-sme - SME prevede:
Orice abatere de la această politică trebuie documentată, explicând clar de ce abaterea este necesară, ce măsuri compensatorii sunt în vigoare și data definită pentru reevaluare.
Această cerință provine din clauza 7.2.1 a Politicii de securitate a informației-sme.
| Arie de control | Justificarea excluderii | Măsuri de protecție necesare |
|---|---|---|
| Controale de dezvoltare securizată pentru cod dezvoltat intern | Neaplicabil deoarece domeniul de aplicare al SMSI acoperă doar un serviciu de revânzare, fără dezvoltare software internă, fără modificare de cod și fără fluxuri de integrare și livrare continuă (CI/CD) | Asigurarea furnizorului, aprobarea schimbărilor, recepția notificărilor privind vulnerabilitățile, comunicarea cu clienții și reevaluare anuală |
| Monitorizarea securității fizice pentru facilități deținute | Neaplicabil deoarece organizația nu are un centru de date, cameră de servere sau facilitate de birou deținută în domeniul de aplicare al SMSI, iar întreaga infrastructură de producție este operată de furnizori cloud auditați | Evaluarea prealabilă a furnizorilor cloud, controale contractuale, revizuirea drepturilor de acces, revizuirea responsabilităților partajate și dovezi din rapoartele de asigurare ale furnizorului |
| Anumite activități de gestionare a mediilor on-premises | Neaplicabil deoarece nu se utilizează medii amovibile sau stocare on-premises în serviciul inclus în domeniul de aplicare | Restricții pentru endpointuri, monitorizare DLP acolo unde este cazul, inventarul activelor și validare periodică |
Pentru NIS2 și DORA, excluderile necesită atenție suplimentară. O companie SaaS ar trebui să excludă foarte rar jurnalizarea, monitorizarea, backup-urile, gestionarea incidentelor, controlul accesului, securitatea furnizorilor sau managementul vulnerabilităților. Chiar și atunci când un control nu este legat de un risc specific, acesta poate fi totuși necesar ca securitate de bază, asigurare pentru clienți, așteptare contractuală sau obligație legală.
Politica Clarysec privind managementul riscurilor pentru SME reamintește, de asemenea, echipelor cum trebuie gestionat riscul acceptat:
Acceptare: justificați de ce nu este necesară nicio acțiune suplimentară și înregistrați riscul rezidual.
Această clauză, 6.1.1 din Politica de management al riscurilor-sme, reflectă exact abordarea necesară pentru excluderi și decizii privind riscul rezidual.
Raportarea incidentelor: demonstrați fluxul de lucru, nu existența politicii
NIS2 Article 23 impune raportarea etapizată a incidentelor semnificative, inclusiv avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, notificare în termen de 72 de ore, actualizări atunci când sunt solicitate și un raport final în termen de o lună de la notificarea de 72 de ore. DORA impune entităților financiare să detecteze, să gestioneze, să clasifice, să escaladeze, să comunice și să raporteze incidentele majore legate de TIC, să informeze clienții afectați acolo unde este necesar, să efectueze analiza cauzei principale și să îmbunătățească controalele.
Un furnizor SaaS poate să nu raporteze întotdeauna direct unei autorități DORA, dar poate fi necesar să susțină termenele de raportare ale clienților financiari. Acest lucru face ca controalele privind incidentele să fie foarte relevante în SoA.
O SoA slabă spune: „Există o politică de răspuns la incidente.”
O SoA solidă spune: „Aplicabil deoarece organizația trebuie să detecteze, să evalueze, să clasifice, să escaladeze, să comunice, să păstreze dovezile, să susțină termenele de raportare către autorități, să notifice clienții afectați atunci când acest lucru este cerut contractual și să învețe din incidentele care afectează servicii, date sau clienți reglementați.”
Dovezile trebuie să includă:
- Planul de răspuns la incidente și matricea de escaladare.
- Criterii de clasificare a severității.
- Flux de notificare a clienților.
- Arbore decizional pentru notificări de reglementare, acolo unde este aplicabil.
- Tichete de incident și cronologii.
- Jurnale și alerte de monitorizare.
- Înregistrări ale exercițiilor tabletop.
- Analiză post-incident și acțiuni corective.
- Proceduri de păstrare a dovezilor.
Politica enterprise Clarysec privind auditul și monitorizarea conformității Politica de audit și monitorizare a conformității explică de ce acest lucru contează:
Pentru a genera dovezi sustenabile și o pistă de audit în sprijinul solicitărilor autorităților de reglementare, procedurilor judiciare sau cererilor clienților privind asigurarea controalelor.
Acest obiectiv provine din clauza 3.4 a Politicii de audit și monitorizare a conformității.
Pentru organizațiile mai mici, păstrarea dovezilor trebuie, de asemenea, să fie explicită. Politica Clarysec privind auditul și monitorizarea conformității pentru SME Politica de audit și monitorizare a conformității-sme - SME prevede:
Dovezile trebuie păstrate cel puțin doi ani sau mai mult atunci când acest lucru este cerut de certificare ori de acordurile cu clienții.
Aceasta este clauza 6.2.4 din Politica de audit și monitorizare a conformității-sme.
O singură SoA, mai multe discuții de audit
Cea mai bună SoA nu duplică cadrele. Ea creează o narațiune trasabilă a controalelor, pe care auditori diferiți o pot înțelege.
| Cadru sau perspectivă | Ce va întreba auditorul sau evaluatorul | Cum ajută SoA |
|---|---|---|
| ISO/IEC 27001:2022 | De ce este inclus sau exclus acest control din Anexa A, care este stadiul implementării și unde sunt dovezile? | Leagă deciziile privind controalele de riscuri, obligații, stadiul implementării, responsabili și dovezi |
| NIS2 | Cum funcționează în practică guvernanța, analiza riscurilor, gestionarea incidentelor, continuitatea activității, lanțul de aprovizionare, criptarea, controlul accesului, managementul activelor și instruirea? | Mapează așteptările Article 21 și Article 23 la controale din Anexa A și înregistrări operaționale |
| DORA | Cum sunt dovedite riscul TIC, gestionarea incidentelor, testarea rezilienței, riscul asociat terților, contractele, drepturile de audit, planurile de ieșire și supravegherea managementului? | Arată ce controale susțin obligațiile entității financiare sau asigurarea furnizorului SaaS |
| GDPR | Poate organizația demonstra integritate, confidențialitate, responsabilitate, pregătire pentru încălcări, suport pentru prelucrare legală și controale pentru persoanele împuternicite? | Leagă obligațiile de confidențialitate de controlul accesului, criptografie, jurnalizare, furnizori, incidente, păstrare și controale privind dovezile |
| NIST CSF 2.0 | Cum sunt susținute rezultatele Govern, Identify, Protect, Detect, Respond și Recover prin controale implementate? | Utilizează aceeași bază de dovezi pentru a arăta acoperirea funcțională a securității cibernetice |
| COBIT 2019 și audit ISACA | Sunt definite obiectivele de guvernanță, responsabilitatea pentru controale, activitățile de asigurare, metricile și responsabilitatea managementului? | Conectează deciziile SoA la responsabili, evaluarea performanței, revizuire independentă și acțiune corectivă |
Un auditor ISO 27001 începe de obicei cu logica clauzelor: domeniu de aplicare, părți interesate, evaluarea riscurilor, tratamentul riscurilor, SoA, obiective, audit intern, revizuire de management și îmbunătățire. Un revizor orientat spre NIS2 se concentrează pe proporționalitate, responsabilitatea managementului, instruire, lanțul de aprovizionare, termenele pentru incidente și impactul asupra serviciului. Un evaluator de client orientat spre DORA se concentrează pe riscul TIC, funcții critice sau importante, incidente TIC majore, testarea rezilienței, clauze contractuale, drepturi de audit, planuri de ieșire, subcontractare și risc de concentrare. Un revizor de confidențialitate se concentrează pe responsabilitatea GDPR și pregătirea pentru încălcări. Un auditor în stil COBIT 2019 sau ISACA testează guvernanța, metricile, responsabilitatea, asigurarea și acțiunea corectivă.
De aceea, SoA nu poate fi întreținută doar de echipa de securitate. Necesită responsabilitate din partea funcțiilor juridic, confidențialitate, achiziții, inginerie, operațiuni, HR și conducerea executivă.
Eșecuri frecvente ale SoA în proiectele de pregătire NIS2 și DORA
Clarysec identifică în mod repetat aceleași probleme în proiectele de pregătire:
- SoA marchează controale ca aplicabile, dar nu este înregistrat niciun risc, nicio obligație sau niciun motiv de business.
- NIS2 și DORA sunt menționate în politici, dar nu sunt mapate la controale, responsabili sau dovezi.
- Controalele pentru furnizori sunt marcate ca implementate, dar nu există Registrul furnizorilor, rating de criticitate, revizuire contractuală sau plan de ieșire.
- Controalele privind incidentele există, dar procesul nu susține fluxuri de raportare de 24 de ore, 72 de ore, către client sau finale.
- Aprobarea managementului este implicită, dar nu există nicio înregistrare a acceptării riscului, a aprobării SoA sau a deciziei privind riscul rezidual.
- Excluderile sunt copiate dintr-un șablon și nu corespund modelului operațional real cloud, la distanță, SaaS sau fintech.
- Dovezile există în mai multe instrumente, dar nicio pistă de audit nu conectează dovezile la SoA.
- Prelucrarea datelor cu caracter personal conform GDPR nu este legată de controale de securitate, răspuns la încălcări, contracte cu furnizori sau retenție.
- Auditul intern verifică documente, dar nu testează dacă SoA reflectă implementarea reală.
- SoA este actualizată doar înainte de certificare, nu după clienți noi, furnizori noi, incidente, constatări de audit sau schimbări de reglementare.
Acestea nu sunt probleme de documentație. Sunt probleme de guvernanță.
Listă practică de verificare pentru o SoA ISO 27001 pregătită pentru audit
Utilizați această listă de verificare înaintea unui audit de certificare ISO 27001, a unei revizuiri de pregătire NIS2, a unei evaluări de client DORA, a unei ședințe a consiliului sau a unui proces de evaluare prealabilă pentru investitori.
| Punct de verificare | Răspuns bun |
|---|---|
| Domeniu de aplicare | Domeniul de aplicare al SMSI reflectă serviciile, clienții, datele, furnizorii, interfețele externalizate și dependențele reglementate |
| Părți interesate | Sunt identificate NIS2, clienții DORA, rolurile GDPR, autoritățile de reglementare, clienții, furnizorii și părțile interesate interne |
| Registru de conformitate | Obligațiile legale, de reglementare, contractuale și ale clienților sunt mapate la politici, controale și responsabili |
| Criterii de risc | Sunt incluse impacturile juridice, operaționale, de confidențialitate, asociate furnizorilor, de reziliență, financiare și reputaționale |
| Registru de riscuri | Fiecare risc include descriere, probabilitate, impact, scor, responsabil, plan de tratament și risc rezidual |
| Includere în SoA | Fiecare control aplicabil are o justificare legată de risc, obligație, domeniu de aplicare, contract sau securitate de bază |
| Excludere din SoA | Fiecare control exclus are o justificare specifică, aprobată, bazată pe dovezi și un declanșator de revizuire |
| Dovezi | Fiecare control aplicabil are dovezi de tip politică, procedură, configurație, raport, test, tichet, jurnal, revizuire sau înregistrare |
| Aprobare de management | Responsabilii de risc aprobă planurile de tratament și riscurile reziduale, iar managementul revizuiește performanța SMSI |
| Revizuire independentă | Auditul intern sau o revizuire independentă testează acuratețea SoA, calitatea dovezilor și realitatea implementării |
| Declanșatoare de actualizare | Actualizările SoA au loc după schimbări de serviciu, schimbări de furnizor, incidente, clienți noi, schimbări de reglementare sau constatări de audit |
Transformați SoA într-o punte de conformitate defensabilă
Prezentarea Elenei către consiliu a reușit deoarece nu a prezentat trei proiecte de conformitate neconectate. A prezentat un singur model operațional controlat și bazat pe dovezi, construit pe ISO/IEC 27001:2022, cu SoA ca punte între reglementare, risc, implementarea controalelor, dovezi și supravegherea managementului.
NIS2 și DORA nu fac ISO 27001 învechit. Ele fac o Declarație de aplicabilitate ISO 27001 bine construită mai valoroasă. SoA poate deveni locul unic în care organizația explică de ce există controalele, de ce excluderile sunt justificabile, cum sunt păstrate dovezile, cum sunt guvernați furnizorii, cum sunt escaladate incidentele și cum știe managementul că SMSI funcționează.
Acțiunea imediată este simplă:
- Deschideți SoA curentă.
- Alegeți cinci controale marcate ca aplicabile și întrebați: „Ce risc, obligație sau contract justifică acest lucru?”
- Alegeți cinci excluderi și întrebați: „Ar mai avea sens acest lucru pentru un auditor NIS2, DORA, GDPR sau ISO/IEC 27001:2022?”
- Verificați dacă fiecare control aplicabil are dovezi actuale.
- Confirmați că managementul a aprobat riscurile reziduale și deciziile SoA.
- Actualizați Registrul de conformitate, Registrul de riscuri și SoA ori de câte ori se schimbă serviciile, furnizorii, clienții, reglementările sau incidentele.
Clarysec ajută organizațiile să facă acest lucru prin Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, seturi de politici enterprise și SME, instrumente pentru Registrul de riscuri, șabloane SoA, pregătire pentru audit și mapare de conformitate transversală pentru NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 și asigurarea solicitată de clienți.
Dacă SoA nu poate răspunde de ce, cine răspunde pentru ea, ce dovezi o demonstrează și ce obligație susține, nu este încă pregătită. Folosiți Clarysec pentru a o transforma într-o punte de conformitate pregătită pentru audit înainte ca un organism de reglementare, auditor sau client să adreseze primul aceleași întrebări.
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
