Procedura pentru Cererile de Acces ale Persoanelor Vizate (DSAR)

[PLATFORM PROVIDER] — Runbook Operațional InternUltima actualizare: [DATE]

Runbook operațional intern. Prezenta procedură ghidează răspunsul [PLATFORM PROVIDER] la cererile de exercitare a drepturilor persoanelor vizate în temeiul GDPR. Ea este publicată pe site-ul de documentație juridică, alături de politicile destinate clienților.

GAP-GOV-03 · GOVERNANCE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior, chiar în deschiderea sa, că este destinată exclusiv uzului intern și că nu este publicată clienților sau participanților. În realitate, ea este înscrisă în navigația juridică publicată a prezentului site de documentație, care nu impune nicio autentificare și indexează întregul corpus în căutarea proprie, astfel încât detaliile operaționale pe care le conține — inclusiv deficiențele privind cererile de exercitare a drepturilor, consemnate mai jos — sunt publice. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

1. Prezentare Generală

În temeiul art. 12-22 din Regulamentul (UE) 2016/679 (GDPR), persoanele fizice (Persoanele Vizate) au drepturi cu privire la datele lor cu caracter personal. Întrucât [PLATFORM PROVIDER] acționează în calitate de Persoană împuternicită de operator, majoritatea cererilor întemeiate pe GDPR sunt primite de Clienți (Operatorii de date) și transmise [PLATFORM PROVIDER] pentru asistență. Cu toate acestea, Persoanele Vizate pot contacta ocazional [PLATFORM PROVIDER] în mod direct.

SLA de răspuns: 5 zile lucrătoare de la primirea unei cereri valide și complete (în conformitate cu Secțiunea 7.2 din DPA).

Termen legal: Operatorul trebuie să răspundă în termen de o lună de la primire, termen prelungibil cu încă două luni atunci când cererea este complexă sau când cererile sunt numeroase (art. 12 alin. (3) GDPR). Termenul de cinci zile lucrătoare menționat mai sus este o țintă internă convenită cu Clienții; el nu reprezintă termenul legal și nu înlătură obligația Operatorului.

---

2. Tipuri de Cereri

Drept GDPR	Articol	Descriere
Dreptul de acces	art. 15	Persoana Vizată solicită o copie a tuturor datelor sale cu caracter personal
Dreptul la rectificare	art. 16	Persoana Vizată solicită corectarea datelor inexacte
Dreptul la ștergere	art. 17	Persoana Vizată solicită ștergerea datelor sale („dreptul de a fi uitat")
Dreptul la restricționarea prelucrării	art. 18	Persoana Vizată solicită suspendarea temporară a prelucrării
Dreptul la portabilitatea datelor	art. 20	Persoana Vizată solicită un export al datelor sale în format care poate fi citit automat
Dreptul la opoziție	art. 21	Persoana Vizată se opune prelucrării (de exemplu, marketing, creare de profiluri)

Care dintre acestea pot fi consemnate ca tip de cerere. Registrul cererilor GDPR acceptă exact cinci valori — deletion, access, portability, objection și restriction — iar formularul de cerere nouă din tabloul de bord oferă aceleași cinci opțiuni. O ștergere se consemnează drept deletion. Nu există un tip rectification: o cerere întemeiată pe art. 16 GDPR este soluționată și probată astfel cum se arată în Secțiunea 5.3, iar nu în registru.

---

3. Primirea Cererii

3.1 Cereri prin Client (Calea Normală)

1. Clientul primește o DSAR de la un participant
2. Clientul înregistrează cererea în tabloul de bord [PLATFORM PROVIDER] (GDPR → Cerere nouă, la /gdpr). Singurul câmp al formularului care identifică persoana este hash-ul SHA-256 al adresei de e-mail a Persoanei Vizate, câmp obligatoriu; acesta este afișat în pagina de detaliu a contactului și poate fi calculat, altfel, ca SHA-256 al adresei convertite în minuscule și lipsite de spațiile de la capete. O cerere nu poate fi depusă pornind exclusiv de la o adresă de e-mail în clar
3. Cererea este creată cu starea pending. Nu există nicio notificare: nu există nicio integrare de alertare, nu se transmite niciun mesaj și nimic nu prelucrează automat o cerere aflată în așteptare. Singura formă de semnalare este un indicator numeric al cererilor GDPR aflate în așteptare, afișat pe pagina principală a tabloului de bord, pe care un membru al personalului trebuie să îl consulte
4. Echipa [PLATFORM PROVIDER] prelucrează cererea în conformitate cu Secțiunea 5 de mai jos și actualizează starea acesteia în tabloul de bord
5. Clientul comunică rezultatul Persoanei Vizate

Control operațional permanent. Întrucât nimic nu semnalează o cerere aflată în așteptare în afara acelui indicator numeric, un membru al personalului trebuie să verifice pagina GDPR pentru cererile în așteptare cel puțin o dată în fiecare zi lucrătoare. Cererile deschise de participanți prin procedura de ștergere în regim de autoservire, precum și cele deschise automat de fluxul de schimbare a adresei de e-mail (Secțiunea 4), nu ajung altfel la nimeni și rămân la starea pending pe termen nelimitat.

GAP-PROC-02 · PROCESS — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior că [PLATFORM PROVIDER] primește o notificare în tabloul de bord atunci când un Client înregistrează o cerere și că fluxul de ștergere se execută în termen de 24 de ore. Niciuna dintre cele două afirmații nu descrie comportamentul sistemului: nu există în platformă niciun mecanism de notificare, de alertare sau de apelare a echipei de gardă și nu există niciun cronometru, nicio golire programată de coadă și niciun job programat pentru cererile GDPR — fluxul rulează numai atunci când un membru al personalului apasă butonul de procesare și se încheie în cadrul aceleiași cereri HTTP. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.2 Cereri Directe către [PLATFORM PROVIDER]

Dacă un participant contactează [PLATFORM PROVIDER] în mod direct (de exemplu, prin e-mail la [PLATFORM PROVIDER LEGAL EMAIL] sau [PLATFORM PROVIDER PRIVACY EMAIL]):

1. Înregistrarea cererii — se creează o intrare în foaia internă de urmărire a DSAR-urilor, în termen de 24 de ore
2. Confirmarea primirii, și numai atât — se transmite Persoanei Vizate un e-mail prin care se confirmă că cererea a fost primită și că este transmisă Operatorului. Nu se confirmă un rezultat, un termen de soluționare și nici existența vreunei categorii determinate de date
3. Identificarea Clientului — se stabilește organizația la ale cărei evenimente a participat Persoana Vizată (se solicită adresa de e-mail și denumirea ori URL-ul evenimentului)
4. Transmiterea către Client în termen de 2 zile lucrătoare — se notifică organizația-Client că a fost primită o DSAR și i se comunică datele de identificare ale Persoanei Vizate. Acest termen constituie o clauză contractuală a DPA (Secțiunea 7.3)
5. Așteptarea autorizării din partea Clientului — [PLATFORM PROVIDER] nu răspunde pe fond Persoanei Vizate și nu soluționează nicio parte a cererii în lipsa autorizării Clientului
6. Procesare normală — după obținerea autorizării, se colaborează cu Clientul pentru soluționarea cererii în termenul SLA de 5 zile

Notă: Cererile adresate direct [PLATFORM PROVIDER] de către Persoanele Vizate sunt neobișnuite. În calitate de Persoană împuternicită de operator, obligația [PLATFORM PROVIDER] este de a asista Operatorul (Clientul), iar DPA obligă [PLATFORM PROVIDER] să transmită Clientului o astfel de cerere în termen de 2 zile lucrătoare și să nu răspundă fără autorizarea acestuia. Acțiunea întreprinsă la indicația Persoanei Vizate, în lipsa acelei autorizări, ar plasa [PLATFORM PROVIDER] în afara instrucțiunilor documentate ale Operatorului (art. 28 alin. (3) lit. (a) și art. 29 GDPR). Capacitatea tehnică de a soluționa unilateral o cerere — de exemplu, ștergerea din Postgres și din Firestore — nu conferă dreptul de a o folosi.

3.3 Verificarea Identității

Înainte de prelucrarea oricărei DSAR:

• Se verifică identitatea solicitantului, pentru a preveni divulgarea neautorizată de date
• Pentru cererile depuse prin tabloul de bord al Clientului: Clientul răspunde de verificarea identității
• Pentru cererile directe: se solicită Persoanei Vizate să confirme adresa sa de e-mail și evenimentul la care a participat. În caz de îndoială, cererea nu se prelucrează până la confirmarea identității.
• NU se solicită documentație excesivă (principiul GDPR al neimpunerii unei sarcini disproporționate)
• Se reține că o cerere este individualizată exclusiv prin hash-ul adresei de e-mail. Înainte de prelucrare, se confirmă că hash-ul introdus corespunde adresei verificate: un hash greșit nu corespunde niciunui contact, fără ca acest lucru să fie semnalat, iar în cazul unei ștergeri cererea se finalizează fără a șterge nimic (a se vedea Secțiunea 4)

---

4. Înregistrarea Cererii

Toate DSAR-urile trebuie înregistrate în registrul intern al cererilor GDPR (tabelul Postgres gdpr_requests). Tabelul conține exact următoarele coloane:

Câmp	Descriere
id	Identificatorul cererii (UUID), generat la creare — acesta este numărul de referință comunicat Persoanei Vizate
org_id	Organizația-Client
type	Una dintre valorile deletion, access, portability, objection, restriction. Nicio altă valoare nu este acceptată
email_hash	Hash-ul SHA-256 al adresei de e-mail a Persoanei Vizate. Nu se stochează nicio adresă de e-mail în clar — niciun tabel PostgreSQL nu conține una
status	pending (la creare), processing (pe durata rulării fluxului), completed (la finalizare). Nicio altă valoare nu este scrisă vreodată
requested_at	Marcajul temporal al creării cererii
completed_at	Marcajul temporal al încheierii cererii, stabilit în momentul în care starea devine completed
requested_by	Identificatorul celui care a creat cererea — un utilizator din personal, attendee:self-service sau attendee:email-change. Nu consemnează cine a prelucrat-o
log	Tablou JSON cu intrările pașilor fluxului (pasul, starea, detalii în format liber, marcajul temporal). Este singurul loc în care pot fi consemnate note în format liber
created_at	Marcajul temporal al creării rândului

Nu există nicio coloană de termen și nicio stare de respingere. Termenul de răspuns nu este calculat și nu este stocat nicăieri în platformă; el trebuie urmărit în foaia internă de urmărire a DSAR-urilor. O cerere refuzată sau respinsă — pe care Secțiunea 8 o impune în cazul unei cereri frauduloase — nu are nicio stare în registru: ea poate fi consemnată numai ca text liber în foaia internă de urmărire, iar o cerere lăsată neprelucrată rămâne imposibil de deosebit de una pe care nimeni nu a analizat-o.

GAP-RET-11 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Această secțiune afirma anterior că registrul conține un câmp request_type, un câmp subject_email în clar sau sub formă de hash, un câmp received_at, un termen deadline calculat, un câmp processed_at, un câmp processed_by și un câmp notes în format liber, cu stările pending, in progress, completed sau rejected. Dintre acestea există numai identificatorul organizației: registrul stochează type, email_hash, requested_at, completed_at, requested_by și un log în format JSON, nu are niciun câmp de termen, iar singurele stări scrise vreodată sunt pending, processing și completed, astfel încât un refuz nu poate fi consemnat în niciun fel în dreptul cererii. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Rectificarea nu poate fi consemnată aici. Registrul nu acceptă un tip rectification, iar endpoint-ul de procesare îl respinge, astfel încât cererile întemeiate pe art. 16 GDPR sunt probate prin jurnalul de audit — a se vedea Secțiunea 5.3.

Intrările din registru create de fluxul de schimbare a adresei de e-mail nu reprezintă ștergeri realizate. Atunci când un participant își schimbă adresa de e-mail din pagina de preferințe, platforma rescrie hash-ul adresei contactului cu noua valoare, după care deschide o cerere de tip deletion în dreptul hash-ului vechi, cu requested_by stabilit la attendee:email-change. Atunci când un membru al personalului prelucrează acea cerere, fluxul caută un contact sub hash-ul vechi, nu găsește niciunul, consemnează find_contact: not_found, marchează cererea drept completed, cu marcaj temporal de finalizare, și se oprește — înaintea tuturor pașilor de ștergere. Prin urmare, evidențele cheiate pe hash-ul adresei de e-mail, pentru a căror curățare fusese deschisă cererea (evidențele de livrare a e-mailurilor, evidențele de livrare push, token-urile de dispozitiv, evidențele difuzărilor către segmente), supraviețuiesc. Cererile al căror requested_by este attendee:email-change nu trebuie contabilizate drept ștergeri realizate în niciun raport de responsabilizare și nu trebuie folosite ca dovadă a ștergerii datelor.

GAP-RET-08 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior că fiecare intrare completed din registru constituie dovada efectuării unei ștergeri. Fluxul de schimbare a adresei de e-mail deschide o cerere de ștergere în dreptul unui hash care nu mai identifică niciun contact, iar fluxul de ștergere consemnează acea cerere drept finalizată fără a șterge nimic, astfel încât registrul acumulează finalizări care nu au efectuat nicio ștergere, în timp ce evidențele cheiate pe hash-ul anterior rămân neatinse. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

5. Proceduri de Procesare

5.1 Dreptul de Acces (art. 15 GDPR)

Obiectiv: Furnizarea unei copii complete și lizibile a tuturor datelor cu caracter personal deținute despre Persoana Vizată.

Pași:

1. În tabloul de bord se accesează secțiunea GDPR (/gdpr), se identifică cererea de acces sau de portabilitate și se apasă Procesare. Nu există o acțiune separată de export și niciun endpoint dedicat exportului: prelucrarea unei cereri de tip access sau portability produce exportul JSON și îl afișează pe loc
2. Sistemul generează un export JSON care conține exact următoarele elemente și nimic altceva:
   • Fișa contactului (hash-ul adresei de e-mail, indicatorii, starea de restricționare, marcajele temporale)
   • Înregistrările (webinar_registrations, inclusiv coloanele de participare attended_via și attended_at — nu există un tabel separat de participare)
   • Evenimentele comportamentale (numai acolo unde consimțământul behavioral_tracking era acordat la momentul consemnării evenimentului)
   • Evidențele de consimțământ (toate scopurile, marcajele temporale, metodele) și istoricul evenimentelor de consimțământ
   • Apartenențele la segmente
   • Evidențele de livrare a e-mailurilor (email_sends: tipul șablonului, starea, marcajele temporale)
   • Evidențele de livrare push (push_sends: tipul șablonului, starea, marcajul temporal al deschiderii)
   • Token-urile de dispozitiv (token-uri FCM asociate contului Persoanei Vizate, pseudonime)
   • Scorurile de prospect
   • Datele cu caracter personal ale contactului din Firestore (adresa de e-mail în clar, numele, numărul de telefon), documentele de consimțământ din Firestore și documentele de înregistrare din Firestore
   • Datele sesiunilor live, pentru fiecare înregistrare: participarea, fișa de actor (numele afișat), sesiunile de prezență, voturile la sondaje, click-urile pe oferte, răspunsurile de feedback, indicatorii de actor blocat și de actor restricționat, mesajele din chat aflate în fluxul live și în fluxul mesajelor eliminate, reacțiile și mesajele sesizate
3. Colectarea manuală a surselor omise. Exportul automat nu interoghează sursele de mai jos, care toate conțin date cu caracter personal ale Persoanei Vizate. Fiecare trebuie extrasă manual și adăugată la răspuns, altfel răspunsul este incomplet:
   • Intrările în funnel (funnel_entries) — fiecare parametru UTM, identificatorul de click publicitar și platforma de click, URL-ul paginii de destinație, URL-ul de proveniență, codul de țară, orașul, tipul dispozitivului, sistemul de operare, browserul, fusul orar al browserului, sursa de recomandare și, pentru intrările provenite din webhook-uri, payload-ul brut al webhook-ului și metadatele comenzii
   • Vizualizările de pagină ale funnel-urilor (funnel_page_views) — hash-ul pseudonim persistent al vizitatorului, derivat din adresa IP și din user agent
   • Evidențele de livrare SMS (sms_sends) — webinarul și sesiunea, tipul șablonului, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării, precum și marcajele temporale de livrare și de click
   • Evidențele difuzărilor către segmente (segment_broadcast_sends) — difuzările care i-au fost transmise Persoanei Vizate
   • Înscrierile în automatizări și execuțiile pașilor (automation_enrollments, automation_step_executions) — inclusiv documentele cu rezultatul pașilor, care conțin adresa de e-mail a destinatarului în clar, pentru pașii de e-mail, și numărul său de telefon în clar, pentru pașii de SMS
   • Evidențele de generare cu AI (ai_jobs) — acolo unde Persoana Vizată a transmis un testimonial aprobat de personal, numele său, citatul, denumirea companiei și nota acordată sunt încorporate în prompturile și în rezultatele de generare stocate
4. Se verifică exportul și materialul colectat manual sub aspectul completitudinii, înainte de transmitere
5. Se răspunde în scris, alături de fișierul JSON, la aspectele prevăzute la art. 15 alin. (1) lit. (a)-(h) GDPR. Exportul conține numai date; el nu indică scopurile prelucrării, categoriile de date cu caracter personal, destinatarii, perioadele de retenție, existența celorlalte drepturi, dreptul de a depune o plângere la o autoritate de supraveghere și nici sursa datelor. În special:
   • Destinatarii trebuie să îi cuprindă pe subîmputerniciții și pe destinatarii ulteriori enumerați în Secțiunea 6, nu numai furnizorii de stocare
   • Sursa (art. 15 alin. (1) lit. (g) GDPR) trebuie comunicată acolo unde datele nu au fost colectate de la Persoana Vizată. Datele privind comenzile și formularele provin din webhook-uri aflate în sarcina Clientului — MerchantPro, WooCommerce, Tally sau un expeditor generic — și nu au fost colectate de [PLATFORM PROVIDER] de la Persoana Vizată
   • Evidențele de consimțământ trebuie adnotate. Rândurile de consimțământ a căror metodă este import au fost scrise de importatorul în masă pentru contacte care nu au interacționat niciodată cu platforma, iar exportul le redă identic cu consimțămintele acordate efectiv de Persoana Vizată. Consimțământul este consemnat numai ca acordare, deci registrul consimțămintelor nu păstrează nicio evidență a unui refuz: absența unui scop poate însemna fie că Persoana Vizată l-a refuzat, fie că nu i-a fost solicitat niciodată, iar exportul nu poate deosebi cele două situații. Acest lucru se menționează expres
6. Răspunsul se transmite Clientului, care are calitatea de Operator. Atunci când cererea a ajuns direct la [PLATFORM PROVIDER], exportul nu se transmite Persoanei Vizate fără autorizarea Clientului (Secțiunea 3.2)
7. Se marchează cererea drept finalizată în tabloul de bord
8. Termen: În 5 zile lucrătoare

Format: JSON (care poate fi citit automat). Dacă Persoana Vizată solicită un format mai accesibil, i se furnizează alături și un rezumat lizibil de către om.

GAP-RET-04 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior că exportul cuprinde evidențe de participare și date de atribuire (parametri UTM și identificatori de click) și îl prezenta drept o copie completă a datelor cu caracter personal deținute. Exportul nu interoghează niciodată intrările în funnel — acolo unde se află toate datele de atribuire, de dispozitiv și de localizare aproximativă — și nici vizualizările de pagină ale funnel-urilor, evidențele de livrare SMS, evidențele difuzărilor către segmente, înscrierile în automatizări și execuțiile pașilor ori evidențele de generare cu AI, astfel încât aceste categorii sunt prelucrate, dar nu sunt accesibile în temeiul art. 15 sau al art. 20 GDPR fără pasul de colectare manuală descris mai sus. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Ce NU este inclus:

• Datele altor participanți (chiar dacă au participat la același eveniment)
• Statisticile agregate sau anonimizate care nu pot fi legate de persoana individuală
• Intrările din jurnalul intern de audit, în integralitatea lor. Un refuz general nu este posibil: GDPR nu cunoaște nicio „prevalență a interesului legitim", art. 15 alin. (4) GDPR protejează exclusiv drepturile și libertățile altora, iar orice restrângere suplimentară presupune o măsură legislativă a Uniunii sau a unui stat membru, în temeiul art. 23 GDPR. Intrările de audit create de fluxul drepturilor persoanelor vizate consemnează chiar hash-ul adresei de e-mail a Persoanei Vizate, iar alte intrări o privesc în mod direct. Poziția corectă este comunicarea intrărilor care o privesc pe Persoana Vizată, cu ocultarea, în temeiul art. 15 alin. (4) GDPR, a identificatorilor personalului [PLATFORM PROVIDER] și al Clientului — identificatorul utilizatorului care a acționat, rolul, adresa IP și user agent-ul — precum și cu menționarea în răspuns a ceea ce a fost ocultat și în ce temei

---

5.2 Dreptul la Ștergere (art. 17 GDPR)

Obiectiv: Ștergerea datelor cu caracter personal ale Persoanei Vizate din sistemele la care ajunge fluxul de ștergere și consemnarea a ceea ce acesta nu atinge.

Pași:

1. În tabloul de bord se accesează secțiunea GDPR (/gdpr) și se identifică cererea de ștergere
2. Se confirmă identitatea și valabilitatea cererii (aceasta să nu facă obiectul unui ordin legal de retenție ori al unui temei legitim de păstrare). Se confirmă că hash-ul adresei de e-mail de pe cerere corespunde unui contact real — un hash fără corespondent duce la o finalizare fără niciun efect (Secțiunea 4)
3. Se apasă Procesare — aceasta rulează sincron fluxul de ștergere:

Acțiunile fluxului automatizat:

Sistem	Acțiune
Postgres email_sends	Ștergere explicită după (org_id, email_hash) — legătura se face prin hash-ul adresei de e-mail, iar nu prin cheie străină, deci tabelul nu este atins de CASCADE
Postgres push_sends	Ștergere explicită după (org_id, email_hash)
Postgres device_tokens	Ștergere explicită după (org_id, email_hash)
Postgres funnel_entries	Ștergere explicită după (org_id, contact_id); recomandările care trimit către link-urile de distribuire ale Persoanei Vizate sunt anulate în prealabil
Postgres contacts	Ștergere definitivă — CASCADE elimină behavioral_events, segment_members, consents, webinar_registrations (tabelul care poartă coloanele de participare), shares, lead_scores și automation_enrollments, iar din înscrieri, automation_step_executions
Documentele de înregistrare Firestore	Ștergere definitivă, câte una pentru fiecare înregistrare (orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}/registrations/{registrationId})
Subcolecția consents Firestore	Ștergere definitivă (orgs/{orgId}/contacts/{emailHash}/consents)
Documentul Firestore cu datele cu caracter personal ale contactului	Ștergere definitivă (orgs/{orgId}/contacts/{emailHash}/pii/private)
Documentul de contact Firestore	Ștergere definitivă (orgs/{orgId}/contacts/{emailHash})
Datele de actor din RTDB	Ștergere fără garanția reușitei, după identificatorul de actor, pentru unicul identificator de actor consemnat în dreptul fiecărei înregistrări — a se vedea mai jos
Firebase Auth	Ștergere prin Admin SDK a contului anonim corespunzător fiecărui identificator de actor consemnat, precum și a contului la care face trimitere documentul de contact
Furnizorul de e-mail	Adresa de e-mail a Persoanei Vizate este transmisă către lista de suprimare — a se vedea mai jos

Documentele Firestore sunt eliminate numai de prezentul flux ori prin ștergerea manuală a webinarului sau a sesiunii din care fac parte: nicio colecție Firestore nu are configurată o politică de expirare automată (time-to-live).

4. Verificarea finalizării fluxului. Tabloul de bord afișează intrările din jurnalul cererii, cu marcaje temporale. Acestea se citesc efectiv; finalizarea nu se tratează drept reușită:
   • Pasul aferent bazei de date live raportează deleted N RTDB paths (M registrations without actor_id skipped). Se verifică acel număr de înregistrări omise. Fiecare înregistrare omisă corespunde unei sesiuni ale cărei date live — numele afișat, mesajele din chat, voturile la sondaje, reacțiile — au rămas neatinse
   • Fiecare ștergere din baza de date live și din Firebase Auth se execută fără garanția reușitei: un eșec este consemnat ca avertisment, iar fluxul continuă, astfel încât un pas poate raporta finalizarea deși anumite căi nu au fost eliminate
   • Atunci când numărul de înregistrări omise este diferit de zero sau când este consemnat un eșec, se aplică procedura manuală de rezervă: pentru fiecare sesiune a Persoanei Vizate se citește live/{sessionId}/identityCache și se șterg datele fiecărui identificator de actor asociat hash-ului adresei sale de e-mail, iar nu doar ale celui consemnat în dreptul înregistrării
5. Se consemnează rezultatul. Fluxul scrie jurnalul pașilor săi în rândul din gdpr_requests și stabilește starea la completed; nu există o acțiune separată de consemnare
6. Termen: cifra de 24 de ore reprezintă o țintă operațională internă pentru prelucrarea cererii de către un membru al personalului, iar nu un comportament automat — nimic nu declanșează fluxul, iar odată declanșat acesta rulează în câteva secunde, în cadrul unei singure cereri HTTP. Confirmarea către Client sau către Persoana Vizată în 5 zile lucrătoare

Ce NU este șters la ștergere:

• Statisticile anonimizate sau agregate (totalurile de vizualizări ale unei sesiuni, nelegate de persoana individuală)
• Intrările din jurnalul de audit. Acestea sunt păstrate în scopuri de securitate și de responsabilizare (art. 5 alin. (2) GDPR). Jurnalul de audit și registrul cererilor persoanelor vizate nu se numără printre tipurile de date pe care jobul de retenție le recunoaște, iar nimic altceva din platformă nu șterge din ele, deci ambele cresc nelimitat. Jurnalul de audit consemnează adresa IP și user agent-ul utilizatorului care acționează, iar intrările create de fluxul drepturilor persoanelor vizate consemnează în metadatele lor hash-ul adresei de e-mail a persoanei vizate, astfel încât hash-ul unei persoane șterse rămâne în jurnalul de audit și după ștergere. Rolul de bază de date al aplicației deține numai privilegii de selectare și de inserare asupra jurnalului de audit, ceea ce îl face să fie doar de adăugare pentru aplicație, dar înseamnă totodată că nu poate fi golit prin conexiunea acesteia
• Însuși rândul din gdpr_requests, păstrat ca dovadă a soluționării cererii. Este păstrat pe termen nelimitat, pentru același motiv ca jurnalul de audit
• consent_events, traseul de consimțământ, doar de adăugare, păstrat ca dovadă în temeiul art. 7 alin. (1) GDPR. Rândurile sale nu sunt șterse: trimiterea la contact este anulată, iar rândul supraviețuiește în formă pseudonimizată, cu păstrarea identificatorilor organizației, ai webinarului și ai înregistrării, a domeniului de aplicare, a scopului, a acțiunii, a metodei, a versiunii de politică și a marcajului temporal. Nicio regulă de retenție nu îl acoperă. În schimb, tabelul consents, care păstrează starea curentă, este șters prin CASCADE
• Două tabele care conțin date cu caracter personal cheiate pe hash-ul adresei de e-mail nu sunt atinse de rutina de ștergere și nu au nicio cheie străină către fișa contactului, deci nu sunt eliminate nici în cascadă: jurnalul de livrare a SMS-urilor și jurnalul destinatarilor difuzărilor către segmente. Prin urmare, o evidență individuală a mesajelor SMS trimise — hash-ul adresei de e-mail, webinarul și sesiunea, tipul de șablon, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării și marcajele temporale de livrare și de click — persistă după o ștergere în temeiul art. 17 GDPR, iar niciunul dintre cele două tabele nu este inclus în exportul de date în temeiul art. 15 GDPR
• Evidențele de generare cu AI (ai_jobs). Rândurile sunt cheiate pe o entitate și pe membrul personalului care a inițiat jobul, fără nicio legătură cu o fișă de contact, deci nu sunt atinse nici de rutina de ștergere, nici de eliminarea în cascadă. Acolo unde Persoana Vizată a transmis un testimonial aprobat de personal, numele său și citatul persistă în promptul și în rezultatul stocate și după ștergere
• Marcajele de deduplicare per actor și numărul de mesaje din baza de date live. Curățarea bazei de date live acoperă optsprezece familii de noduri, dar nu are nicio cale pentru marcajele de deduplicare per actor aflate sub live/{sessionId}/synced/ și nici pentru live/{sessionId}/actorMessageCounts/{actorId}, astfel încât identificatorul anonim de actor al Persoanei Vizate și numărul său de mesaje pe sesiune rămân stocate ca valori terminale
• Datele sesiunilor live aflate sub orice alt identificator de actor decât cel consemnat în dreptul înregistrării. Fiecare înregistrare stochează un singur identificator de actor și îl păstrează pe primul întâlnit, astfel încât participantul care s-a conectat de pe un al doilea dispozitiv sau care s-a reconectat sub o nouă identitate anonimă își păstrează numele afișat, mesajele din chat, voturile la sondaje și reacțiile sub identificatorul neconsemnat

Reziduurile din sesiunile live sunt permanente dacă nu sunt eliminate manual. Datele sesiunilor live din Realtime Database sunt păstrate pe termen nelimitat. Nu există nicio funcție programată de curățare: baza de cod Cloud Functions exportă zece funcții, dintre care nouă sunt declanșatoare de bază de date, iar una este un job de reconciliere a prezenței care rulează din minut în minut, și niciuna nu șterge datele sesiunii. Nici trecerea unei sesiuni în starea de replay sau de arhivă nu le elimină — jobul de ciclu de viață scrie în Firestore un instantaneu cu statistici și nu efectuează nicio ștergere în Realtime Database. Singurele operațiuni care elimină un nod de sesiune live sunt ștergerea manuală a sesiunii și ștergerea manuală a webinarului asociat. Prin urmare, textul mesajelor din chat, numele afișate ale participanților, evidențele de prezență și de participare, voturile la sondaje, reacțiile, click-urile pe oferte și răspunsurile de feedback persistă pe toată durata de viață a fișei webinarului.

Ștergerea la nivelul furnizorului de e-mail este o suprimare, nu o eliminare. La finalizarea unei ștergeri, platforma transmite furnizorului de e-mail adresa contactului cu statutul de respins definitiv, astfel încât niciun mesaj viitor să nu îi mai poată fi livrat. Prin proiectare, aceasta menține adresa de e-mail în clar în evidențele furnizorului pe termen nelimitat. Persoana Vizată trebuie informată despre acest lucru, iar păstrarea trebuie justificată — este o prelucrare necesară pentru a da efect propriei sale ștergeri și pentru a împiedica orice contactare ulterioară, întemeiată pe art. 17 alin. (3) lit. (b) și pe art. 6 alin. (1) lit. (c)/(f) GDPR.

Copii în clar pot rămâne în memoria altor instanțe ale API-ului. API-ul menține, în memoria procesului, o memorie cache cu datele de contact în clar (adresă de e-mail, nume și număr de telefon), cheiată pe organizație și pe hash-ul adresei de e-mail, pentru a evita citirile repetate din Firestore. Memoria cache nu are termen de expirare, iar intrările sunt invalidate numai în procesul care efectuează scrierea. Atunci când rulează mai multe instanțe ale API-ului, o rectificare sau o ștergere aplicată pe o instanță nu elimină copia deținută de o alta. Fluxul invalidează intrarea pe instanța care l-a executat; într-o implementare cu mai multe instanțe, numai o repornire sau o nouă implementare garantează invalidarea peste tot. „Verificarea finalizării fluxului" nu constituie dovada că nu a mai rămas nicio copie în clar.

GAP-RET-03 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Această secțiune afirma anterior că fluxul șterge toate datele cu caracter personal ale Persoanei Vizate din toate sistemele și enumera ștergerea prin CASCADE a unor tabele denumite registrations, attendance_records și attribution_data, dintre care niciunul nu există în schemă. În realitate, mai multe categorii supraviețuiesc unei ștergeri: jurnalul de livrare a SMS-urilor și jurnalul destinatarilor difuzărilor către segmente, evidențele de generare cu AI care conțin testimoniale aprobate ale participanților, marcajele de deduplicare per actor și numărul de mesaje din baza de date live, precum și toate datele sesiunilor live care aparțin oricărui alt identificator de actor decât cel unic consemnat în dreptul fiecărei înregistrări; suplimentar, adresa de e-mail este păstrată la furnizorul de e-mail sub forma unei suprimări permanente. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

GAP-RET-05 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior că jurnalele de audit sunt păstrate doi ani în conformitate cu politica de securitate și că registrul cererilor GDPR este păstrat trei ani ca dovadă de conformitate, iar cifra de doi ani era reluată în șablonul de confirmare a ștergerii transmis Persoanei Vizate. Niciunul dintre cele două tabele nu se numără printre tipurile de date pe care jobul de retenție le recunoaște și niciun alt mecanism nu șterge din ele, deci ambele sunt păstrate pe termen nelimitat; în plus, rolul de bază de date al aplicației nu deține niciun privilegiu de ștergere asupra jurnalului de audit. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Temeiuri juridice pentru refuzul ștergerii:

• Obligație juridică de păstrare (de exemplu, evidențe fiscale sau financiare — nu se aplică datelor participanților)
• Ordin legal de retenție
• Prelucrarea este necesară pentru constatarea, exercitarea sau apărarea unui drept în instanță
• Aducerea la îndeplinire a ștergerii înseși: adresa de e-mail aflată pe lista de suprimare a furnizorului este păstrată în temeiul art. 17 alin. (3) lit. (b) GDPR, pentru ca ștergerea să poată produce efecte
• Se reține că jurnalul de audit și traseul evenimentelor de consimțământ nu sunt refuzate în temeiul vreunei prevalențe. Ele sunt păstrate ca dovadă de responsabilizare, în temeiul art. 5 alin. (2) și al art. 7 alin. (1) GDPR, ceea ce constituie un temei de păstrare, iar nu un motiv de refuz al dreptului; Persoana Vizată trebuie informată cu privire la ceea ce se păstrează și la motivul păstrării

---

5.3 Dreptul la Rectificare (art. 16 GDPR)

Obiectiv: Corectarea datelor cu caracter personal inexacte.

Ce poate fi corectat în realitate:

• De către personalul Clientului, în tabloul de bord: exclusiv numele contactului (Contacte → [Contact] → Editare nume). Corectura este scrisă în documentul Firestore cu datele cu caracter personal ale contactului
• De către Persoana Vizată, în pagina de preferințe a participantului: numele său, adresa sa de e-mail (operațiune care rescrie hash-ul adresei contactului) și eliminarea numărului său de telefon
• Nimic din PostgreSQL nu necesită corectare, întrucât niciun tabel PostgreSQL nu conține o adresă de e-mail, un număr de telefon sau un nume de persoană în clar. Contactele sunt cheiate printr-un hash SHA-256 al adresei de e-mail convertite în minuscule și lipsite de spațiile de la capete, iar datele de contact în clar sunt păstrate exclusiv în Firestore, la orgs/{orgId}/contacts/{emailHash}/pii/private. Se aplică două excepții. Prima: motorul de automatizări consemnează rezultatul fiecărui pas executat sub forma unui document JSON în PostgreSQL, iar pentru pașii de e-mail și de SMS acel document conține adresa de e-mail sau numărul de telefon al destinatarului, în clar; aceste evidențe sunt eliminate în cascadă la ștergerea contactului, dar nu sunt pseudonimizate în alt mod — și nu sunt actualizate printr-o rectificare. A doua: tabelul ai_jobs stochează textul integral al promptului fiecărei generări cu AI, care poate conține un testimonial aprobat al unui participant, împreună cu numele și denumirea companiei consemnate în dreptul acestuia; rândurile respective nu poartă nicio legătură cu un contact, nu sunt eliminate la ștergere și nu sunt actualizate printr-o rectificare
• Numele afișat al participantului, păstrat în baza de date live, nu este actualizat printr-o rectificare și își păstrează valoarea anterioară

Pași:

1. Clientul efectuează corectura în tabloul de bord (Contacte → [Contact] → Editare) ori Persoana Vizată o efectuează ea însăși în pagina de preferințe
2. Corectura este scrisă în Firestore. Propagarea către celelalte instanțe ale API-ului este supusă memoriei cache din proces cu datele cu caracter personal în clar, descrisă în Secțiunea 5.2: într-o implementare cu mai multe instanțe, o altă instanță poate servi o copie învechită până la repornirea sa
3. Dacă documentul de contact al aplicației mobile trebuie actualizat, API-ul gestionează sincronizarea
4. Rectificarea se probează prin jurnalul de audit. O rectificare nu poate fi consemnată în registrul cererilor GDPR — niciun tip rectification nu este acceptat. Corectura numelui efectuată de personal scrie o intrare de audit updated_contact_name, cu identificatorul contactului, noua valoare, utilizatorul care a acționat și marcajul temporal; acea intrare constituie evidența corecturii. Corectura pe care Persoana Vizată o efectuează ea însăși în pagina de preferințe nu este auditată și trebuie consemnată manual în foaia internă de urmărire a DSAR-urilor
5. Termen: Imediat la efectuarea corecturii de către Client, sub rezerva reîmprospătării memoriei cache pe celelalte instanțe ale API-ului; confirmare către Persoana Vizată în 5 zile lucrătoare

GAP-RET-08 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură îl instruia anterior pe operator să consemneze o rectificare în registrul cererilor GDPR și descria corecturile ca fiind propagate automat în Firestore și în PostgreSQL. Registrul acceptă numai tipurile deletion, access, portability, objection și restriction, iar un tip de rectificare este respins, astfel încât acel pas nu poate fi realizat; corecturile sunt scrise exclusiv în Firestore și nu ajung nici la numele afișat al participantului din baza de date live, nici la adresele și numerele de telefon în clar păstrate în evidențele de execuție a pașilor de automatizare, nici la memoriile cache din procesele celorlalte instanțe ale API-ului. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

5.4 Dreptul la Restricționarea Prelucrării (art. 18 GDPR)

Obiectiv: Suspendarea prelucrării pentru o Persoană Vizată fără ștergerea datelor acesteia.

Pași:

1. În tabloul de bord se marchează contactul drept processing_restricted ori se prelucrează o cerere de tip restriction din pagina GDPR. Oricare dintre cele două operațiuni stabilește indicatorul de restricționare și marcajul său temporal în fișa contactului; nimic altceva nu este scris
2. Restricționarea prelucrării în temeiul art. 18 GDPR este aplicată consecvent, ca restricție absolută: unui contact restricționat nu i se poate acorda și nici reacorda vreun consimțământ, nu i se transmite niciun mesaj de e-mail, SMS sau push, este exclus din exporturile de contacte și de segmente, precum și din difuzările către segmente, iar pentru el nu se transmite niciun eveniment de conversie pe server
3. Consemnarea evenimentelor comportamentale nu este suprimată de restricționare și trebuie oprită manual. Stabilirea indicatorului de restricționare nu scrie nimic în Firestore, iar calea de colectare a datelor comportamentale nu efectuează nicio verificare a restricționării, astfel încât mesajele din chat, voturile la sondaje, reacțiile, click-urile pe oferte și feedbackul unui contact restricționat continuă să fie consemnate în baza de date analitică și în baza de date live atât timp cât acesta participă la sesiuni. Pentru a opri consemnarea în baza de date analitică, documentul de consimțământ behavioral_tracking al contactului din Firestore trebuie trecut pe „retras", printr-o acțiune separată a operatorului — a se vedea nota privind retragerea consimțământului din Secțiunea 5.6 —, după care modificarea este sincronizată automat către baza de date analitică. Pentru a opri captarea datelor din sesiunile live, contactul trebuie exclus de la sesiunile următoare; nimic din produs nu o suprimă
4. Contactul rămâne în sistem (datele nu sunt șterse), dar este în rest înghețat
5. Se consemnează restricționarea în gdpr_requests (tip restriction)
6. Se notifică Persoana Vizată cu privire la confirmarea restricționării și i se comunică ce anume oprește și ce nu oprește restricționarea
7. Termen: În 2 zile lucrătoare

GAP-RET-09 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură arăta anterior că o restricționare a prelucrării suprimă consemnarea evenimentelor comportamentale. Stabilirea restricționării scrie numai indicatorul de restricționare în fișa contactului: calea de colectare a datelor comportamentale nu efectuează nicio verificare a restricționării, iar condiția din amonte, aflată în Cloud Functions, este consimțământul contactului pentru urmărirea comportamentală, pe care restricționarea nu îl retrage — astfel încât evenimentele comportamentale continuă să fie consemnate în dreptul unui contact restricționat. Celelalte suprimări enumerate în prezenta secțiune sunt aplicate efectiv. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Ridicarea restricționării: Clientul poate ridica restricționarea din tabloul de bord (operațiune care necesită un motiv documentat din partea Persoanei Vizate).

---

5.5 Dreptul la Portabilitatea Datelor (art. 20 GDPR)

Obiectiv: Furnizarea datelor în format care poate fi citit automat, în vederea transferului către alt serviciu.

Pași:

• Identică cu procedura de acces (Secțiunea 5.1) — același export JSON, produs de aceeași acțiune, cu aceleași omisiuni. Pasul de colectare manuală de la Secțiunea 5.1, punctul 3, se aplică integral: intrările în funnel, vizualizările de pagină ale funnel-urilor, evidențele de livrare SMS, evidențele difuzărilor către segmente, evidențele de automatizare și evidențele de generare cu AI nu se regăsesc în export
• Se confirmă că exportul este într-un format standard (JSON poate fi citit automat și este portabil)
• Termen: În 5 zile lucrătoare

---

5.6 Dreptul la Opoziție (art. 21 GDPR)

Obiectiv: Oprirea prelucrării întemeiate pe interesul legitim sau efectuate în scop de marketing direct.

Scenarii aplicabile:

Opoziție	Acțiune
Opoziție față de e-mailurile de marketing	Retragerea consimțământului email_marketing nu este suficientă: acel consimțământ condiționează numai sincronizarea contactului în lista și în segmentele furnizorului de e-mail de marketing. Fiecare e-mail transmis din produs — confirmarea înregistrării, notificările de reamintire, mesajul „începe acum", cel de replay, e-mailul dintr-o automatizare, retrimiterea și difuzarea către segment — funcționează exclusiv pe condiția tranzacțională (contactul să nu fie suprimat pentru bounce, reclamație sau dezabonare globală și să nu facă obiectul unei restricționări în temeiul art. 18 GDPR). Pentru a le opri, se stabilește suplimentar indicatorul de dezabonare globală al contactului, acesta se elimină din segmentele folosite pentru difuzări ori i se aplică o restricționare a prelucrării în temeiul art. 18 GDPR
Opoziție față de notificările push de marketing	Neimplementat. Nu există nicio cale de trimitere a notificărilor push de marketing, iar consimțământul push_marketing nu condiționează nimic. Retragerea sa consemnează opoziția, dar nu schimbă niciun comportament. Notificările push tranzacționale sunt oprite printr-o restricționare a prelucrării în temeiul art. 18 GDPR
Opoziție față de urmărirea comportamentală	Se retrage consimțământul behavioral_tracking. Atunci când un participant nu a acordat consimțământul pentru urmărirea comportamentală, mesajele sale din chat, voturile la sondaje, reacțiile, click-urile pe oferte și feedbackul sunt scrise în continuare în baza de date a sesiunilor live și rămân vizibile pentru personal în tabloul de bord live, iar participarea sa este consemnată în continuare în dreptul înregistrării. Sunt suprimate numai rândurile granulare de evenimente comportamentale din baza de date analitică. Evenimentele deja consemnate sunt eliminate numai printr-o ștergere în temeiul art. 17 GDPR
Opoziție față de WhatsApp/SMS	SMS: se retrage consimțământul sms_notifications; aceasta este o condiție aplicată efectiv — niciun mesaj SMS nu este trimis în lipsa unui consimțământ sms_notifications acordat și neretras. sms_marketing nu condiționează nimic. WhatsApp: neimplementat. WhatsApp există numai sub forma unui comutator de integrare la nivel de organizație și a unor link-uri de distribuire; nu există nicio cale de trimitere a mesajelor, deci whatsapp_notifications și whatsapp_marketing nu condiționează nimic
Opoziție față de urmărirea conversiilor publicitare	Se aplică o restricționare a prelucrării în temeiul art. 18 GDPR. Pe căile de conversie de pe server nu există nicio condiție de consimțământ publicitar: Meta Conversions API și TikTok Events API transmit la fiecare înregistrare pentru care Clientul a activat integrarea, iar valoarea consimțământului publicitar consemnată în documentul de înregistrare nu este citită de nimic. Restricționarea prelucrării este singurul mecanism care le suprimă. Se reține că aceasta oprește numai transmiterile viitoare — a se vedea Secțiunea 6
Opoziție față de comunicările tranzacționale	Nu poate fi onorată în temeiul interesului legitim dacă participantul este o persoană înregistrată activă — se informează Persoana Vizată
Opoziție față de măsurarea paginilor de destinație	Nu poate fi onorată retroactiv și nu poate fi dezactivată individual. Un identificator de vizitator unic — un hash al adresei IP și al user agent-ului vizitatorului — este consemnat pentru fiecare pas de funnel încărcat de acesta, o singură dată pe zi, fără nicio condiție de consimțământ și fără nicio legătură cu o fișă de contact, deci nu poate fi localizat pentru o anumită persoană. Atunci când Clientul a activat integrarea Meta, pe calea paginii de destinație se transmite suplimentar către Meta Platforms, Inc. o vizualizare de pagină, pe partea de server, care poartă adresa IP brută și user agent-ul brut ale vizitatorului
Opoziție față de moderarea automată a chatului	Nu poate fi dezactivată individual. Atunci când Clientul configurează cuvinte interzise, fiecare mesaj din chat este verificat automat; mesajul care corespunde este fie mascat pe loc, fie eliminat din fluxul live și mutat într-un flux al mesajelor eliminate, vizibil pentru personal, care păstrează textul original al mesajului, împreună cu motivul eliminării și cu marcajul temporal. Pentru o Persoană Vizată, mesajele eliminate sunt șterse numai printr-o ștergere în temeiul art. 17 GDPR și numai sub identificatorul de actor consemnat în dreptul înregistrării sale

Cum se retrage în realitate un consimțământ. Nu există niciun control pus la dispoziția personalului prin care să se retragă un consimțământ. Vizualizarea consimțămintelor unui contact din tabloul de bord este disponibilă numai în citire, anularea unei înregistrări nu retrage niciun consimțământ, întrucât consimțămintele sunt stabilite la nivel de organizație, iar pentru această operațiune nu există niciun endpoint de API destinat personalului. Un consimțământ poate fi retras numai de Persoana Vizată, din pagina de preferințe a participantului, prin urmarea unui link de dezabonare (care retrage exclusiv email_marketing) sau de către un operator, prin trecerea pe „retras" a documentului de consimțământ din Firestore, modificare sincronizată apoi automat către baza de date analitică. data_processing și tos_acceptance nu pot fi retrase deloc din pagina de preferințe.

Pași:

1. Se consemnează opoziția în gdpr_requests (tip objection). Se reține că prelucrarea unei cereri de tip objection aplică o restricționare a prelucrării — stabilește același indicator ca o cerere de tip restriction și nu face nimic altceva. Ea nu retrage niciun consimțământ
2. Se retrag consimțămintele relevante pe una dintre căile de mai sus și se aplică orice suprimare suplimentară impusă de tabel
3. Se confirmă Persoanei Vizate ce anume s-a oprit efectiv și se arată separat ce anume nu controlează consimțământul retras
4. Se confirmă Persoanei Vizate în 5 zile lucrătoare

GAP-CONSENT-06 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta procedură prezenta anterior retragerea consimțământului, efectuată de personal în tabloul de bord ori prin API, drept mecanismul care oprește fiecare categorie de prelucrare. Nu există niciun control de retragere pus la dispoziția personalului, iar mai multe dintre consimțămintele menționate nu condiționează nimic — push_marketing, sms_marketing, whatsapp_notifications și whatsapp_marketing nu au în spate nicio cale de trimitere, în timp ce email_marketing condiționează numai sincronizarea către furnizorul de e-mail de marketing, iar nu e-mailurile transmise din produs, și nu există nicio condiție de consimțământ publicitar pe căile de conversie de pe server. Restricționarea prelucrării în temeiul art. 18 GDPR este singura suprimare transversală pe care platforma o aplică efectiv. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

6. Coordonarea cu Subîmputerniciții

[PLATFORM PROVIDER] angajează unsprezece subîmputerniciți, enumerați în Anexa III (annex-sub-processors.md). Tabelul de mai jos îi cuprinde pe aceia care dețin sau primesc datele cu caracter personal ale unei Persoane Vizate într-un mod care influențează o cerere de exercitare a drepturilor, precum și proiectul Firebase propriu al Clientului, care nu este un subîmputernicit al [PLATFORM PROVIDER].

Subîmputernicit	Impact DSAR	Acțiunea [PLATFORM PROVIDER]
Google LLC (Firestore, RTDB, Firebase Auth)	Ștergerea contului Auth, ștergerea datelor din Firestore/RTDB	Acoperită de fluxul de ștergere (apeluri Admin SDK), sub rezerva excluderilor privind baza de date live din Secțiunea 5.2
Railway Corp. (Postgres)	Ștergeri de tabele Postgres	Acoperite de fluxul de ștergere (operațiuni directe în baza de date), sub rezerva excluderilor de tabele din Secțiunea 5.2
NewsmanApp SRL (livrare e-mail)	Deține adresa de e-mail în clar a Persoanei Vizate, prenumele și numele, apartenența la segmente, precum și evenimentele de vizualizare, click, bounce, reclamație și dezabonare pe care le returnează platformei	Automatizată, însă reprezintă o suprimare, iar nu o ștergere. Fluxul citește adresa de e-mail în clar din Firestore înainte de a o șterge și, după ștergere, o transmite furnizorului cu statutul de respins definitiv. Apelul se execută fără garanția reușitei, iar rezultatul său este consemnat. Prin urmare, adresa este păstrată la furnizor pe termen nelimitat, astfel încât niciun mesaj viitor să nu îi mai poată fi livrat; Persoana Vizată trebuie informată despre acest lucru. [PLATFORM PROVIDER] nu șterge fișa de abonat și nici evenimentele comportamentale deținute de furnizor — atunci când Clientul solicită acest lucru, el trebuie să acționeze din propriul cont deschis la furnizor
SendSMS.ro (România)	Numărul de telefon al destinatarului și corpul integral al mesajului sunt transmise furnizorului ca parametri în șirul de interogare al URL-ului, ceea ce impune prezumția că sunt consemnate în jurnalele de cereri ale furnizorului. La livrare, mesajul ajunge la operatorul de rețea mobilă al destinatarului	Nu se întreprinde nicio acțiune la ștergere. Fluxul nu efectuează niciun apel către furnizor, iar jurnalul local de livrare (sms_sends) nu este nici el șters (Secțiunea 5.2). Clientul este informat că ștergerea jurnalelor de mesaje deținute de furnizor trebuie solicitată în temeiul propriului său contract încheiat cu acesta și că perioada de retenție practicată de furnizor pentru conținutul mesajelor și pentru jurnalele de livrare nu este stabilită
Meta Platforms, Inc.	A primit deja, pentru fiecare înregistrare pentru care Clientul a activat integrarea, hash-uri SHA-256 ale adresei de e-mail, ale prenumelui și ale numelui, identificatorul înregistrării netransformat în hash, precum și adresa IP a clientului și user agent-ul, în formă brută — dar niciun număr de telefon; iar pe paginile de destinație ale funnel-urilor, o vizualizare de pagină de pe server, care poartă adresa IP brută și user agent-ul brut	Nu se întreprinde nicio acțiune la ștergere. În platformă nu există niciun apel de ștergere și niciun mecanism de audiență de excludere. Aplicarea unei restricționări a prelucrării în temeiul art. 18 GDPR oprește numai transmiterile viitoare. Pentru datele deja transmise, Clientul este îndrumat către procedura proprie a Meta de solicitare a ștergerii datelor; [PLATFORM PROVIDER] nu o poate iniția
TikTok Pte. Ltd.	A primit deja, pentru fiecare înregistrare pentru care Clientul a activat integrarea, hash-uri SHA-256 ale adresei de e-mail, ale prenumelui, ale numelui și ale identificatorului înregistrării — dar niciun număr de telefon — împreună cu adresa IP a clientului, user agent-ul, identificatorul de click ttclid și valoarea cookie-ului _ttp, toate în formă brută	Nu se întreprinde nicio acțiune la ștergere, la fel ca în cazul Meta. O restricționare a prelucrării în temeiul art. 18 GDPR oprește numai transmiterile viitoare; pentru datele deja transmise, Clientul este îndrumat către procedura proprie a TikTok de solicitare a ștergerii datelor
Anthropic PBC (SUA)	Acolo unde Persoana Vizată a transmis un testimonial aprobat de personal, numele său, citatul, denumirea companiei și nota acordată au fost transmise în prompturile de generare și sunt păstrate local în evidențele de generare cu AI	Nu se întreprinde nicio acțiune la ștergere. Evidențele de generare sunt cheiate pe o entitate și pe un utilizator din personal, iar nu pe un contact, astfel încât fluxul nu ajunge la ele, iar conținutul testimonialului supraviețuiește ștergerii. Perioada de retenție practicată de Anthropic pentru intrările și ieșirile API nu este stabilită
Cloudflare, Inc.	Termină conexiunile TLS și asigură funcția de proxy pentru întregul trafic al participanților în producție, inclusiv pentru trimiterile formularelor de înregistrare care poartă adresa de e-mail, numele și numărul de telefon în clar; fiecare adresă IP de client pe care platforma o consemnează sau o transmite mai departe provine dintr-un antet furnizat de Cloudflare	Exclusiv jurnale tranzitorii de proxy și de margine. Nu există date cu caracter personal stocate care să fie șterse și nu se întreprinde nicio acțiune la ștergere
Firebase-ul organizației-Client (FCM)	Asocieri de token-uri FCM pe proiectul Firebase al Clientului	Clientul trebuie să acționeze separat — [PLATFORM PROVIDER] șterge din propriul Postgres evidența device_tokens, dar nu poate revoca token-urile în proiectul Firebase al Clientului

Important: Ștergerea nu se propagă către platformele de publicitate. Identificatorii sub formă de hash, adresele IP brute și valorile brute ale user agent-ului deja transmise către Meta Platforms, Inc. și către TikTok Pte. Ltd. rămân la acestea; platforma nu efectuează niciun apel de ștergere și nu operează nicio audiență de excludere. De asemenea, ea nu efectuează niciun apel către furnizorul de SMS-uri și nici către furnizorul de AI. Singura acțiune ulterioară automată la ștergere este suprimarea la nivelul furnizorului de e-mail, descrisă mai sus, care păstrează adresa de e-mail în loc să o elimine. Clienții sunt informați că propriul lor proiect Firebase, contul lor deschis la furnizorul de SMS-uri și platformele de publicitate necesită acțiuni de ștergere separate și că [PLATFORM PROVIDER] nu le poate efectua în numele Clientului.

GAP-RET-06 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Această secțiune afirma anterior că [PLATFORM PROVIDER] nu poate accesa contul Clientului deschis la furnizorul de e-mail, că însuși Clientul trebuie să șteargă acolo contactul și că setul complet al subîmputerniciților afectați de o cerere de exercitare a drepturilor se rezumă la patru. În realitate, fluxul de ștergere apelează automat furnizorul de e-mail pentru a plasa adresa pe o listă de suprimare permanentă, ceea ce păstrează adresa în clar pe termen nelimitat, în loc să o șteargă, iar cel puțin încă cinci destinatari — furnizorul de SMS, Meta Platforms, Inc., TikTok Pte. Ltd., Anthropic PBC și Cloudflare, Inc. — primesc datele cu caracter personal ale Persoanei Vizate și lipseau din prezentul tabel. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

7. Șabloane de Răspuns

7.1 Confirmarea primirii (transmisă în 3 zile lucrătoare)

Subiect: Cererea dumneavoastră GDPR — Primită

Stimate/Stimată [Name],

Am primit cererea dumneavoastră de [acces / ștergere / rectificare] datată [DATE]. Vom procesa cererea dumneavoastră în 5 zile lucrătoare și vă vom informa cu privire la rezultat.

Număr de referință: [GDPR-REQUEST-ID]

Dacă aveți întrebări, răspundeți la acest e-mail.

Cu stimă, Echipa de Confidențialitate [Organization Name]

7.2 Confirmarea Ștergerii

Subiect: Cererea dumneavoastră de Ștergere a Datelor — Finalizată

Stimate/Stimată [Name],

Cererea dumneavoastră de ștergere a datelor (referință: [GDPR-REQUEST-ID]), formulată pentru adresa de e-mail [email], a fost soluționată. Am șters din sistemele noastre fișa dumneavoastră de contact, înregistrările și participarea dumneavoastră, evidențele dumneavoastră de consimțământ, datele dumneavoastră comportamentale și de interacțiune, evidențele de livrare a e-mailurilor și a notificărilor push, token-urile dumneavoastră de dispozitiv, intrările dumneavoastră de campanie și de funnel, precum și datele dumneavoastră din sesiunile live — inclusiv numele afișat, mesajele din chat, voturile la sondaje, reacțiile și feedbackul.

Anumite evidențe nu sunt șterse și avem obligația de a vă comunica despre care este vorba și din ce motiv:

• Adresa dumneavoastră de e-mail a fost înscrisă pe o listă de suprimare permanentă la furnizorul nostru de livrare a e-mailurilor. O menținem acolo pentru ca niciun alt mesaj să nu vă mai poată fi trimis. În acest scop, ea este păstrată pe termen nelimitat.
• Jurnalul nostru de audit de securitate și evidența prezentei cereri sunt păstrate pe termen nelimitat, ca dovadă a soluționării corecte a cererii dumneavoastră și pentru a menține complete evidențele noastre de securitate (art. 5 alin. (2) GDPR). Acolo unde jurnalul de audit face trimitere la dumneavoastră, o face printr-un hash unidirecțional al adresei dumneavoastră de e-mail.
• Istoricul consimțămintelor pe care le-ați acordat și le-ați retras este păstrat, cu eliminarea legăturii către fișa dumneavoastră de contact, ca dovadă a obținerii valabile a consimțământului (art. 7 alin. (1) GDPR).
• În jurnalele noastre de livrare a mesajelor se păstrează o evidență a mesajelor SMS sau a difuzărilor care v-au fost transmise, identificată printr-un hash unidirecțional al adresei dumneavoastră de e-mail.
• Acolo unde ați transmis un testimonial care a fost aprobat pentru publicare, numele dumneavoastră și textul testimonialului pot rămâne în evidențele stocate de generare a conținutului.
• Acolo unde v-ați conectat la o sesiune live de pe mai multe dispozitive sau v-ați reconectat sub o nouă identitate de sesiune, datele consemnate sub identitatea suplimentară pot rămâne. Rămân, de asemenea, marcaje tehnice interne care conțin numai identificatorul dumneavoastră anonim de sesiune și numărul mesajelor trimise. Vă rugăm să ne comunicați dacă apreciați că vă aflați în această situație, iar noi le vom elimina.
• Statisticile de utilizare anonimizate (de exemplu, totalurile vizualizărilor unui eveniment) nu vă pot fi atribuite și nu fac obiectul ștergerii.

Nu am șters și nu putem șterge datele deja transmise către platformele de publicitate folosite de organizatorul evenimentului dumneavoastră. Vă rugăm să le contactați direct sau să solicitați organizatorului evenimentului să facă acest lucru.

Dacă apreciați că au fost omise date, contactați-ne la [[email protected]].

Cu stimă, Echipa de Confidențialitate [Organization Name]

GAP-RET-03 · CODE — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Această secțiune comunica anterior Persoanei Vizate, prin șablonul său, că toate datele cu caracter personal asociate adresei sale de e-mail au fost șterse din sistemele platformei și că jurnalele de audit de securitate sunt păstrate doi ani. Niciuna dintre cele două afirmații nu era exactă: mai multe categorii de date cu caracter personal supraviețuiesc fluxului de ștergere, astfel cum se arată în Secțiunea 5.2, iar nici jurnalul de audit, nici registrul cererilor nu fac obiectul vreunei reguli de retenție. Șablonul de mai sus prezintă situația astfel cum este implementată; el nu trebuie readus la formularea anterioară. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

7.3 Livrarea Exportului de Acces

Subiect: Exportul dumneavoastră de Date — Gata

Stimate/Stimată [Name],

Exportul dumneavoastră de date (referință: [GDPR-REQUEST-ID]) este atașat, împreună cu un rezumat al scopurilor pentru care vă prelucrăm datele, al destinatarilor acestora, al duratei pentru care le păstrăm, al provenienței lor și al celorlalte drepturi de care beneficiați.

[Atașați exportul JSON]

Dacă doriți un rezumat lizibil de către om, răspundeți la acest e-mail.

Cu stimă, Echipa de Confidențialitate [Organization Name]

---

8. Escaladare

Scenariu	Acțiune
Cererea nu poate fi soluționată în 5 zile lucrătoare	Se informează Persoana Vizată cu privire la întârziere și la termenul prelungit (maximum o lună, în conformitate cu art. 12 alin. (3) GDPR, prelungibil cu încă două luni atunci când cererea este complexă)
Identitatea nu poate fi verificată	Se solicită o confirmare suplimentară; cererea nu se prelucrează până la verificare
Cererea implică un ordin legal de retenție	Se consultă consilierul juridic înainte de procesare
Persoana Vizată amenință cu o plângere la autoritatea de supraveghere	Se escaladează la consilierul juridic; se asigură documentarea răspunsului
Persoana Vizată este un minor (sub 16 ani)	Se consultă consilierul juridic; se stabilește dacă se aplică consimțământul părintesc
Cererea pare frauduloasă	Se documentează și se refuză. Registrul nu are nicio stare de respingere, iar o cerere refuzată nu poate fi consemnată în dreptul acesteia, astfel încât decizia, motivele și probele se consemnează în foaia internă de urmărire a DSAR-urilor, iar intrarea din registru se lasă neprelucrată, în loc să fie marcată drept finalizată

---

9. Ciclul de Revizuire

Prezenta procedură trebuie revizuită:

• Anual
• După orice DSAR care relevă o deficiență în proces
• Atunci când sunt adăugate noi tipuri de date sau noi activități de prelucrare care afectează domeniul de aplicare al DSAR-urilor

Modificări încorporate în prezenta revizuire. Al treilea criteriu de mai sus s-a activat în mod repetat între revizuirea anterioară a prezentei proceduri și cea de față, fără ca vreo revizuire să aibă loc. Următoarele modificări aduse platformei sunt reflectate în Secțiunile 5.1, 5.2 și 6:

• Difuzările către segmente și jurnalul destinatarilor difuzărilor către segmente
• Canalul de intrare pentru webhook-urile de comenzi din comerțul electronic, care introduce date cu caracter personal necolectate de la Persoana Vizată (art. 15 alin. (1) lit. (g) GDPR)
• Moderarea automată a chatului, care păstrează textul original al mesajelor eliminate într-un flux vizibil pentru personal
• Oglindirea pe server prin TikTok Events API, activă începând cu 8 mai 2026
• Vizualizarea de pagină transmisă pe server prin Meta Conversions API de pe paginile de destinație ale funnel-urilor
• Mutarea marcajelor de deduplicare per actor din baza de date live într-un nod la care fluxul de ștergere nu ajunge

Control propus. Pentru a împiedica repetarea acestui tip de abatere, al treilea criteriu se leagă de o condiție concretă: orice tabel PostgreSQL nou care conține date cu caracter personal trebuie adăugat în rutina de export și în rutina de ștergere ori consemnat expres ca excludere în Secțiunile 5.1 și 5.2, înainte de a fi pus în funcțiune.

---

Versiunea Documentului: 1.0 (DRAFT) Întocmit de: [Legal Team / Engineering] Stadiul Revizuirii: ⚠️ NECESITĂ REVIZUIRE JURIDICĂ — Procedura și șabloanele de răspuns trebuie revizuite de un consilier juridic specializat în GDPR înainte de utilizare.

Ultima actualizare: [DATE]