Matricea responsabilității partajate în cloud pentru ISO, NIS2, DORA

Directorul operațional (COO) al unei companii fintech îl sună pe directorul securității informațiilor (CISO) luni, la 07:15.

Un client bancar european solicită dovezi că platforma SaaS a companiei poate îndeplini cerințele DORA privind riscul asociat terților TIC. Echipa de vânzări a trimis deja pachetul obișnuit de securitate pentru furnizori: certificatul ISO, rezumatul executiv al testului de penetrare, certificatul de asigurare cibernetică, nota de informare privind confidențialitatea și raportul de asigurare al furnizorului cloud.

Banca revine cu o întrebare mai precisă:

„Arătați-ne cine deține fiecare control din mediul vostru cloud. Voi, furnizorul vostru cloud, furnizorul bazei de date administrate, furnizorul de identitate, furnizorul de jurnalizare și orice persoană împuternicită secundară. Apoi arătați dovezile.”

Mai târziu, în aceeași dimineață, CISO are o ședință cu consiliul de administrație. CEO va pune aceeași întrebare în limbaj de business: „Suntem siguri că această platformă este securizată și cine răspunde dacă ceva nu merge bine?”

Aici se blochează multe programe de conformitate în cloud.

Organizația poate avea un furnizor cloud solid, instrumente bune, politici rezonabile și un registru de riscuri. Dar atunci când i se cere să demonstreze limitele de responsabilitate, dovezile sunt dispersate. Achizițiile au contractele. Juridicul are acordul de prelucrare a datelor. Ingineria are diagramele de arhitectură. Securitatea are jurnalele și configurațiile cloud. Confidențialitatea are lista persoanelor împuternicite secundare. Conformitatea are Declarația de aplicabilitate. Nimeni nu are un artefact controlat care să spună, control cu control, ce face furnizorul, ce trebuie să configureze clientul, ce persoană împuternicită secundară este implicată, ce clauză face obligația opozabilă și ce dovezi trebuie să se aștepte un auditor să vadă.

Acel artefact este matricea responsabilității partajate în cloud.

Nu slide-ul generic al hiperscalerului care spune că furnizorul securizează cloudul, iar clientul securizează ce se află în cloud. O matrice reală a responsabilității partajate în cloud pentru ISO/IEC 27001:2022, NIS2, DORA și GDPR este o înregistrare de guvernanță. Ea rezistă verificărilor prealabile ale clienților, unui audit ISO, unei revizuiri DORA, unei contestări privind responsabilitatea demonstrabilă în GDPR și unei investigații de incident.

De ce responsabilitatea partajată în cloud devine o problemă de audit

Modelul responsabilității partajate este prezentat de obicei ca o delimitare tehnică. În IaaS, furnizorul gestionează facilitățile fizice, hardware-ul, virtualizarea și infrastructura de bază. Clientul gestionează identitățile, datele, sarcinile de lucru, regulile de rețea, opțiunile de criptare și configurațiile. În SaaS, furnizorul preia mai multă responsabilitate operațională, dar clientul rămâne responsabil pentru accesul utilizatorilor, guvernanța datelor, temeiul juridic, configurare, așteptările de monitorizare și escaladarea incidentelor.

Această explicație este utilă, dar incompletă.

Auditorii, autoritățile de reglementare și clienții mari întreabă mai mult decât „cine operează controlul?”. Ei vor să știe:

• Cine este responsabil pentru risc?
• Ce clauză contractuală face acea responsabilitate opozabilă?
• Ce politică impune controlul?
• Ce serviciu cloud, platformă SaaS sau persoană împuternicită secundară intră în domeniul de aplicare?
• Ce dovezi demonstrează că respectivul control a funcționat în perioada revizuită?
• Ce cerință de cadru este satisfăcută de dovezi?
• Ce se întâmplă dacă furnizorul își schimbă serviciul, locația, subcontractantul sau profilul de risc al controalelor?

ISO/IEC 27001:2022 transformă acest lucru într-o problemă de sistem de management. Clauzele 4.1 până la 4.4 impun organizației să înțeleagă aspectele interne și externe, părțile interesate, obligațiile legale și contractuale, domeniul de aplicare al SMSI, interfețele și dependențele. Clauzele 6.1.1 până la 6.1.3 impun evaluarea riscurilor, tratarea riscurilor, aprobarea de către proprietarul riscului, acceptarea riscului rezidual și Declarația de aplicabilitate. Clauza 8.1 impune planificare și control operațional, inclusiv controlul proceselor, produselor și serviciilor furnizate extern care sunt relevante pentru SMSI.

Pe scurt, dacă un furnizor cloud, un furnizor SaaS sau o persoană împuternicită secundară susține un proces de business inclus în domeniul de aplicare, acesta nu poate rămâne în afara SMSI. Trebuie să fie vizibil în domeniul de aplicare, risc, tratament, control contractual și dovezi.

NIS2 ridică miza. Article 21 impune entităților esențiale și importante să implementeze măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea, securitatea lanțului de aprovizionare, achiziția securizată, dezvoltarea securizată, gestionarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor și autentificarea multifactor sau autentificarea continuă, după caz. Article 20 plasează responsabilitatea de guvernanță la nivelul organelor de conducere.

DORA este și mai explicită pentru entitățile financiare. Se aplică din 17 ianuarie 2025 și impune entităților financiare să gestioneze riscul TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale și riscul asociat terților TIC. Articles 28-30 impun managementul riscului asociat terților TIC, evaluarea preliminară a riscului de concentrare, măsuri contractuale de protecție, drepturi de audit și acces, vizibilitate asupra subcontractării, drepturi de încetare și strategii de ieșire.

GDPR adaugă testul responsabilității demonstrabile. Article 5 impune ca datele cu caracter personal să fie prelucrate cu integritate și confidențialitate, iar Article 5(2) impune operatorului să poată demonstra conformitatea. Article 28 reglementează contractele cu persoanele împuternicite și persoanele împuternicite secundare. Article 32 impune securitatea prelucrării. Articles 33 și 34 impun notificarea încălcărilor securității datelor cu caracter personal, acolo unde este aplicabil.

Matricea responsabilității partajate în cloud devine puntea dintre aceste obligații.

Definiția Clarysec: un artefact de guvernanță, nu o diagramă

În proiectele Clarysec, o matrice a responsabilității partajate în cloud este o înregistrare controlată a SMSI care leagă serviciile cloud, furnizorii, persoanele împuternicite secundare, controalele, politicile, obligațiile contractuale, dovezile și așteptările de audit.

Cea mai clară explicație apare în Zenith Blueprint Zenith Blueprint, în faza Controale în acțiune, pasul 23:

„Furnizorii cloud securizează infrastructura, dar voi rămâneți responsabili pentru datele voastre, configurațiile voastre, politicile voastre de acces și pregătirea voastră pentru răspuns la incidente.”

Același pas explică faptul că utilizarea cloudului trebuie tratată ca parte a SMSI, incluzând clasificarea serviciilor cloud, înțelegerea datelor prelucrate sau stocate, evaluarea furnizorului, clauzele contractuale și managementul modificărilor serviciilor. Astfel, responsabilitatea partajată este transformată dintr-un concept într-o structură de control trasabilă.

Zenith Controls Zenith Controls tratează controalele din Anexa A ISO/IEC 27001:2022 și îndrumările ISO/IEC 27002:2022 5.20, 5.21 și 5.23 ca ancore centrale:

• 5.20, Abordarea securității informațiilor în acordurile cu furnizorii.
• 5.21, Gestionarea securității informațiilor în lanțul de aprovizionare TIC.
• 5.23, Securitatea informațiilor pentru utilizarea serviciilor cloud.

Acestea nu sunt elemente izolate dintr-o listă de verificare. Ele definesc coloana vertebrală a matricii.

Standardele-suport pot consolida matricea. ISO/IEC 27017 ajută cu practicile de securitate specifice cloudului. ISO/IEC 27018 și ISO/IEC 27701 susțin guvernanța PII și a confidențialității. ISO/IEC 27005 susține evaluarea riscurilor. ISO 22301 susține continuitatea și reziliența. ISO/IEC 27035 susține gestionarea incidentelor. ISO/IEC 20000-1 poate ajuta acolo unde serviciile cloud fac parte din furnizarea de servicii administrate.

Matricea minimă viabilă a responsabilității partajate

O matrice matură nu începe cu 200 de rânduri. Începe cu serviciile cloud care contează cel mai mult.

Pentru un SaaS, o companie fintech sau un IMM reglementat, Clarysec începe de obicei cu:

1. Mediul cloud de producție destinat clienților.
2. Furnizorul de identitate.
3. Serviciul administrat de baze de date sau de stocare.
4. Platforma de jurnalizare, monitorizare și SIEM.
5. SaaS pentru plăți, KYC, analiză sau suport clienți.
6. Serviciul de backup și recuperare în caz de dezastru.
7. Furnizorul de servicii administrate sau furnizorul de servicii de securitate administrate.
8. Persoanele împuternicite secundare care accesează, stochează sau prelucrează date ale clienților.

Prima matrice trebuie să includă următoarele coloane.

Un rând practic privind jurnalizarea poate arăta astfel.

Acel rând nu este doar documentație. El spune securității ce să configureze, achizițiilor ce limbaj contractual să verifice, confidențialității ce flux de date să înregistreze și auditorilor ce dovezi să solicite.

Fundamentul politicilor: transformarea matricii într-o cerință opozabilă

O matrice a responsabilității partajate în cloud fără susținere prin politici este doar o foaie de calcul. Politicile Clarysec o fac opozabilă.

Pentru IMM-uri, Cloud Usage Policy - SME Politica de utilizare a serviciilor cloud - IMM, secțiunea „Cerințe de guvernanță”, clauza 5.3 impune:

„Un registru al serviciilor cloud trebuie menținut de furnizorul IT sau de directorul general (GM). Acesta trebuie să înregistreze:”

Aceeași politică pentru IMM-uri, clauza 5.2.3, corelează guvernanța cloud cu riscul privind confidențialitatea și locația:

„Rezidența datelor și practicile de confidențialitate respectă cerințele legale aplicabile (de exemplu, GDPR)”

Pentru mediile organizaționale mari, Cloud Usage Policy Politica de utilizare a serviciilor cloud, secțiunea „Cerințe de guvernanță”, clauza 5.1 prevede:

„Organizația trebuie să mențină un registru centralizat al serviciilor cloud, deținut de CISO, care conține:”

Clauza 5.4 face apoi responsabilitățile cloud opozabile contractual:

„Toate contractele CSP (Cloud Service Provider) trebuie să includă prevederi opozabile pentru:”

Guvernanța furnizorilor extinde matricea dincolo de furnizorul imediat. Third-Party and Supplier Security Policy - SME Politica de securitate privind terții și furnizorii - IMM, secțiunea „Cerințe de guvernanță”, clauza 5.3.5 impune:

„Restricții privind subcontractarea ulterioară fără aprobare”

Aceeași politică pentru furnizori destinată IMM-urilor, secțiunea „Cerințe de implementare a politicii”, clauza 6.3.1 adaugă revizuirea periodică:

„Furnizorii critici sau cu risc ridicat trebuie revizuiți cel puțin anual. Revizuirea trebuie să verifice:”

La nivelul organizațiilor mari, Third party and supplier security policy Politica de securitate privind terții și furnizorii, secțiunea „Cerințe de guvernanță”, clauza 5.3 prevede:

„Contractele cu furnizorii trebuie să includă:”

Pentru datele cu caracter personal, Data Protection and Privacy Policy Politica de protecție a datelor și confidențialitate, secțiunea „Aplicare și conformitate”, clauza 8.5.1 impune:

„Contractele cu persoanele împuternicite trebuie să includă:”

Pentru vizibilitatea dependențelor, Supplier Dependency Risk Management Policy Politica de management al riscului de dependență față de furnizori, clauza 6.5.4 impune:

„Valorificarea relației cu furnizorul pentru a obține actualizări privind subcontractanții sau dependențele din lanțul de aprovizionare cu un nivel în aval, acolo unde acestea ne-ar putea afecta (de exemplu, dacă un furnizor critic de software se bazează semnificativ pe o bibliotecă terță, acest lucru trebuie înregistrat).”

Pentru jurnale, Logging and Monitoring Policy - SME Politica de jurnalizare și monitorizare - IMM, secțiunea „Cerințe de guvernanță”, clauza 5.5.1.3 oferă o cerință contractuală concretă:

„Contractele trebuie să impună furnizorilor să păstreze jurnalele cel puțin 12 luni și să ofere acces la cerere”

Împreună, aceste politici transformă matricea într-o înregistrare de guvernanță obligatorie, care susține aprobarea furnizorilor, adoptarea serviciilor cloud, responsabilitatea demonstrabilă privind confidențialitatea, revizuirea anuală și dovezile de audit.

Maparea matricii la ISO/IEC 27001:2022, NIS2, DORA și GDPR

Greșeala clasică este crearea a patru registre separate de conformitate. Un singur control poate satisface mai multe obligații dacă responsabilitatea și dovezile sunt trasabile.

ISO/IEC 27001:2022 furnizează motorul SMSI: context, părți interesate, domeniu de aplicare, leadership, tratarea riscurilor, obiective, control operațional, evaluarea performanței și îmbunătățire. Anexa A oferă structura practică de control.

NIS2 Article 21 se mapează natural la aceeași matrice prin securitatea lanțului de aprovizionare, gestionarea incidentelor, continuitate, control al accesului, managementul activelor și achiziție securizată. Article 20 face matricea relevantă pentru consiliul de administrație, deoarece organele de conducere trebuie să aprobe și să supravegheze măsurile de management al riscurilor de securitate cibernetică.

DORA transformă matricea într-un instrument de risc asociat terților TIC. Articles 5, 6 și 8 impun guvernanță, management documentat al riscurilor TIC și identificarea activelor, funcțiilor și dependențelor. Articles 17-19 impun detectarea incidentelor, clasificarea, escaladarea, comunicarea și raportarea. Articles 28-30 impun managementul riscurilor asociate terților, analiza riscului de concentrare, clauze contractuale, controale de subcontractare, drepturi de audit, drepturi de încetare și strategii de ieșire.

GDPR contribuie cu perspectiva datelor cu caracter personal. Fiecare rând aferent unui serviciu cloud trebuie să identifice dacă sunt prelucrate date cu caracter personal, dacă furnizorul este persoană împuternicită sau persoană împuternicită secundară, dacă locația datelor contează și ce contract sau dovezi DPA există.

NIST CSF 2.0 ajută la comunicarea aceleiași matrici în limbaj de rezultate. Funcția GOVERN acoperă contextul organizațional, cerințele legale și de reglementare, dependențele, managementul riscurilor, rolurile, politicile și supravegherea. Rezultatele GV.SC sunt deosebit de utile pentru riscul cibernetic asociat furnizorilor, inclusiv rolurile furnizorilor, criticitatea, cerințele contractuale, verificările prealabile, monitorizarea, coordonarea incidentelor și planificarea încetării.

COBIT 2019 adaugă o perspectivă de asigurare și guvernanță. Acesta întreabă dacă responsabilitatea, practicile de management, deținerea, monitorizarea și remedierea problemelor sunt repetabile și susținute prin dovezi.

Construirea matricii de la registru la dovadă

Imaginați-vă o companie SaaS care utilizează o platformă IaaS de tip hiperscaler, o bază de date administrată, un furnizor terț de identitate, o platformă SaaS de suport clienți și un SIEM extern. Fluxul de implementare este direct.

Pasul 1: începeți cu registrul serviciilor cloud

Utilizați Cloud Usage Policy sau Cloud Usage Policy - SME ca factor declanșator. Înregistrați fiecare serviciu cloud, proprietarul, scopul, categoriile de date, locația, funcția de business, nivelul furnizorului, proprietarul contractului și data revizuirii.

Dacă serviciul stochează înregistrări despre clienți, jurnale de autentificare sau tichete de suport, marcați-l ca relevant pentru confidențialitate. Dacă susține disponibilitatea în producție, marcați-l ca operațional critic. Dacă susține o funcție critică sau importantă a unui client financiar, marcați-l ca relevant pentru DORA.

Pasul 2: adăugați domenii de responsabilitate partajată

Pentru fiecare serviciu, definiți responsabilitățile în domeniile de bază.

Pasul 3: legați controalele de risc și de Declarația de aplicabilitate

Zenith Blueprint, faza Managementul riscurilor, pasul 13, explică cerința de trasabilitate:

„Faceți referințe încrucișate la reglementări: dacă anumite controale sunt implementate special pentru a respecta GDPR, NIS2 sau DORA, puteți nota acest lucru fie în registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.”

De exemplu, riscul „acces neautorizat la datele de producție ale clienților prin configurare greșită în cloud” se poate mapa la controlul accesului, utilizarea cloudului, jurnalizare, criptografie, managementul vulnerabilităților și acorduri cu furnizorii. SoA poate face trimitere la Anexa A ISO/IEC 27001:2022 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 și 8.24, cu note pentru GDPR Article 32, NIS2 Article 21 și managementul riscurilor TIC DORA, acolo unde este aplicabil.

Pasul 4: atașați dovezile înainte de sezonul de audit

Dovezile trebuie proiectate în matrice, nu colectate în panică.

Lista de dovezi transformă responsabilitatea în probă verificabilă. De asemenea, ajută echipele comerciale să răspundă mai rapid la verificările prealabile ale clienților mari, deoarece pot arăta nu doar certificări, ci și deținerea controalelor și dovezi operaționale.

Persoanele împuternicite secundare: punctul orb al celor mai multe matrici

Persoanele împuternicite secundare sunt locul în care responsabilitatea partajată devine risc real de lanț de aprovizionare.

Un furnizor SaaS poate fi persoana voastră împuternicită în sensul GDPR. Acest furnizor se poate baza pe un furnizor de găzduire cloud, CDN, serviciu de analiză, platformă de suport, serviciu de livrare e-mail, bază de date administrată, furnizor de observabilitate și procesator de plăți. Unele pot accesa date cu caracter personal. Altele pot susține livrarea unui serviciu critic fără a vedea direct datele. Unele pot fi în afara UE. Unele pot fi înlocuibile. Altele pot crea risc de concentrare.

DORA Article 29 impune evaluarea riscului de concentrare pentru servicii TIC critice sau importante, incluzând substituibilitatea, aranjamentele multiple cu aceiași furnizori sau furnizori conectați, lanțurile de subcontractare, subcontractanții din țări terțe, legislația privind insolvența, constrângerile privind recuperarea datelor și caracterul opozabil al protecției datelor în Uniune. DORA Article 30 impune prevederi contractuale privind condițiile de subcontractare, locațiile, prelucrarea și stocarea datelor, accesul și recuperarea, asistența în caz de incident, cooperarea cu autoritățile, drepturile de audit, încetarea și ieșirea.

NIS2 Article 21 impune în mod similar securitatea lanțului de aprovizionare pentru furnizorii direcți și furnizorii de servicii, plus luarea în considerare a vulnerabilităților specifice furnizorilor, a practicilor de securitate cibernetică ale furnizorilor și a procedurilor de dezvoltare securizată.

De aceea, Clarysec tratează maparea persoanelor împuternicite secundare ca o extensie obligatorie a guvernanței furnizorilor, nu ca o listă exclusiv pentru confidențialitate. Registrul persoanelor împuternicite secundare trebuie să arate ce furnizor utilizează persoana împuternicită secundară, de ce serviciu depinde aceasta, dacă sunt prelucrate date cu caracter personal, dacă susține o funcție critică, regiunea de prelucrare acolo unde este relevant, obligațiile transmise în lanț, drepturile de aprobare sau opoziție, asigurarea disponibilă, metoda de monitorizare și opțiunea de ieșire.

Zenith Blueprint, faza Controale în acțiune, pasul 23, afirmă:

„Pentru fiecare furnizor critic, identificați dacă utilizează subcontractanți (persoane împuternicite secundare) care pot accesa datele sau sistemele voastre. Documentați modul în care cerințele voastre de securitate a informațiilor sunt transmise acestor părți, fie prin termenii contractuali ai furnizorului, fie prin propriile clauze directe.”

Acesta este nivelul de dovadă pe care auditorii îl așteaptă atunci când întreabă dacă responsabilitățile cloud sunt controlate în aval.

Cum testează auditorii aceeași matrice

O matrice solidă a responsabilității partajate în cloud rezistă mai multor stiluri de audit deoarece este construită în jurul deținerii, opozabilității și dovezilor.

Matricea nu este obiectivul final. Este harta pe care auditorii o folosesc pentru a testa dacă sistemul de guvernanță este real.

Un auditor ISO poate selecta un risc de acces cloud cu impact ridicat și îl poate urmări din registrul de riscuri către SoA, apoi către revizuiri ale drepturilor de acces, dovezi MFA și alerte de monitorizare. Un evaluator DORA poate selecta un furnizor TIC critic și poate solicita testul de ieșire, analiza subcontractării și drepturile contractuale de audit. Un revizor GDPR se poate concentra pe ștergere, rezidența datelor, notificarea încălcării și transparența persoanelor împuternicite secundare.

Tipare comune de eșec

Cele mai frecvente eșecuri ale responsabilității partajate nu sunt exotice.

În primul rând, organizațiile se bazează pe rapoartele de asigurare ale furnizorilor fără să le mapeze la responsabilitățile clientului. Un furnizor cloud poate demonstra securitatea fizică, reziliența infrastructurii și controalele platformei, dar nu și faptul că bucketul vostru de stocare era privat, că rolurile IAM respectau principiul privilegiului minim sau că jurnalele erau activate.

În al doilea rând, contractele conțin limbaj generic de securitate, dar nu termene privind incidentele, drepturi de acces la jurnale, drepturi de audit, limite de subcontractare, prevederi de returnare a datelor sau suport pentru ieșire. Zenith Blueprint, faza Controale în acțiune, pasul 23, evidențiază arii tipice ale acordurilor cu furnizorii, precum confidențialitatea, controlul accesului, măsuri tehnice și organizatorice, termene privind incidentele, dreptul de audit, controalele subcontractanților și prevederile de final de contract.

În al treilea rând, persoanele împuternicite secundare sunt listate în scopuri de confidențialitate, dar nu sunt legate de securitate, continuitate sau risc de concentrare. Un furnizor din aval de observabilitate sau suport poate să nu apară niciodată în registrul de riscuri, deși indisponibilitatea sau încălcarea securității la acesta ar putea afecta furnizarea serviciului către clienți.

În al patrulea rând, SoA spune că un control este aplicabil, dar nimeni nu poate produce dovezi operaționale. Jurnalizarea cloud poate fi marcată ca implementată, dar organizația nu poate demonstra setările de retenție, revizuirile drepturilor de acces, gestionarea alertelor sau angajamentele furnizorului privind accesul la jurnale.

În al cincilea rând, planurile de răspuns la incidente nu reflectă dependența de furnizor. Dacă furnizorul notifică un incident de platformă, cine evaluează impactul asupra clienților? Cine stabilește dacă este necesară notificarea conform NIS2, DORA sau GDPR? Cine contactează clienții afectați? Ce se întâmplă dacă analiza cauzei principale indică o persoană împuternicită secundară?

Responsabilitatea managementului: de ce trebuie să îi pese consiliului

NIS2 Article 20 impune organelor de conducere să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să beneficieze de instruire. DORA Article 5 impune organului de conducere să definească, să aprobe, să supravegheze și să fie responsabil pentru aranjamentele de management al riscurilor TIC, inclusiv politicile privind terții TIC, planurile de continuitate și recuperare, planurile de audit, instruirea și canalele de raportare.

Acest lucru schimbă scopul matricii. Nu mai este doar o foaie de lucru de securitate. Devine dovada că managementul știe:

• Ce servicii cloud susțin operațiunile critice.
• Ce terți și persoane împuternicite secundare sunt semnificative.
• Ce obligații se aplică în temeiul contractelor cu clienții, GDPR, NIS2 și DORA.
• Ce responsabilități sunt păstrate de organizație.
• Ce angajamente ale furnizorului sunt opozabile contractual.
• Ce lacune necesită finanțare, remediere sau acceptarea riscului.

Pentru IMM-uri, proporționalitatea contează. O entitate mai mică nu are nevoie de o birocrație greoaie, dar are totuși nevoie de documentație, monitorizare, sisteme reziliente, detectarea surselor de risc TIC, identificarea dependențelor-cheie de terți, măsuri de continuitate, testare, lecții învățate și revizuire periodică acolo unde intră în domeniul de aplicare.

Matricea este unul dintre cele mai eficiente instrumente proporționale, deoarece consolidează obligațiile în loc să le multiplice.

Un sprint de 30 de zile pentru a vă pregăti modelul cloud pentru audit

Dacă nu puteți răspunde cine deține fiecare control cloud, ce dovezi îl demonstrează și ce persoană împuternicită secundară l-ar putea afecta, modelul vostru de responsabilitate partajată este încă o diagramă, nu un artefact de guvernanță.

Un sprint practic de 30 de zile arată astfel:

1. Creați sau actualizați registrul serviciilor cloud folosind Cloud Usage Policy sau Cloud Usage Policy - SME.
2. Identificați serviciile critice, prelucrarea datelor cu caracter personal, sistemele destinate clienților și relevanța DORA sau NIS2.
3. Construiți prima matrice în jurul controalelor din Anexa A ISO/IEC 27001:2022 5.20, 5.21 și 5.23 folosind Zenith Controls.
4. Legați fiecare rând de registrul de riscuri și Declarația de aplicabilitate folosind pasul 13 din Zenith Blueprint.
5. Validați clauzele pentru furnizori și persoane împuternicite folosind Third party and supplier security policy, Third-Party and Supplier Security Policy - SME și Data Protection and Privacy Policy.
6. Adăugați dovezi privind retenția jurnalelor, escaladarea incidentelor, aprobarea persoanelor împuternicite secundare, drepturile de audit și ieșirea.
7. Revizuiți anual furnizorii critici și după modificări majore, incidente, persoane împuternicite secundare noi sau constatări de audit.

Obiectivul este simplu. Când clientul, auditorul, autoritatea de reglementare sau consiliul întreabă „cine deține acest control?”, nu căutați prin contracte, tichete și foldere. Deschideți matricea, arătați proprietarul, arătați clauza, arătați dovezile și arătați trasabilitatea în aval.

Clarysec vă poate ajuta să transformați pachetele de asigurare ale furnizorilor cloud într-o matrice integrată a responsabilității partajate pentru audituri ISO/IEC 27001:2022, pregătirea NIS2, riscul asociat terților TIC în DORA, responsabilitatea demonstrabilă în GDPR și verificările prealabile ale clienților mari.

Începeți cu registrul. Construiți matricea. Atașați dovezile. Apoi utilizați-o ca dovadă pregătită pentru consiliu că riscul cloud nu este externalizat, ci guvernat.