Protecția informațiilor de identificare personală (PII), pregătită pentru audit, pentru GDPR, NIS2 și DORA
Alerta a ajuns în inboxul Sarei marți, la ora 22:00.
În calitate de CISO al unei companii FinTech SaaS aflate în creștere, alertele primite târziu în noapte îi erau familiare. Aceasta era diferită. Un dezvoltator junior expusese o bază de date de staging printr-un endpoint public în timp ce testa o nouă funcționalitate de analiză. Baza de date ar fi trebuit să conțină date de test, dar o sincronizare recentă din producție către staging o populase cu PII reale ale clienților.
Incidentul a fost izolat rapid. Apoi a apărut a doua constatare. O foaie de calcul de migrare numită customer_users_final_v7.xlsx fusese copiată din același set de date. Conținea nume, adrese de e-mail, permisiuni pe roluri, jurnale de utilizare, câmpuri privind țara, note de suport și comentarii în text liber care nu ar fi trebuit niciodată să ajungă într-un flux de testare. Fusese copiată pe o unitate partajată, descărcată de un dezvoltator, atașată la un tichet și uitată.
Până la miezul nopții, Sarah nu mai gestiona o configurare tehnică greșită. Gestiona o problemă de audit.
Compania era deja certificată ISO/IEC 27001:2022. Consiliul de administrație solicita asigurare privind GDPR înainte de lansarea pe piața UE. Clienții din servicii financiare trimiteau chestionare de due diligence DORA. Relațiile cloud și cu servicii administrate ridicau întrebări NIS2 privind lanțul de aprovizionare. Departamentul juridic putea explica obligațiile. Echipa de inginerie putea indica criptarea. Echipa de produs avea intenții declarate privind protecția datelor încă din faza de proiectare. Declarația de aplicabilitate menționa confidențialitatea și protecția PII.
Dar nimeni nu putea arăta, într-un lanț trasabil, ce PII existau, de ce erau prelucrate, cine le putea accesa, unde erau mascate, ce furnizori intrau în contact cu ele, cât timp erau păstrate și cum ar fi fost clasificat un incident conform GDPR, NIS2 sau DORA.
Exact această lacună explică importanța ISO/IEC 27701:2025 și ISO/IEC 29151:2022. Ele nu sunt simple etichete de confidențialitate. Ajută organizațiile să transforme angajamentele privind confidențialitatea în controale de protecție a PII pregătite pentru audit. ISO/IEC 27701:2025 extinde un sistem de management al securității informațiilor ISO/IEC 27001:2022 către managementul informațiilor privind confidențialitatea. ISO/IEC 29151:2022 adaugă îndrumări practice pentru protejarea informațiilor de identificare personală pe întregul lor ciclu de viață.
Abordarea Clarysec constă în construirea unui singur model operațional de confidențialitate și securitate bazat pe dovezi, nu a unor silozuri separate de conformitate. Acest model combină Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls și politicile Clarysec într-un sistem unic și trasabil pentru GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, asigurare aliniată NIST și așteptările de guvernanță COBIT 2019.
De ce protecția PII este acum o temă de audit la nivelul consiliului de administrație
Protecția PII era tratată anterior ca responsabilitate a echipei de confidențialitate. Astăzi, este o temă de încredere, reziliență și reglementare la nivelul consiliului de administrație.
GDPR rămâne baza pentru protecția datelor cu caracter personal în Europa și dincolo de aceasta. Definește datele cu caracter personal, prelucrarea, operatorul, persoana împuternicită de operator, destinatarul, terțul, consimțământul și încălcarea securității datelor cu caracter personal în moduri care afectează contractele SaaS, operațiunile de suport, analiza datelor, telemetria produsului, managementul furnizorilor și răspunsul la incidente. Principiile sale impun legalitate, echitate, transparență, limitarea scopului, minimizarea datelor, exactitate, limitarea stocării, integritate, confidențialitate și responsabilitate. Din perspectivă de audit, GDPR nu întreabă doar dacă datele sunt criptate. Întreabă dacă organizația poate demonstra de ce există datele și cum este asigurată conformitatea.
NIS2 ridică nivelul guvernanței securității cibernetice pentru entitățile esențiale și importante. Article 21 impune măsuri de management al riscurilor de securitate cibernetică, inclusiv analiza riscului, politici de securitate a sistemelor informatice, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltare securizată, gestionarea vulnerabilităților, evaluarea eficacității controalelor, igienă cibernetică, criptografie, securitate HR, controlul accesului, managementul activelor, autentificare și comunicații securizate. Article 23 adaugă raportarea etapizată a incidentelor, inclusiv o avertizare timpurie în termen de 24 de ore, notificare în termen de 72 de ore și un raport final în termen de o lună de la notificare.
DORA schimbă discuția pentru entitățile financiare și furnizorii lor TIC. Se aplică de la 17 ianuarie 2025 și instituie un regim armonizat de reziliență operațională digitală care acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței, riscul asociat terților TIC, cerințele contractuale și supravegherea furnizorilor terți critici de servicii TIC. Pentru multe entități financiare, DORA funcționează ca act juridic sectorial al Uniunii acolo unde obligațiile echivalente NIS2 se suprapun. Pentru furnizorii SaaS și TIC care deservesc instituții financiare, presiunea DORA apare adesea prin clauze contractuale, audituri ale clienților, cerințe de planificare a ieșirii, obligații de sprijin în caz de incident și testarea rezilienței.
ISO/IEC 27001:2022 oferă coloana vertebrală a sistemului de management. Impune context, părți interesate, domeniu de aplicare, responsabilitatea conducerii, politici, roluri, evaluarea riscurilor, tratarea riscurilor, Declarația de aplicabilitate, audit intern, analiza efectuată de management și îmbunătățire continuă. Anexa A include controale direct relevante pentru protecția PII, inclusiv 5.34 Confidențialitatea și protecția PII, 5.18 drepturi de acces, 8.11 mascarea datelor, 5.23 securitatea informațiilor pentru utilizarea serviciilor cloud, 8.15 jurnalizare, 8.33 informații de test, 8.24 utilizarea criptografiei și 8.10 ștergerea informațiilor.
Provocarea nu este că organizațiile nu au controale. Provocarea este că aceste controale sunt fragmentate. Înregistrările privind confidențialitatea se află la departamentul juridic. Revizuirea drepturilor de acces este la IT. Scripturile de mascare sunt la inginerie. Contractele cu furnizorii sunt la achiziții. Dovezile sunt în tichete, capturi de ecran, foi de calcul și e-mailuri.
ISO/IEC 27701:2025 și ISO/IEC 29151:2022 ajută la unificarea acestor dovezi în jurul managementului informațiilor privind confidențialitatea și al practicilor de protecție a PII. Clarysec transformă această structură într-un model operațional.
De la SMSI la PIMS: lanțul integrat de controale privind confidențialitatea
Un SMSI ISO/IEC 27001:2022 răspunde unei întrebări esențiale: securitatea informațiilor este guvernată, bazată pe risc, implementată, monitorizată și îmbunătățită?
Un sistem de management al informațiilor privind confidențialitatea, sau PIMS, extinde această întrebare pentru datele cu caracter personal: responsabilitățile privind confidențialitatea, activitățile de prelucrare PII, riscurile de confidențialitate, obligațiile operatorului și ale persoanei împuternicite de operator, drepturile persoanelor vizate și dovezile privind controalele de confidențialitate sunt gestionate în același sistem?
ISO/IEC 27701:2025 extinde SMSI către guvernanța confidențialității. ISO/IEC 29151:2022 îl completează cu îndrumări practice pentru protecția PII, inclusiv limitarea colectării, gestionarea divulgării, aplicarea mascării sau pseudonimizării, protejarea transferurilor, restricționarea accesului și alinierea controalelor la riscul de confidențialitate.
| Strat | Întrebare principală | Dovezi de audit tipice |
|---|---|---|
| ISO/IEC 27001:2022 | Există un SMSI guvernat, bazat pe risc, cu controale selectate și operaționale? | Domeniu de aplicare, părți interesate, evaluarea riscurilor, plan de tratare, SoA, politici, audit intern, analiză efectuată de management |
| ISO/IEC 27701:2025 | Responsabilitățile privind confidențialitatea, riscurile de confidențialitate și activitățile de prelucrare PII sunt guvernate în cadrul sistemului de management? | Roluri privind confidențialitatea, registru de prelucrare, proceduri pentru operator și persoană împuternicită de operator, evaluări ale riscurilor de confidențialitate, DPIA, proces pentru solicitările persoanelor vizate |
| ISO/IEC 29151:2022 | Sunt implementate măsuri practice de protecție PII pe întregul ciclu de viață al datelor? | Clasificare PII, restricții de acces, mascare, pseudonimizare, controale de păstrare, măsuri de protecție pentru transferuri, dovezi privind incidentele |
| GDPR | Poate organizația să demonstreze o prelucrare legală, echitabilă, transparentă, minimizată, securizată și responsabilă? | Înregistrări privind temeiul juridic, note de informare privind confidențialitatea, DPIA, proces privind încălcările, acorduri cu persoanele împuternicite de operator, gestionarea drepturilor |
| NIS2 și DORA | Poate organizația să guverneze riscurile de securitate cibernetică și reziliență, inclusiv incidentele și furnizorii? | Supravegherea conducerii, cadru de risc TIC, clasificarea incidentelor, playbook-uri de raportare, registre ale furnizorilor, drepturi de audit, teste de continuitate |
Acest model pe straturi previne cea mai frecventă greșeală în conformitatea privind confidențialitatea: tratarea PII ca pe încă un tip de date sensibile. PII implică obligații juridice, etice, operaționale, contractuale și reputaționale. Necesită un lanț de controale care începe cu conștientizarea datelor și se încheie cu dovezi.
Începeți cu cunoașterea datelor, nu cu diagrame de criptare
Cea mai frecventă deficiență de confidențialitate pe care o observă Clarysec este lipsa contextului. O companie nu poate proteja PII dacă nu știe ce PII deține, unde se află, ce scop deservesc, cât timp sunt păstrate sau cine le poate accesa.
Zenith Blueprint începe această activitate devreme, în faza de management al riscurilor. La pasul 9, identificarea activelor, amenințărilor și vulnerabilităților, instruiește organizațiile să inventarieze activele informaționale și să marcheze explicit datele cu caracter personal:
„Pentru fiecare activ, înregistrați detaliile-cheie: nume/descriere, proprietar, locație și clasificare (sensibilitate). De exemplu, un activ ar putea fi «Baza de date a clienților – deținută de departamentul IT – găzduită pe AWS – conține date personale și financiare (sensibilitate ridicată)».”
De asemenea, adaugă: „Asigurați-vă că activele care conțin date cu caracter personal sunt marcate (pentru relevanță GDPR) și că activele serviciilor critice sunt notate (pentru aplicabilitate potențială NIS2 dacă activați într-un sector reglementat).”
Aceasta este baza pentru adoptarea ISO/IEC 27701:2025 și ISO/IEC 29151:2022. Secvența practică este simplă:
- Identificați sistemele, seturile de date, depozitele, jurnalele, rapoartele, backup-urile, instrumentele de suport, mediile de dezvoltare și furnizorii care prelucrează PII.
- Alocați un proprietar fiecărui activ PII.
- Clasificați PII în funcție de sensibilitate, scopul organizației, temeiul juridic, rolul de prelucrare și cerința de păstrare.
- Conectați fiecare activ PII la amenințări, vulnerabilități, scenarii de risc și obligații de reglementare.
- Selectați controalele, atribuiți dovezile și monitorizați funcționarea în timp.
Politicile Clarysec fac această abordare executabilă. Politica de protecție a datelor și confidențialitate pentru IMM-uri Politica de protecție a datelor și confidențialitate - SME prevede:
„Coordonatorul pentru confidențialitate trebuie să mențină un registru al tuturor activităților de prelucrare a datelor cu caracter personal, inclusiv categoriile de date, scopul, temeiul juridic și perioadele de păstrare”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.2.1.
Pentru organizațiile enterprise, Politica de protecție a datelor și confidențialitate Politica de protecție a datelor și confidențialitate stabilește o regulă strictă de minimizare:
„Pot fi colectate și prelucrate numai datele necesare pentru un scop specific și legitim al organizației.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.1.
Aceste clauze transformă responsabilitatea GDPR în activități zilnice. Ele susțin, de asemenea, managementul informațiilor privind confidențialitatea și protecția PII, deoarece obligă organizația să definească ce date există, de ce există și dacă sunt necesare.
Cele trei controale care fac protecția PII operațională
Trei controale din Anexa A ISO/IEC 27001:2022 determină adesea dacă protecția PII poate fi susținută în audit: 5.34 Confidențialitatea și protecția PII, 8.11 mascarea datelor și 5.18 drepturi de acces.
5.34 Confidențialitatea și protecția PII
Controlul 5.34 este nucleul de guvernanță. În Zenith Controls, 5.34 este tratat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea, împreună cu conceptele de securitate cibernetică Identify și Protect și capabilități operaționale în protecția informațiilor și conformitate juridică.
Zenith Controls clarifică dependența:
„Un inventar al activelor informaționale (5.9) ar trebui să includă deținerile de date PII (baze de date ale clienților, fișiere HR). Acest lucru susține 5.34, asigurând că organizația știe ce PII are și unde se află, ceea ce reprezintă primul pas în protejarea acestora.”
Controlul 5.34 depinde de 5.9 inventarul informațiilor și al altor active asociate, deoarece PII nu pot fi protejate dacă nu pot fi găsite. De asemenea, se conectează la 5.23 securitatea informațiilor pentru utilizarea serviciilor cloud, deoarece majoritatea PII se află acum în platforme cloud, instrumente SaaS, medii de analiză și servicii administrate.
Pentru prelucrările cu risc ridicat, Politica de protecție a datelor și confidențialitate la nivel enterprise impune:
„Modelarea amenințărilor și evaluările de impact asupra protecției datelor (DPIA) sunt obligatorii pentru sistemele de prelucrare cu risc ridicat.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.4.
Această clauză este critică. Transformă confidențialitatea într-o activitate de proiectare și management al riscurilor, nu într-o revizuire juridică de ultim moment.
8.11 mascarea datelor
Controlul 8.11 este răspunsul direct la expunerea bazei de date de staging a Sarei. Zenith Controls descrie 8.11 ca un control preventiv de confidențialitate în cadrul protecției informațiilor. Leagă 8.11 de 5.12 clasificarea informațiilor, deoarece deciziile de mascare depind de sensibilitate, de 5.34, deoarece mascarea susține protecția confidențialității, și de 8.33 informații de test, deoarece mediile de testare nu ar trebui să expună PII reale.
Politica privind mascarea datelor și pseudonimizarea Politica privind mascarea datelor și pseudonimizarea formulează regula explicit:
„Datele reale cu caracter personal nu trebuie utilizate în medii de dezvoltare, testare sau staging. În schimb, trebuie utilizate date mascate sau pseudonimizate, generate pe baza unor șabloane de transformare aprobate în prealabil.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.
Pentru IMM-uri, Politica privind mascarea datelor și pseudonimizarea pentru SME Politica privind mascarea datelor și pseudonimizarea - SME adaugă o cerință-cheie de securitate și dovezi:
„Accesul la chei trebuie protejat prin criptare, control al accesului și jurnalizare.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.1.3.
Acest lucru contează deoarece pseudonimizarea reduce riscul numai atunci când logica de transformare, cheile și căile de reidentificare sunt controlate.
5.18 drepturi de acces
Controlul 5.18 este nucleul operațional al principiului privilegiului minim. Zenith Controls îl tratează ca preventiv, legat de confidențialitate, integritate și disponibilitate, și plasat în zona de management al identității și accesului. Leagă 5.18 de 5.15 controlul accesului, 5.16 managementul identității și 8.2 drepturi de acces privilegiat.
Politica de clasificare și etichetare a datelor pentru SME Politica de clasificare și etichetare a datelor - SME prevede:
„Accesul trebuie limitat la utilizatori autorizați în mod specific, pe baza principiului necesității de a cunoaște.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.2.1.
Politica de clasificare și etichetare a datelor la nivel enterprise Politica de clasificare și etichetare a datelor adaugă baza de clasificare:
„Toate activele informaționale trebuie să aibă o clasificare atribuită clar la momentul creării sau al înregistrării în inventar. În absența unei clasificări explicite, activele trebuie încadrate implicit ca «Confidențial» până la revizuirea formală.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.
Împreună, aceste controale formează lanțul practic de protecție a PII: identificați PII, clasificați-le, limitați accesul, mascați-le acolo unde identitatea completă nu este necesară, protejați cheile, jurnalizați accesul și păstrați dovezile.
Construiți trasabilitatea prin Declarația de aplicabilitate
Un sistem de management al confidențialității devine pregătit pentru audit atunci când poate demonstra trasabilitatea. Zenith Blueprint, faza de management al riscurilor, pasul 13, planificarea tratării riscurilor și Declarația de aplicabilitate, descrie Declarația de aplicabilitate ca document de legătură:
„SoA este, în fapt, un document de legătură: conectează evaluarea/tratamentul riscurilor la controalele concrete pe care le aveți. Prin completarea lui, verificați și dacă ați omis vreun control.”
Acest concept este central pentru pregătirea ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 și DORA. Fiecare control PII ar trebui să fie trasabil de la cerință la risc, de la risc la control, de la control la proprietar, de la proprietar la dovezi și de la dovezi la revizuire.
| Element de trasabilitate | Exemplu pentru PII din suportul pentru clienți | Dovezi așteptate |
|---|---|---|
| Activ PII | Platformă de ticketing de suport cu nume ale clienților, e-mailuri, jurnale și atașamente | Înregistrare în Registrul activelor, proprietar, locație cloud, clasificare |
| Scopul prelucrării | Suport pentru clienți și diagnosticarea serviciului | Registru de prelucrare, temei juridic, perioadă de păstrare |
| Scenariu de risc | Agentul de suport sau dezvoltatorul accesează excesiv datele clienților | Înregistrare în Registrul de riscuri, probabilitate, impact, proprietar |
| Selectarea controlului | 5.34 protecția PII, 5.18 drepturi de acces, 8.11 mascare, 8.15 jurnalizare, 5.23 guvernanță cloud | SoA, politică de acces, standard de mascare, configurație de jurnalizare |
| Dovezi operaționale | Acces bazat pe roluri, exporturi mascate, revizuirea trimestrială a accesului, alertare la descărcări în masă | Înregistrări ale revizuirilor de acces, alerte DLP, jurnale, dovezi din tichete |
| Mapare reglementară | Responsabilitate și securitate GDPR, managementul riscurilor NIS2, risc TIC DORA și cerințe privind furnizorii | Matrice de conformitate, playbook de incident, registru al contractelor cu furnizorii |
| Dovezi de revizuire | Constatare de audit intern închisă, acțiune rezultată din analiza efectuată de management acceptată | Raport de audit, acțiune corectivă, proces-verbal al analizei efectuate de management |
ISO/IEC 27005:2022 susține această abordare bazată pe risc, punând accent pe cerințele părților interesate, criterii comune de risc, proprietari de risc responsabili, evaluare repetabilă a riscurilor, tratarea riscurilor, selectarea controalelor, alinierea Declarației de aplicabilitate, aprobarea riscului rezidual, monitorizare și îmbunătățire continuă. Protecția PII ar trebui să fie un ciclu viu de risc, nu un exercițiu unic de documentare GDPR.
Remediați foaia de calcul riscantă și baza de date de staging
Incidentul Sarei poate fi transformat într-un pachet de controale repetabil dacă remedierea este gestionată sistematic.
| Pas | Acțiune | Rezultat al dovezilor Clarysec |
|---|---|---|
| 1 | Înregistrați baza de date de staging și foaia de calcul ca active PII | Înregistrări în inventarul activelor cu proprietar, locație, clasificare, categorii PII, scop și perioadă de păstrare |
| 2 | Actualizați activitatea de prelucrare | Înregistrare în registru care indică categoriile de date, temeiul juridic, scopul și perioada de păstrare |
| 3 | Clasificați fișierele și seturile de date | Clasificare Confidențial sau superioară aplicată implicit până la revizuirea formală |
| 4 | Eliminați PII reale din mediile care nu sunt de producție | Set de date mascat sau pseudonimizat, generat pe baza șabloanelor de transformare aprobate |
| 5 | Restricționați și revizuiți accesul | Permisiuni pe baza principiului necesității de a cunoaște, acces excesiv revocat, înregistrare de revizuire a accesului |
| 6 | Protejați logica de transformare și cheile | Acces la chei protejat prin criptare, control al accesului și jurnalizare |
| 7 | Colectați dovezile centralizat | Înregistrare de activ, înregistrare de risc, revizuire a accesului, dovadă de ștergere, aprobare de mascare și închidere de tichet |
| 8 | Actualizați SoA și planul de tratare a riscurilor | Scenariu de risc legat de 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 și controalele privind furnizorii |
| 9 | Decideți dacă este necesară o DPIA | DPIA sau justificare documentată pentru deciziile privind prelucrarea cu risc ridicat |
| 10 | Înregistrați lecțiile învățate | Instruire actualizată, reguli de dezvoltare securizată, controale de export, monitorizare DLP și îndrumări privind datele de test |
Politica de audit și monitorizare a conformității pentru IMM-uri Politica de audit și monitorizare a conformității - SME prevede:
„Toate dovezile trebuie stocate într-un dosar centralizat de audit.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.1.
Politica de securitate a informațiilor Politica de securitate a informației face explicită așteptarea mai largă privind auditul:
„Toate controalele implementate trebuie să fie verificabile, susținute de proceduri documentate și de dovezi păstrate privind funcționarea lor.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.6.1.
Aceste două clauze fac diferența dintre a avea un control și a-l putea demonstra.
Mapare de conformitate transversală pentru un singur set de controale PII
Protecția PII devine mai ușor de susținut atunci când este mapată între cadre înainte ca auditorul să întrebe.
| Temă de protecție PII | Relevanță GDPR | Relevanță ISO/IEC 27001:2022, ISO/IEC 27701:2025 și ISO/IEC 29151:2022 | Relevanță NIS2 | Relevanță DORA | Perspectivă de audit NIST și COBIT 2019 |
|---|---|---|---|---|---|
| Inventar PII și registru de prelucrare | Responsabilitate, temei juridic, limitarea scopului, limitarea stocării | Context SMSI, 5.9 inventarul activelor, managementul informațiilor privind confidențialitatea, protecția PII | Managementul activelor și analiza riscului | Cunoașterea dependențelor de active și servicii TIC | Dovezi pentru funcția Identify și guvernanță asupra activelor informaționale |
| Drepturi de acces și principiul privilegiului minim | Integritate și confidențialitate, acces limitat pe rol | 5.15 controlul accesului, 5.16 managementul identității, 5.18 drepturi de acces, 8.2 drepturi de acces privilegiat | Controlul accesului, securitate HR, autentificare | Controale de risc TIC și supravegherea accesului privilegiat | Aplicarea accesului, responsabilitate, asumarea proprietății și monitorizare |
| Mascare și pseudonimizare | Minimizarea datelor, protecția datelor încă din faza de proiectare, securitatea prelucrării | 5.12 clasificare, 5.34 protecția PII, 8.11 mascarea datelor, 8.33 informații de test | Igienă cibernetică și dezvoltare securizată | Testare securizată, reducerea pierderii datelor, reziliență operațională | Testarea măsurilor tehnice de protecție și funcționarea fiabilă a controalelor |
| Clasificarea și raportarea incidentelor | Evaluarea și notificarea încălcării securității datelor cu caracter personal | Planificarea incidentelor, evaluarea evenimentelor, răspuns, colectarea dovezilor | Avertizare timpurie în 24 de ore, notificare în 72 de ore, raport final | Clasificarea și raportarea incidentelor majore legate de TIC | Criterii de escaladare, jurnale decizionale, cauza principală, remediere |
| Prelucrare prin furnizori și cloud | Obligațiile persoanei împuternicite de operator, transferuri, contracte | 5.21 lanțul de aprovizionare TIC, 5.23 servicii cloud, 5.31 cerințe juridice și contractuale | Securitatea lanțului de aprovizionare | Riscul asociat terților TIC, drepturi de audit, ieșire și tranziție | Guvernanța terților, asigurare și responsabilitatea managementului |
Aici Zenith Controls este deosebit de util. Pentru 5.34, mapează protecția PII la inventarul activelor, mascarea datelor și guvernanța cloud. Pentru 8.11, mapează mascarea la clasificare, protecția confidențialității și informații de test. Pentru 5.18, mapează drepturile de acces la controlul accesului, managementul identității și acces privilegiat. Aceste relații permit unei echipe să explice nu doar că un control există, ci de ce există și ce controale adiacente trebuie să funcționeze împreună cu acesta.
Cum testează auditori diferiți același control PII
Un singur control, cum ar fi 8.11 mascarea datelor, va fi examinat diferit în funcție de perspectiva de audit.
| Tip de auditor | Focalizare principală | Dovezi pe care le va aștepta |
|---|---|---|
| Auditor ISO/IEC 27001:2022 și ISO/IEC 27701:2025 | Integrarea SMSI și PIMS, tratarea riscurilor, acuratețea SoA | Evaluarea riscurilor, înregistrare SoA, politică de mascare, înregistrări ale schimbărilor, rezultate ale auditului intern |
| Revizor GDPR sau al autorității de protecție a datelor | Protecția datelor încă din faza de proiectare, minimizare, responsabilitate | Registru de prelucrare, temei juridic, DPIA, dovezi de pseudonimizare, logică de păstrare |
| Evaluator NIS2 | Dezvoltare securizată, prevenirea incidentelor, guvernanță | Procedură de dezvoltare securizată, instruirea dezvoltatorilor, dovezi de remediere a incidentelor, revizuirea eficacității controalelor |
| Client sau auditor DORA | Reziliență operațională TIC și risc asociat terților | Dovezi de testare a aplicațiilor critice, clauze contractuale ale furnizorilor, obligații de sprijin în caz de incident, planificarea recuperării și ieșirii |
| Revizor aliniat NIST sau COBIT 2019 | Proiectarea controlului, funcționare, responsabilitate, monitorizare | Proprietar de control, metrici, depozit securizat, raportare către management, acțiuni corective |
Un auditor ISO/IEC 27001:2022 începe cu logica sistemului de management. PII se află în domeniul de aplicare? Cerințele părților interesate sunt identificate? Riscurile de confidențialitate sunt evaluate folosind criterii definite? Controalele sunt selectate prin tratarea riscurilor? SoA este corectă? Auditul intern și analizele efectuate de management acoperă controalele legate de PII?
Un revizor de confidențialitate începe cu responsabilitatea. Ce date cu caracter personal sunt prelucrate? Care este temeiul juridic? Persoanele vizate sunt informate? Prelucrarea este limitată la un scop specific? Activitățile cu risc ridicat sunt evaluate? Persoanele împuternicite de operator sunt guvernate?
Un evaluator axat pe NIS2 începe cu guvernanța și managementul riscurilor de securitate cibernetică. Managementul aprobă și supraveghează măsurile? Gestionarea incidentelor, continuitatea, securitatea furnizorilor, controlul accesului, managementul activelor, dezvoltarea securizată și evaluarea eficacității controalelor sunt integrate?
Un client sau auditor DORA întreabă dacă managementul riscurilor TIC este documentat, guvernat de consiliul de administrație, proporțional și susținut prin contracte. Dacă PII sunt prelucrate în servicii care susțin entități financiare, așteptați-vă la întrebări despre asistența în caz de incident, locațiile de prelucrare a datelor, recuperare, drepturi de audit, niveluri de serviciu, încetare și ieșire.
Un revizor COBIT 2019 sau aliniat ISACA testează alinierea guvernanței. Cine deține riscul PII? Ce organism de guvernanță primește raportări? Sunt responsabilitățile atribuite? Furnizorii sunt monitorizați? Abaterile sunt urmărite? Sunt utilizate metrici pentru luarea deciziilor? Riscul rezidual este acceptat formal?
Un singur model de dovezi poate satisface toate aceste perspective, dar numai dacă sistemul de control este proiectat pentru trasabilitate încă de la început.
Constatări de audit frecvente în programele de protecție PII
Organizațiile care abordează pregătirea ISO/IEC 27701:2025 sau ISO/IEC 29151:2022 fără un set integrat de instrumente întâlnesc adesea aceleași constatări.
| Constatare | De ce contează | Remediere Clarysec |
|---|---|---|
| Inventarul PII exclude jurnale, backup-uri, exporturi de analiză sau atașamente de suport | PII ascunse nu pot fi protejate sau șterse în mod fiabil | Extindeți inventarul activelor de la pasul 9 și registrul de prelucrare pentru a include toate locațiile PII |
| Mediile de testare utilizează date de producție | PII reale sunt expuse acolo unde nu sunt necesare | Aplicați politica de mascare și șabloanele de transformare aprobate |
| Revizuirile de acces sunt generice și nu se concentrează pe depozitele PII | Accesul excesiv rămâne nedetectat | Mapați 5.18 drepturi de acces la proprietarii activelor PII și la dovezile de revizuire periodică |
| Temeiul juridic este documentat, dar nu este legat de sisteme sau păstrare | Responsabilitatea GDPR nu poate fi demonstrată | Adăugați câmpuri pentru temei juridic și păstrare în registrul de prelucrare și inventarul activelor |
| Contractele cu furnizorii nu includ locația datelor, asistență în caz de incident, drepturi de audit sau prevederi de ieșire | Rămân lacune de asigurare privind furnizorii pentru DORA, NIS2 și GDPR | Aliniați verificarea prealabilă a furnizorilor și contractele la guvernanța terților TIC și cloud |
| Playbook-urile de incidente nu disting incidentele de securitate de încălcările securității datelor cu caracter personal | Termenele de raportare pot fi ratate | Construiți arbori decizionali de clasificare pentru declanșatoarele de raportare GDPR, NIS2 și DORA |
| Dovezile sunt dispersate în tichete, unități partajate, capturi de ecran și e-mail | Pregătirea pentru audit eșuează chiar și atunci când controalele funcționează | Utilizați dosare centralizate de audit și standarde de denumire a dovezilor |
Aceste constatări nu sunt probleme de documentație. Sunt probleme de model operațional. ISO/IEC 27701:2025 și ISO/IEC 29151:2022 nu le vor remedia decât dacă guvernanța confidențialității, controalele de securitate și gestionarea dovezilor sunt integrate în fluxurile normale de lucru.
Ce ar trebui să întrebe managementul înainte de următorul audit
Înainte de a urmări pregătirea ISO/IEC 27701:2025, implementarea ISO/IEC 29151:2022 sau o evaluare de client pentru GDPR, NIS2 ori DORA, managementul ar trebui să adreseze zece întrebări directe:
- Avem un registru complet al activităților de prelucrare PII, inclusiv categoriile de date, scopul, temeiul juridic și perioada de păstrare?
- Activele PII sunt marcate în inventarul activelor, inclusiv jurnale, backup-uri, exporturi, instrumente de analiză și atașamente de suport?
- Clasificările datelor sunt atribuite la creare sau la înregistrarea în inventar, iar activele nerevizuite sunt încadrate implicit ca Confidențial?
- Putem demonstra că accesul la PII este limitat la utilizatori autorizați pe baza principiului necesității de a cunoaște?
- Mediile de dezvoltare, testare și staging utilizează date mascate sau pseudonimizate în locul datelor reale cu caracter personal?
- Șabloanele de mascare sunt aprobate, iar cheile sunt protejate, controlate prin acces și jurnalizate?
- SoA conectează riscurile PII la controale și obligații de reglementare?
- Contractele cloud și cu furnizorii sunt revizuite pentru locația datelor, securitate, sprijin în caz de incident, drepturi de audit, recuperare și ieșire?
- Procesul nostru de gestionare a incidentelor poate clasifica încălcările securității datelor cu caracter personal conform GDPR, incidentele semnificative NIS2 și incidentele majore legate de TIC conform DORA?
- Dovezile sunt stocate centralizat și păstrate într-un mod pe care un auditor îl poate urmări?
Dacă răspunsul la oricare dintre aceste întrebări este neclar, organizația nu este încă pregătită pentru audit.
Faceți protecția PII demonstrabilă
Incidentul nocturn al Sarei s-ar fi putut transforma într-o reacție fragmentată de conformitate. În schimb, poate deveni punctul de plecare pentru un model operațional mai solid: un SMSI ISO/IEC 27001:2022 extins către confidențialitate prin ISO/IEC 27701:2025, consolidat de practicile ISO/IEC 29151:2022 și mapat la GDPR, NIS2, DORA, asigurare aliniată NIST și așteptările de guvernanță COBIT 2019.
Aceasta este valoarea reală a protecției PII pregătite pentru audit. Nu depinde de găsirea foii de calcul potrivite înainte de sosirea auditorului. Depinde de un sistem care știe deja unde sunt PII, de ce există, cum sunt protejate, cine este responsabil, ce furnizori sunt implicați și unde se află dovezile.
Începeți cu Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru a vă structura implementarea. Utilizați Zenith Controls: The Cross-Compliance Guide Zenith Controls pentru a mapa protecția PII între ISO/IEC 27001:2022, GDPR, NIS2, DORA, asigurare aliniată NIST și așteptările de guvernanță COBIT 2019. Operaționalizați activitatea cu politicile Clarysec, inclusiv Politica de protecție a datelor și confidențialitate Politica de protecție a datelor și confidențialitate, Politica privind mascarea datelor și pseudonimizarea Politica privind mascarea datelor și pseudonimizarea, Politica de clasificare și etichetare a datelor Politica de clasificare și etichetare a datelor, Politica de audit și monitorizare a conformității pentru SME Politica de audit și monitorizare a conformității - SME și Politica de securitate a informației Politica de securitate a informației.
Dacă următorul audit al unui client, revizuirea GDPR, proiectul de pregătire NIS2 sau evaluarea de furnizor DORA se apropie, nu așteptați o încălcare care să expună lacunele. Descărcați seturile de instrumente Clarysec, solicitați o demonstrație sau programați o evaluare a protecției PII și construiți un program de confidențialitate care nu este doar conform, ci și demonstrabil.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
