DSAR, ștergere și dovezi ISO 27001 în 2026

E-mailul a ajuns în căsuța de e-mail a Sarei la ora 9:03.
Nu era prima cerere de acces a persoanei vizate primită de compania ei SaaS, aflată în creștere rapidă. Era însă prima care se simțea ca un audit public.
Expeditorul era un fost angajat, devenit între timp activist pentru protecția datelor. Cererea cita articole GDPR după număr și solicita toate datele cu caracter personal, restricționarea imediată a prelucrării, lista fiecărui serviciu terț care deținea datele sale și dovada verificabilă a ștergerii din sistemele de producție și din copiile de rezervă. Un jurnalist era în copie.
În câteva minute, lacunele au devenit vizibile. Echipa de inginerie a avertizat că „ștergerea reală” dintr-o bază de date multi-tenant ar putea afecta alți clienți. Marketingul încerca să clarifice datele utilizatorului din platformele de analiză. Juridicul a identificat o speță de muncă nerezolvată. Securitatea era preocupată că jurnalele ar putea dezvălui logica de detecție sau datele altei persoane. Suportul avea înregistrări sub două adrese de e-mail. Financiarul avea facturi sub o a treia adresă.
Cronometrul pornise deja.
Acest scenariu nu mai este neobișnuit. Drepturile persoanelor vizate în 2026 nu sunt o problemă de inbox pentru echipa de confidențialitate. Sunt un proces organizațional controlat, dependent de inventare de active, decizii privind temeiul juridic, verificarea identității, controlul accesului, reguli de retenție, reținere legală, coordonarea furnizorilor, divulgare securizată, dovezi de ștergere și jurnalizare care poate susține auditul.
GDPR stabilește drepturile persoanelor fizice. ISO/IEC 27001:2022 oferă echipelor de securitate și conformitate disciplina unui sistem de management pentru a demonstra că aceste drepturi sunt gestionate consecvent, securizat și repetabil.
Pentru CISO, manageri de conformitate, lideri în protecția datelor și responsabili de business, obiectivul nu este crearea mai multor documente. Obiectivul este construirea unui singur flux de lucru DSAR, de ștergere și de restricționare, fiabil, care produce dovezile cerute de GDPR, de auditurile ISO/IEC 27001:2022 și de așteptările mai largi de asigurare din NIS2, DORA, NIST CSF 2.0 și COBIT 2019.
De ce gestionarea ad-hoc a DSAR eșuează sub presiune
Majoritatea eșecurilor DSAR nu sunt cauzate de intenții greșite. Sunt cauzate de fragmentare.
O organizație poate avea o notă de informare privind confidențialitatea, o căsuță poștală a DPO și o clauză GDPR în contractele cu furnizorii, dar poate avea în continuare dificultăți în a răspunde la întrebări operaționale de bază:
- Cine validează identitatea solicitantului?
- Care entitate juridică este operator sau persoană împuternicită de operator?
- Ce sisteme trebuie căutate?
- Cine este responsabil pentru fiecare sistem?
- Ce date intră în domeniul cererii?
- Ce date trebuie anonimizate sau redactate înainte de divulgare?
- Ce date nu pot fi șterse din motive fiscale, de audit, litigii, prevenirea fraudei sau obligație legală?
- Cum se aplică tehnic restricționarea prelucrării?
- Ce furnizori trebuie să sprijine căutarea, exportul, ștergerea sau restricționarea?
- Ce dovezi demonstrează că cererea a fost gestionată la timp?
- Ce se întâmplă dacă DSAR indică o încălcare a securității datelor cu caracter personal?
GDPR Article 5 impune ca datele cu caracter personal să fie prelucrate legal, echitabil și transparent, colectate pentru scopuri determinate, limitate la ceea ce este necesar, menținute exacte, păstrate nu mai mult decât este necesar și protejate prin măsuri tehnice și organizatorice adecvate. Article 5(2) explicitează responsabilitatea: operatorul trebuie să poată demonstra conformitatea. Article 4 definește prelucrarea în sens larg, incluzând colectarea, stocarea, utilizarea, divulgarea, restricționarea, ștergerea și distrugerea.
Aceasta înseamnă că procesul DSAR este, în sine, o activitate de prelucrare. El trebuie controlat.
GDPR Article 3 este, de asemenea, relevant pentru companiile cloud, SaaS, fintech și digitale din afara UE. Dacă oferiți bunuri sau servicii persoanelor din Uniune, le monitorizați comportamentul sau prelucrați date cu caracter personal în contextul unui sediu din UE, GDPR se poate aplica inclusiv atunci când activitățile sunt externalizate sau infrastructura este globală.
ISO/IEC 27001:2022 aduce structură acestei realități. Clauzele 4.1-4.4 impun organizației să își înțeleagă contextul, părțile interesate, cerințele, domeniul de aplicare al SMSI și procesele care interacționează. O persoană vizată este o parte interesată. Drepturile GDPR sunt cerințe. Aplicațiile SaaS, furnizorii de identitate, platformele de analiză, instrumentele de suport, depozitele de date și copiile de rezervă în cloud sunt procese care interacționează. Un flux de lucru DSAR aparține SMSI, nu unui proces paralel.
Cele trei drepturi ale persoanei vizate care creează cea mai mare presiune
Accesul, ștergerea și restricționarea expun cea mai mare diferență dintre promisiunea juridică și capabilitatea operațională.
| Drept | Focus GDPR | Întrebare operațională | Eșec frecvent | Dovezi așteptate de auditori |
|---|---|---|---|---|
| Cerere de acces sau DSAR | Article 15 | Putem localiza, revizui și divulga în siguranță datele cu caracter personal ale solicitantului? | Căutare incompletă în sisteme, verificare slabă a identității sau divulgare accidentală a datelor unui terț | Înregistrare de primire, validarea identității, jurnal de căutare în sisteme, înregistrare de redactare, aprobare, copie a răspunsului, dovezi de închidere |
| Cerere de ștergere | Article 17 | Putem șterge datele cu caracter personal acolo unde este necesar, păstrând în același timp datele care trebuie menținute legal? | Se șterge prea mult, prea puțin, se ignoră copiile de rezervă sau nu se înregistrează excepțiile | Decizie de ștergere, analiza temeiului juridic, tichete de ștergere, confirmări din sisteme, tratamentul copiilor de rezervă, verificări privind reținerea legală |
| Cerere de restricționare | Article 18 | Putem opri prelucrarea activă fără a afecta activitățile organizației, securitatea sau obligațiile legale? | Nu există metodă tehnică pentru marcarea înregistrărilor restricționate în instrumentele SaaS și fluxurile de date | Marcaj de restricționare, modificări de acces, dovadă de suprimare, registru de excepții, revizuire periodică |
GDPR Article 6 este central pentru această logică decizională. Nu puteți prelucra, păstra, divulga sau refuza ștergerea fără a înțelege temeiul juridic. Article 9 ridică nivelul cerințelor pentru categoriile speciale de date cu caracter personal, cum ar fi datele privind sănătatea, datele biometrice utilizate pentru identificare unică sau datele care dezvăluie caracteristici sensibile. Într-un mediu SaaS din 2026, acest lucru poate afecta integrarea utilizatorilor, verificarea identității, monitorizarea fraudei, atașamentele din suportul pentru clienți și evidențele angajaților.
Politica de protecție a datelor și confidențialitate [P17] pentru organizații enterprise de la Clarysec formulează obligația direct. În clauza 3.6 privind obiectivele, aceasta impune organizației să:
Respecte drepturile persoanelor vizate, inclusiv accesul, rectificarea, ștergerea, restricționarea, portabilitatea, opoziția și protecția împotriva procesului decizional automatizat.
Acest obiectiv devine verificabil numai atunci când este asociat cu responsabili, registre, fluxuri de lucru, controale și dovezi.
Începeți de unde încep auditorii: domeniu de aplicare, părți interesate și responsabilități
În Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului [ZB], faza Fundamentul și leadershipul SMSI, Pasul 2, se concentrează pe nevoile părților interesate și pe domeniul de aplicare al SMSI. Pentru GDPR, Blueprint identifică așteptările autorităților de reglementare astfel:
Autorități de reglementare din UE
(GDPR)Prelucrarea legală a datelor cu caracter
personal, raportarea încălcărilor în 72 h,
drepturile persoanelor vizateNumiți un responsabil cu protecția datelor, stabiliți
procesul de răspuns la încălcări, proceduri pentru
gestionarea cererilor privind datele.
Acesta este punctul corect de pornire. Înainte de automatizarea tichetelor sau configurarea portalurilor, definiți domeniul de aplicare al prelucrării drepturilor persoanelor vizate:
- Care entități juridice acționează ca operator, operator asociat sau persoană împuternicită de operator?
- Ce produse, servicii și teritorii sunt în domeniu?
- Ce categorii de persoane vizate există, cum ar fi clienți, angajați, utilizatori de probă, prospecți, furnizori, vizitatori ai site-ului sau utilizatori ai aplicației?
- Ce sisteme, depozite și furnizori dețin date cu caracter personal?
- Ce roluri aprobă divulgarea, refuzul, ștergerea, restricționarea sau escaladarea?
- Ce indicatori sunt raportați managementului?
Clauzele 5.1-5.3 din ISO/IEC 27001:2022 impun leadership, alinierea politicilor, resurse și responsabilități atribuite. Acest lucru se aliniază direct cu responsabilitatea prevăzută de GDPR.
Politica de protecție a datelor și confidențialitate [P17], clauza 6.4.1 privind cerințele de implementare a politicii, prevede:
Responsabilul cu protecția datelor (DPO) trebuie să mențină procese documentate pentru primirea, validarea, urmărirea și răspunsul la cererile persoanelor vizate (DSR).
Pentru IMM-uri, Politica de protecție a datelor și confidențialitate - SME [P17S] de la Clarysec utilizează o responsabilizare dimensionată corespunzător. Clauza 5.2.1 privind cerințele de guvernanță 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 retenție
Acest registru de prelucrare este centrul operațional al capacității de răspuns la DSAR. Dacă este incomplet, echipa DSAR caută pe baza memoriei, a mesajelor Slack și a cunoștințelor informale. Dacă este exact, echipa caută după activitate de prelucrare, categorie de date, responsabil de sistem, furnizor și regulă de retenție.
Fluxul de lucru DSAR Clarysec: de la primire la închidere
Un flux de lucru DSAR pregătit pentru audit trebuie să fie suficient de simplu pentru a funcționa sub presiune, dar suficient de controlat pentru a rezista în fața unei autorități de reglementare, a unei revizuiri de asigurare solicitate de clienți sau a unui audit ISO/IEC 27001:2022.
1. Primire și confirmare
Cererile trebuie să intre printr-un canal controlat, cum ar fi o căsuță poștală pentru confidențialitate, un portal, un formular de suport sau o coadă de primire juridică. Personalul trebuie să recunoască solicitările formulate în limbaj obișnuit. O persoană nu trebuie să scrie „DSAR” pentru a exercita un drept. „Ce date aveți despre mine?” sau „ștergeți-mi profilul” poate fi suficient pentru a declanșa fluxul de lucru.
Politica de protecție a datelor și confidențialitate - SME [P17S], clauza 6.5.2 privind cerințele de implementare a politicii, stabilește un nivel de serviciu clar:
Coordonatorul pentru confidențialitate trebuie să confirme primirea cererilor în termen de 3 zile lucrătoare și să răspundă în termen de 30 de zile
Confirmarea trebuie să includă referința cererii, clarificarea domeniului dacă este necesar, instrucțiuni pentru verificarea identității și termenul estimat de răspuns.
2. Verificarea identității și a autorității
O DSAR poate deveni o încălcare a securității datelor cu caracter personal dacă informațiile sunt transmise persoanei greșite. Verificarea trebuie să fie proporțională și să nu colecteze excesiv date noi cu caracter personal. Utilizați portaluri autentificate acolo unde este posibil. Pentru foști utilizatori, validați pe baza datelor de cont cunoscute. Pentru angajați, coordonați cu HR. Pentru reprezentanți, solicitați dovada autorității.
Păstrați dovezi privind metoda de verificare, data finalizării, aprobatorul, orice informații suplimentare solicitate și decizia în cazul în care verificarea eșuează.
3. Clasificarea cererii
Un singur mesaj poate conține mai multe drepturi. Clasificați fiecare drept separat, deoarece accesul, ștergerea, restricționarea, opoziția și portabilitatea necesită logică decizională și dovezi diferite. Marcați, de asemenea, potențiale reclamații, aspecte legate de angajați, date ale copiilor, date din categorii speciale și posibile încălcări ale securității datelor cu caracter personal.
4. Căutați în inventar, nu doar în sistemele evidente
Aici ISO/IEC 27001:2022 devine practic. Zenith Blueprint [ZB], faza Controale în acțiune, Pasul 22, avertizează că domeniul inventarului este mai larg decât se așteaptă multe organizații:
Domeniul acestui inventar este mai larg decât realizează majoritatea. Trebuie să includă:
✓ Active fizice: laptopuri, servere, telefoane, benzi de backup, medii amovibile,
înregistrări tipărite.
✓ Active digitale: documente, seturi de date, depozite, e-mailuri, cod sursă, fișiere
stocate în cloud.
✓ Active logice: conturi de utilizator, credențiale, chei, licențe software, API-uri.
✓ Active legate de servicii: platforme SaaS, servicii de securitate administrate, spații
de stocare externalizate.
✓ Oameni ca active: nu în sens de transformare în bunuri, ci din perspectiva responsabilităților
atribuite, a accesului și a expunerii la informații determinate de rol.
Pasul 22 explică și asumarea responsabilității:
Fiecare activ trebuie să aibă un proprietar definit, nu persoana care îl utilizează, ci persoana responsabilă pentru
utilizarea, protecția și ciclul său de viață. Asumarea responsabilității este esențială pentru alinierea controalelor: cine clasifică
activul (5.10), cine decide nivelul său de acces (8.3), cine gestionează ștergerea acestuia (8.10), cine se asigură
că este returnat (5.9 se suprapune subtil cu procedurile de returnare a activelor).
În Zenith Controls: ghidul de conformitate transversală [ZC], controlul ISO/IEC 27002:2022 5.9, Inventarul informațiilor și al altor active asociate, este tratat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Conceptul său de securitate cibernetică este Identify, capabilitatea operațională este Asset Management, iar domeniile sale de securitate includ Guvernanță, Ecosistem și Protecție.
Pentru DSAR, aceasta înseamnă că inventarul nu este o foaie de calcul IT. Este harta care indică echipelor de confidențialitate, juridic și securitate unde ar putea exista date cu caracter personal.
5. Revizuiți, redactați și aprobați divulgarea
Un răspuns DSAR nu trebuie să fie un export brut. Revizuirea trebuie să protejeze datele cu caracter personal ale altor persoane, informațiile confidențiale ale organizației, privilegiul juridic, datele sensibile din perspectiva securității, semnalele de fraudă și datele din afara domeniului cererii.
Aprobarea trebuie să fie bazată pe risc. Răspunsurile de acces uzuale pot fi aprobate de Coordonatorul pentru confidențialitate sau de DPO. Cererile care implică angajați, litigii, date din categorii speciale, copii, fraudă, jurnale de securitate sau exporturi de volum mare trebuie să implice conducerea juridică, HR sau conducerea de securitate.
6. Livrați securizat
Nu atașați fișiere mari necriptate la e-mail. Utilizați portaluri autentificate, fișiere criptate cu transmiterea separată a parolei sau linkuri securizate de transfer cu expirare și jurnale de acces. Înregistrați metoda de livrare, data, contul destinatarului, data expirării și confirmarea, acolo unde este disponibilă.
7. Închideți cu dovezi
Politica de protecție a datelor și confidențialitate [P17], clauza 6.4.3, este explicită:
Toate acțiunile întreprinse trebuie jurnalizate în scop de audit, inclusiv deciziile de refuz al cererilor.
Politica de protecție a datelor și confidențialitate - SME [P17S], clauza 6.5.4, prevede:
Toate răspunsurile la cererile persoanelor vizate trebuie înregistrate într-un registru securizat, cu acces restricționat la Coordonatorul pentru confidențialitate și GM
O DSAR nu este finalizată când e-mailul este trimis. Este finalizată când registrul arată cererea, verificarea identității, deciziile, sistemele căutate, răspunsul, excepțiile, aprobările, livrarea și închiderea.
Ștergerea este distrugere controlată, nu un buton de delete
Cererile de ștergere arată dacă protecția datelor a fost integrată în sisteme sau adăugată după lansare.
Politica de păstrare și eliminare a datelor [P14] pentru organizații enterprise de la Clarysec, clauza 4.3.3 privind roluri și responsabilități, atribuie responsabilitatea rolului care:
Răspunde cererilor de ștergere și asigură ștergerea la timp și verificabilă a datelor cu caracter personal acolo unde este necesar.
Expresia „acolo unde este necesar” este critică. Ștergerea conform GDPR nu este absolută. Organizațiile pot fi nevoite să păstreze date pentru obligații legale, audit, taxe, obligații de reglementare, prevenirea fraudei, securitate, litigii sau constatarea, exercitarea ori apărarea unor pretenții juridice. Fluxul de lucru trebuie să includă o decizie legală privind retenția și excepțiile.
Zenith Blueprint [ZB], faza Controale în acțiune, Pasul 19, explică controlul ISO/IEC 27002:2022 8.10, Ștergerea informațiilor, în termeni operaționali:
Acest control asigură că datele nu sunt păstrate mai mult decât este necesar, iar atunci când nu mai sunt
necesare, acestea trebuie șterse securizat și fiabil. Multe organizații acumulează volume mari
de date în timp, dar fără un proces clar de ștergere, acele date pot rămâne inactive și
neprotejate, crescând discret riscul de expunere, încălcare sau neconformitate cu cerințele de reglementare.
De asemenea, avertizează:
Nu uitați copiile de rezervă și sistemele arhivate; acestea păstrează adesea date istorice mult după valoarea lor
operațională. Politicile de ștergere trebuie să se extindă la:✓ Setări de retenție a copiilor de rezervă,
✓ Cicluri de viață ale instantaneelor,
✓ Depozite arhivate de e-mail sau documente.
Și încheie cu dovezile:
Procesul de ștergere în sine trebuie jurnalizat și, în cazul datelor cu risc ridicat sau reglementate,
revizuit sau aprobat. Aceasta asigură trasabilitate și protejează împotriva distrugerii accidentale sau
neautorizate a înregistrărilor valoroase.
În Zenith Controls [ZC], controlul ISO/IEC 27002:2022 8.10, Ștergerea informațiilor, este mapat ca un control preventiv concentrat pe confidențialitate, aliniat conceptului de securitate cibernetică Protect și asociat capabilităților operaționale Protecția informațiilor și Juridic și conformitate.
Pentru arhitecturi cloud complexe, ștergerea criptografică poate fi adecvată atunci când este proiectată corect. Dacă datele cu caracter personal sunt criptate cu o cheie specifică persoanei vizate sau tenantului, distrugerea cheii poate face datele permanent inaccesibile, inclusiv atunci când fragmente criptate rămân în copiile de rezervă până la rotația programată. Acest lucru trebuie proiectat, documentat, testat și aprobat cu atenție. Nu este o soluție de ocolire pentru o arhitectură slabă de ștergere.
Capabilitatea aplicației este, prin urmare, esențială. Politica privind cerințele de securitate a aplicațiilor - SME [P09S] de la Clarysec, clauza 6.5.1.3, impune aplicațiilor să:
permită exportul și ștergerea securizată a datelor cu caracter personal atunci când este cerut legal (de exemplu, GDPR Article 17 – dreptul la ștergere).
Dacă echipele de produs nu construiesc capabilități de export și ștergere, echipele de confidențialitate sunt forțate să utilizeze scripturi de bază de date, tichete către furnizori și activități manuale inconsecvente.
Reținere legală și suspendarea ștergerii
Un flux de lucru matur pentru ștergere trebuie să includă o cale „nu ștergeți”. Aceasta nu este o scuză pentru a ignora ștergerea. Este o excepție controlată.
Politica de retenție a datelor și politica de eliminare securizată - SME [P14S] pentru IMM-uri de la Clarysec, clauza 5.4 privind cerințe de guvernanță, prevede:
Datele supuse reținerii în scop juridic și suspendării ștergerii (de exemplu, în cazul unui litigiu, audit sau investigație) trebuie identificate clar în sistem și protejate împotriva ștergerii, chiar dacă perioada de retenție programată a expirat.
Politica de păstrare și eliminare a datelor [P14], clauza 6.4.1, reflectă același principiu:
Dacă este emisă o blocare legală și suspendare a ștergerii (de exemplu, pe durata unui litigiu, a unei investigații sau a unui audit), datele care altfel ar fi supuse distrugerii trebuie păstrate peste perioada normală de retenție.
Auditorii vor ambele părți ale poveștii: dovezi ale ștergerii la timp și dovezi ale retenției justificate.
Restricționarea prelucrării: dreptul subestimat
Cererile de restricționare nu impun întotdeauna ștergerea. Ele impun organizației să limiteze prelucrarea activă, păstrând datele în condiții controlate.
Exemple frecvente includ:
- Un client contestă exactitatea datelor și solicită încetarea utilizării datelor pe durata verificării.
- Un fost angajat se opune prelucrării, dar înregistrarea este necesară pentru pretenții juridice.
- Un utilizator solicită ștergerea, dar date minime trebuie păstrate pentru menținerea unei liste de suprimare.
- O investigație de fraudă impune retenție, dar nu utilizare operațională normală.
Un flux de lucru practic pentru restricționare trebuie să includă o decizie juridică, un marcaj în sistem, ajustarea controlului accesului, suprimarea marketingului, excluderea din analiză, instruirea furnizorilor, revizuire periodică și dovezi privind excepțiile.
În Zenith Controls [ZC], controlul ISO/IEC 27002:2022 5.34, Confidențialitatea și protecția PII, este tratat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Se mapează la Identify și Protect, cu capabilități operaționale de Protecția informațiilor și Juridic și conformitate.
Zenith Blueprint [ZB], faza Controale în acțiune, Pasul 23, rezumă testul de audit:
Confirmați că organizația dvs. a implementat măsuri de confidențialitate (5.34) aliniate cu
cerințele legale aplicabile. Verificați clasificarea PII, controalele de acces adecvate, practicile
sigure de gestionare și instruirea de conștientizare. Validați dacă cererile de acces ale persoanelor vizate,
ștergerea datelor sau jurnalele de prelucrare sunt susținute operațional, nu doar prin politică.
Expresia-cheie este „susținute operațional, nu doar prin politică”.
Maparea fluxurilor de lucru DSAR la dovezi ISO/IEC 27001:2022
ISO/IEC 27001:2022 nu înlocuiește GDPR. Acesta organizează dovezile.
Clauzele 6.1.1-6.1.3 impun evaluarea riscurilor, tratamentul riscului, criterii de acceptare a riscului, proprietari de risc, selectarea controalelor, o Declarație de aplicabilitate și un Plan de tratare a riscurilor. Riscurile DSAR includ divulgarea neautorizată, depășirea termenelor, ștergerea incompletă, retenția ilegală, verificarea excesivă a identității, lipsa de cooperare a furnizorilor și incapacitatea de a restricționa prelucrarea.
Clauza 8.1 impune organizațiilor să planifice, să implementeze și să controleze procesele SMSI, să păstreze dovezi documentate, să controleze schimbările și să se asigure că procesele, produsele și serviciile furnizate extern, relevante pentru SMSI, sunt controlate. Acest lucru se potrivește operațiunilor DSAR, deoarece cererile traversează funcții interne și persoane împuternicite de operator externe.
| Referință ISO/IEC 27001:2022 sau ISO/IEC 27002:2022 | Relevanță DSAR | Dovezi tipice |
|---|---|---|
| Clauza 4.1-4.4 | Context, părți interesate, domeniul de aplicare al SMSI și procese | Domeniul de aplicare al SMSI, cerințe ale părților interesate, note privind aplicabilitatea GDPR |
| Clauza 5.1-5.3 | Leadership, politică și responsabilități | Rol DPO sau Coordonator pentru confidențialitate, RACI, aprobări de politici |
| Clauza 6.1.1-6.1.3 | Evaluarea și tratamentul riscurilor | Registru de riscuri DSAR, plan de tratament, Declarație de aplicabilitate |
| Clauza 8.1 | Planificare și control operațional | Procedură DSR, înregistrări ale fluxului de lucru, urmărirea sarcinilor furnizorilor |
| Controlul 5.9 | Inventarul informațiilor și al altor active asociate | Inventarul activelor, atestări ale responsabililor de sistem, legături cu registrul de prelucrare |
| Controlul 5.15 | Controlul accesului | Acces DSAR bazat pe roluri, registre restricționate, înregistrări ale aprobărilor |
| Controlul 5.19 și 5.20 | Relații cu furnizorii și acorduri cu furnizorii | Clauze pentru persoane împuternicite de operator, condiții de asistență DSAR, jurnale ale răspunsurilor furnizorilor |
| Controlul 5.23 | Securitatea informației pentru utilizarea serviciilor cloud | Locația datelor în cloud, responsabilități privind SaaS, dovezi de ștergere în cloud |
| Controlul 5.31 | Cerințe legale, statutare, de reglementare și contractuale | Registru al cerințelor GDPR, decizii privind temeiul juridic și retenția |
| Controlul 5.34 | Confidențialitatea și protecția PII | Flux de lucru DSR, reguli de gestionare a PII, înregistrări privind instruirea |
| Controlul 8.10 | Ștergerea informațiilor | Tichete de ștergere, dovadă de ștergere criptografică, jurnale de excepții |
| Controlul 8.13 | Copiile de rezervă ale informațiilor | Calendare de retenție a copiilor de rezervă, abordare de restaurare și purjare |
| Controlul 8.15 | Jurnalizare | Jurnal al acțiunilor DSAR, jurnale de export, înregistrări ale activității administrative |
| Controlul 8.16 | Activități de monitorizare | Alerte, revizuiri, escaladarea incidentelor din gestionarea DSAR |
Un pachet solid de dovezi include procedura DSR, registrul DSR, registrul activităților de prelucrare, inventarul activelor, calendarul de retenție a datelor, registrul de reținere legală, procedura de verificare a identității, ghidul de redactare, metoda de divulgare securizată, procedura de ștergere, procedura de restricționare, playbook-ul pentru furnizori, registrul de excepții, înregistrările privind instruirea, rezultatele auditului intern și raportarea în cadrul analizei efectuate de management.
Un flux de lucru practic pentru acces, ștergere și restricționare
| Etapă a fluxului de lucru | Artefact Clarysec | Acțiune | Dovezi produse |
|---|---|---|---|
| Primire | Politica de protecție a datelor și confidențialitate [P17] sau Politica de protecție a datelor și confidențialitate - SME [P17S] | Înregistrați cererea, atribuiți un responsabil, confirmați primirea în termenul SLA intern | Intrare în registrul DSR, marcaj temporal al confirmării |
| Domeniu și identitate | Zenith Blueprint [ZB] Pasul 2 | Confirmați GDPR ca cerință a părților interesate, validați identitatea solicitantului | Înregistrare de validare a identității, note privind domeniul |
| Căutare în inventar | Zenith Blueprint [ZB] Pasul 22 și maparea Zenith Controls [ZC] 5.9 | Căutați în CRM, facturare, baza de date a produsului, suport, IdP, analiză, e-mail și furnizori | Listă de verificare pentru căutarea în sisteme, atestări ale responsabililor |
| Pachet de acces | Politica de protecție a datelor și confidențialitate [P17] | Revizuiți, redactați, aprobați și divulgați datele în siguranță | Note de redactare, aprobare, înregistrare de livrare securizată |
| Decizie de ștergere | Politica de păstrare și eliminare a datelor [P14] | Confirmați ce poate fi șters și ce trebuie păstrat | Decizie privind temeiul juridic și excepția de retenție |
| Capabilitatea aplicației | Politica privind cerințele de securitate a aplicațiilor - SME [P09S] | Utilizați funcțiile de export și ștergere acolo unde sunt cerute legal | Tichet de ștergere, jurnale de administrare a produsului |
| Verificare reținere legală | Politica de retenție a datelor și politica de eliminare securizată - SME [P14S] | Confirmați dacă se aplică o reținere pentru litigiu, audit sau investigație | Rezultat al verificării reținerii legale |
| Restricționare | Maparea Zenith Controls [ZC] 5.34 | Suprimați prelucrarea pentru marketing și analiză până la finalizare | Marcaj de restricționare, dovadă de suprimare |
| Închidere | Politica de protecție a datelor și confidențialitate [P17] | Jurnalizați toate acțiunile și orice refuz sau refuz parțial | Înregistrare de închidere, copie a răspunsului, registru de excepții |
Acest flux de lucru transformă criza Sarei într-un proces verificabil. Fiecare etapă are un responsabil, o bază de control și dovezi.
Valoarea de conformitate transversală dincolo de GDPR
Un flux de lucru DSAR își are rădăcina în GDPR, dar aceleași controale susțin cadre mai largi.
NIS2 Article 20 face din securitatea cibernetică o responsabilitate a managementului pentru entitățile esențiale și importante. Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, evaluarea eficacității, igiena cibernetică, instruirea, controlul accesului, managementul activelor, autentificarea și comunicațiile securizate. DSAR se bazează pe multe dintre aceleași capabilități.
DORA se aplică de la 17 ianuarie 2025 multor entități financiare și stabilește cerințe uniforme privind managementul riscurilor TIC, raportarea incidentelor, testarea rezilienței și riscul TIC asociat terților. Articles 5 și 6 impun guvernanță și management documentat al riscurilor TIC. Articles 17-20 tratează detectarea incidentelor, clasificarea, escaladarea, comunicarea și închiderea. Articles 24-30 tratează testarea rezilienței, riscul TIC asociat terților, registrele de servicii, drepturile de audit, locația datelor, asistența în caz de incidente și strategiile de ieșire. O companie fintech care gestionează DSAR prin platforme cloud trebuie să alinieze gestionarea cererilor de confidențialitate cu Registrul serviciilor TIC.
NIST CSF 2.0 ajută la transpunerea aceleiași activități în rezultate de securitate cibernetică. GOVERN abordează cerințele legale, de reglementare și contractuale, strategia de risc, rolurile, politica și supravegherea. IDENTIFY și PROTECT se aliniază puternic cu vizibilitatea activelor, clasificarea datelor, controlul accesului, ștergerea, guvernanța furnizorilor și protecția confidențialității.
COBIT 2019 pune întrebări de guvernanță. Cine deține procesul? Ce obiective sunt definite? Cum este măsurată performanța? Cum sunt aprobate excepțiile? Cum se obține asigurarea? Dovezile DSAR pot susține obiective precum APO13 Securitate gestionată, APO14 Date gestionate și DSS06 Controale gestionate ale proceselor de afaceri.
Perspectiva auditorului
| Perspectiva auditorului | Pe ce se concentrează | Cerere tipică de dovezi |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Dacă procesele DSAR sunt incluse în domeniu, evaluate din perspectiva riscului, controlate, resursate și dovedite în cadrul SMSI | Domeniul de aplicare al SMSI, evaluarea riscurilor, Declarație de aplicabilitate, procedură DSR, registre, înregistrări ale auditului intern |
| Auditor de confidențialitate GDPR sau autoritate de reglementare | Dacă drepturile persoanelor vizate au fost gestionate legal, transparent, securizat și în termenele aplicabile | Dosarul cererii, verificarea identității, cronologia răspunsului, analiza temeiului juridic, dovezi de ștergere sau restricționare |
| Evaluator NIST CSF | Dacă rezultatele privind guvernanța, vizibilitatea activelor, protecția datelor, controlul accesului, detecția și răspunsul sunt definite și îmbunătățite | Profil curent și țintă, plan de remediere a lacunelor, inventarul activelor, controale pentru furnizori, indicatori |
| Auditor COBIT 2019 sau ISACA | Dacă obiectivele de guvernanță, rolurile, controalele de proces, indicatorii de performanță și activitățile de asigurare funcționează | RACI, KPI, testarea controalelor, aprobări de excepții, raportare către management |
| Auditor orientat DORA | Dacă riscul TIC al entității financiare, dependențele de terți, căile de incident și reziliența sunt integrate | Registru de servicii TIC, clauze ale furnizorilor, proceduri de incident, teste de reziliență, dovezi de ieșire |
| Revizor orientat NIS2 | Dacă managementul a aprobat măsuri de risc, iar controalele privind activele, accesul, incidentele, furnizorii și instruirea sunt proporționale | Procese-verbale ale consiliului de administrație, măsuri de risc, registre de instruire, supravegherea furnizorilor, playbook-uri de incident |
Nu creați dovezi separate pentru fiecare cadru. Creați un singur flux de lucru DSAR fiabil și mapați-l corect.
Indicatori DSAR pe care managementul trebuie să îi vadă
Managementul nu poate supraveghea ceea ce nu vede. Indicatorii utili includ volumul cererilor pe tip de drept, timpul mediu de confirmare, timpul mediu de închidere, respectarea termenelor, ratele de clarificare a identității, excepțiile de ștergere, cazurile de reținere legală, timpii de răspuns ai furnizorilor, refuzurile parțiale, incidentele identificate în timpul gestionării și acțiunile de remediere deschise.
Acești indicatori arată dacă drepturile persoanelor vizate sunt sănătoase operațional sau depind de eforturi eroice.
Lacune frecvente în pregătirea pentru DSAR
Clarysec observă frecvent aceleași puncte slabe în SaaS, fintech, servicii profesionale și IMM-uri cloud-first:
- Nu există responsabil pentru fiecare sistem care conține date cu caracter personal
- Registrul de prelucrare nu este aliniat cu utilizarea reală a SaaS
- Platformele de marketing, analiză și depozitele de date sunt excluse din căutări
- Nu există un standard documentat de verificare a identității
- Nu există revizuire de redactare înainte de divulgare
- Ștergerea în producție este efectuată fără tratamentul copiilor de rezervă
- Nu există verificare privind reținerea legală înainte de ștergere
- Restricționarea este gestionată manual, fără marcaj în sistem
- Contractele cu furnizorii nu conțin termeni de asistență DSAR
- Refuzurile și refuzurile parțiale nu sunt documentate
- Nu există eșantionare prin audit intern a DSAR finalizate
- Personalul din prima linie nu este instruit să recunoască cererile
Lista dvs. de verificare a pregătirii DSAR pentru 2026
Utilizați aceasta ca test de maturitate:
- Avem un proces documentat de primire, validare, urmărire și răspuns pentru DSR?
- Confirmăm primirea cererilor într-un SLA intern definit?
- Menținem un registru DSR securizat, cu acces restricționat?
- Avem un registru actualizat al activităților de prelucrare, cu categorii, scopuri, temeiuri juridice și perioade de retenție?
- Cunoaștem fiecare sistem, platformă SaaS, depozit și furnizor care poate deține date cu caracter personal?
- Fiecare activ relevant are un responsabil desemnat?
- Putem exporta date cu caracter personal în siguranță?
- Putem șterge în siguranță date cu caracter personal acolo unde este cerut legal?
- Putem restricționa prelucrarea tehnic sau procedural?
- Verificăm reținerea legală înainte de ștergere?
- Documentăm deciziile de refuz, refuz parțial și excepție?
- Contractele cu furnizorii susțin asistența DSAR?
- Testăm fluxul de lucru prin audit intern sau exerciții de tip tabletop?
- Raportăm performanța DSAR către management?
- Mapăm controalele DSAR în tratamentul riscului ISO/IEC 27001:2022 și în Declarația de aplicabilitate?
Dacă mai multe răspunsuri sunt „nu în mod consecvent”, următoarea cerere poate expune lacuna.
Transformați drepturile persoanelor vizate în dovezi pregătite pentru audit
Drepturile persoanelor vizate în 2026 cer mai mult decât bune intenții și o căsuță poștală pentru confidențialitate. Ele cer un flux de lucru care poate identifica datele, valida identitatea, lua decizii legale, coordona furnizorii, proteja divulgarea, executa ștergerea, aplica restricționarea și păstra dovezile.
Clarysec ajută organizațiile să construiască acest flux de lucru fără a crea o birocrație paralelă de conformitate. Începeți cu Zenith Blueprint pentru a plasa drepturile persoanelor vizate în faza și pașii corecți ai SMSI. Utilizați Politica de protecție a datelor și confidențialitate, Politica de protecție a datelor și confidențialitate - SME, Politica de păstrare și eliminare a datelor, Politica de retenție a datelor și politica de eliminare securizată - SME și Politica privind cerințele de securitate a aplicațiilor - SME de la Clarysec pentru a defini responsabilitățile și regulile operaționale.
Apoi utilizați Zenith Controls pentru a mapa controalele ISO/IEC 27002:2022 5.9, 5.34 și 8.10 în dovezi de conformitate transversală pentru asigurarea GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 și COBIT 2019.
Dacă doriți să știți dacă fluxurile dvs. DSAR, de ștergere și de restricționare ar rezista mâine unui audit, Clarysec vă poate ajuta să testați procesul, să închideți lacunele și să construiți pachetul de dovezi înainte ca următoarea cerere să sosească. Descărcați modelele relevante de politici Clarysec sau programați o evaluare a pregătirii DSAR pentru a trece de la răspuns reactiv la operațiuni de confidențialitate controlate și pregătite pentru audit.
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


