Plan operațional GDPR de 72 de ore pentru încălcările securității datelor cu caracter personal (PII), destinat CISO
Este marți, ora 2:13 dimineața, când se declanșează alerta.
Maria, CISO al unei platforme FinTech SaaS în creștere rapidă, este trezită de o escaladare din SOC: interogări anormale ale bazei de date provin dintr-un cont de dezvoltator. Contul a accesat tabele care conțineau numele clienților, adrese de e-mail, istoricul tranzacțiilor și numere naționale de identificare. În câteva minute, echipa confirmă că datele de autentificare ale dezvoltatorului au fost furate printr-un atac de tip phishing. Fereastra de expunere nu este clară. Intenția atacatorului este necunoscută. Aria de impact este încă în curs de stabilire.
Termenul începe acum.
Conform GDPR, Maria poate avea 72 de ore pentru a notifica o autoritate de supraveghere dacă incidentul este susceptibil să genereze un risc pentru persoane. Pentru NIS2, dacă organizația este o entitate esențială sau importantă, iar incidentul este semnificativ, poate fi necesară o avertizare timpurie în termen de 24 de ore și o notificare formală în termen de 72 de ore. Pentru DORA, se pot aplica și obligații de raportare a incidentelor TIC din sectorul financiar și obligații de reziliență operațională. Clienții, asigurătorii, consilierii juridici, conducerea executivă și auditorii vor solicita răspunsuri.
Acesta este momentul în care un plan generic de răspuns la incidente eșuează frecvent. Un runbook pentru programe malware poate explica izolarea gazdelor. O procedură SOC poate explica păstrarea jurnalelor. Însă un proces ISO/IEC 27701:2025 de gestionare a încălcărilor securității PII trebuie să răspundă, sub presiune, unor întrebări mai dificile:
- Au fost datele cu caracter personal expuse, modificate, pierdute, distruse sau accesate fără autorizare?
- Organizația acționează ca operator de date, persoană împuternicită, operator asociat sau persoană subîmputernicită?
- Când a avut loc luarea la cunoștință și ce dovezi o demonstrează?
- Este obligatorie notificarea de reglementare conform articolului 33 GDPR?
- Persoanele afectate sunt expuse unui risc ridicat conform articolului 34 GDPR?
- Dacă organizația acționează ca persoană împuternicită, cât de repede trebuie notificat operatorul?
- Ce dovezi vor susține decizia peste șase luni, în timpul unui audit?
Diferența dintre haos și control nu este dată de numărul de instrumente de securitate din stivă. Diferența este dacă organizația a construit un Sistem de management al informațiilor privind confidențialitatea disciplinat, sau PIMS, care conectează răspunsul la incidente, guvernanța confidențialității, gestionarea probelor, escaladarea către furnizori și raportarea de reglementare într-un ciclu de viață unic, defensabil.
Gestionarea încălcărilor începe înainte ca cineva să spună „încălcare”
Prima eroare operațională este presupunerea că gestionarea încălcărilor securității PII începe numai după ce departamentul juridic confirmă o încălcare a securității datelor cu caracter personal. În realitate, procesul începe când o persoană, un sistem, un furnizor sau un client observă ceva ce ar putea implica PII.
Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint plasează acest declanșator uman în faza Controls in Action, Pasul 16: People Controls II. Ghidul precizează:
„Un sistem eficace de răspuns la incidente nu începe cu instrumente, ci cu oamenii. Controlul 6.8 subliniază importanța asigurării faptului că fiecare angajat, contractant sau parte interesată știe cum să recunoască și să raporteze un potențial incident de securitate și se simte în siguranță și împuternicit să facă acest lucru.”
Acest lucru este important deoarece multe incidente de confidențialitate nu sunt detectate inițial de un SIEM. Ele încep cu un agent de suport care vede atașamentul altui client, un angajat de salarizare care observă o foaie de calcul trimisă greșit, un client care raportează factura altui utilizator sau un furnizor care raportează pierderea unui laptop.
Politica de protecție a datelor și confidențialitate pentru IMM-uri Politica de protecție a datelor și confidențialitate pentru IMM-uri, secțiunea Aplicare și conformitate, clauza 8.3.1, transformă acest lucru într-o obligație imediată:
„Toate încălcările securității datelor cu caracter personal sau incidentele suspectate trebuie raportate imediat Coordonatorului pentru confidențialitate”
Pentru programele enterprise, Politica de protecție a datelor și confidențialitate Politica de protecție a datelor și confidențialitate, secțiunea Aplicare și conformitate, clauza 8.3.2, atribuie conducerea:
„Responsabilul cu protecția datelor (DPO) trebuie să coordoneze limitarea, analiza și escaladarea încălcării, în conformitate cu ISO/IEC 27035 și articolele 33 și 34 GDPR.”
Aceasta este trecerea de la „IT investighează” la „ciclul de viață PIMS pentru încălcări a fost activat.”
Primul punct de presiune: eveniment, incident de securitate, incident de confidențialitate sau încălcare a securității PII
La ora 2:13, echipa Mariei are o alertă. Încă nu are o încălcare confirmată care trebuie notificată. Prima decizie critică este clasificarea.
Zenith Blueprint, faza Controls in Action, Pasul 23: controale organizaționale, explică controlul ISO/IEC 27002:2022 5.25, Evaluarea și decizia privind evenimentele de securitate a informațiilor:
„Nu orice anomalie este un dezastru. Nu orice alertă indică o compromitere. În lumea reală, echipele de securitate și unitățile de business sunt inundate de zgomot: tentative de autentificare, anomalii ale jurnalelor, încălcări minore ale politicilor, activitate shadow IT. Provocarea reală nu constă doar în detecție, ci în distingerea elementelor inofensive de cele dăunătoare și în cunoașterea situațiilor care impun escaladare.”
Un ciclu de viață pentru încălcări ale confidențialității trebuie să facă această distincție repetabilă. Nu trebuie să depindă de persoana aflată de gardă, de avocatul care se alătură primul sau de toleranța CISO la incertitudine.
Un model practic de clasificare Clarysec separă patru etape:
| Etapă de clasificare | Întrebare | Proprietar tipic | Dovezi necesare |
|---|---|---|---|
| Eveniment | S-a întâmplat ceva neobișnuit? | Helpdesk, SOC, proprietar de business | Tichet, raport, alertă, e-mail, extras de jurnal |
| Incident de securitate | Evenimentul a amenințat sau a compromis securitatea informației? | Coordonatorul răspunsului la incidente | Tichet de incident, note de triaj, sisteme afectate |
| Incident de confidențialitate | Evenimentul ar putea implica PII sau obligații privind confidențialitatea? | Responsabil pentru confidențialitate sau DPO | Categorii de PII, persoane vizate, rol de prelucrare |
| Încălcare confirmată sau suspectată a securității PII | PII au fost expuse, pierdute, modificate, distruse sau accesate ilegal ori accidental? | DPO, responsabil pentru confidențialitate, juridic, proprietar de business | Evaluarea riscurilor, decizia de notificare, registru de dovezi |
Cuvântul „suspectată” este esențial. Clarysec nu recomandă așteptarea certitudinii perfecte înainte de deschiderea fluxului de lucru pentru încălcări ale confidențialității. Registrul încălcărilor trebuie deschis atunci când o încălcare a securității PII este suspectată în mod rezonabil, apoi actualizat pe măsură ce faptele se clarifică.
Politica de gestionare a incidentelor și încălcărilor PII Politica de gestionare a incidentelor și încălcărilor PII, secțiunea Clasificare și evaluarea încălcării, clauza 4.2.3, impune operatorilor să documenteze decizia înainte de orice acțiune externă:
„[Operator] Responsabilul cu protecția datelor / Consilierul pentru confidențialitate TREBUIE să evalueze riscul pentru persoanele vizate afectate pentru fiecare încălcare confirmată sau suspectată în mod rezonabil a securității PII și să înregistreze recomandarea de notificare, justificarea riscului și recomandarea în REG10 înainte de luarea deciziei de notificare externă.”
Această clauză este nucleul operațional al unui răspuns GDPR la încălcări, pregătit pentru audit: evaluează riscul, înregistrează justificarea, capturează recomandarea, decide și păstrează dovezile în REG10.
Termenul de 72 de ore este o problemă de dovezi, nu o simplă reamintire în calendar
Multe echipe tratează cerința GDPR de notificare în 72 de ore ca pe un termen-limită dintr-un plan de proiect. Într-un incident real, partea dificilă este demonstrarea momentului în care organizația a luat cunoștință, a faptelor cunoscute la acel moment, a vitezei cu care a acționat și a motivului pentru care decizia de notificare a fost rezonabilă.
Politica de răspuns la incidente pentru IMM-uri Politica de răspuns la incidente pentru IMM-uri, secțiunea Scop, clauza 1.2, formulează obiectivul:
„Această politică permite organizației să minimizeze prejudiciile, să protejeze datele clienților și să respecte obligațiile de reglementare, cum ar fi cerința GDPR de notificare în 72 de ore a încălcărilor securității datelor cu caracter personal.”
Politica de protecție a datelor și confidențialitate pentru IMM-uri, secțiunea Aplicare și conformitate, clauza 8.3.3, precizează:
„Acolo unde este necesar, notificarea autorităților și a persoanelor afectate trebuie să aibă loc în termen de 72 de ore”
Pentru programele enterprise, Politica de protecție a datelor și confidențialitate, secțiunea Aplicare și conformitate, clauza 8.3.3, precizează:
„Încălcările care ating pragul legal de notificare trebuie raportate autorităților de supraveghere în termen de 72 de ore.”
Scopul nu este notificarea fiecărei anomalii. Scopul este luarea unei decizii defensabile suficient de rapid pentru ca notificarea obligatorie să poată fi transmisă la timp. Prin urmare, un PIMS matur utilizează termene interne mai scurte decât termenele legale externe.
| Timp de la luarea la cunoștință | Acțiune PIMS | Dovezi de capturat în REG10 |
|---|---|---|
| 0-4 ore | Deschiderea înregistrării incidentului PII, atribuirea proprietarului, păstrarea dovezilor inițiale, identificarea rolului de prelucrare | Raport de intrare, marcaj temporal al luării la cunoștință, roluri atribuite, sisteme și date inițiale implicate |
| 4-12 ore | Limitarea expunerii, identificarea categoriilor de PII, stabilirea obligațiilor de operator sau de persoană împuternicită | Acțiuni de conținere, tipuri de date afectate, evaluarea rolului, dependențe de furnizori sau clienți |
| 12-24 ore | Efectuarea evaluării preliminare a riscurilor și stabilirea probabilității notificării autorității de supraveghere | Justificarea riscului, impact probabil, incertitudine, recomandare DPO, contribuție juridică |
| 24-48 ore | Pregătirea notificării sau a justificării pentru lipsa notificării, coordonarea comunicărilor către clienți sau operatori | Proiect de notificare, jurnal decizional, aprobări, notificări către clienți, referințe la dovezi |
| 48-72 ore | Transmiterea notificării obligatorii, documentarea justificării întârzierii dacă este necesar, pregătirea comunicării către persoane dacă riscul este ridicat | Dovezi de transmitere, referință a autorității de reglementare, decizie finală, plan de comunicare |
| După 72 de ore | Continuarea investigației, actualizarea autorității de reglementare dacă este necesar, notificarea persoanelor unde este obligatoriu, finalizarea lecțiilor învățate | Rapoarte ulterioare, acțiuni corective, aprobare de închidere, backlog de îmbunătățiri |
Politica de gestionare a incidentelor și încălcărilor PII, secțiunea Notificări și comunicări, clauza 4.4.1, formulează explicit cerința de documentare:
„[Operator] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să pregătească o decizie documentată de notificare de reglementare pentru fiecare încălcare confirmată a securității PII, fără întârzieri nejustificate și într-un termen intern care susține termenele externe de notificare aplicabile, și TREBUIE să păstreze notificarea, justificarea pentru lipsa notificării sau justificarea întârzierii în REG10.”
O autoritate de reglementare poate contesta o decizie. Un auditor poate testa dacă procesul a fost urmat. Însă, dacă organizația poate demonstra dovezi la timp, criterii structurate, recomandarea DPO și o justificare documentată, se află într-o poziție mult mai solidă decât o echipă care spune: „Am discutat într-un apel.”
Operatorii și persoanele împuternicite au nevoie de trasee diferite pentru încălcări
Companiile SaaS moderne operează adesea în mai mult de un rol de confidențialitate. Platforma FinTech a Mariei poate fi operator pentru abonații direcți și persoană împuternicită pentru clienții enterprise. Într-un alt scenariu, un portal de suport B2B poate fi persoană împuternicită pentru atașamentele tichetelor clienților, dar operator pentru propriile metadate interne de suport.
Această distincție schimbă traseul de notificare.
| Obligație | Rol de operator PII | Rol de persoană împuternicită PII |
|---|---|---|
| Obligație principală | Față de autoritatea de supraveghere și persoanele afectate, atunci când pragurile sunt îndeplinite | Față de operatorul sau clientul afectat |
| Destinatarul notificării | Autoritatea de supraveghere relevantă și, dacă riscul este ridicat, persoanele afectate | Clientul sau operatorul menționat în contract |
| Declanșatorul notificării | Risc pentru drepturile și libertățile persoanelor | Luarea la cunoștință a unei încălcări care afectează PII ale clientului |
| Termen | Fără întârzieri nejustificate și, acolo unde este fezabil, în termen de 72 de ore de la luarea la cunoștință | Fără întârzieri nejustificate și în termenele contractuale, adesea 24 sau 48 de ore |
| Evaluarea riscurilor | Trebuie să evalueze riscul pentru persoane și să decidă notificarea conform articolelor 33 și 34 | Furnizează faptele pentru ca operatorul să poată evalua riscul |
Pentru persoanele împuternicite, Politica de gestionare a incidentelor și încălcărilor PII, secțiunea Notificări și comunicări, clauza 4.4.4, precizează:
„[Persoană împuternicită] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să notifice operatorul sau clientul afectat fără întârzieri nejustificate și în orice termen contractual aplicabil după ce ia cunoștință de o încălcare a securității PII care afectează PII ale clientului și TREBUIE să înregistreze notificările inițiale și ulterioare în REG08 și REG10.”
O persoană împuternicită nu trebuie să aștepte finalizarea analizei de risc GDPR a operatorului. Aceasta trebuie să notifice operatorul cu faptele disponibile și să furnizeze actualizări pe măsură ce investigația continuă. Operatorul decide apoi notificarea autorității de supraveghere și comunicarea către persoanele afectate pentru prelucrarea sa.
Pentru impacturi cu risc ridicat asupra persoanelor, operatorul trebuie să evalueze și comunicarea directă. Politica de gestionare a incidentelor și încălcărilor PII, clauza 4.4.3, precizează:
„[Operator] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să coordoneze comunicarea către persoanele vizate afectate atunci când evaluarea încălcării identifică un declanșator de comunicare cu risc ridicat sau echivalent și TREBUIE să înregistreze conținutul comunicării, publicul-țintă, momentul, metoda de livrare și dovezile aprobării în REG10.”
Politica de protecție a datelor și confidențialitate pentru programe enterprise, secțiunea Aplicare și conformitate, clauza 8.3.4, consolidează această cerință:
„Dacă este identificat un risc ridicat pentru persoane, persoanele vizate afectate trebuie notificate fără întârzieri nejustificate, cu excepția cazului în care se aplică o excepție (de exemplu, există criptare puternică).”
Acea excepție trebuie să se bazeze pe dovezi. Afirmația „datele au fost criptate” nu este suficientă. Organizația trebuie să demonstreze că datele expuse erau ilizibile pentru părți neautorizate și că cheile relevante nu au fost compromise.
Furnizorii pot decide succesul sau eșecul primelor 24 de ore
Terții dețin adesea faptele necesare pentru clasificare și notificare. Un furnizor cloud poate deține jurnale de acces. O persoană împuternicită pentru salarizare poate ști ce angajați au fost afectați. Un furnizor de servicii administrate poate să fi efectuat schimbarea de configurare. O persoană subîmputernicită poate deține telemetrie criminalistică.
Prin urmare, clauzele privind încălcările în relația cu furnizorii trebuie proiectate înainte de incident.
Politica de securitate privind terții și furnizorii Politica de securitate privind terții și furnizorii, secțiunea Cerințe de guvernanță, clauza 5.3.3, include guvernanță contractuală asupra:
„Termenelor de notificare a încălcărilor (de exemplu, în termen de 24 sau 72 de ore, în funcție de criticitate și de cerințele de reglementare)”
Pentru organizațiile mai mici, Politica de securitate privind terții și furnizorii pentru IMM-uri Politica de securitate privind terții și furnizorii pentru IMM-uri susține în mod similar termenele de notificare a încălcărilor în cadrul guvernanței furnizorilor.
Clarysec recomandă ca contractele cu furnizorii și acordurile de prelucrare a datelor să definească:
- Ce constituie o încălcare suspectată a securității PII
- Cine trebuie notificat și prin ce canal
- Termenul de notificare inițială, adesea mai scurt decât termenul de reglementare al operatorului
- Faptele minime necesare în prima notificare
- Frecvența actualizărilor pe durata investigației
- Obligațiile de păstrare a dovezilor
- Transmiterea în lanț a obligațiilor de notificare către persoanele subîmputernicite
- Suportul pentru comunicările către autoritatea de reglementare și persoanele vizate
- Obligațiile de acțiuni corective post-incident
Dacă acordurile cu furnizorii utilizează formulări vagi precum „cât mai curând posibil”, termenul GDPR al operatorului poate depinde de dezbaterea internă a altei organizații. Acesta nu este un model operațional defensabil.
Dovezile transformă răspunsul în conformitate defensabilă
În timpul incidentului Mariei, echipa are nevoie de jurnale de autentificare, înregistrări ale interogărilor bazei de date, dovezi de phishing, modificări ale controlului accesului, liste ale clienților afectați, acțiuni de conținere, recomandarea DPO și proiecte de comunicare. În scenariul portalului SaaS B2B, echipa ar putea avea nevoie de capturi de ecran, permisiuni pentru stocare bazată pe obiecte, ID-uri de tichete de suport, modificări IAM și jurnale de acces între entități găzduite.
Dovezile trebuie păstrate corespunzător. Capturile de ecran izolate, exporturile din chat și folderele personale nu sunt suficiente.
Zenith Blueprint, faza Controls in Action, Pasul 23, discută controlul ISO/IEC 27002:2022 5.28, Colectarea dovezilor:
„Când apare un incident de securitate a informațiilor, unul dintre cele mai critice și totuși adesea neglijate elemente ale răspunsului este reprezentat de dovezi. Nu jurnale, nu capturi de ecran, nu relatări disparate, ci dovezi păstrate corespunzător, care respectă lanțul de custodie și sunt rezistente la alterare.”
Politica privind colectarea dovezilor și activitățile criminalistice Politica privind colectarea dovezilor și activitățile criminalistice, secțiunea Cerințe de guvernanță, clauza 5.5, precizează:
„Toate dovezile colectate trebuie identificate în mod unic, etichetate și stocate într-un depozit securizat cu:”
Politica de gestionare a incidentelor și încălcărilor PII, secțiunea Dovezi, păstrarea înregistrărilor și confidențialitate, clauza 4.5.1, conectează aceste dovezi la înregistrarea PIMS:
„[Ambele] Coordonatorul răspunsului la incidente TREBUIE să mențină o înregistrare REG10 completă pentru fiecare incident PII suspectat sau confirmat, de la intrare până la închidere, inclusiv fapte, moment, clasificare, evaluare, acțiuni, decizii, notificări, referințe la dovezi și starea închiderii.”
REG10 devine sursa unică de adevăr pentru incident. REG08 capturează notificările către clienți sau operatori acolo unde este aplicabil. Împreună, acestea permit echipelor de securitate, confidențialitate, juridic și audit să lucreze dintr-un singur lanț de dovezi.
| Câmp REG10 | Exemplu de intrare |
|---|---|
| ID incident | PII-2026-034 |
| Marcaj temporal al luării la cunoștință | 2026-06-23 02:13 UTC, alertă SOC confirmată |
| Rol de prelucrare | Operator pentru abonații direcți, persoană împuternicită pentru seturile de date ale clienților enterprise |
| PII implicate | Nume, adrese de e-mail de serviciu, istoricul tranzacțiilor, numere naționale de identificare |
| Clasificare inițială | Incident de securitate confirmat cu încălcare suspectată a securității PII |
| Conținere | Datele de autentificare ale dezvoltatorului revocate, sesiuni terminate, accesul la baza de date afectată restricționat |
| Evaluarea riscurilor | Identificatori nepublici accesați, riscul de fraudă de identitate nu poate fi exclus |
| Decizie de notificare | Notificarea autorității de supraveghere aprobată pentru datele în care organizația este operator; clienții enterprise au fost notificați ca operatori |
| Referințe la dovezi | Jurnal de autentificare E-034-01, export de interogări E-034-02, artefact de phishing E-034-03 |
| Închidere | Cauza principală remediată, controalele MFA consolidate, instruirea privind phishing-ul actualizată, comunicarea ulterioară cu clienții finalizată |
Scopul nu este birocrația. Scopul este să evite ca organizația să reconstruiască memoria din mesaje Slack dispersate după ce sună autoritatea de reglementare.
Maparea răspunsului PIMS ISO 27701 la ISO 27001 și ISO 27002
Un proces matur pentru încălcări ale securității PII se află la intersecția dintre guvernanța confidențialității și managementul securității informației.
Clauzele 4.1-4.4 din ISO/IEC 27001:2022 impun organizațiilor să înțeleagă contextul, părțile interesate, domeniul de aplicare al SMSI și procesele sistemului de management. Pentru gestionarea încălcărilor securității PII, aceasta înseamnă că procesul trebuie să reflecte obligațiile de reglementare, contractele cu clienții, rolurile de prelucrare, dependențele de furnizori și obligațiile sectoriale înainte ca un incident să apară.
Zenith Controls: The Cross-Compliance Guide Zenith Controls ajută la maparea controalelor de incident într-un model mai larg de asigurare. Cele mai relevante controale ISO/IEC 27002:2022 sunt:
| Control ISO/IEC 27002:2022 | Tratament în Zenith Controls | De ce contează pentru gestionarea încălcărilor securității PII |
|---|---|---|
| 5.24 Planificarea și pregătirea managementului incidentelor de securitate a informațiilor | Control corectiv, răspuns și recuperare, guvernanță și managementul evenimentelor de securitate a informațiilor | Definește planuri, roluri, căi de escaladare, șabloane de comunicare și pregătirea pentru încălcări ale confidențialității |
| 5.25 Evaluarea și decizia privind evenimentele de securitate a informațiilor | Control de detectare, detectare și răspuns, managementul evenimentelor de securitate a informațiilor | Creează punctul decizional structurat pentru clasificarea incidentelor de confidențialitate și a încălcărilor suspectate ale securității PII |
| 5.26 Răspunsul la incidente de securitate a informațiilor | Control corectiv, răspuns și recuperare, managementul evenimentelor de securitate a informațiilor | Activează conținerea, coordonarea, suportul pentru notificare, recuperarea și comunicarea cu părțile interesate |
| 5.28 Colectarea dovezilor | Păstrarea dovezilor și fiabilitate investigativă pe parcursul ciclului de viață al incidentului | Susține responsabilitatea GDPR, calitatea criminalistică, răspunsurile către autoritatea de reglementare și capacitatea de apărare în audit |
| 6.8 Raportarea evenimentelor de securitate a informațiilor | Canal de raportare bazat pe oameni și instruire de conștientizare | Asigură raportarea rapidă a incidentelor PII suspectate de către angajați, contractanți și părți interesate |
ISO/IEC 27035 susține managementul structurat al incidentelor. ISO/IEC 27037 susține gestionarea probelor digitale. ISO/IEC 29134 poate susține logica evaluării impactului asupra confidențialității atunci când remedierea încălcării indică necesitatea unei revizuiri DPIA mai aprofundate. ISO/IEC 27701:2025 aduce apoi în sistemul de management contextul rolurilor de confidențialitate, impactul asupra persoanelor vizate, obligațiile operatorului și ale persoanei împuternicite și cerințele PIMS privind dovezile.
Un incident, mai multe perspective de reglementare
Incidentul Mariei nu este doar o problemă GDPR. Deoarece compania furnizează servicii cloud clienților din sectorul financiar, NIS2 și DORA pot fi, de asemenea, aplicabile. Contractele cu clienții pot impune notificarea în 24 de ore. Asigurarea cibernetică poate impune notificare rapidă. Guvernanța internă poate impune raportarea către organul de conducere.
Crearea unor narațiuni separate pentru fiecare cadru generează risc de contradicții. Metoda Clarysec constă în menținerea unui singur lanț de dovezi, din care se creează livrabile specifice fiecărui cadru.
| Cadru sau reglementare | Perspectiva asupra incidentului | Livrabil Clarysec din lanțul de dovezi |
|---|---|---|
| GDPR | Încălcare a securității datelor cu caracter personal, risc pentru persoane, notificarea autorității de supraveghere, comunicare către persoanele afectate | Înregistrare decizională REG10, recomandare DPO, justificare pentru articolele 33 și 34, dovezi de comunicare |
| ISO/IEC 27701:2025 | Guvernanță PIMS, obligații ale operatorului și ale persoanei împuternicite, risc pentru persoanele vizate, dovezi privind confidențialitatea | Clasificarea incidentului PII, evaluarea rolului, REG08 și REG10, acțiuni corective |
| ISO/IEC 27001:2022 | Context SMSI, părți interesate, proces de răspuns la incidente, îmbunătățire continuă | Înregistrare a incidentului, actualizări ale tratamentului riscului, input pentru analiza efectuată de management, dovezi privind eficacitatea controalelor |
| NIS2 | Gestionarea incidentelor semnificative, raportare etapizată, măsuri de securitate pentru toate riscurile | Dovezi pentru avertizarea timpurie în 24 de ore, pachet de notificare a incidentului în 72 de ore, suport pentru raportul final la o lună |
| DORA | Managementul incidentelor legate de TIC pentru entități financiare și reziliență operațională digitală | Fapte privind impactul TIC, dependențe de terți, feedback din testarea rezilienței, suport pentru raportarea incidentului |
| NIST CSF 2.0 | Profil curent și Profil țintă, plan de acțiune prioritizat, comunicarea riscurilor | Actualizări ale lacunelor, îmbunătățiri țintă, narațiune de risc la nivelul organului de conducere |
| COBIT 2019 | Guvernanță, obiective de management, responsabilitate, performanța controlului | RACI, jurnale decizionale, metrici de proces, urmărirea acțiunilor corective |
Articolul 21 NIS2 stabilește măsuri de management al riscurilor de securitate cibernetică, inclusiv gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, evaluarea eficacității, igiena cibernetică, criptografia, controlul accesului, managementul activelor, MFA și comunicațiile securizate. Articolul 23 NIS2 instituie raportarea etapizată pentru incidente semnificative, inclusiv avertizare timpurie în termen de 24 de ore, notificarea incidentului în termen de 72 de ore, actualizări la cerere și un raport final nu mai târziu de o lună după notificarea incidentului.
DORA se aplică de la 17 ianuarie 2025 și stabilește cerințe uniforme pentru managementul riscurilor TIC, raportarea incidentelor legate de TIC, testarea rezilienței operaționale digitale, schimbul de informații și managementul riscurilor asociate terților TIC pentru entitățile financiare. Pentru un furnizor FinTech, un singur incident poate fi, prin urmare, o încălcare GDPR, un incident semnificativ NIS2, un eveniment TIC relevant pentru DORA din perspectiva clienților și un eveniment de notificare contractuală.
Cum vor testa auditorii ciclul de viață
Auditorii se opresc rar la „arătați-mi politica de răspuns la incidente.” Ei testează dacă ciclul de viață funcționează sub presiunea dovezilor.
Un auditor ISO/IEC 27701:2025 sau ISO/IEC 27001:2022 va întreba cum intră incidentele de confidențialitate în SMSI și PIMS, cine clasifică evenimentele, cum diferă obligațiile operatorului și ale persoanei împuternicite și cum generează incidentele acțiuni corective.
Un auditor GDPR sau o autoritate de supraveghere se va concentra asupra momentului luării la cunoștință, riscului pentru persoane, implicării DPO, justificării notificării, comunicării către persoanele afectate și responsabilității. Aceștia pot eșantiona incidente care nu au fost notificate pentru a testa dacă justificarea pentru lipsa notificării a fost documentată.
O revizuire NIS2 sau DORA va examina pragurile pentru incidente semnificative, raportarea etapizată, impactul TIC, dependențele de terți, implicațiile privind reziliența și dacă raportarea a fost aliniată la cerințele autorității competente relevante sau ale clienților.
Un evaluator NIST CSF 2.0 va întreba dacă incidentul a modificat Profilul curent și Profilul țintă ale organizației. Un revizor COBIT 2019 se va concentra pe guvernanță, responsabilitate, deținerea procesului, metrici și urmărirea acțiunilor corective.
Un pachet de dovezi de audit solid trebuie să includă:
| Element de dovadă | De ce îl solicită auditorii |
|---|---|
| Înregistrarea incidentului REG10 | Demonstrează intrarea, momentul, clasificarea, evaluarea, deciziile, notificările și închiderea |
| Înregistrarea REG08 privind notificarea clientului sau a operatorului | Demonstrează comunicările persoanei împuternicite și istoricul actualizărilor către client |
| Raportul sau alerta inițială | Stabilește modul în care incidentul a fost detectat și când a început luarea la cunoștință |
| Cronologia acțiunilor-cheie | Arată conținerea, evaluarea, aprobările și deciziile de notificare |
| Evaluarea rolului de prelucrare | Demonstrează separarea obligațiilor operatorului și ale persoanei împuternicite |
| Categorii de PII și persoane vizate afectate | Susține evaluarea riscurilor și domeniul notificării |
| Recomandarea DPO sau a Consilierului pentru confidențialitate | Demonstrează existența recomandării responsabile privind confidențialitatea înainte de decizia externă |
| Notificarea sau justificarea pentru lipsa notificării | Susține responsabilitatea conform articolelor 33 și 34 GDPR |
| Indexul depozitului de dovezi | Demonstrează integritatea dovezilor și disciplina lanțului de custodie |
| Cauza principală și planul de acțiuni corective | Arată îmbunătățirea continuă și revizuirea eficacității controalelor |
Aici Zenith Controls are valoare comercială și operațională. Ajută la maparea acelorași dovezi la controalele de incident ISO/IEC 27002:2022, responsabilitatea GDPR, gestionarea incidentelor NIS2, așteptările DORA privind reziliența, comunicarea NIST CSF și guvernanța COBIT, fără reconstruirea narațiunii de audit de fiecare dată.
Un ritm operațional pentru primele 24 de ore
Un plan operațional realist pentru încălcări ale securității PII trebuie să fie practic, nu teoretic. Luați în considerare o expunere SaaS între entități găzduite raportată de un client la ora 08:12.
La 08:12, echipa de customer success primește raportul și urmează comportamentul de raportare din Zenith Blueprint, Pasul 16. Tichetul este etichetat ca incident PII suspectat.
La 08:25, Coordonatorul răspunsului la incidente deschide REG10. Înregistrarea include marcajul temporal al luării la cunoștință, raportorul, sistemul, tipurile de date suspectate și proprietarul.
La 09:02, echipa de inginerie revine asupra modificării permisiunilor. Jurnalele sunt exportate înainte de rotire. Custodele de dovezi etichetează raportul clientului, modificarea IAM, exportul jurnalelor de acces și confirmarea conținerii în depozitul securizat.
La 10:30, Responsabilul pentru confidențialitate stabilește că organizația acționează ca persoană împuternicită pentru atașamentele de suport ale clienților. Conform Politicii de gestionare a incidentelor și încălcărilor PII, clauza 4.4.4, clienții operatori afectați trebuie notificați fără întârzieri nejustificate și în termenele contractuale. Se deschide REG08.
La 12:00, DPO evaluează riscul pentru persoanele vizate. Datele par limitate, însă unele atașamente pot include nume ale angajaților și ID-uri interne. DPO înregistrează justificarea riscului și recomandarea în REG10.
La 15:00, clienții operatori afectați primesc notificarea inițială: ce s-a întâmplat, când a fost detectat, ce a fost conținut, ce PII pot fi implicate, ce este încă analizat și când va fi transmisă următoarea actualizare.
La 18:00, managementul primește o informare scurtă: notificările către clienți au fost transmise, deciziile de notificare a autorității de reglementare aparțin operatorilor pentru PII ale clienților, prelucrarea internă în rol de operator este încă evaluată, dovezile sunt păstrate, iar analiza cauzei principale este în desfășurare.
Acest ritm previne cele mai frecvente eșecuri în cazul încălcărilor: termene ratate, roluri neclare, recomandări nedocumentate și comunicări necontrolate.
Tipare comune de eșec care trebuie eliminate înainte de următoarea alertă
Cele mai dăunătoare eșecuri în gestionarea încălcărilor confidențialității sunt rareori cauzate de lipsa unui singur document. Ele sunt cauzate de rupturi între securitate, confidențialitate, juridic, furnizori și proprietarii de business.
Clarysec observă frecvent aceste tipare:
- Există planuri de răspuns la incidente, dar lipsește clasificarea încălcărilor securității PII.
- Notificarea GDPR în 72 de ore este menționată, dar termenele interne nu sunt mai scurte decât termenul legal.
- Escaladarea persoanei împuternicite este întârziată deoarece echipele așteaptă analiza completă a cauzei principale.
- Contractele cu furnizorii nu impun notificarea rapidă a încălcărilor sau suportul pentru dovezi.
- Recomandarea DPO este verbală și nu este introdusă niciodată în registrul încălcărilor.
- Comunicarea cu persoanele expuse unui risc ridicat este luată în considerare prea târziu.
- Dovezile sunt stocate în foldere personale, fire de chat sau comentarii din tichete.
- Deciziile de lipsă a notificării nu sunt documentate.
- Lecțiile învățate nu actualizează controalele, instruirea, clauzele cu furnizorii sau planurile de tratare a riscurilor.
Zenith Blueprint, Pasul 23, surprinde motivul pentru care structura contează:
„Un răspuns la incidente fără structură devine improvizație. E-mailurile circulă, se convoacă ședințe, iar deciziile sunt luate emoțional sau inconsecvent. Însă un SMSI matur transformă răspunsul în disciplină.”
Această disciplină este scopul gestionării încălcărilor securității PII conform ISO/IEC 27701:2025.
Construiți ciclul de viață Clarysec pentru încălcări ale securității PII
Abordarea Clarysec combină trei niveluri.
În primul rând, Zenith Blueprint oferă foaia de parcurs pentru implementare. Pasul 16 asigură faptul că oamenii recunosc și raportează incidentele suspectate. Pasul 23 operaționalizează evaluarea, decizia, răspunsul și colectarea dovezilor prin controalele ISO/IEC 27002:2022 5.25, 5.26 și 5.28.
În al doilea rând, setul de politici definește autoritatea și obligațiile. Politicile pentru IMM-uri fac practice raportarea, luarea la cunoștință în 72 de ore și registrele de incidente pentru organizațiile mai mici. Politicile enterprise atribuie conducerea către DPO, pragurile de încălcare, comunicarea către persoanele afectate, termenii de notificare a furnizorilor, gestionarea probelor și guvernanța criminalistică. Politica de gestionare a incidentelor și încălcărilor PII, specifică PIMS, adaugă obligații ale operatorului și persoanei împuternicite bazate pe roluri, REG08, REG10, justificarea notificării și dovezile de închidere.
În al treilea rând, Zenith Controls acționează ca busolă pentru maparea cerințelor de conformitate între cadre. Acesta mapează planificarea, evaluarea, răspunsul și dovezile privind incidentele într-o perspectivă integrată asupra ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 și așteptărilor de asigurare de tip COBIT.
Pentru CISO, acest lucru reduce confuzia operațională. Pentru DPO, creează un traseu decizional defensabil privind confidențialitatea. Pentru managerii de conformitate, conectează o singură înregistrare de incident la mai multe livrabile de reglementare. Pentru auditori, creează dovezi trasabile. Pentru executivi, reduce probabilitatea ca un incident de confidențialitate gestionabil să devină o criză de reglementare și de reputație.
Următorul pas
Nu așteptați alerta de la ora 2 dimineața pentru a descoperi dacă procesul pentru încălcări ale securității PII funcționează.
Începeți săptămâna aceasta cu trei acțiuni:
- Revizuiți dacă preluarea incidentelor capturează explicit incidentele PII suspectate.
- Confirmați că obligațiile de încălcare ale operatorului și ale persoanei împuternicite sunt separate în politici, contracte și registre de dovezi.
- Derulați un exercițiu de tip tabletop folosind un scenariu realist, cum ar fi date de autentificare compromise, expunere între entități găzduite, un fișier de salarizare trimis greșit, un laptop criptat pierdut sau compromiterea unui furnizor.
Clarysec vă poate ajuta să operaționalizați acest lucru prin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls și setul de politici PIMS ISO/IEC 27701:2025, inclusiv Politica de gestionare a incidentelor și încălcărilor PII Politica de gestionare a incidentelor și încălcărilor PII, Politica de protecție a datelor și confidențialitate Politica de protecție a datelor și confidențialitate, Politica de răspuns la incidente pentru IMM-uri Politica de răspuns la incidente pentru IMM-uri, Politica de securitate privind terții și furnizorii Politica de securitate privind terții și furnizorii și Politica privind colectarea dovezilor și activitățile criminalistice Politica privind colectarea dovezilor și activitățile criminalistice.
Descărcați toolkitul Clarysec PIMS, programați o evaluare a pregătirii pentru încălcări sau solicitați o demonstrație pentru a transforma răspunsul GDPR în 72 de ore dintr-o improvizație într-un proces disciplinat, pregătit pentru audit.
Obțineți certificarea PECB ISO/IEC 27701 și implementați-vă PIMS-ul
- ✓ Materiale oficiale PECB și două încercări de examen
- ✓ Taxa de certificare și AMF pentru primul an incluse, după caz
- ✓ Studiu individual sau live online · curs alocat în 1 zi lucrătoare
Despre autor
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