Dovezi pentru TOMs prevăzute de GDPR Article 32, corelate cu ISO, NIS2 și DORA

E-mailul ajunge în căsuța poștală a CISO cu greutatea familiară a unei oportunități care poate schimba trimestrul companiei.

Un prospect enterprise important solicită dovezi privind „măsurile tehnice și organizatorice prevăzute de GDPR Article 32, mapate la ISO 27001:2022, NIS2 și DORA, acolo unde este aplicabil”. În același timp, departamentul juridic a informat consiliul de administrație cu privire la răspunderea conducerii în temeiul NIS2 și la așteptările DORA privind reziliența operațională. Instrucțiunea consiliului pare simplă: demonstrați conformitatea, evitați munca duplicată și nu transformați acest demers în trei proiecte separate.

Compania are controale. MFA este activată. Backup-urile rulează. Dezvoltatorii revizuiesc codul. Echipa de confidențialitate menține evidența activităților de prelucrare. Echipa de infrastructură scanează vulnerabilitățile. Furnizorii sunt revizuiți în etapa de achiziție. Dar atunci când prospectul cere dovezi, răspunsul se fragmentează.

Raportul furnizorului de identitate se află într-un loc. Jurnalele de backup sunt în alt loc. Registrul riscurilor nu a mai fost actualizat de la ultima lansare de produs. Dovezile de securitate ale furnizorilor se află în e-mailurile de achiziții. Există note din exerciții tabletop de răspuns la incidente, dar nimeni nu poate demonstra că lecțiile învățate au fost integrate în tratamentul riscurilor. Consiliul de administrație a aprobat bugetul de securitate, dar aprobarea nu este legată de un risc TIC sau de o decizie documentată privind un control.

Aceasta este problema reală a măsurilor tehnice și organizatorice prevăzute de GDPR Article 32, denumite în mod obișnuit TOMs. Majoritatea organizațiilor nu eșuează pentru că nu au controale. Eșuează pentru că nu pot demonstra că respectivele controale sunt bazate pe risc, aprobate, implementate, monitorizate și îmbunătățite.

Responsabilitatea prevăzută de GDPR face această așteptare explicită. GDPR Article 5 impune ca datele cu caracter personal să fie protejate printr-un nivel adecvat de securitate împotriva prelucrării neautorizate sau ilegale și împotriva pierderii, distrugerii sau deteriorării accidentale. Article 5(2) stabilește responsabilitatea operatorului de date de a demonstra conformitatea. Definițiile din GDPR contează, de asemenea. Datele cu caracter personal au o sferă largă, prelucrarea acoperă aproape orice operațiune asupra datelor, pseudonimizarea este o măsură de protecție recunoscută, iar o încălcare a securității datelor cu caracter personal include distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat, accidental sau ilegal.

Prin urmare, un dosar de dovezi pentru Article 32 nu poate fi un folder cu capturi de ecran aleatorii. Trebuie să fie un sistem viu de control.

Abordarea Clarysec transformă TOMs prevăzute de GDPR Article 32 într-un motor de dovezi trasabil, construit pe ISO/IEC 27001:2022 ISO/IEC 27001:2022, consolidat prin managementul riscurilor conform ISO/IEC 27005:2022 și corelat cu obligațiile NIS2 și DORA acolo unde acestea se aplică. Scopul nu este documentația de dragul documentației. Scopul este ca organizația să fie pregătită pentru audit înainte ca un client, auditor, autoritate de reglementare sau membru al consiliului să adreseze întrebarea dificilă.

De ce TOMs prevăzute de GDPR Article 32 eșuează în practică

Article 32 este adesea înțeles greșit ca o listă de instrumente de securitate: criptare, backup-uri, jurnalizare, controlul accesului și răspuns la incidente. Aceste măsuri contează, dar sunt defensabile numai atunci când sunt adecvate riscului și conectate la ciclul de viață al datelor cu caracter personal.

Pentru o companie SaaS care prelucrează date despre angajații clienților, „folosim criptare” nu este suficient. Un auditor poate întreba ce date protejează criptarea, unde este obligatorie criptarea, cum sunt gestionate cheile, dacă backup-urile sunt criptate, dacă datele de producție sunt mascate în testare, cine poate ocoli controalele și cum sunt aprobate excepțiile.

Politica enterprise de protecție a datelor și confidențialitate a Clarysec surprinde principiul operațional:

„Implementarea măsurilor tehnice și organizatorice (TOMs) care protejează confidențialitatea, integritatea și disponibilitatea informațiilor de identificare personală (PII) pe întregul lor ciclu de viață.”

Sursa: Politica de protecție a datelor și confidențialitate, Obiective, clauza de politică 3.3. Politica de protecție a datelor și confidențialitate

Formularea „pe întregul lor ciclu de viață” este locul în care multe programe TOMs devin vulnerabile. Datele cu caracter personal pot fi protejate în producție, dar copiate în sisteme de analiză, jurnale, exporturi de suport, medii de testare, backup-uri, platforme ale furnizorilor și dispozitive ale angajaților. Fiecare locație creează risc de securitate și confidențialitate.

GDPR Article 6 impune existența unui temei juridic pentru prelucrare, inclusiv consimțământ, contract, obligație legală, interese vitale, sarcină publică sau interese legitime. Atunci când datele sunt reutilizate pentru un scop ulterior, trebuie analizate compatibilitatea și măsurile de protecție, precum criptarea sau pseudonimizarea. Pentru date cu risc mai ridicat, sarcina probatorie crește. GDPR Article 9 impune limite stricte pentru categoriile speciale de date cu caracter personal, precum datele privind sănătatea, datele biometrice utilizate pentru identificare și alte informații sensibile. Article 10 restricționează datele privind condamnările penale și infracțiunile.

Pentru IMM-uri, Clarysec exprimă tratamentul riscurilor în termeni practici:

„Controalele trebuie implementate pentru a reduce riscurile identificate, inclusiv criptarea, anonimizarea, eliminarea securizată și restricțiile de acces”

Sursa: Politica de protecție a datelor și confidențialitate - IMM, Tratamentul riscurilor și excepții, clauza de politică 7.2.1. Politica de protecție a datelor și confidențialitate - IMM

Aceasta este o bază solidă pentru TOMs. Pentru a deveni pregătit pentru audit, fiecare control trebuie legat și de un risc, un responsabil, o cerință de politică, un element de dovadă și o cadență de revizuire.

ISO 27001:2022 este coloana vertebrală a dovezilor pentru Article 32

ISO 27001:2022 funcționează foarte bine pentru GDPR Article 32 deoarece tratează securitatea ca pe un sistem de management, nu ca pe o listă de verificare cu controale izolate. Standardul impune un Sistem de management al securității informației, sau SMSI, proiectat pentru a păstra confidențialitatea, integritatea și disponibilitatea prin managementul riscurilor.

Primul pas critic este domeniul de aplicare. Clauzele ISO 27001:2022 4.1 până la 4.4 solicită organizației să înțeleagă aspectele interne și externe, să identifice părțile interesate și cerințele acestora, să stabilească ce cerințe vor fi abordate prin SMSI și să definească domeniul de aplicare al SMSI, inclusiv interfețele și dependențele cu organizațiile externe. Pentru TOMs prevăzute de Article 32, domeniul de aplicare al SMSI ar trebui să reflecte prelucrarea datelor cu caracter personal, obligațiile față de clienți, persoanele împuternicite, persoanele subîmputernicite, platformele cloud, telemunca, funcțiile de suport și mediile de produs.

Al doilea pas este leadershipul. Clauzele 5.1 până la 5.3 impun angajamentul conducerii de vârf, o Politică de securitate a informației, resurse, roluri și responsabilități, precum și raportarea performanței. Acest aspect contează deoarece GDPR Article 32, NIS2 și DORA se bazează pe guvernanță. Un control fără responsabil, finanțare sau revizuire reprezintă o dovadă slabă.

Politica enterprise de securitate a informației a Clarysec formulează explicit acest lucru:

„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).”

Sursa: Politica de securitate a informației, Cerințe de implementare a politicii, clauza de politică 6.1.2. Politica de securitate a informației

Aceeași politică stabilește așteptarea privind dovezile:

„Toate controalele implementate trebuie să fie verificabile, susținute de proceduri documentate și de dovezi păstrate privind funcționarea lor.”

Sursa: Politica de securitate a informației, Cerințe de implementare a politicii, clauza de politică 6.6.1.

Clauzele ISO 27001:2022 6.1.1 până la 6.1.3 impun apoi evaluarea riscurilor, tratamentul riscurilor, o Declarație de aplicabilitate, aprobarea riscului rezidual și responsabilitatea proprietarului de risc. Clauza 6.2 impune obiective măsurabile. Clauzele 7.5, 9.1, 9.2, 9.3 și 10.2 impun informații documentate, monitorizare, audit intern, analiză efectuată de management și acțiune corectivă.

Pentru GDPR Article 32, aceasta creează o structură defensabilă.

ISO/IEC 27005:2022 consolidează această structură. Acesta recomandă organizațiilor să identifice cerințe din ISO 27001:2022 Annex A, reglementări, contracte, standarde sectoriale, reguli interne și controale existente, apoi să le includă în evaluarea riscurilor și tratamentul riscurilor. De asemenea, impune criterii de risc și criterii de acceptare care iau în considerare factori juridici, de reglementare, operaționali, de furnizor, tehnologici și umani, inclusiv confidențialitatea.

Politica de management al riscurilor a Clarysec este aliniată direct:

„Un proces formal de management al riscurilor trebuie menținut în conformitate cu ISO/IEC 27005 și ISO 31000, acoperind identificarea, analiza, evaluarea, tratamentul, monitorizarea și comunicarea riscurilor.”

Sursa: Politica de management al riscurilor, Cerințe de guvernanță, clauza de politică 5.1. Politica de management al riscurilor

Pentru IMM-uri, aceeași cerință devine simplă și aplicabilă:

„Fiecare intrare de risc trebuie să includă: descriere, probabilitate, impact, scor, proprietar și plan de tratament.”

Sursa: Politica de management al riscurilor - IMM, Cerințe de guvernanță, clauza de politică 5.1.2. Politica de management al riscurilor - IMM

Această propoziție este un test rapid de pregătire pentru audit. Dacă un risc nu are proprietar sau plan de tratament, nu este încă un risc care poate fi susținut prin dovezi.

Puntea Clarysec: risc, SoA, controale și reglementări

Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori a Clarysec Zenith Blueprint tratează conformitatea ca activitate de trasabilitate. În faza de management al riscurilor, Pasul 13 se concentrează pe planificarea tratamentului riscurilor și pe Declarația de aplicabilitate. Acesta explică faptul că organizațiile ar trebui să mapeze controalele la riscuri, să adauge referințe la controalele Annex A în intrările de tratament al riscurilor, să coreleze reglementările externe și să obțină aprobarea managementului.

Zenith Blueprint este direct cu privire la rolul SoA:

„SoA este, în fapt, un document-punte: leagă evaluarea/tratamentul riscurilor de controalele efective pe care le aveți. Prin completarea lui, verificați în același timp dacă ați omis vreun control.”

Sursa: Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori, faza Managementul riscurilor, Pasul 13: Planificarea tratamentului riscurilor și Declarație de aplicabilitate (SoA). Zenith Blueprint

Pasul 14 din Zenith Blueprint adaugă stratul de corelare cu reglementările. Acesta recomandă organizațiilor să documenteze modul în care cerințele GDPR, NIS2 și DORA sunt acoperite de politici și controale. Pentru GDPR, accentuează protecția datelor cu caracter personal în evaluările și tratamentele riscurilor, inclusiv criptarea ca măsură tehnică și răspunsul la încălcări ca parte a mediului de control. Pentru NIS2, evidențiază evaluarea riscurilor, securitatea rețelei, controlul accesului, gestionarea incidentelor și continuitatea activității. Pentru DORA, indică managementul riscurilor TIC, răspunsul la incidente, raportarea și supravegherea riscurilor asociate terților TIC.

Acesta este nucleul metodei Clarysec: un singur SMSI, un singur registru al riscurilor, o singură SoA, o singură bibliotecă de dovezi, rezultate multiple de conformitate.

Zenith Controls: ghidul de conformitate încrucișată Zenith Controls susține acest demers ajutând organizațiile să utilizeze temele de control din ISO/IEC 27002:2022 ISO/IEC 27002:2022 ca ancore de conformitate încrucișată. Pentru GDPR Article 32, cele mai importante ancore includ frecvent protecția confidențialității și a PII, controlul 5.34; revizuirea independentă a securității informației, controlul 5.35; și utilizarea criptografiei, controlul 8.24.

NIS2 transformă TOMs într-o problemă de securitate cibernetică la nivelul consiliului

Multe organizații tratează TOMs prevăzute de GDPR ca responsabilitate a echipei de confidențialitate. NIS2 schimbă conversația.

NIS2 se aplică multor entități mijlocii și mari din sectoarele enumerate și, în unele cazuri, indiferent de dimensiune. Sectoarele digitale și tehnologice acoperite includ furnizorii de servicii de cloud computing, furnizorii de centre de date, rețelele de livrare de conținut, furnizorii de servicii DNS, registrele TLD, furnizorii de servicii de încredere, furnizorii publici de comunicații electronice, furnizorii de servicii administrate, furnizorii de servicii de securitate administrate, piețele online, motoarele de căutare și platformele de rețele sociale. Aplicabilitatea pentru SaaS și IMM-uri tehnologice depinde de sector, dimensiune, desemnarea de către statul membru și impactul sistemic sau transfrontalier.

NIS2 Article 20 plasează responsabilitatea privind securitatea cibernetică asupra organelor de conducere. Acestea trebuie să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire. Entitățile esențiale pot primi amenzi administrative de cel puțin 10 milioane EUR sau cel puțin 2% din cifra de afaceri anuală mondială. Entitățile importante pot primi amenzi de cel puțin 7 milioane EUR sau cel puțin 1,4%.

NIS2 Article 21 este direct relevant pentru TOMs prevăzute de Article 32 deoarece impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale. Aceste măsuri trebuie să ia în considerare stadiul actual al tehnologiei, standardele europene și internaționale, costul, expunerea, dimensiunea, probabilitatea, severitatea și impactul societal sau economic. Domeniile obligatorii includ analiza riscului, politici de securitate, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și dezvoltarea securizate, managementul vulnerabilităților, evaluarea eficacității, igiena cibernetică, instruirea, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor, MFA sau autentificare continuă și comunicații securizate, acolo unde este adecvat.

NIS2 Article 23 adaugă raportarea etapizată a incidentelor: avertizare timpurie în termen de 24 de ore, notificarea incidentului în termen de 72 de ore, actualizări intermediare la cerere și un raport final în cel mult o lună de la notificarea de 72 de ore. Dacă o încălcare a securității datelor cu caracter personal se califică și drept incident semnificativ NIS2, dosarul de dovezi trebuie să susțină atât deciziile de raportare privind confidențialitatea, cât și pe cele de securitate cibernetică.

DORA ridică standardul pentru reziliența financiară și furnizorii TIC

DORA se aplică din 17 ianuarie 2025 și creează un cadru normativ sectorial financiar pentru reziliența operațională digitală. Acesta acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale, schimbul de informații privind amenințările cibernetice și vulnerabilitățile, riscul asociat terților TIC, cerințele contractuale pentru furnizorii TIC, supravegherea furnizorilor terți critici de servicii TIC și supravegherea.

Pentru entitățile financiare identificate și în temeiul normelor naționale NIS2, DORA funcționează ca act juridic sectorial al Uniunii pentru obligațiile suprapuse de management al riscurilor de securitate cibernetică și raportare a incidentelor. În practică, entitățile financiare acoperite ar trebui să prioritizeze DORA pentru aceste domenii suprapuse, menținând în același timp coordonarea cu autoritățile competente NIS2 și CSIRT-urile relevante.

Pentru dovezile privind GDPR Article 32, DORA contează în două moduri. În primul rând, companiile fintech pot intra direct în domeniul de aplicare ca entități financiare, inclusiv instituții de credit, instituții de plată, furnizori de servicii de informare cu privire la conturi, instituții emitente de monedă electronică, firme de investiții, furnizori de servicii privind criptoactivele, locuri de tranzacționare și furnizori de servicii de finanțare participativă. În al doilea rând, furnizorii SaaS, cloud, de date, software și servicii administrate pot fi tratați de clienții financiari ca furnizori terți de servicii TIC, deoarece DORA definește serviciile TIC în sens larg.

DORA Article 5 impune guvernanță și controale interne pentru managementul riscurilor TIC, organismul de conducere definind, aprobând, supraveghind și rămânând responsabil pentru cadrul de risc TIC. Article 6 impune un cadru documentat de management al riscurilor TIC, incluzând strategii, politici, proceduri, protocoale și instrumente TIC pentru protejarea informațiilor și a activelor TIC. Article 17 impune un proces de management al incidentelor legate de TIC care acoperă detecția, gestionarea, notificarea, înregistrarea, cauza rădăcină, indicatorii de avertizare timpurie, clasificarea, rolurile, comunicările, escaladarea și răspunsul. Article 19 impune raportarea incidentelor majore legate de TIC către autoritățile competente.

DORA Articles 28 și 30 transformă riscul asociat terților TIC într-un domeniu de control reglementat. Entitățile financiare rămân responsabile pentru conformitate atunci când utilizează servicii TIC. Acestea au nevoie de o strategie pentru riscul asociat terților, registre contractuale, evaluări de criticitate, verificare prealabilă, revizuirea riscului de concentrare, drepturi de audit și inspecție, declanșatori de încetare, strategii de ieșire și prevederi contractuale care acoperă locațiile datelor, disponibilitatea, autenticitatea, integritatea, confidențialitatea, asistența în caz de incident, recuperarea, nivelurile de serviciu și cooperarea cu autoritățile.

Pentru Article 32, aceasta înseamnă că furnizorii fac parte din dosarul TOMs. Nu puteți demonstra securitatea prelucrării dacă persoanele împuternicite critice, platformele cloud, furnizorii de analiză, instrumentele de suport și furnizorii TIC nu sunt controlați.

Construirea practică, într-o săptămână, a dovezilor pentru Article 32

Un dosar solid de dovezi începe cu un scenariu de risc clar.

Folosiți acest exemplu: „Acces neautorizat la datele cu caracter personal ale clienților în aplicația de producție.”

Creați sau actualizați intrarea de risc. Includeți descriere, probabilitate, impact, scor, proprietar și plan de tratament. Atribuiți responsabilitatea către Head of Engineering, Managerul securității sau un rol responsabil echivalent. Evaluați probabilitatea pe baza modelului de acces, a suprafeței de atac expuse, a vulnerabilităților cunoscute și a incidentelor anterioare. Evaluați impactul pe baza volumului datelor cu caracter personal, sensibilității, contractelor cu clienții, consecințelor GDPR și posibilului impact asupra serviciului în NIS2 sau DORA.

Selectați tratamente precum MFA pentru acces privilegiat, controale de acces bazate pe roluri, revizuiri trimestriale ale accesului, criptare în repaus, TLS, scanarea vulnerabilităților, jurnalizare, alertare, backup securizat, proceduri de răspuns la incidente și mascarea datelor în medii care nu sunt de producție.

Apoi mapați riscul la SoA. Adăugați referințe ISO/IEC 27002:2022 precum 5.34 protecția confidențialității și a PII, 8.24 utilizarea criptografiei, 5.15 controlul accesului, 5.18 drepturi de acces, 8.13 backup-ul informațiilor, 8.15 jurnalizare, 8.16 activități de monitorizare, 8.8 managementul vulnerabilităților tehnice, 8.25 ciclul de viață al dezvoltării securizate și 8.10 ștergerea informațiilor, acolo unde este aplicabil. Adăugați note care arată cum aceste controale susțin GDPR Article 32, NIS2 Article 21 și managementul riscurilor TIC conform DORA, acolo unde este relevant.

Pentru maparea de reglementare, păstrați denumirile controalelor exacte și evitați echivalențele forțate.

Construiți acum folderul de dovezi. Politica IMM de audit și monitorizare a conformității a Clarysec oferă o regulă simplă:

„Toate dovezile trebuie stocate într-un folder centralizat de audit.”

Sursa: Politica de audit și monitorizare a conformității - IMM, Cerințe de implementare a politicii, clauza de politică 6.2.1. Politica de audit și monitorizare a conformității - IMM

Pentru acest scenariu unic de risc, folderul ar trebui să conțină:

Dovezile privind accesul nu trebuie să se oprească la capturi de ecran. Politica de control al accesului - IMM adaugă o cerință operațională utilă:

„Managerul IT trebuie să documenteze rezultatele revizuirii și acțiunile corective.”

Sursa: Politica de control al accesului - IMM, Cerințe de guvernanță, clauza de politică 5.5.3. Politica de control al accesului - IMM

Dovezile privind backup-urile trebuie să demonstreze recuperabilitatea, nu doar sarcini finalizate cu succes. Politica de backup și restaurare - IMM prevede:

„Testele de restaurare sunt efectuate cel puțin trimestrial, iar rezultatele sunt documentate pentru a verifica recuperabilitatea”

Sursa: Politica de backup și restaurare - IMM, Cerințe de guvernanță, clauza de politică 5.3.3. Politica de backup și restaurare - IMM

Aceasta oferă o buclă completă de dovezi: reglementarea creează cerința, riscul explică de ce contează, SoA selectează controlul, politica definește funcționarea, iar dovezile păstrate demonstrează că respectivul control funcționează.

Controale în acțiune: transformarea politicii în dovezi operaționale

Faza Controale în acțiune din Zenith Blueprint, Pasul 19, se concentrează pe verificarea tehnică. Aceasta recomandă revizuirea conformității securității punctelor terminale, a managementului identității și accesului, a configurațiilor de autentificare, a securității controlului sursei, a capacității și disponibilității, a managementului vulnerabilităților și patch-urilor, a configurațiilor de bază securizate, a protecției antimalware, a ștergerii și minimizării datelor, a mascării și datelor de test, a DLP, a backup-ului și restaurării, a redundanței, a jurnalizării și monitorizării și a sincronizării timpului.

Pentru TOMs prevăzute de GDPR Article 32, Pasul 19 este locul în care limbajul abstract al controlului devine dovadă. Un dosar solid de dovezi ar trebui să arate că:

• Criptarea punctelor terminale este activată și monitorizată.
• Utilizatorii privilegiați au MFA.
• Procesele de angajare, transfer și încetare a raporturilor de muncă sunt reconciliate cu înregistrările HR.
• Conturile de serviciu sunt documentate și restricționate.
• Depozitele de cod sunt protejate prin controlul accesului și se efectuează scanarea secretelor.
• Scanările de vulnerabilitate sunt efectuate și urmărite până la remediere.
• Datele de producție nu sunt copiate informal în medii de testare.
• Politicile de ștergere securizată și retenție sunt aplicate.
• Alertele DLP sunt revizuite.
• Testele de restaurare din backup demonstrează recuperabilitatea.
• Jurnalele sunt centralizate, păstrate și revizuibile.
• Sincronizarea timpului susține investigații fiabile ale incidentelor.

Elementul-cheie este legătura. Un raport de patch fără o referință la risc, politică și SoA este un artefact IT. Un raport de patch legat de GDPR Article 32, NIS2 Article 21, managementul riscurilor TIC conform DORA și un Plan de tratament al riscurilor ISO 27001:2022 este dovadă pregătită pentru audit.

Un singur dosar de dovezi, mai multe perspective de audit

Aceleași dovezi TOMs vor fi citite diferit de părți interesate diferite. Un revizor de confidențialitate se poate concentra pe datele cu caracter personal, necesitate, proporționalitate și responsabilitate. Un auditor ISO 27001 se poate concentra pe domeniul de aplicare, tratamentul riscurilor, SoA și dovezile de funcționare. O autoritate NIS2 se poate concentra pe supravegherea managementului, măsurile din Article 21 și pregătirea pentru raportarea conform Article 23. Un supraveghetor DORA sau un client financiar se poate concentra pe guvernanța riscurilor TIC, testarea rezilienței și dependențele de terți.

Clarysec folosește Zenith Controls ca ghid de conformitate încrucișată pentru această traducere.

Aceasta previne munca de conformitate duplicată. În loc să construiți pachete de dovezi separate pentru GDPR, NIS2 și DORA, construiți un singur dosar de dovezi ale controalelor și etichetați fiecare element pentru obligațiile pe care le susține.

Lacune frecvente în programele TOMs pentru Article 32

Cea mai frecventă lacună este orfanizarea controalelor. O companie are un control, precum criptarea, dar nu poate explica ce risc tratează, ce politică îl impune, cine îl deține sau cum este revizuit.

A doua lacună este reprezentată de dovezile slabe privind furnizorii. În GDPR, persoanele împuternicite și persoanele subîmputernicite contează. În NIS2, securitatea lanțului de aprovizionare face parte din managementul riscurilor de securitate cibernetică. În DORA, riscul asociat terților TIC este un domeniu reglementat, cu registre, verificare prealabilă, garanții contractuale, drepturi de audit și planificare a ieșirii. O foaie de calcul cu furnizori nu este suficientă dacă dependențele critice nu sunt evaluate din perspectiva riscului și controlate.

A treia lacună este dovada privind incidentele. Organizațiile au adesea un Plan de răspuns la incidente, dar nu au dovezi că procesele de clasificare, escaladare, raportare către autorități și comunicare către clienți au fost testate. NIS2 și DORA ridică așteptările în acest punct, iar evaluarea încălcărilor securității datelor cu caracter personal conform GDPR trebuie integrată în același flux de lucru.

A patra lacună este dovada privind backup-ul. O sarcină de backup finalizată cu succes nu demonstrează recuperabilitatea. Un test de restaurare documentat o demonstrează.

A cincea lacună este analiza efectuată de management. TOMs prevăzute de Article 32 trebuie să fie proporționale cu riscul. Dacă managementul nu revizuiește niciodată riscurile, incidentele, problemele furnizorilor, bugetul, constatările de audit și riscul rezidual, proporționalitatea devine dificil de demonstrat.

Setul final de instrumente pregătit pentru audit

Faza Audit, revizuire și îmbunătățire din Zenith Blueprint, Pasul 30, oferă lista finală de verificare a pregătirii. Aceasta include domeniul de aplicare și contextul SMSI, politica de securitate a informației semnată, documentele de evaluare și tratament al riscurilor, SoA, politicile și procedurile Annex A, registre de instruire, înregistrări operaționale, raportul de audit intern, registrul acțiunilor corective, procese-verbale ale analizelor efectuate de management, dovezi de îmbunătățire continuă și înregistrări privind obligațiile de conformitate.

Politica enterprise de audit și monitorizare a conformității a Clarysec indică scopul acestei discipline:

„Generarea de dovezi defensabile și a unei piste de audit în sprijinul solicitărilor autorităților de reglementare, al procedurilor juridice sau al cererilor clienților privind asigurarea controalelor.”

Sursa: Politica de audit și monitorizare a conformității, Obiective, clauza de politică 3.4. Politica de audit și monitorizare a conformității

Un dosar matur de dovezi pentru TOMs prevăzute de Article 32 ar trebui să includă:

Pașii următori: construiți dovezi TOMs pentru Article 32 cu Clarysec

Dacă trebuie să demonstrați măsurile tehnice și organizatorice prevăzute de GDPR Article 32, nu începeți prin colectarea de capturi de ecran aleatorii. Începeți cu trasabilitatea.

1. Definiți domeniul de aplicare al SMSI și limitele prelucrării datelor cu caracter personal.
2. Identificați cerințele GDPR, NIS2, DORA, contractuale și ale clienților.
3. Construiți criterii de risc folosind ISO/IEC 27005:2022 și apetitul la risc aprobat de management.
4. Creați sau actualizați Registrul riscurilor.
5. Mapați fiecare tratament la controalele ISO 27001:2022 și la SoA.
6. Utilizați Zenith Controls pentru a corela controalele de confidențialitate, criptografie, furnizori, incidente și revizuire independentă cu așteptările de conformitate.
7. Urmați Zenith Blueprint Pasul 13 și Pasul 14 pentru a conecta riscurile, controalele și obligațiile de reglementare.
8. Utilizați Zenith Blueprint Pasul 19 pentru a verifica funcționarea controalelor tehnice.
9. Utilizați Zenith Blueprint Pasul 30 pentru a asambla dosarul final de dovezi pregătit pentru audit.
10. Stocați centralizat toate dovezile, etichetați-le după risc și temă de control și mențineți vizibile acțiunile corective.

Clarysec vă poate ajuta să transformați GDPR Article 32 dintr-o obligație vagă de conformitate într-un sistem de dovezi defensabil, bazat pe risc, aliniat cu ISO 27001:2022, NIS2 și DORA.

Începeți cu Zenith Blueprint, consolidați-l cu politicile Clarysec și utilizați Zenith Controls pentru ca fiecare TOM să fie trasabilă, testabilă și pregătită pentru audit.