Politica de Retenție a Datelor

[PLATFORM PROVIDER] — Document InternUltima actualizare: [DATE]

Document operațional intern. Este publicat pe site-ul de documentare juridică, alături de politicile destinate clienților. Consolidează într-o singură referință operațională perioadele de retenție definite în DPA, în ROPA și în Anexa II și consemnează, pentru fiecare loc de stocare a datelor cu caracter personal, dacă vreun mecanism aplică efectiv perioada indicată.

---

1. Scop

Prezenta politică documentează perioadele de retenție a datelor pentru toate datele cu caracter personal prelucrate de [PLATFORM PROVIDER] în numele organizațiilor-client, precum și mecanismele utilizate pentru aplicarea acestor perioade. Sprijină conformitatea cu art. 5 alin. (1) lit. (e) din Regulamentul (UE) 2016/679 (GDPR) (principiul limitării stocării).

Acolo unde o perioadă din Secțiunea 2 este indicată drept „Fără ștergere automată", niciun job programat, niciun declanșator de bază de date și nicio regulă de ciclu de viață a stocării nu elimină datele în funcție de vechime. Aceste date persistă până la intervenirea unuia dintre declanșatoarele de ștergere consemnate în același rând; fiecare dintre acestea este o acțiune întreprinsă de o persoană.

---

2. Calendarul de Retenție

Perioadele de retenție se configurează per organizație și nu este preconfigurată nicio politică implicită. Jobul de aplicare a retenției acționează exclusiv asupra politicilor existente, astfel încât o organizație care nu a configurat niciuna nu are date șterse în funcție de vechime. Ecranul de setări pentru retenție transmite în prezent opt tipuri de date, în timp ce API-ul acceptă cinci, iar API-ul validează întreaga transmitere înainte de a scrie orice parte din ea; prin urmare, orice încercare de salvare este respinsă și nicio politică de retenție nu poate fi configurată din produs.

Acolo unde o politică ar putea fi salvată, API-ul acceptă o perioadă cuprinsă între 30 și 3.650 de zile, iar jobul de aplicare respinge, în mod independent, orice politică sub 30 de zile.

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

Versiunile anterioare ale prezentei Politici indicau perioadele din această secțiune drept valori implicite la nivel de platformă, aplicate de un job zilnic. Ștergerea în funcție de vechime depinde integral de o politică de retenție configurată per organizație; nicio astfel de politică nu este preconfigurată, iar ecranul de setări pentru retenție nu poate salva în prezent niciuna, astfel încât nicio organizație nu are date șterse în funcție de vechime. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.1 Date ale Participanților (Postgres + Firestore)

Tip de date	Tabel / Colecție	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Fișa contactului și datele cu caracter personal ale contactului	contacts (Postgres — exclusiv email_hash, fără text în clar) + Firestore orgs/{orgId}/contacts/{emailHash}/pii/private (adresă de e-mail, nume, număr de telefon)	Fără ștergere automată — păstrate pe durata relației de afaceri dintre organizație și [PLATFORM PROVIDER]	Cerere de ștergere din partea participantului sau încetarea contractului organizației (operațiune manuală)	Ștergere explicită a rândului din contacts, propagată prin CASCADE către tabelele legate; ștergerea documentului Firestore
Fișa înregistrării	webinar_registrations (Postgres)	Fără ștergere automată	Cerere de ștergere sau încetarea contractului organizației	CASCADE din contacts
Evenimente comportamentale (chat, sondaje, oferte, participare)	behavioral_events (Postgres)	Configurabilă per organizație; nicio politică nu poate fi salvată în prezent, deci, în practică, nu există ștergere automată	Politica de retenție configurată (odată devenită configurabilă), cerere de ștergere sau încetarea contractului organizației	Ștergere după vechime acolo unde există o politică; CASCADE din contacts
Trimiteri de e-mail / evidențe de livrare	email_sends (Postgres)	Fără ștergere automată — jobul de aplicare acceptă acest tabel, dar API-ul îl respinge ca tip de date configurabil	Cerere de ștergere sau încetarea contractului organizației	Ștergere explicită după (org_id, email_hash) în fluxul de ștergere — nu există nicio cheie străină către contacts, deci propagarea în cascadă nu ajunge la el
Evidențe de livrare push	push_sends (Postgres)	Fără ștergere automată — jobul de aplicare acceptă acest tabel, dar API-ul îl respinge ca tip de date configurabil	Cerere de ștergere sau încetarea contractului organizației	Ștergere explicită după (org_id, email_hash)
Evidențe de consimțământ	consents (Postgres) + subcolecția Firestore de consimțăminte	Fără ștergere automată și fără o perioadă de retenție proprie — evidențele de consimțământ există și dispar odată cu fișa contactului	Cerere de ștergere sau încetarea contractului organizației	CASCADE din contacts; ștergerea subcolecției Firestore
Istoricul evenimentelor de consimțământ	consent_events (Postgres)	Fără ștergere automată, iar rândurile supraviețuiesc ștergerii	Numai ștergerea organizației	Niciuna. La ștergere, contact_id este setat pe NULL, iar rândul este păstrat — organizația, scopul, acțiunea, metoda, versiunea politicii și marcajul temporal — ca evidență, în temeiul art. 7 alin. (1) GDPR, a faptului că un consimțământ a fost acordat sau retras
Evidențe de participare	Coloanele attended_via și attended_at din webinar_registrations (Postgres) — nu există un tabel de participare distinct	Fără ștergere automată	Cerere de ștergere sau încetarea contractului organizației	CASCADE din contacts
Apartenența la segmente	segment_members (Postgres)	Configurabilă per organizație; nicio politică nu poate fi salvată în prezent, deci, în practică, nu există ștergere automată	Politica de retenție configurată (odată devenită configurabilă), cerere de ștergere sau încetarea contractului organizației	Ștergere după vechime acolo unde există o politică; CASCADE din contacts
Scoruri de prospect / date de implicare	lead_scores (Postgres)	Configurabilă per organizație; nicio politică nu poate fi salvată în prezent, deci, în practică, nu există ștergere automată	Politica de retenție configurată (odată devenită configurabilă), cerere de ștergere sau încetarea contractului organizației	Ștergere după vechime acolo unde există o politică; CASCADE din contacts
Link-uri de distribuire generate de participanți	shares (Postgres)	Fără ștergere automată	Cerere de ștergere sau încetarea contractului organizației	CASCADE din contacts

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. În primul rând, 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. În al doilea rând, 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 compania consemnate în dreptul acestuia; rândurile respective nu poartă nicio legătură cu fișa contactului și nu sunt eliminate la ștergere. A se vedea Secțiunea 2.8.

2.2 Date privind Token-urile de Dispozitiv (Postgres)

Tip de date	Tabel	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Token-uri de dispozitiv FCM	device_tokens	Fără ștergere automată. device_tokens este unul dintre cele cinci tipuri de date configurabile, cheiat pe updated_at, iar ecranul de setări propune o valoare implicită de 60 de zile; această valoare implicită nu poate fi salvată în prezent (a se vedea Secțiunea 2)	Politica de retenție configurată (odată devenită configurabilă); un răspuns UNREGISTERED din partea FCM la trimitere; ștergere în temeiul GDPR	Ștergere explicită după (org_id, email_hash) sau după (org_id, fcm_token); ștergere după vechime acolo unde există o politică

Aplicare: Jobul programat enforce-retention rulează zilnic și șterge rânduri numai pentru organizațiile care dețin o politică de retenție activă pentru tipul de date în cauză. Politica privind token-urile de dispozitiv este cheiată pe coloana updated_at, nu pe o coloană last_updated, care nu există. Jobul rulează prin conexiunea privilegiată la baza de date a planificatorului, căreia nu i se aplică Row Level Security.

2.3 Date de Atribuire și Marketing (Postgres)

Tip de date	Tabel	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Metadate de atribuire (parametri UTM, identificatori de click publicitar și platforma de click, URL-ul paginii de destinație, URL-ul de proveniență, țara, orașul, tipul de dispozitiv, sistemul de operare, browserul, fusul orar)	Coloane pe funnel_entries (Postgres) — nu există un tabel attribution_data	Fără ștergere automată — nu este un tip de date configurabil	Cerere de ștergere sau ștergerea funnel-ului din care fac parte	Ștergere explicită după contact_id în fluxul de ștergere; CASCADE din funnels / funnel_steps. Cheia străină către contacts este ON DELETE SET NULL, astfel încât simpla propagare în cascadă ar lăsa rândul pe loc. A se vedea Secțiunea 2.8
Evenimente de conversie pe server (Meta Conversions API, TikTok Events API)	Fără stocare locală. Nu există un tabel conversion_events; conversiile de pe server sunt transmise platformei de publicitate și nu sunt păstrate de platformă	Nu se aplică	Nu se aplică	Nu se aplică. Datele transmise către Meta și către TikTok ies de sub controlul [PLATFORM PROVIDER] în momentul transmiterii; a se vedea Secțiunea 5

2.4 Date ale Sesiunilor Live (Firebase RTDB)

Spațiul de nume al Realtime Database este live/{sessionId}/…. Acesta nu conține niciun segment de organizație și nu există nicio cale de forma /orgs/{orgId}/sessions/{sessionId}/….

Tip de date	Locație	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Prezența participanților și evidențele de participare	RTDB live/{sessionId}/presence, attendance, presenceTimeline, presenceSessions	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat	Ștergerea nodului RTDB live/{sessionId}
Mesajele din chat și mesajele moderate	RTDB live/{sessionId}/stream și live/{sessionId}/removedStream	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat	Ștergerea nodului RTDB live/{sessionId}
Numele afișate ale participanților	RTDB live/{sessionId}/actors	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat; cerere de ștergere (per actor)	Ștergerea nodului RTDB live/{sessionId}; ștergere per actor în fluxul de ștergere
Datele sondajelor	RTDB live/{sessionId}/polls, pollVotes, pollCounts	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat	Ștergerea nodului RTDB live/{sessionId}
Reacții, click-uri pe oferte și răspunsuri de feedback	RTDB live/{sessionId}/reactions, reactionsByActor, offerClicks, feedbackResponses	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat; cerere de ștergere (per actor)	Ștergerea nodului RTDB live/{sessionId}; ștergere per actor în fluxul de ștergere
Memoria cache de identitate (identificatorul anonim de actor asociat hash-ului adresei de e-mail a participantului)	RTDB live/{sessionId}/identityCache	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat; cerere de ștergere (per actor)	Ștergerea nodului RTDB live/{sessionId}; ștergere per actor în fluxul de ștergere
Marcaje de sincronizare per actor și numărul de mesaje per actor	RTDB live/{sessionId}/synced și live/{sessionId}/actorMessageCounts	Fără ștergere automată și fără a fi atinse de rutina de ștergere per actor	Ștergerea manuală a sesiunii sau a webinarului asociat	Ștergerea nodului RTDB live/{sessionId}
Statisticile sesiunii (contoare)	RTDB live/{sessionId}/stats	Fără ștergere automată	Ștergerea manuală a sesiunii sau a webinarului asociat	Ștergerea nodului RTDB live/{sessionId}

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.

Instantaneul cu statistici scris în documentul de sesiune din Firestore la încheierea unei sesiuni cuprinde contoare — numărul maxim de spectatori simultani, numărul de mesaje, numărul de autori, numărul de voturi la sondaje, click-urile pe oferte și click-urile unice pe oferte —, împreună cu o cronologie a prezenței și cu momentul activării ofertei. Niciun conținut al mesajelor din chat nu este arhivat în Firestore și nu există nicio setare de retenție a arhivei per organizație.

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

Versiunile anterioare ale prezentei Politici arătau că datele sesiunilor live sunt eliminate de o funcție programată de curățare, la scurt timp după încheierea sesiunii. O astfel de funcție nu există: 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. Înregistrările sesiunilor live — textul mesajelor din chat, numele afișate ale participanților, prezența, participarea, voturile la sondaje, reacțiile și feedbackul — sunt eliminate numai atunci când un membru al personalului șterge sesiunea sau webinarul asociat. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Notă privind confidențialitatea. Accesul la datele sesiunilor live din Realtime Database este autorizat exclusiv pe baza atributului role din token-ul de autentificare al apelantului. Regulile de securitate nu conțin niciun identificator de organizație și nu fac nicio comparație între organizația apelantului și organizația proprietară a sesiunii, astfel încât un utilizator autentificat al tabloului de bord, cu oricare dintre rolurile admin, moderator, marketer sau staff — din orice organizație de pe platformă — poate citi datele oricărei sesiuni live dacă îi cunoaște identificatorul. Sunt vizate fluxul de chat, fluxul mesajelor moderate, prezența, participarea, cronologia prezenței, numărul de mesaje per actor, click-urile pe oferte, răspunsurile de feedback și memoria cache de identitate care asociază identificatorul anonim de actor al unui participant cu hash-ul adresei sale de e-mail. Separat, fluxul de chat, directorul de actori (care conține numele afișate ale participanților), listele de actori blocați și restricționați, definiția formularului de feedback și tabelul link-urilor urmărite pot fi citite de orice utilizator autentificat, ceea ce include fiecare participant anonim al fiecărei sesiuni. Toate organizațiile folosesc un singur proiect Firebase per mediu, deci un singur set de reguli guvernează întreaga platformă. Retenția pe termen nelimitat și lizibilitatea nerestricționată se cumulează: datele descrise în tabelul de mai sus rămân lizibile în aceste condiții atât timp cât sunt păstrate.

2.5 Date de Configurare și de Organizație (Firestore)

Tip de date	Colecție	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Configurarea organizației	orgs/{orgId}	Fără ștergere automată — păstrată pe durata abonamentului	Încetarea contractului organizației, efectuată manual (a se vedea Secțiunea 3.1)	Ștergerea documentului și a subcolecțiilor Firestore, executată manual
Configurarea webinarelor și a sesiunilor	orgs/{orgId}/webinars/{webinarId} și orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}	Fără ștergere automată	Ștergerea manuală a webinarului sau a sesiunii; încetarea contractului organizației	Ștergerea subcolecției Firestore
Documentele de contact ale participanților (date cu caracter personal)	orgs/{orgId}/contacts/{emailHash} și subcolecțiile sale pii/private și consents	Fără ștergere automată	Cerere de ștergere sau încetarea contractului organizației	Ștergerea documentului Firestore
Documentele de înregistrare	orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}/registrations/{registrationId}	Fără ștergere automată	Cerere de ștergere; ștergerea manuală a webinarului sau a sesiunii din care fac parte	Ștergerea documentului Firestore, pentru fiecare înregistrare, în fluxul de ștergere

Nicio colecție Firestore nu are configurată o politică de expirare automată (time-to-live). Documentele de înregistrare și documentele cu datele cu caracter personal ale contactelor sunt eliminate numai printr-o cerere de ștergere sau prin ștergerea manuală a webinarului ori a sesiunii din care fac parte.

2.6 Date de Autentificare

Tip de date	Locație	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
UID Firebase Anonymous Auth (participanți web)	Firebase Auth (la nivel de proiect)	Fără expirare automată. Păstrat până când un membru al personalului rulează endpoint-ul manual de golire, al cărui prag implicit vizează conturile create în urmă cu mai mult de 7 zile	Golire manuală, inițiată de personal; ștergere în temeiul GDPR	Ștergere în masă a conturilor Auth care nu au niciun furnizor de identitate; ștergere per actor în fluxul de ștergere
UID Firebase Auth (utilizatorii aplicației mobile)	Firebase Auth + câmp în documentul de contact din Firestore	Fără ștergere automată — păstrat pe durata relației de afaceri	Cerere de ștergere sau încetarea contractului organizației	Ștergere Firebase Auth + ștergerea câmpului din Firestore
JWT Firebase Auth (aplicație mobilă, pe dispozitiv)	iOS Keychain / Android EncryptedSharedPreferences	1 oră (reînnoit automat în timpul utilizării active)	Dezinstalarea aplicației, deconectarea sau expirarea token-ului	Curățarea stocării securizate a sistemului de operare / revocarea token-ului Firebase Auth
Coduri de verificare de unică folosință trimise prin e-mail (conțin adresa de e-mail în clar, alături de cod)	Firestore verification_codes/{emailHash}	10 minute	Utilizarea cu succes, expirarea sau 3 încercări eșuate	Ștergerea documentului Firestore la utilizare, la verificarea expirării sau la a treia încercare eșuată
Evidențe de link-uri magice (conțin adresa de e-mail în clar)	Firestore magic_links/{oobCode}	Șterse la prima utilizare; în rest, fără ștergere automată	Utilizarea link-ului; în rest, golirea manuală inițiată de personal, descrisă mai sus	Ștergerea documentului Firestore

UID-ul anonim de Auth nu se limitează la Firebase Auth: același identificator este cheia de actor la live/{sessionId}/actors/{actorId}, este stocat în coloana actor_id din webinar_registrations și este asociat hash-ului adresei de e-mail a contactului la live/{sessionId}/identityCache/{actorId}. Pentru fiecare înregistrare se stochează un singur identificator de actor, astfel încât, atunci când un participant se alătură de pe mai multe dispozitive sau revine sub o nouă identitate anonimă, identificatorii neconsemnați în dreptul înregistrării nu sunt atinși de rutina de ștergere per actor.

2.7 Jurnale de Audit

Tip de date	Locație	Perioadă de retenție	Note
Jurnale de audit ale operațiunilor de scriere din API	Tabelul PostgreSQL audit_log	Fără ștergere automată	Păstrate pe termen nelimitat, în scopul responsabilității prevăzute la art. 5 alin. (2) GDPR; nu fac obiectul cererilor de ștergere (temei juridic: interesul legitim în menținerea unei piste de audit de securitate). Intrările 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
Jurnalele cererilor GDPR	Tabelul PostgreSQL gdpr_requests	Fără ștergere automată	Păstrate pe termen nelimitat, ca evidență a acțiunilor de ștergere și de acces. Conțin hash-ul adresei de e-mail a persoanei vizate care formulează cererea
Jurnalele aplicației și ale evenimentelor de securitate	Jurnale de aplicație structurate, emise la ieșirea standard și preluate de furnizorul de găzduire	⚠️ Nestabilită. Nu există un loc de stocare distinct pentru jurnalele de incidente; perioada de retenție a jurnalelor la furnizorul de găzduire nu este documentată în evidențele [PLATFORM PROVIDER] și trebuie confirmată cu furnizorul	A se vedea declarația privind monitorizarea, de mai jos

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.

Monitorizare și alertare. Platforma emite jurnale de aplicație structurate la ieșirea standard, pe care furnizorul de găzduire le păstrează și le face căutabile, și expune un endpoint de stare a sistemului, accesibil numai administratorilor, care raportează contoare de cereri și contoare de citiri din baza de date. Aceste contoare sunt ținute în memoria procesului și se resetează la fiecare repornire sau implementare. Nu există niciun serviciu de urmărire a erorilor, nicio integrare de apelare a echipei de gardă și nicio alertare automată: detectarea incidentelor depinde de o persoană care observă jurnalele, endpoint-ul de stare sau o sesizare din partea unui client.

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

Versiunile anterioare ale prezentei Politici indicau o perioadă de retenție de doi ani pentru jurnalul de audit, de trei ani pentru registrul cererilor persoanelor vizate și de un an pentru jurnalele incidentelor de securitate păstrate într-un serviciu intern de jurnalizare. Niciunul dintre aceste trei tabele sau locuri de stocare nu este recunoscut de jobul de retenție, un asemenea serviciu de jurnalizare nu există și nu este implementată nicio alertare automată; jurnalul de audit și registrul cererilor sunt păstrate pe termen nelimitat și nu pot fi golite prin rolul de bază de date al aplicației. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.8 Funnel-uri, Automatizări, Generare cu AI, SMS și Difuzări (Postgres)

Tip de date	Tabel	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Intrări în funnel (atribuire, dispozitiv, localizare aproximativă, payload-uri de webhook, metadate de achiziție)	funnel_entries	Fără ștergere automată — nu este un tip de date configurabil	Cerere de ștergere (după contact) sau ștergerea funnel-ului din care fac parte	Ștergere explicită după contact_id în fluxul de ștergere; CASCADE din funnels / funnel_steps
Vizualizări de pagină ale funnel-urilor (hash persistent, pseudonim, al adresei IP și al user agent-ului)	funnel_page_views	Fără ștergere automată — nu este un tip de date configurabil	Numai ștergerea funnel-ului sau a pasului din care fac parte	CASCADE din funnels / funnel_steps. Nu este atins de fluxul de ștergere — nicio legătură cu o fișă de contact
Înscrieri în automatizări (contact, stare, eveniment declanșator)	automation_enrollments	Fără ștergere automată — nu este un tip de date configurabil	Cerere de ștergere sau ștergerea automatizării	CASCADE din contacts; CASCADE din automations
Execuții ale pașilor de automatizare (adresă de e-mail / număr de telefon în clar în documentul cu rezultatul)	automation_step_executions	Fără ștergere automată — nu este un tip de date configurabil	Cerere de ștergere sau ștergerea automatizării	Numai CASCADE din automation_enrollments
Joburi de generare cu AI (prompt de sistem, prompt de utilizator, rezultatul modelului — pot conține numele și citatul din testimonialul unui participant)	ai_jobs	Fără ștergere automată — nu este un tip de date configurabil	Numai ștergerea organizației	Nicio cale de ștergere. Nu este atins de fluxul de ștergere — rândurile sunt cheiate pe o entitate și pe un utilizator din personal, nu pe o fișă de contact
Evidențe de livrare SMS	sms_sends	Fără ștergere automată — jobul de aplicare acceptă acest tabel, dar API-ul îl respinge ca tip de date configurabil, deci nicio politică nu poate fi salvată	Ar fi o politică de retenție configurată, odată devenită configurabilă	Ștergere după vechime (în prezent inaccesibilă). Nu este atins de fluxul de ștergere — cheiat pe email_hash, fără cheie străină către contacts; absent din exportul în temeiul art. 15
Jurnalul destinatarilor difuzărilor către segmente	segment_broadcast_sends	Fără ștergere automată — nu este un tip de date configurabil	Numai ștergerea organizației	Nicio cale de ștergere. Nu este atins de fluxul de ștergere — cheiat pe email_hash, fără cheie străină către contacts; absent din exportul în temeiul art. 15
Conținutul difuzărilor către segmente (subiect, titlu, corp, îndemn la acțiune, autor)	segment_broadcasts	Fără ștergere automată — nu este un tip de date configurabil	Numai ștergerea organizației	Nicio cale de ștergere
Jurnalul de activitate al webhook-urilor de intrare (metadate per apel care, pentru sursele de comerț electronic și de formular, pot conține date de payload la nivel de destinatar)	webhook_events	Fără ștergere automată — nu este un tip de date configurabil	Numai ștergerea organizației	Nicio cale de ștergere. Nu este atins de fluxul de ștergere — rândurile nu au nicio legătură cu o fișă de contact

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

Versiunile anterioare ale prezentei Politici arătau că aceasta consolidează fiecare perioadă de retenție din întregul corpus, însă subsistemele de funnel-uri, de automatizări, de generare cu AI, de SMS și de difuzări către segmente lipseau din ea. Niciunul dintre tabelele de mai sus nu este un tip de date configurabil, prin urmare niciunul nu face obiectul vreunei perioade de retenție automate, iar jurnalul de livrare a SMS-urilor, jurnalul destinatarilor difuzărilor către segmente, tabelul vizualizărilor de pagină ale funnel-urilor, tabelul joburilor de generare cu AI și jurnalul de activitate al webhook-urilor nu sunt atinse deloc de fluxul de ștergere în temeiul art. 17 GDPR. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.9 Stocarea de Obiecte (Firebase Cloud Storage)

Tip de date	Locație	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Fișiere aferente webinarelor, paginilor, ofertelor și șabloanelor de pagină; biblioteca media a organizației; elementele de brand; fișierele personalului — imagini de marketing care pot înfățișa persoane identificabile	Prefixele Cloud Storage orgs/{orgId}/webinars/, pages/, offers/, media/, page_templates/, branding/ și staff/	Fără ștergere automată — nu este configurată nicio regulă de ciclu de viață a stocării, iar stocarea de obiecte nu este un tip de date configurabil	Ștergerea manuală a entității-părinte — webinar, pagină, ofertă, șablon, element media sau fișier încărcat	Ștergerea obiectului individual sau a prefixului de stocare al entității, efectuată de rutina care șterge entitatea-părinte

Stocarea de obiecte nu este atinsă de fluxul de ștergere în temeiul art. 17 GDPR: rutina de ștergere nu efectuează nicio operațiune în Cloud Storage, astfel încât un obiect care înfățișează sau numește o persoană vizată este eliminat numai atunci când un membru al personalului șterge entitatea căreia îi aparține.

Regulile de securitate Cloud Storage acordă acces public necondiționat de citire tuturor celor șapte căi delimitate pe organizație — webinars/, pages/, offers/, media/, page_templates/, branding/ și staff/ — astfel încât orice obiect stocat sub prefixul unei organizații poate fi citit, fără autentificare, de oricine îi cunoaște sau îi poate ghici calea. Accesul de scriere pe aceleași căi impune doar ca apelantul să fie autentificat; identificatorul de organizație din cale nu este niciodată comparat cu cel din token-ul apelantului, astfel încât un utilizator autentificat al unei organizații poate suprascrie elementele de brand, fișierele media, șabloanele de pagină și fișierele paginilor de destinație ale altei organizații. O regulă finală, cu caracter general (catch-all), acordă drept de citire și de scriere asupra tuturor celorlalte obiecte din bucket oricărui utilizator autentificat, ceea ce include fiecare participant anonim.

GAP-ISO-03 · CONFIG — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezentul document arăta anterior că prezintă consolidat fiecare perioadă de retenție din întregul corpus, însă stocarea de obiecte lipsea din el, iar în restul corpusului era descrisă exclusiv ca loc de stocare a codului HTML al paginilor de destinație. Aceasta găzduiește însă și biblioteca media a organizației, elementele de brand, șabloanele de pagină și fișierele personalului, nicio regulă de ciclu de viață nu șterge vreunul dintre aceste elemente, iar fluxul de ștergere în temeiul art. 17 GDPR nu efectuează nicio operațiune de stocare, astfel încât imaginile stocate supraviețuiesc unei ștergeri. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.10 Copii Tranzitorii ale Datelor de Contact (memoria procesului API)

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.

În consecință, o rectificare în temeiul art. 16 GDPR și o ștergere în temeiul art. 17 GDPR nu produc efecte la nivelul întregului strat de API până la repornirea sau reimplementarea fiecărui proces. Dimensiunea memoriei cache este raportată de endpoint-ul de stare a sistemului, accesibil numai administratorilor.

2.11 Copii de Rezervă

Copiile de rezervă sunt operate de furnizorii de găzduire, nu de aplicație, iar în baza de cod [PLATFORM PROVIDER] nu este definită nicio configurare de copii de rezervă.

Tip de date	Locație	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Copii de rezervă PostgreSQL	Furnizorul de găzduire (Railway Corp.)	Atât Anexa II, cât și ROPA indică 30 de zile. ⚠️ Configurarea efectivă a furnizorului nu este documentată în evidențele [PLATFORM PROVIDER] și trebuie confirmată	Ieșirea din rotația copiilor de rezervă, prin vechime	Niciuna disponibilă aplicației — copiile de rezervă sunt imuabile și nu pot fi modificate pentru a elimina o evidență individuală
Copii de rezervă Firestore	Google LLC	ROPA indică 7 zile. ⚠️ Programarea și retenția configurate nu sunt documentate în evidențele [PLATFORM PROVIDER] și trebuie confirmate	Ieșirea din rotația copiilor de rezervă, prin vechime	Niciuna disponibilă aplicației
Realtime Database	Google LLC	Anexa II consemnează că datele sesiunilor live nu fac obiectul copiilor de rezervă	Nu se aplică	Nu se aplică

Datele cu caracter personal șterse în temeiul art. 17 GDPR rămân prezente în orice copie de rezervă realizată anterior ștergerii, până la ieșirea acelei copii din rotație. Valoarea de 30 de zile de mai sus și cea de 90 de zile de la Secțiunea 10.1 din DPA sunt măsuri diferite și nu se contrazic: 30 de zile reprezintă perioada de rotație după care o anumită copie de rezervă nu mai există, iar 90 de zile reprezintă termenul-limită până la care [PLATFORM PROVIDER] se angajează că datele șterse la încetarea contractului au ieșit din toate copiile de rezervă.

2.12 Date Exportate în Afara Platformei

Personalul poate exporta din tabloul de bord membrii unui segment salvat. Exportul preia din Firestore adresa de e-mail în clar și numele fiecărui membru, apoi le returnează pentru descărcare; formatul său este destinat importului manual la furnizorul de e-mail.

Tip de date	Locație	Perioadă de retenție	Declanșator ștergere	Metodă de ștergere
Exporturi de contacte dintr-un segment (adresa de e-mail în clar și numele fiecărui membru al segmentului)	Fișiere deținute de Client în afara platformei	Nu se află sub controlul [PLATFORM PROVIDER]. Niciun job de retenție și niciun flux de ștergere nu pot ajunge la un fișier exportat	Stabilită de Client în calitate de Operator	Ștergere de către Client

Exportul nu impune un consimțământ email_marketing, iar atunci când membrul personalului care îl solicită activează opțiunea de includere a contactelor marcate, sunt returnate și contactele suprimate pentru bounce, pentru reclamație de spam sau pentru dezabonare globală. Contactele dezabonate apar în exportul implicit, întrucât dezabonarea retrage consimțământul de marketing fără a seta indicatorul de suprimare. Sunt excluse în toate cazurile numai contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR. Fiecare export este consemnat în jurnalul de audit sub denumirea exported_segment_contacts, ceea ce constituie controlul compensator; Clientul, în calitate de Operator, rămâne răspunzător pentru retenția, securitatea și ștergerea fișierului exportat.

---

3. Mecanisme de Aplicare

3.1 Joburi Programate Automate

Job	Program	Acțiune
enforce-retention	Zilnic (ora 02:00 în mod implicit; ora de rulare este configurabilă la nivel de sistem)	Citește fiecare rând din retention_policies și, pentru fiecare, șterge rândurile mai vechi decât perioada configurată din unul dintre tabelele behavioral_events, segment_members, device_tokens, lead_scores, email_sends, push_sends, sms_sends sau scheduler_job_runs. Acționează exclusiv asupra politicilor existente, iar în prezent nu poate fi creată nicio politică (a se vedea Secțiunea 2). Rulează prin conexiunea privilegiată la baza de date a planificatorului, căreia nu i se aplică Row Level Security

Atunci când o politică activă ar șterge, într-o singură rulare, mai mult de zece mii de rânduri, jobul consemnează o avertizare și nu șterge nimic, astfel încât un tabel al cărui volum restant a depășit acel prag nu este readus în perioada sa de retenție prin rulările ulterioare. O politică configurată sub minimul de 30 de zile este omisă, cu o avertizare, și nu este contabilizată drept eșec.

Niciun alt job programat nu șterge date cu caracter personal. În special:

• Nu există nicio Cloud Function și niciun job programat care să elimine datele sesiunilor live din Realtime Database. Datele sesiunii sunt șterse numai prin ștergerea manuală a unei sesiuni sau a webinarului asociat (a se vedea Secțiunea 2.4).
• Nu există niciun job de curățare la încetarea contractului organizației. Niciun câmp de stare a organizației nu declanșează ștergerea și nu există niciun cronometru de perioadă de grație. Ștergerea la încetarea contractului — obligația de la Secțiunea 10.1 din DPA — este efectuată manual de echipa de inginerie.
• Golirea conturilor anonime Firebase Auth și a documentelor de link-uri magice rămase neutilizate se realizează printr-un endpoint manual, rezervat administratorilor, nu printr-un job programat (a se vedea Secțiunea 2.6).

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

Versiunile anterioare ale prezentei Politici enumerau încă două joburi programate, cleanup-rtdb-sessions și org-termination-cleanup. Niciunul dintre ele nu există: platforma înregistrează opt joburi programate, dintre care numai enforce-retention șterge date cu caracter personal, iar baza de cod Cloud Functions nu conține nicio funcție de curățare. Ștergerea datelor sesiunilor live și ștergerea la încetarea contractului unei organizații sunt, prin urmare, operațiuni manuale, în spatele cărora nu se află niciun cronometru automat, inclusiv în ceea ce privește angajamentul de 30 de zile de la Secțiunea 10.1 din DPA. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.2 Ștergere Declanșată de Evenimente

Eveniment	Acțiune
FCM returnează UNREGISTERED la trimiterea unei notificări push	Ștergerea imediată a rândului corespunzător din device_tokens
Un membru al personalului procesează din tabloul de bord o cerere de ștergere în temeiul GDPR	Executarea fluxului de ștergere descris în Secțiunea 3.3
Un participant a cărui fișă de contact este deja marcată pentru un hard bounce ori pentru o adresă respinsă folosește calea de ștergere în autoservire	Crearea unei cereri de ștergere GDPR în starea pending. Nimic nu o procesează automat; un membru al personalului trebuie să o soluționeze. Calea returnează 403 pentru orice contact ce nu poartă acest marcaj
Clientul reziliază abonamentul	Ștergere manuală de către echipa de inginerie, în termenul prevăzut la Secțiunea 10.1 din DPA. Nu există niciun cronometru de perioadă de grație și niciun job automat de curățare

Retragerea unui consimțământ nu declanșează o ștergere. Consimțămintele data_processing și tos_acceptance nu pot fi retrase în niciun fel: sunt acordate la înregistrare, endpoint-ul de preferințe le elimină din orice transmitere, iar o retragere ajunsă pe calea de sincronizare a consimțămintelor este consemnată drept omisă. Nicio cale de cod nu creează o cerere GDPR la retragerea vreunui consimțământ.

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

Versiunile anterioare ale prezentei Politici arătau că retragerea de către participant a consimțământului data_processing declanșează fluxul de ștergere GDPR. Acel consimțământ nu poate fi retras prin nicio interfață, iar nicio retragere de consimțământ nu creează o cerere de ștergere. Ștergerea este inițiată de un membru al personalului sau prin calea îngustă de autoservire, disponibilă exclusiv contactelor deja marcate pentru un hard bounce ori pentru o adresă respinsă, care creează o cerere ce trebuie apoi soluționată de un membru al personalului. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.3 Ștergere Manuală (DSAR)

Cererile de ștergere în temeiul GDPR, procesate prin tabloul de bord sau prin procedura DSAR (dsar-procedure.md), execută, în ordine:

1. PostgreSQL: ștergeri explicite din email_sends, push_sends și device_tokens, identificate după (org_id, email_hash); anularea referințelor de distribuire de pe funnel_entries; o ștergere explicită din funnel_entries, identificată după contact_id; apoi ștergerea rândului din contacts, propagată prin CASCADE către behavioral_events, segment_members, consents, webinar_registrations, lead_scores, shares și automation_enrollments (iar, prin intermediul înscrierii, către automation_step_executions).
2. Firestore: ștergerea fiecărui document de înregistrare, a subcolecției de consimțăminte a contactului, a documentului cu datele cu caracter personal ale contactului și a documentului de contact în sine.
3. Firebase Auth: ștergerea contului anonim consemnat în dreptul fiecărei înregistrări și a contului neanonim referit în documentul de contact.
4. Realtime Database: ștergere per actor, pentru fiecare înregistrare care poartă un identificator de actor, a participării, a prezenței, a numelui afișat al actorului, a limitelor de cereri, a voturilor la sondaje, a reacțiilor, a click-urilor pe oferte, a răspunsurilor de feedback, a sesiunilor de prezență, a intrărilor din memoria cache de identitate și din cea de consimțământ, a intrărilor privind actorii blocați și restricționați, a mesajelor din chat și din chatul moderat, precum și a mesajelor sesizate.
5. Furnizorul de e-mail: adresa de e-mail în clar a contactului, citită din Firestore înainte de ștergere, este transmisă furnizorului de e-mail ca suprimare permanentă (a se vedea Secțiunea 5).
6. Confirmarea este consemnată în tabelul gdpr_requests.

Ce nu atinge fluxul de ștergere. 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, iar niciunul dintre cele două tabele nu este inclus în exportul de date în temeiul art. 15.

Următoarele conțin, de asemenea, date cu caracter personal ale persoanei vizate și supraviețuiesc unei ștergeri:

• consent_events — istoricul consimțămintelor prevăzut la art. 7 alin. (1) GDPR. contact_id este setat pe NULL; organizația, scopul, acțiunea, metoda, versiunea politicii și marcajul temporal sunt păstrate.
• audit_log și gdpr_requests — păstrate pe termen nelimitat, în scopul responsabilității; metadatele de audit scrise de fluxul drepturilor persoanelor vizate includ hash-ul adresei de e-mail a persoanei vizate.
• ai_jobs, funnel_page_views și webhook_events — nu au nicio legătură cu o fișă de contact, astfel încât nu sunt atinse nici de ștergerile explicite, nici de propagarea în cascadă.
• Nodurile Realtime Database live/{sessionId}/synced/… și live/{sessionId}/actorMessageCounts/{actorId} — nu sunt acoperite de rutina de ștergere per actor.
• Orice date ale sesiunilor live scrise sub un identificator de actor diferit de cel consemnat în dreptul înregistrării — un al doilea dispozitiv sau o revenire sub o nouă identitate anonimă —, inclusiv mesajele din chat și numele afișate.
• Obiectele din Cloud Storage (Secțiunea 2.9), pe care fluxul de ștergere nu le atinge niciodată.
• Memoria cache din proces cu datele de contact, pe orice altă instanță a API-ului decât cea care a executat ștergerea, până la repornirea acelui proces (Secțiunea 2.10).
• Adresa de e-mail în clar a contactului, la furnizorul de e-mail, păstrată prin proiectare pe o listă de suprimare permanentă (Secțiunea 5).

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

Versiunile anterioare ale prezentei Politici descriau fluxul de ștergere drept o operațiune care elimină toate datele cu caracter personal ale persoanei vizate din toate tabelele și din toate colecțiile. Fluxul ajunge la locurile de stocare enumerate mai sus, însă jurnalul de livrare a SMS-urilor, jurnalul destinatarilor difuzărilor către segmente, tabelul joburilor de generare cu AI, tabelul vizualizărilor de pagină ale funnel-urilor, jurnalul de activitate al webhook-urilor, obiectele din Cloud Storage și două noduri Realtime Database per actor îi supraviețuiesc, iar datele sesiunilor live scrise sub un al doilea identificator de actor nu sunt atinse deloc. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

4. Ștergerea Datelor Persoanei Vizate vs. Încetarea Contractului Organizației

Scenariu	Ce se șterge	Ce se păstrează
Cerere de ștergere din partea participantului	Locurile de stocare enumerate în Secțiunea 3.3, pașii 1–4	Locurile de stocare enumerate în Secțiunea 3.3, la rubrica „Ce nu atinge fluxul de ștergere", împreună cu statisticile agregate ale sesiunii, care nu sunt legate de o persoană
Încetarea abonamentului organizației	Toate datele organizației (contacte, webinare, înregistrări, evenimente comportamentale, token-uri de dispozitiv, evidențe push), șterse manual de echipa de inginerie — nu există niciun job automat de curățare și niciun cronometru de perioadă de grație	Jurnalele de audit și registrul cererilor persoanelor vizate, pe care niciun mecanism nu le golește
Închiderea platformei [PLATFORM PROVIDER]	Toate datele Clientului, în conformitate cu Secțiunea 10 din DPA (Ștergerea și Returnarea Datelor cu Caracter Personal): ștergerea din sistemele de producție în termen de 30 de zile și din copiile de rezervă în termen de 90 de zile, pe măsura ieșirii acestora din rotație; ori returnarea în format care poate fi citit automat, la alegerea Clientului	Niciunele — ștergere completă sau returnare către Client, sub rezerva excepției de retenție legală de la Secțiunea 10.2 din DPA

---

5. Retenția la nivelul subîmputerniciților

[PLATFORM PROVIDER] angajează unsprezece subîmputerniciți, enumerați în Anexa III. Ștergerea se propagă către aceștia după cum urmează.

Subîmputernicit	Date acoperite	Mecanismul de ștergere
Google LLC (Firestore, RTDB, Firebase Auth, Cloud Storage)	UID-uri Auth, documente Firestore, noduri RTDB, obiecte stocate	Apeluri de ștergere prin Firebase Admin SDK în fluxul de ștergere, pentru Auth, Firestore și RTDB. Obiectele din Cloud Storage nu sunt șterse de flux (Secțiunea 2.9)
Railway Corp. (PostgreSQL, găzduirea aplicației)	Toate tabelele Postgres	Operațiuni directe în baza de date, în cadrul fluxului de ștergere, sub rezerva excluderilor de la Secțiunea 3.3. Copiile de rezervă ies din rotație prin vechime (Secțiunea 2.11)
NewsmanApp SRL (e-mail tranzacțional și de marketing)	Evidențe de abonați sincronizate din platformă, jurnale de livrare, precum și evenimente de vizualizare, de click, de bounce, de reclamație și de dezabonare	Automat, la ștergere — însă sub forma unei suprimări, nu a unei ștergeri; a se vedea nota de mai jos
Meta Platforms, Inc. (Meta Pixel, Conversions API)	Identificatori sub formă de hash, adresa IP, user agent-ul și URL-ul paginii, transmise la înregistrare și la vizitarea paginilor de destinație	Niciunul. Transmiterea este unidirecțională și fără confirmare de primire; platforma nu deține niciun loc de stocare locală a evenimentelor și nu dispune de niciun apel de ștergere sau de suprimare către Meta
Google LLC (Google Analytics, Google Ads)	Identificatori de analiză și de publicitate, pe partea de client	Niciunul. Nu este implementat niciun mecanism de ștergere pe server; ștergerea rămâne o chestiune între Client și Google
TikTok Pte. Ltd. (TikTok Pixel, Events API)	Identificatori sub formă de hash, la care se adaugă adresa IP brută, user agent-ul brut și identificatorii de click, transmiși la fiecare înregistrare	Niciunul. Transmiterea este unidirecțională și fără confirmare de primire; nu este implementat niciun apel de ștergere sau de suprimare
LinkedIn Corporation	Nu se aplică — integrarea este prevăzută în modelul de date, dar nu este activă	Nu se aplică
Cloudflare, Inc. (proxy invers, CDN, Turnstile)	Metadate aferente fiecărei cereri a participanților, inclusiv transmiterilor formularelor de înregistrare, precum și adresele IP transmise pentru verificarea Turnstile	Niciunul disponibil aplicației. Retenția la nivelul furnizorului este guvernată de setările contului Cloudflare al Clientului sau al [PLATFORM PROVIDER]
Microsoft Corporation (Microsoft Clarity), contractat pentru clienții din UE prin Microsoft Ireland Operations Limited (MIOL)	Date de reluare a sesiunii și de analiză pentru vizitatorii care acceptă cookie-urile de analiză	Niciunul implementat în platformă. La retragerea consimțământului, scriptul de consimțământ aplică excluderea (opt-out) pentru vizitator; ștergerea rămâne o chestiune între Client și Microsoft
SendSMS.ro (SMS tranzacțional)	Numărul de telefon al destinatarului, în clar, și corpul integral al mesajului, transmise ca parametri în șirul de interogare și, prin urmare, de presupus prezente în jurnalele de cereri ale furnizorului	Niciunul implementat. La ștergere nu se efectuează niciun apel de suprimare sau de ștergere, iar jurnalul local sms_sends nu este el însuși șters (Secțiunea 2.8)
Anthropic PBC (Claude API)	Prompturile și rezultatele generării, care pot îngloba un testimonial aprobat al unui participant — numele afișat al autorului, citatul, compania și nota acordată — precum și imagini de referință încărcate de personal	Niciunul implementat. Evidența locală din ai_jobs nu este atinsă de fluxul de ștergere (Secțiunea 2.8), iar către furnizor nu se efectuează niciun apel de ștergere

Notă privind furnizorul de e-mail. Ș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. Apelul este efectuat automat de platformă, ca ultim pas al fluxului de ștergere; nu necesită nicio acțiune din partea Clientului.

Notă privind integrările furnizate de Client. Atunci când o integrare rulează pe contul propriu al Clientului — furnizorul de e-mail, proiectul Firebase Cloud Messaging al Clientului și furnizorul de SMS —, Clientul este cel care deține contractul cu furnizorul respectiv și rămâne răspunzător pentru orice ștergere pe care platforma nu o efectuează în numele său.

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

Versiunile anterioare ale prezentei Politici arătau că [PLATFORM PROVIDER] nu poate apela furnizorul de e-mail în numele Clientului și că ștergerea unui contact la nivelul acestuia trebuie declanșată de Client. În realitate, platforma apelează furnizorul automat, la fiecare ștergere, iar apelul înscrie adresa de e-mail în clar a persoanei vizate pe o listă de suprimare permanentă, în loc să o elimine, astfel încât adresa rămâne la furnizor pe termen nelimitat. Secțiunea enumera totodată trei subîmputerniciți, în condițiile în care sunt angajați unsprezece, și indica pentru doi dintre ei o entitate juridică greșită. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

---

6. Retenții Legale

Dacă [PLATFORM PROVIDER] primește un ordin valabil de retenție legală (de exemplu, un ordin judecătoresc sau o anchetă a unei autorități de reglementare), datele supuse ordinului sunt păstrate exclusiv prin măsuri organizatorice: echipa de inginerie dezactivează manual politica de retenție vizată, iar cererea este respinsă în etapa de triere a cererilor persoanelor vizate. Retențiile legale sunt analizate de consilierul juridic. Datele sunt eliberate din retenție imediat ce temeiul juridic expiră.

În modelul de date nu există niciun indicator de retenție legală. Nici jobul de aplicare a retenției, nici fluxul de ștergere nu evaluează vreo condiție de retenție legală, astfel încât niciunul dintre ele nu s-ar opri din proprie inițiativă dacă o retenție legală ar fi în vigoare.

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

Versiunile anterioare ale prezentei Politici arătau că datele aflate sub o retenție legală sunt excluse din calendarul automat de retenție și că retențiile legale sunt urmărite într-un registru intern. Niciun tabel nu poartă un indicator de retenție legală, jobul de retenție șterge exclusiv pe baza organizației și a marcajului temporal, iar fluxul de ștergere nu efectuează nicio verificare a unei retenții legale, astfel încât excluderea este o practică manuală, nu un control tehnic. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

7. Ciclul de Revizuire

Prezenta Politică trebuie revizuită:

• Anual
• Când sunt adăugate noi tipuri de date sau activități de prelucrare
• Când perioadele de retenție sunt modificate (necesită amendament DPA și notificarea clientului)
• După ce un DSAR scoate la iveală o deficiență de retenție

Toate cele patru situații au survenit de la ultima revizuire de fond a prezentei Politici. Activitățile de prelucrare introduse între timp — subsistemul de funnel-uri și urmărirea vizualizărilor de pagină aferente, motorul de automatizări, generarea de conținut asistată de AI, notificările prin SMS, difuzările către segmente, webhook-urile de intrare pentru comenzile de comerț electronic, marcajele per actor din Realtime Database și memoria cache din proces cu datele de contact — sunt consemnate în prezent în Secțiunea 2.4 și în Secțiunile 2.8–2.10. Prezenta Politică nu poartă nicio dată de revizuire consemnată, în raport cu care să poată fi măsurat ciclul anual; consemnarea unei asemenea date constituie o condiție prealabilă a următoarei revizuiri.

---

Versiunea Documentului: 1.0 (DRAFT) Întocmit de: [Legal Team / Engineering] Stadiul Revizuirii: ⚠️ NECESITĂ REVIZUIRE JURIDICĂ — Perioadele de retenție trebuie validate în raport cu legislația aplicabilă și acordurile cu clienții înainte de aplicare.

Ultima actualizare: [DATE] Următoarea revizuire: [DATE + 1 year]