Guvernanța accesului la PII pentru ISO 27701:2025 și GDPR

Întrebarea auditorului extern a rămas suspendată în aer, aparent simplă.

„Îmi puteți arăta jurnalul revizuirii accesului pentru accesul echipei de suport la PII din producție în ultimul trimestru?”

Pentru Anya, CISO la Medtelligence, un furnizor SaaS de tehnologie medicală aflat în creștere rapidă, acesta era momentul decisiv. Medtelligence acționează ca persoană împuternicită de operator pentru PII în relația cu spitalele și gestionează date sensibile ale pacienților într-o platformă cloud. Compania avea autentificare puternică, roluri definite și o echipă de inginerie matură. Dar auditorul nu întreba dacă exista o pagină de autentificare. Cerea dovada că accesul la date cu caracter personal era guvernat în timp.

Voia să vadă cine putea accesa PII din producție, de ce avea acces, când fusese aprobat accesul, dacă mai era necesar, dacă activitatea de suport era jurnalizată și dacă permisiunile inutile fuseseră eliminate.

Anya a deschis consola IAM. Existau ingineri de suport, administratori de baze de date, un cont de serviciu pentru integrare, un furnizor de servicii administrate, două roluri de acces de urgență și un fost contractor încă prezent într-un grup, deoarece tichetul de încetare a colaborării fusese închis înainte de eliminarea dreptului de acces. HR indica faptul că persoana plecase cu șase săptămâni înainte. Fișierul de calcul pentru revizuirea accesului indica „în așteptare”. SIEM avea jurnale, dar nimeni nu mapase evenimentele care dovedeau accesul la PII.

Aici devine reală guvernanța confidențialității.

Conform GDPR, datele cu caracter personal trebuie prelucrate cu integritate și confidențialitate, protejate împotriva prelucrării neautorizate sau ilegale, a pierderii accidentale, a distrugerii sau a deteriorării, prin măsuri tehnice și organizatorice adecvate. GDPR stabilește explicit și responsabilitatea: operatorul trebuie să poată demonstra conformitatea. ISO/IEC 27701:2025 transformă această responsabilitate într-un sistem de management al informațiilor privind confidențialitatea, sau PIMS, în care accesul la PII nu mai este o considerație tehnică secundară. Devine un ciclu de viață guvernat la nivel de roluri, persoane împuternicite de operator, platforme cloud, angajați, administratori privilegiați, jurnale, revizuiri, contracte și dovezi.

Pentru multe organizații, lacuna nu este lipsa controlului accesului. Lacuna este incapacitatea de a demonstra consecvent guvernanța accesului la PII în raport cu ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 și COBIT 2019.

Guvernanța accesului la PII nu înseamnă doar IAM

Un program IAM tradițional întreabă: „Pot utilizatorii potriviți să acceseze sistemele potrivite?”

Un PIMS matur conform ISO/IEC 27701:2025 pune întrebări mai dificile:

• Ce sisteme prelucrează PII?
• Ce roluri necesită acces la ce categorii de PII?
• Organizația acționează ca operator PII, persoană împuternicită de operator pentru PII, operator asociat sau persoană subîmputernicită?
• Accesul este limitat de scop, de o nevoie de business documentată și de principiul privilegiului minim?
• Acțiunile privilegiate sunt jurnalizate și revizuite?
• Organizația poate demonstra că accesul persoanelor împuternicite de operator și al persoanelor subîmputernicite este controlat contractual?
• Căile de suport cloud, izolarea mediului clientului, exporturile și acțiunile administrative sunt incluse în dovezi?
• Deciziile de acces sunt revizuite după angajare, schimbare de rol, incident, încetarea colaborării și modificare semnificativă a sistemului?

De aceea, guvernanța securității PII și a controlului accesului reprezintă o punte naturală între ISO/IEC 27701:2025 și GDPR. GDPR oferă cadrul juridic al responsabilității. ISO/IEC 27701:2025 operaționalizează managementul confidențialității pentru operatori și persoane împuternicite de operator. ISO/IEC 27001:2022 oferă mecanismul de management al riscurilor al SMSI. ISO/IEC 27002:2022 oferă arhitectura controalelor, inclusiv confidențialitatea și protecția PII, controlul accesului, drepturile de acces, jurnalizarea, serviciile cloud, relațiile cu furnizorii, clasificarea, ștergerea, mascarea și criptografia.

Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului de la Clarysec plasează acest subiect în faza Controale în acțiune. În pasul 23, care acoperă controalele organizaționale 5.19 până la 5.37, acesta descrie controlul ISO/IEC 27002:2022 5.34, Confidențialitatea și protecția PII, ca pe o chestiune de încredere, nu doar ca pe o problemă de date:

informațiile de identificare personală nu sunt doar un alt tip de date; ele reprezintă o formă profund sensibilă de încredere. Nume, adrese, ID-uri, evidențe medicale, detalii financiare: aceste date spun o poveste despre persoane reale.

Același pasaj oferă fundamentul practic: protecția confidențialității începe cu cunoașterea datelor. O organizație trebuie să știe ce PII colectează, unde se află, de ce sunt prelucrate și cine le poate accesa.

Presiunea de conformitate din spatele controlului accesului la PII

Guvernanța accesului la PII nu mai este o problemă a unui singur cadru. Organizații precum Medtelligence operează la intersecția dintre reglementarea confidențialității, legislația privind securitatea cibernetică, reziliența operațională, asigurarea solicitată de clienți și certificarea de securitate.

GDPR Article 5 impune ca datele cu caracter personal să fie prelucrate potrivit principiilor legalității, echității, transparenței, limitării scopului, reducerii la minimum a datelor, exactității, limitării stocării, integrității și confidențialității. Article 5(2) introduce responsabilitatea: operatorul este responsabil și trebuie să poată demonstra conformitatea. Article 32 impune apoi măsuri tehnice și organizatorice adecvate pentru securitatea prelucrării.

NIS2 Article 21 impune entităților esențiale și importante să adopte măsuri tehnice, operaționale și organizatorice adecvate și proporționale pentru managementul riscurilor de securitate cibernetică. Domeniile minime includ analiza riscurilor, politici de securitate, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și dezvoltarea securizate, evaluarea eficacității, igiena cibernetică și instruirea, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor și, acolo unde este cazul, autentificarea multifactor sau autentificarea continuă și comunicațiile securizate. Article 20 atribuie, de asemenea, organelor de conducere responsabilitatea de a aproba și supraveghea măsurile de management al riscurilor de securitate cibernetică.

DORA se aplică de la 17 ianuarie 2025 unei game largi de entități financiare și creează un regim sectorial specific de reziliență operațională. Acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale, schimbul de informații, riscul asociat terților TIC și acordurile contractuale cu furnizorii terți de servicii TIC. Pentru entitățile financiare și furnizorii de servicii TIC care le susțin, controlul accesului nu este doar o problemă de confidențialitate. Este parte a rezilienței operaționale.

ISO/IEC 27001:2022 integrează aceste obligații într-un sistem de management bazat pe risc. Clauzele 6.1.1 până la 6.1.3 cer organizațiilor să abordeze riscurile și oportunitățile, să definească un proces de evaluare a riscurilor de securitate a informației, să identifice riscurile pentru confidențialitate, integritate și disponibilitate, să evalueze riscurile, să selecteze opțiuni de tratare, să determine controale, să compare controalele selectate cu Annex A, să documenteze Declarația de aplicabilitate, să obțină aprobarea proprietarului de risc și să accepte riscurile reziduale. Clauzele 8.2 și 8.3 impun evaluări ale riscurilor la intervale planificate sau după schimbări semnificative, precum și implementarea planului de tratare a riscurilor cu rezultate documentate.

Pentru guvernanța PII, aceasta înseamnă că controlul accesului nu este o setare IAM izolată. Este o decizie de tratare a riscurilor. Un rol care poate exporta evidențe salariale, date ale pacienților, detalii de plată, documente de identitate, date de localizare sau transcrieri ale suportului pentru clienți trebuie justificat în Registrul de riscuri, reflectat în Declarația de aplicabilitate, aplicat în IAM, jurnalizat în producție, revizuit periodic și eliminat atunci când nu mai este necesar.

Modelul de control Clarysec: de la promisiunea de confidențialitate la dovezi

Clarysec tratează guvernanța accesului la PII ca pe un lanț de dovezi. Lanțul începe cu inventarul datelor și definirea rolurilor, continuă prin aprobarea și aplicarea accesului și se încheie cu monitorizare, revizuire, revocare și înregistrări pregătite pentru audit.

În Zenith Controls: ghidul de conformitate transversală, subiectul se află în principal în jurul a trei controale ISO/IEC 27002:2022:

Auditorii acceptă rar afirmația „folosim IAM” ca dovadă. Ei se așteaptă să vadă cum deciziile IAM sunt legate de obligațiile de confidențialitate, proprietatea asupra sistemelor, clasificarea datelor, nevoia de business, tratarea riscurilor, frecvența revizuirii accesului, perimetrul jurnalizării și contractele cu furnizorii.

Politica de securitate PII și control al accesului de la Clarysec stabilește baza în limbaj PIMS:

[Both] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să restricționeze accesul la PII la roluri aprobate și utilizatori autorizați, înregistrați sau trasabili în REG02 sau REG12, înainte ca accesul să fie activat.

Din secțiunea „4.2 Baza de referință pentru controlul accesului”, clauza de politică 4.2.1.

Eticheta „[Both]” înseamnă că acest control se aplică indiferent dacă organizația acționează ca operator PII sau ca persoană împuternicită de operator pentru PII. Distincția contează. Operatorii nu reușesc adesea să definească reguli de acces bazate pe scop. Persoanele împuternicite de operator nu reușesc adesea să demonstreze că accesul este limitat la instrucțiunile clientului, la căi de suport aprobate și la personal autorizat contractual.

Aceeași politică ridică nivelul cerinței pentru PII sensibile sau cu impact ridicat:

[Both] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să revizuiască accesul utilizatorilor la sistemele care prelucrează PII cu impact ridicat sau sensibile cel puțin trimestrial și să înregistreze rezultatul revizuirii în REG12.

Din secțiunea „4.2 Baza de referință pentru controlul accesului”, clauza de politică 4.2.3.

Aici un PIMS devine auditabil. Revizuirea accesului nu este doar un e-mail de la un manager. Este o înregistrare în REG12, legată de un sistem, o categorie de date, un rol, un proprietar, rezultatul revizuirii și o acțiune de remediere.

Fundamentul politicilor: privilegiu minim, nevoie de business și blocare implicită

Guvernanța eficace începe cu reguli aplicabile. Înainte ca Anya să poată arăta auditorului un jurnal al revizuirii accesului, trebuia să arate că cerința privind revizuirile accesului fusese stabilită formal.

Politica de control al accesului pentru IMM-uri de la Clarysec stabilește principiul:

Această politică aplică principiul privilegiului minim și impune ca accesul să fie limitat la minimul necesar pentru îndeplinirea atribuțiilor postului.

Din secțiunea „Scop”, clauza de politică 1.3.

Politica de protecție a datelor și confidențialitate pentru IMM-uri leagă accesul de nevoia de business:

Accesul utilizatorilor la date cu caracter personal trebuie limitat la rolurile cu o nevoie de business documentată

Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.2.

Pentru organizații mai mari, Politica de protecție a datelor și confidențialitate pentru întreprinderi exprimă așteptarea de control ca cerință de sistem:

Toate sistemele trebuie să aplice implicit accesul pe baza principiului privilegiului minim.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.1.

Distincția este importantă. O companie mai mică poate avea nevoie de o evidență simplă, dar explicită, a nevoii de business. O întreprindere are nevoie de aplicare la nivel de sistem, revizuire periodică, separarea atribuțiilor, guvernanța accesului privilegiat și dovezi păstrate pentru audit intern, asigurare solicitată de clienți, solicitări ale autorităților de reglementare și investigarea încălcărilor securității datelor.

Ciclul de viață al accesului la PII: aprobare, utilizare, revizuire, revocare

Cea mai frecventă deficiență a accesului la PII nu este aprobarea inițială. Este persistența accesului.

Zenith Blueprint, în faza Controale în acțiune, pasul 22, explică astfel controlul ISO/IEC 27002:2022 5.18, Drepturi de acces:

Controlul 5.18 asigură că drepturile de acces nu sunt doar acordate corespunzător, ci și revizuite, ajustate și revocate într-un mod controlat și trasabil.

Apoi descrie scenarii familiare: un nou angajat primește acces, își schimbă rolul și păstrează permisiuni vechi; un fost administrator pleacă, dar un token rămâne activ; un cont de contractor expiră pe hârtie, dar nu și în IAM. Acestea sunt exact punctele slabe care devin incidente de securitate GDPR atunci când sunt implicate PII.

Politica privind gestionarea conturilor de utilizator și a privilegiilor pentru IMM-uri de la Clarysec stabilește o frecvență de bază:

O revizuire a tuturor conturilor de utilizator și a privilegiilor trebuie efectuată la fiecare șase luni.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.1.

Pentru medii de întreprindere, Politica privind gestionarea conturilor de utilizator și a privilegiilor întărește ritmul operațional:

Revizuiri trimestriale ale tuturor conturilor de utilizator și ale privilegiilor asociate trebuie efectuate de Securitatea IT în colaborare cu managerii de departament.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.5.1.

Un ciclu practic de viață al accesului la PII trebuie să includă:

1. Clasificarea sistemului și a categoriilor de PII.
2. Definirea rolurilor aprobate și a nevoii de business documentate.
3. Maparea rolurilor la scopurile prelucrării.
4. Aprobarea accesului înainte de activare.
5. Aplicarea principiului privilegiului minim, a separării atribuțiilor și a autentificării puternice.
6. Jurnalizarea autentificării, accesului, exportului, configurării și acțiunilor privilegiate.
7. Revizuirea accesului cu o frecvență stabilită pe baza riscului.
8. Eliminarea accesului la schimbarea rolului, încetarea colaborării, închiderea proiectului, expirarea contractului sau instrucțiunea clientului.
9. Păstrarea dovezilor în registrul PIMS și în pista de audit.

Aceasta nu este birocrație. Este modul în care o organizație demonstrează că accesul la PII este controlat prin proiectare, implicit și prin dovezi.

Exemplu practic: revizuirea trimestrială a accesului la PII

Auditul Anyei a reușit atunci când a mutat discuția de la declarații de politică la dovezi.

Mai întâi, a citat Politica de securitate PII și control al accesului, clauza 4.2.3, care impunea revizuirea trimestrială a accesului la PII cu impact ridicat sau sensibile și înregistrarea rezultatului revizuirii în REG12.

Apoi a parcurs împreună cu auditorul trimestrul anterior:

• IT a generat o listă a tuturor utilizatorilor, grupurilor, rolurilor privilegiate, conturilor de serviciu, conturilor furnizorilor, rolurilor de acces de urgență și permisiunilor de suport pentru baza de date de producție care conținea date ale pacienților.
• Lista a fost transmisă Proprietarului de aplicație, directorul departamentului de Succes al clienților, care deținea nevoia operațională a echipei de suport.
• Proprietarul de aplicație a revizuit lista linie cu linie în raport cu rolul curent, responsabilitatea de suport pentru clienți și scopul prelucrării.
• Doi agenți de suport care se mutaseră în alte echipe au fost marcați pentru revocare.
• A fost creat un tichet în sistemul de management al serviciilor IT, legat de revizuirea accesului, cu SLA atribuit, și închis după revocare.
• REG12 a fost actualizat cu înregistrarea revizuirii, aprobatorul, excepțiile, tichetul de remediere, dovada închiderii și data următoarei revizuiri.

Rezultatul a fost un lanț de dovezi în buclă închisă. Anya nu a spus doar că Medtelligence folosește principiul privilegiului minim. A arătat cerința din politică, proprietarul responsabil, lista de acces, decizia de revizuire, acțiunea corectivă și revocarea finalizată.

Aceasta este diferența dintre controlul accesului și guvernanța accesului.

Accesul furnizorilor și al persoanelor împuternicite de operator: punctul orb în auditurile PIMS

Multe riscuri de acces neautorizat apar prin suport, externalizare, parteneri de integrare, furnizori de servicii administrate și persoane subîmputernicite. O persoană împuternicită de operator poate avea acces la distanță la datele de producție ale clientului. Un furnizor cloud poate asigura căi de acces pentru suport. O persoană subîmputernicită poate întreține un index de căutare care conține identificatori ai clienților. Un furnizor administrat de servicii de securitate poate accesa jurnale care conțin date cu caracter personal.

Conform GDPR, operatorii trebuie să utilizeze persoane împuternicite de operator care oferă garanții suficiente. Conform ISO/IEC 27701:2025, guvernanța persoanelor împuternicite de operator și a persoanelor subîmputernicite trebuie operaționalizată prin instrucțiuni documentate, controale contractuale, asigurare și monitorizare. ISO/IEC 27002:2022 susține acest lucru prin controale privind relațiile cu furnizorii, inclusiv 5.19 Securitatea informației în relațiile cu furnizorii, 5.20 Abordarea securității informației în acordurile cu furnizorii și 5.21 Managementul securității informației în lanțul de aprovizionare TIC.

Zenith Blueprint, în faza Controale în acțiune, pasul 23, sintetizează ariile de dovezi pentru acordurile cu furnizorii, inclusiv:

✓ Responsabilități privind controlul accesului, cum ar fi cine poate accesa datele dvs., cum sunt gestionate credențialele și ce monitorizare este implementată;

Include, de asemenea, obligații de confidențialitate, măsuri tehnice și organizatorice, termene de raportare a incidentelor, drepturi de audit, controale ale subcontractanților și dezactivarea conturilor la finalul contractului.

Politica de management al confidențialității pentru persoanele împuternicite de operator, persoanele subîmputernicite și terți de la Clarysec transformă aceste cerințe în dovezi PIMS din perspectiva operatorului:

[Controller] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să verifice, înainte de aprobare, că câmpurile de control contractual pentru persoana împuternicită de operator din REG08 acoperă sfera prelucrării, durata, scopul, categoriile de PII, categoriile de persoane vizate, confidențialitatea, securitatea, autorizarea persoanelor subîmputernicite, asistența, auditul sau asigurarea, returnarea, ștergerea și încetarea.

Din secțiunea „4.3 Controale contractuale și instrucțiuni documentate”, clauza de politică 4.3.2.

Accesul furnizorilor este controlat direct și în politicile Clarysec pentru furnizori, atât pentru IMM-uri, cât și pentru întreprinderi. Politica de securitate privind terții și furnizorii pentru IMM-uri prevede:

Furnizorilor trebuie să li se acorde acces doar la sistemele și datele minime necesare pentru îndeplinirea funcției lor.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.1.

Politica de securitate privind terții și furnizorii pentru întreprinderi adaugă RBAC, revizuire și privilegiu minim:

Personalul furnizorilor trebuie să fie supus controalelor de acces bazate pe roluri (RBAC), revizuirilor periodice ale accesului și aplicării principiului privilegiului minim.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.1.

Dacă accesul furnizorilor poate ajunge la PII, acesta aparține PIMS. Trebuie să apară în controale contractuale, aprobări de acces, grupuri IAM, perimetrul jurnalizării, înregistrări ale revizuirilor, înregistrări de încetare a colaborării, proceduri operaționale de răspuns la incidente și dovezi de audit.

Accesul la PII în cloud: responsabilitatea partajată nu înseamnă responsabilitate partajată pentru demonstrarea conformității

Guvernanța accesului la PII în cloud este zona în care organizațiile supraestimează adesea furnizorul și își subestimează propriile responsabilități. Furnizorul cloud poate securiza infrastructura, dar clientul guvernează în continuare identitățile, rolurile, configurația mediului clientului, accesul de suport, jurnalele, setările de criptare, permisiunile de export și pregătirea pentru răspuns la incidente.

Zenith Blueprint, în faza Controale în acțiune, pasul 23, afirmă direct acest lucru în îndrumările privind serviciile cloud:

Furnizorii cloud securizează infrastructura, dar dvs. rămâneți responsabil pentru datele dvs., configurațiile dvs., politicile dvs. de acces și pregătirea dvs. pentru răspuns la incidente.

De asemenea, avertizează:

În cloud, vizibilitatea este parțială dacă nu este proiectată deliberat. Trebuie să configurați jurnalizarea, să aplicați criptarea, să definiți roluri de identitate și să monitorizați activitatea prin instrumente native sau integrări cu terți. Aceasta nu este o sarcină de infrastructură; este o cerință SMSI.

Politica de utilizare a serviciilor cloud de la Clarysec transformă această cerință într-o obligație de acces la nivel de întreprindere:

Toate serviciile cloud trebuie să aplice controlul accesului bazat pe identitate, aliniat la principiul privilegiului minim.

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.1.

Pentru organizațiile care acționează ca persoane împuternicite de operator în medii cloud, Politica pentru persoanele împuternicite de operator care prelucrează PII în cloud de la Clarysec definește o obligație PIMS de revizuire mai specifică:

[Processor] Responsabilul cu securitatea informațiilor TREBUIE să revizuiască accesul privilegiat în cloud, accesul de suport, accesul la PII ale clienților și acoperirea jurnalizării în REG12 cel puțin trimestrial.

Din secțiunea „4.2 Configurație cloud, izolarea mediului clientului, acces și jurnalizare”, clauza de politică 4.2.4.

Această clauză este deosebit de relevantă pentru companiile SaaS, platformele găzduite în cloud, serviciile administrate de date și persoanele împuternicite de operator B2B.

Guvernanța accesului la PII în cloud nu este completă dacă jurnalele native cloud, politicile IAM, conturile de serviciu, rolurile privilegiate, instrumentele de suport pentru clienți, cheile API și funcțiile de export al datelor nu sunt revizuite împreună.

Jurnalizarea și monitorizarea: memoria guvernanței PII

Un program PIMS de control al accesului fără jurnale este o promisiune fără memorie.

Politica de securitate PII și control al accesului impune definirea perimetrului de jurnalizare înainte de utilizarea în producție sau de o modificare semnificativă:

[Both] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să definească în REG12 domeniul jurnalizării PII pentru evenimente de autentificare, evenimente de acces, acțiuni privilegiate, activități de export PII și modificări semnificative de configurare înainte de utilizarea în producție sau de o modificare semnificativă.

Din secțiunea „4.6 Jurnalizare și monitorizare”, clauza de politică 4.6.1.

Politica de jurnalizare și monitorizare pentru IMM-uri explicitează conținutul jurnalelor de acces:

Jurnale de acces: acces la fișiere (în special pentru date sensibile sau cu caracter personal), modificări ale permisiunilor, utilizarea resurselor partajate

Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.3.

Politica de jurnalizare și monitorizare pentru întreprinderi se concentrează pe utilitatea pentru audit:

Registrul pistei de audit a SMSI trebuie să consemneze disponibilitatea datelor de jurnal pentru audituri, investigații și revizuiri reglementare.

Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.

Acest lucru este critic deoarece dovezile privind confidențialitatea trebuie adesea să răspundă la întrebări bazate pe evenimente:

• Cine a accesat PII?
• Accesul a fost autorizat?
• Accesul a fost legat de un tichet de suport, o solicitare juridică, o sarcină operațională sau o instrucțiune a clientului?
• Datele au fost exportate, copiate, modificate sau șterse?
• A fost utilizat acces privilegiat?
• Permisiunile au fost modificate înainte sau după acces?
• Activitatea a indicat un incident de securitate sau o încălcare a securității datelor cu caracter personal?

Jurnalele nu sunt doar pentru SOC. Ele sunt dovezi PIMS, dovezi pentru asigurarea solicitată de clienți, dovezi de asigurare privind persoanele împuternicite de operator și dovezi pentru răspunsul la incidente.

Maparea cerințelor de conformitate între cadre: un model de acces, mai multe perspective

O deficiență în revizuirile accesului la PII nu este niciodată doar o singură constatare. Poate deveni o problemă de responsabilitate GDPR, o slăbiciune PIMS conform ISO/IEC 27701:2025, o neconformitate ISO/IEC 27001:2022, un eșec de guvernanță NIS2, o preocupare de reziliență DORA, o lacună de guvernanță NIST CSF 2.0 sau o problemă de maturitate a proceselor COBIT 2019.

Un tabel de corelare mai detaliat arată cum un singur proces de guvernanță a accesului la PII susține mai multe cerințe:

Valoarea Zenith Controls este că echipele pot mapa aceste perspective înapoi la aceleași dovezi de control, în loc să mențină silozuri separate de conformitate.

Rulați un sprint de 45 de minute pentru dovezile privind accesul la PII

O modalitate utilă de a testa pregătirea este să alegeți un sistem cu impact ridicat, cum ar fi o platformă de suport pentru clienți, un sistem HR, un portal de plăți, un portal pentru pacienți, un lac de date sau o bază de date de producție SaaS, și să rulați un sprint concentrat de colectare a dovezilor.

Pasul 1: definiți contextul prelucrării PII

Înregistrați în REG12:

• Numele și proprietarul sistemului
• Categoriile de PII
• Categoriile de persoane vizate
• Rolul de operator sau persoană împuternicită de operator
• Scopul prelucrării
• Indicatorul de PII cu impact ridicat sau sensibile
• Dependențe cloud, de furnizori și de persoane subîmputernicite

Dacă sistemul implică o persoană împuternicită de operator, verificați câmpurile de control contractual REG08 folosind Politica de management al confidențialității pentru persoanele împuternicite de operator, persoanele subîmputernicite și terți. Aprobarea trebuie să acopere sfera prelucrării, durata, scopul, categoriile de PII, categoriile de persoane vizate, confidențialitatea, securitatea, autorizarea persoanelor subîmputernicite, asistența, auditul sau asigurarea, returnarea, ștergerea și încetarea.

Pasul 2: extrageți lista de acces

Exportați toți utilizatorii, grupurile, rolurile privilegiate, conturile de serviciu, rolurile de suport, conturile de acces de urgență, cheile API și conturile furnizorilor. Comparați fiecare drept de acces cu rolurile aprobate.

Pasul 3: confirmați privilegiul minim și alinierea la scop

Utilizați baza de referință din Politica de securitate PII și control al accesului: accesul trebuie restricționat la roluri aprobate și utilizatori autorizați, înregistrați sau trasabili în REG02 sau REG12 înainte de activare. Dacă un utilizator nu poate fi trasat la rol, scop și aprobare, constatarea nu este „documentație lipsă”. Constatarea este „acces la PII care nu poate fi demonstrat ca autorizat”.

Pasul 4: verificați perimetrul jurnalizării

Confirmați că jurnalele capturează autentificarea, evenimentele de acces, acțiunile privilegiate, activitatea de export PII și modificările semnificative de configurare. Apoi confirmați unde sunt stocate jurnalele, cât timp sunt păstrate, cine le poate accesa și dacă sunt consemnate în Registrul pistei de audit a SMSI pentru audituri, investigații și revizuiri reglementare.

Pasul 5: închideți bucla

Pentru fiecare excepție, înregistrați proprietarul de risc, acțiunea imediată de izolare, remedierea permanentă, data-țintă, dovezile necesare, decizia privind riscul rezidual și dacă este necesară evaluarea încălcării securității datelor.

Acest exercițiu unic arată de obicei maturitatea reală a guvernanței accesului la PII. Organizațiile solide pot răspunde rapid. Organizațiile slabe descoperă că politica de confidențialitate, configurația IAM, contractele cu persoanele împuternicite de operator, jurnalizarea cloud și dovezile de audit sunt deconectate.

Constatări frecvente de audit în guvernanța accesului la PII

Cele mai multe constatări sunt previzibile. Ele apar atunci când confidențialitatea, securitatea, juridicul, IT și furnizorii controlează fiecare o parte din poveste, dar nimeni nu deține întregul ciclu de viață al accesului la PII.

Constatările frecvente includ:

• Sistemele PII nu sunt listate complet în inventarul PIMS.
• Rolurile de acces sunt definite tehnic, dar nu sunt mapate la scopurile prelucrării.
• PII sensibile sunt accesibile prin grupuri operaționale largi.
• Revizuirile trimestriale acoperă angajații, dar nu conturile de serviciu, cheile API sau utilizatorii furnizorilor.
• Accesul de suport cloud este posibil, dar nu este revizuit ca acces la PII.
• Există jurnale, dar acestea nu dovedesc accesul la PII, exportul sau activitatea privilegiată.
• Contractele cu persoanele împuternicite de operator includ clauze generale de confidențialitate, dar nu controale specifice privind controlul accesului, auditul, persoanele subîmputernicite, returnarea, ștergerea sau încetarea.
• Foști angajați sau contractori păstrează acces prin grupuri partajate sau tokenuri neadministrate.
• Accesul la depozitul de date este mai larg decât accesul la aplicația sursă.
• Conturile de acces de urgență există fără revizuire post-utilizare.
• Impersonarea clientului de către suport nu este jurnalizată cu contextul tichetului.
• Declarația de aplicabilitate include controale de acces, dar dovezile nu arată implementarea specifică PII.

Fiecare dintre aceste constatări poate deveni o problemă de responsabilitate GDPR, o problemă de asigurare solicitată de clienți, o slăbiciune de guvernanță NIS2 sau DORA ori o neconformitate ISO/IEC 27001:2022, în funcție de domeniul de aplicare.

Cum arată un model matur

Un model operațional matur nu se bazează pe campanii eroice de curățare trimestrială. El integrează guvernanța accesului la PII în operațiunile curente.

În primul rând, organizația are cunoașterea datelor. Știe unde există PII, de ce sunt prelucrate, ce rol PIMS se aplică și ce sisteme, furnizori, servicii cloud, jurnale, copii de rezervă și exporturi intră în domeniul de aplicare.

În al doilea rând, accesul este bazat pe roluri și aliniat la scop. Permisiunile sunt definite prin roluri aprobate, nevoie de business documentată, scopul prelucrării și principiul privilegiului minim.

În al treilea rând, controalele sunt aplicate tehnic. IAM, RBAC, gestionarea accesului privilegiat, MFA, accesul condiționat, controalele mediului clientului, criptarea și segregarea mediilor aplică cerințele politicii.

În al patrulea rând, monitorizarea este deliberată. Organizația poate reconstrui autentificarea, accesul, exportul, acțiunea privilegiată, accesul de suport și modificările de configurare care afectează PII.

În al cincilea rând, revizuirile sunt bazate pe risc și documentate. PII cu impact ridicat primesc cel puțin o revizuire trimestrială. Accesul furnizorilor și accesul de suport cloud sunt incluse. Excepțiile sunt urmărite până la închidere.

În al șaselea rând, dovezile sunt reutilizabile. Aceleași înregistrări susțin responsabilitatea GDPR, operarea PIMS conform ISO/IEC 27701:2025, tratarea riscurilor ISO/IEC 27001:2022, măsurile de management al riscurilor NIS2, guvernanța riscurilor TIC DORA, rezultatele GOVERN din NIST CSF 2.0 și asigurarea managementului COBIT 2019.

Aceasta este diferența dintre controlul accesului ca setare și guvernanța accesului ca sistem.

Transformați accesul la PII în dovezi pregătite pentru audit

Dacă următorul audit, următoarea revizuire de client sau următoarea solicitare a unei autorități de reglementare ar începe mâine cu „arătați-mi cine poate accesa PII”, echipa dvs. ar produce dovezi în câteva minute sau ar începe să reconcilieze fișiere de calcul?

Clarysec vă poate ajuta să închideți această lacună.

Începeți cu Politica de securitate PII și control al accesului, aliniați obligațiile persoanelor împuternicite de operator și ale mediilor cloud prin Politica de management al confidențialității pentru persoanele împuternicite de operator, persoanele subîmputernicite și terți și Politica pentru persoanele împuternicite de operator care prelucrează PII în cloud, apoi utilizați Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului pentru a implementa controalele în secvența corectă. În final, utilizați Zenith Controls: ghidul de conformitate transversală pentru a mapa dovezile privind accesul la PII în ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 și COBIT 2019.

Cel mai rapid pas practic următor este simplu: selectați un sistem PII cu impact ridicat, populați REG12, exportați lista de acces, verificați perimetrul jurnalizării și rulați o revizuire de tip trimestrial. Într-o singură sesiune, veți ști dacă guvernanța accesului la PII este pregătită pentru audit sau doar pregătită la nivel de politică.