Evaluarea Impactului asupra Protecției Datelor (DPIA)

[PLATFORM PROVIDER] — Activitățile de prelucrare ale platformei de evenimentArticolul 35 GDPRUltima actualizare: [DATE]

1. Introducere și Domeniu de Aplicare

1.1 Scop

Prezenta Evaluare a Impactului asupra Protecției Datelor (DPIA) evaluează riscurile de confidențialitate asociate activităților de prelucrare ale platformei de eveniment [PLATFORM PROVIDER] și documentează măsurile luate pentru atenuarea acestor riscuri, astfel cum impune art. 35 din Regulamentul (UE) 2016/679 (GDPR).

1.2 De Ce Este Necesară o DPIA

Art. 35 alin. (1) GDPR impune realizarea unei DPIA atunci când prelucrarea este „susceptibilă să genereze un risc ridicat pentru drepturile și libertățile persoanelor fizice". O DPIA este necesară în mod specific (potrivit art. 35 alin. (3) GDPR și Orientărilor EDPB 09/2022) pentru:

Monitorizarea sistematică — urmărirea comportamentală a participanților (chat, sondaje, oferte, tipare de participare)
Prelucrarea la scară largă — prelucrarea datelor participanților, la scară, la nivelul mai multor organizații-Client
Profilarea — calificarea prospecților și scorul de implicare, întemeiate pe comportamentul participanților

Prelucrarea realizată de [PLATFORM PROVIDER] îndeplinește toate cele trei criterii.

1.3 Domeniul de Aplicare al Prezentei DPIA

Prezenta DPIA acoperă prelucrarea efectuată de [PLATFORM PROVIDER] în calitate de Persoană împuternicită de operator, în numele organizațiilor-Client (Operatori de date). Evaluarea riscurilor se realizează din perspectiva [PLATFORM PROVIDER], în calitate de furnizor al platformei.

Două dintre operațiunile de prelucrare evaluate mai jos nu sunt, în implementarea lor actuală, determinate de Client. Generarea de conținut asistată de AI funcționează pe baza unei singure acreditări la nivel de platformă, deținute de [PLATFORM PROVIDER]; furnizorul, modelele și retenția prompturilor și a rezultatelor sunt alese de [PLATFORM PROVIDER], iar organizațiile nu dispun de niciun comutator propriu. Transferurile de conversii publicitare pe server sunt executate de codul [PLATFORM PROVIDER], în temeiul evaluării interesului legitim expuse în Secțiunea 3.3 din prezentul document, iar nu al evaluării proprii a Clientului. Ambele sunt incluse mai jos în domeniul de aplicare. Calificarea celor două operațiuni drept prelucrare de operator sau de persoană împuternicită, precum și evidențele și informările care decurg din aceasta, fac obiectul unei analize.

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

Prezenta DPIA, la fel ca ansamblul corpusului juridic, tratează [PLATFORM PROVIDER] exclusiv în calitate de persoană împuternicită de operator, care acționează pe baza instrucțiunilor Clientului. În cazul generării de conținut asistate de AI și al măsurării conversiilor publicitare pe server, [PLATFORM PROVIDER] stabilește în realitate furnizorul, scopul și temeiul juridic, iar Clientul nu dispune de niciun mijloc de a da instrucțiuni cu privire la acestea, de a se opune ori de a le dezactiva. Pentru această prelucrare nu există nicio evidență în temeiul art. 30 alin. (1) GDPR și nicio informare în temeiul art. 13 și 14 GDPR în care [PLATFORM PROVIDER] să figureze în calitate de Operator. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

În domeniul de aplicare:

Colectarea datelor de înregistrare ale participanților
Urmărirea comportamentală (chat, sondaje, oferte, participare)
Moderarea automată a mesajelor de chat ale participanților (mascarea cuvintelor interzise și eliminarea tacită)
Livrarea notificărilor push (tranzacționale și de marketing)
Livrarea e-mailurilor de marketing
Difuzările tranzacționale către segmente, transmise în afara condiției de consimțământ de marketing
Livrarea notificărilor prin SMS
Calificarea prospecților și scorul de implicare
Urmărirea conversiilor pe platformele publicitare (pe server și client-side)
Măsurarea vizitatorilor paginilor de destinație (vizualizările de pagină ale funnel-urilor și PageView-ul Meta transmis de pe server)
Difuzarea video către participanți printr-un player încorporat al unui terț
Generarea de conținut asistată de AI
Automatizarea drepturilor persoanelor vizate în temeiul GDPR
Autentificarea în aplicația mobilă și stocarea token-urilor de dispozitiv

În afara domeniului de aplicare:

Utilizarea platformei de către Client în scopuri proprii (fiecare Client ar trebui să realizeze propria DPIA la nivel de Operator, acolo unde este necesar)
Integrările cu acreditări per organizație, în măsura în care Clientul le configurează și le contractează direct: contul NewsmanApp SRL propriu al Clientului, Firebase per organizație, contul SendSMS.ro propriu al Clientului și conturile proprii ale Clientului pe platformele publicitare

Cloudflare, Inc. nu se află în afara domeniului de aplicare. În producție, este un proxy invers obligatoriu, plasat în fața traficului participanților: terminează TLS și vede fiecare cerere a participanților, inclusiv trimiterile formularului de înregistrare, care poartă adresa de e-mail, numele și numărul de telefon în clar; pentru acest trafic, adresa IP a clientului pe care platforma o consemnează sau o transmite mai departe este preluată dintr-un antet furnizat de Cloudflare, pe care funcția sa auxiliară de extragere a adresei IP îl verifică înaintea oricărui alt antet de proxy. În plus, Cloudflare Turnstile este injectat în paginile de destinație publicate, în afara grupului de scripturi condiționate de consimțământ, iar verificarea pe server transmite adresa IP a vizitatorului către Cloudflare. Alături de conturile per organizație există și un cont NewsmanApp SRL la nivel de platformă. Anthropic PBC este angajat pe baza unei singure acreditări la nivel de platformă și nu constituie nicidecum o integrare furnizată de Client. Transferurile de conversii pe server sunt efectuate de codul propriu al [PLATFORM PROVIDER] și nu pot fi declinate drept integrări furnizate de Client.

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

Versiunile anterioare ale prezentei DPIA plasau Cloudflare, Newsman și platformele publicitare integral în afara domeniului de aplicare, în calitate de integrări furnizate de Client, pentru care răspunderea revenea Clientului. Cloudflare este în prezent un proxy obligatoriu, aflat pe traseul cererilor către domeniile participanților, un cont Newsman la nivel de platformă există în plus față de cele per organizație, iar transferurile publicitare pe server sunt efectuate de codul [PLATFORM PROVIDER], în temeiul evaluării din Secțiunea 3.3. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2. Descrierea Prelucrării

2.1 Natura Prelucrării

Dimensiune	Descriere
Metoda de colectare	Formulare de înregistrare web, onboarding în aplicația mobilă, evenimente comportamentale în timp real în timpul evenimentelor, evenimente de conversie pe server la înregistrare
Stocare	Firestore (datele cu caracter personal ale contactelor, configurația), PostgreSQL (analiză de marketing și comportamentală, cheiată pe hash-ul adresei de e-mail, cu excepțiile consemnate în Secțiunea 3.4), Firebase Realtime Database (datele în timp real ale sesiunilor live), Firebase Cloud Storage (biblioteca media a organizației, elementele de brand, șabloanele de pagină și fișierele paginilor de destinație), precum și o memorie cache în proces, cu datele de contact în clar, menținută de API
Utilizare	Livrarea evenimentului, calificarea prospecților, mesagerie prin e-mail, push, SMS, difuzări tranzacționale către segmente, urmărirea conversiilor publicitare, măsurarea vizitatorilor paginilor de destinație, moderarea automată a chatului, generarea de conținut asistată de AI, analiză
Acces	Utilizatorii din personalul organizației-Client, în cele patru roluri definite de platformă — `admin`, `moderator`, `marketer` și `staff`; infrastructura platformei [PLATFORM PROVIDER] (automatizat); niciun acces al personalului [PLATFORM PROVIDER] la datele cu caracter personal ale participanților în operațiunile normale
Dezvăluire	[PLATFORM PROVIDER] angajează unsprezece subîmputerniciți, enumerați în Anexa III (annex-sub-processors.md). Cei care primesc date cu caracter personal ale participanților în funcționarea normală sunt Google LLC, Railway Corp., NewsmanApp SRL, Cloudflare, Inc., Meta Platforms, Inc., TikTok Pte. Ltd., Microsoft Corporation, SendSMS.ro și Anthropic PBC. Formularea „numai date sub formă de hash" nu este exactă: Meta și TikTok primesc adresa IP brută și user agent-ul brut ale vizitatorului, alături de hash-uri SHA-256 ale adresei de e-mail, ale numărului de telefon și ale numelui. În plus, pagina de vizionare a participantului încorporează conținut video de la un player terț, din browserul participantului și în afara grupului de scripturi condiționate de consimțământ
Retenție	Variabilă în funcție de tipul de date — a se vedea ROPA și Politica de Retenție a Datelor (data-retention-policy.md). Datele sesiunilor live din Realtime Database, jurnalul de audit și registrul cererilor persoanelor vizate nu fac obiectul niciunei ștergeri automate; a se vedea Secțiunea 4.2 R10 și R11
Ștergere	Fluxul de ștergere GDPR (incomplet — a se vedea Secțiunea 4.2 R8); ștergere în cascadă la subîmputerniciți

2.2 Scopul Prelucrării

A se vedea ROPA (ropa.md) pentru registrul complet al scopurilor. Scopuri principale:

Accesul la eveniment și livrarea acestuia (executarea contractului)
Urmărirea comportamentală pentru calificarea prospecților (consimțământ)
Marketing prin e-mail (consimțământ) — email_marketing condiționează un singur lucru: sincronizarea contactului în lista și în segmentele furnizorului de e-mail de marketing. Orice altă cale de e-mail — confirmarea înregistrării, notificările de reamintire, mesajul „începe acum", replay-ul, e-mailul din automatizări, retrimiterea și difuzarea către segmente — funcționează exclusiv pe condiția tranzacțională
Livrarea notificărilor push — exclusiv tranzacțională (consimțământ). Fiecare trimitere push impune o evidență de consimțământ push_notifications acordat și neretras, verificată la momentul trimiterii; notificările push de marketing nu sunt implementate
Comunicări prin SMS (consimțământ — o evidență de consimțământ sms_notifications acordat și neretras). Mesageria WhatsApp nu este implementată: whatsapp_notifications și whatsapp_marketing sunt acceptate și afișate drept scopuri ale consimțământului, însă nu condiționează nicio cale de trimitere
Urmărirea conversiilor publicitare — pe server (interes legitim, art. 6 alin. (1) lit. (f) GDPR; a se vedea Secțiunea 3.3) și prin pixeli client-side (a se vedea Secțiunea 3.1)
Securitate, prevenirea fraudei, detectarea abuzurilor (interes legitim)
Moderarea automată a mesajelor de chat ale participanților (interes legitim, determinat de Client)
Difuzări tranzacționale către membrii unui segment, transmise independent de consimțământul de marketing (a se vedea Secțiunea 3.1)
Măsurarea vizitatorilor paginilor de destinație, aplicată fiecărui vizitator, iar nu numai persoanelor înregistrate (a se vedea Secțiunile 3.3 și 3.4)
Generarea asistată de AI a paginilor de destinație, a textelor de marketing și a întrebărilor pentru sondaje (a se vedea Secțiunea 1.3 și Secțiunea 4.2 R15)

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

Versiunile anterioare ale prezentei DPIA arătau că notificările push tranzacționale se întemeiază pe interesul legitim și că notificările push de marketing constituie un scop implementat. Tot acolo, WhatsApp figura printre canalele de comunicare active, iar urmărirea conversiilor publicitare era prezentată drept condiționată de categoria publicitară a bannerului de cookie-uri. În realitate, notificarea push tranzacțională impune un consimțământ push_notifications acordat, notificările push de marketing și mesageria WhatsApp nu dispun de nicio cale de trimitere, iar pe evenimentele de conversie de pe server și pe pixelii client-side nu există nicio condiție de consimțământ publicitar. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.3 Persoanele vizate

Participanții la evenimente (persoane fizice B2C care se înregistrează la evenimentele găzduite de Client)
Utilizatorii din personalul propriu al organizației-Client, ale căror date de cont, adresă IP și user agent sunt prelucrate și păstrate în jurnalul de audit
De regulă, nu sunt vizate categorii vulnerabile de persoane. Vârsta minimă de 16 ani este prevăzută în Termenii și Condițiile Clientului și este autodeclarată prin acceptarea acestora; ea nu este impusă tehnic. Pe nicio cale de înregistrare nu se colectează un câmp privind vârsta, data nașterii sau confirmarea vârstei, astfel încât o persoană sub 16 ani se poate înregistra fără a fi detectată. Într-o asemenea situație, scopurile întemeiate pe consimțământ, arătate mai sus, pot să nu aibă un temei valabil pentru respectiva persoană înregistrată (art. 8 GDPR).

2.4 Categoriile de Date

A se vedea Secțiunea 2.6 din DPA (Tipuri de Date cu Caracter Personal) și fișele Activităților de Prelucrare din ROPA pentru inventarul complet al datelor. Categorii principale:

Categorie	Sensibilitate	Exemple
Date de înregistrare	Scăzută-medie	Adresă de e-mail, nume, telefon
Date comportamentale	Medie	Mesaje de chat, voturi la sondaje, click-uri pe oferte
Date tehnice	Scăzută	Tipul dispozitivului, țara, token FCM (pseudonim)
Date de atribuire	Medie	Identificatori de click publicitar, parametri UTM
Evidențe de consimțământ	Scăzută	Marcaje temporale și scopuri ale consimțământului
Date de livrare push	Scăzută	Identificatorul mesajului FCM, starea trimiterii (legată de email_hash)
Identificatori de vizitator	Medie	Un hash SHA-256 persistent al adresei IP și al user agent-ului vizitatorului, consemnat pentru fiecare vizitator care nu este bot, pe fiecare pagină de destinație a unui funnel
Date privind dispozitivul și mediul	Scăzută-medie	Tipul dispozitivului, sistemul de operare, browserul, fusul orar, țara, orașul, URL-ul paginii de destinație și URL-ul de proveniență, consemnate per contact la intrarea în funnel
Date privind achizițiile și comenzile	Medie	Identificatorul comenzii, valoarea totală, moneda și starea plății, primite prin webhook din magazinul de comerț electronic al Clientului și asociate unui contact identificat
Payload-uri de webhook de la terți	Medie	Întregul corp brut al trimiterilor de formulare și al webhook-urilor terților, păstrat ca metadate ale intrării în funnel
Date de moderare	Medie	Textul integral original al unui mesaj de chat eliminat prin moderare automată, datele de actor ale autorului și motivul eliminării
Etichete de suprimare	Scăzută	Un motiv de suprimare a e-mailului, derivat per contact de sincronizarea cu furnizorul de e-mail, de exemplu o etichetă de bounce sau de reclamație de spam
Evidențe de livrare SMS	Scăzută-medie	Hash-ul adresei de e-mail, webinarul și sesiunea, tipul de șablon, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării, marcajele temporale de livrare și de click
Date de prompt și de rezultat AI	Medie	Prompturile de sistem și de utilizator, instrucțiunile personalului, rezultatele modelului și numărul de token-uri — inclusiv testimoniale aprobate ale participanților (numele afișat, citatul, compania, nota acordată) încorporate în prompt — împreună cu imaginile de referință încărcate de personal
Date de audit privind personalul	Scăzută-medie	Identificatorul utilizatorului din personal care acționează, adresa IP și user agent-ul, consemnate la fiecare scriere auditată
Obiecte din Cloud Storage	Medie	Biblioteca media a organizației, elementele de brand, șabloanele de pagină, imaginile ofertelor și ale webinarelor și fișierele paginilor de destinație, care pot înfățișa persoane identificabile

Nu se colectează în mod intenționat categorii speciale de date (art. 9 GDPR). Câmpurile în format liber pe care le controlează participanții — mesajele de chat, testimonialele, răspunsurile de feedback și payload-urile de webhook de la terți — pot conține însă date din categorii speciale, furnizate din proprie inițiativă de persoana vizată; asupra acestor câmpuri nu se efectuează nicio filtrare a conținutului din categorii speciale.

3. Necesitate și Proporționalitate

3.1 Temeiuri Juridice

Toate scopurile de prelucrare au temeiuri juridice identificate (a se vedea fișele Activităților de Prelucrare din ROPA). Evaluări principale:

Prelucrare	Temei juridic	Proporțional?
Colectarea datelor de înregistrare	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Da — date minime pentru livrarea serviciului
Urmărirea comportamentală	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Sub rezerve — consimțământul colectat este grupat, parțial dedus și valabil la nivelul întregii organizații; a se vedea nota privind mecanica consimțământului, de sub prezentul tabel
E-mail tranzacțional	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Da — necesar pentru serviciu; testul de echilibru mai jos
Push tranzacțional și SMS	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Da — la momentul trimiterii se impune o evidență `push_notifications` sau `sms_notifications` acordată și neretrasă
E-mail de marketing	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Sub rezerve — opt-in-ul explicit condiționează numai sincronizarea cu furnizorul de marketing; push-ul de marketing și marketingul prin SMS nu condiționează nimic, întrucât niciuna dintre cele două căi de trimitere nu există
Urmărirea conversiilor publicitare — client-side (pixeli)	⚠️ Nu a fost stabilit	Pixelii Meta și TikTok sunt clasificați ca necesari și transmit o vizualizare de pagină înainte de orice decizie privind consimțământul, într-o stare de consimțământ reținut, fără cookie-uri (`fbq('consent','revoke')` / `ttq.holdConsent()`); adresa IP, user agent-ul și URL-ul paginii ajung totuși la Meta și la TikTok anterior consimțământului. Legalitatea în temeiul art. 5 alin. (3) ePrivacy nu este stabilită — a se vedea caseta DEFICIENȚĂ CUNOSCUTĂ.
Urmărirea conversiilor publicitare — pe server (CAPI)	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Sub rezerve — identificatorii sub formă de hash sunt transmiși împreună cu adresa IP brută și cu user agent-ul brut; testul de echilibru mai jos
Măsurarea vizitatorilor paginilor de destinație	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Sub rezerve — se aplică fiecărui vizitator, inclusiv persoanelor fără nicio relație anterioară, care nu se înregistrează niciodată; testul de echilibru în Secțiunea 3.3
Calificarea prospecților	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Da — condiționată de consimțământul `behavioral_tracking`
Difuzarea tranzacțională către segmente	⚠️ Determinat de Client; nestabilit în evidențele [PLATFORM PROVIDER]	Nu — trimiterea nu este condiționată de consimțământul de marketing; a se vedea nota privind căile de ocolire operate de personal, de sub prezentul tabel
Moderarea automată a chatului	Interes legitim (art. 6 alin. (1) lit. (f) GDPR), determinat de Client	Sub rezerve — persoana vizată nu este informată; a se vedea Secțiunea 4.2 R14
Generarea de conținut asistată de AI	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Sub rezerve — testimonialele aprobate ale participanților sunt transmise unui furnizor din SUA fără informare și fără nicio condiție de consimțământ; a se vedea Secțiunea 4.2 R15
Securitate/prevenirea fraudei	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Da — esențial; se folosesc date minime

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

Prezentul document arăta anterior că pixelii Meta și TikTok se încarcă numai dacă participantul acceptă cookie-urile publicitare. În realitate, ambii pixeli sunt clasificați ca necesari și transmit o vizualizare de pagină înainte de orice decizie privind consimțământul, într-o configurație menită să rămână fără cookie-uri până la acordarea consimțământului publicitar. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

Notă privind mecanica consimțământului. Consimțământul consemnat de platformă nu este granular în sensul sugerat de tabelul anterior.

Pe formularul public de funnel, o singură bifă consemnează atât acceptarea termenilor și condițiilor, cât și acordul pentru prelucrarea datelor cu caracter personal, iar un număr de telefon introdus în formular acordă consimțământul pentru notificări SMS fără o bifă separată; atunci când este bifată și căsuța de marketing, respectivul consimțământ de marketing se extinde asupra marketingului prin SMS. Aplicația pentru participanți aplică aceeași grupare pentru consimțămintele privind termenii și prelucrarea.

Consimțământul este consemnat numai ca acordare. Lăsarea nebifată a căsuței de marketing nu consemnează nimic — nu se stochează niciun refuz și nu se scrie niciun eveniment de consimțământ — iar o nouă înregistrare cu căsuța bifată reacordă un consimțământ de marketing retras anterior.

Contactele încărcate prin importatorul în masă sunt scrise cu consimțăminte acordate pentru prelucrarea datelor și pentru acceptarea termenilor, consemnate cu versiunea de politică în vigoare și cu metoda „import", precum și cu consimțământ de marketing atunci când rândul importat poartă acel indicator.

Consimțămintele sunt raportate la organizație, iar nu la eveniment: o singură acordare acoperă fiecare eveniment ulterior din cadrul acelei organizații, atât timp cât nu este retrasă. Există exact zece scopuri valabile ale consimțământului — data_processing, tos_acceptance, email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications și sms_marketing — dintre care whatsapp_notifications, whatsapp_marketing, push_marketing și sms_marketing sunt acceptate și afișate, însă nu condiționează nimic, iar data_processing și tos_acceptance nu pot fi retrase din pagina de preferințe. Versiunea în vigoare a politicii de consimțământ este "1.0". Rezultatul bannerului de cookie-uri ține de un vocabular distinct și este stocat exclusiv într-un cookie propriu, pe dispozitivul vizitatorului (rx_cookie_consent, care consemnează opțiunile pentru categoriile necesare, de analiză și de publicitate, un marcaj temporal și o versiune, păstrat douăsprezece luni); el nu este niciodată scris în registrul consimțămintelor, astfel încât platforma nu deține nicio evidență pe server despre cine a acceptat sau a respins cookie-urile.

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

Prezenta DPIA consemna anterior consimțământul pentru urmărirea comportamentală drept opt-in, granular și revocabil și trata această caracterizare drept justificarea proporționalității prelucrării. Consimțământul colectat în realitate este grupat cu termenii și condițiile, dedus din introducerea unui număr de telefon, raportat la organizație, iar nu la eveniment, fabricat de importatorul în masă pentru contacte care nu au utilizat niciodată platforma și consemnat numai ca acordare, astfel încât un refuz și absența oricărei decizii nu se pot deosebi în registrul consimțămintelor. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

Notă privind căile de ocolire operate de personal. Trei funcționalități livrate permit personalului Clientului să ajungă la contacte care nu dețin niciun consimțământ de marketing. În primul rând, difuzarea tranzacțională către segmente transmite fiecărui membru al unui segment un subiect, un corp și un îndemn la acțiune compuse de personal, filtrate numai după restricționarea prelucrării în temeiul art. 18 GDPR și după indicatorul de suprimare a e-mailului, fără nicio condiție de consimțământ de marketing. În al doilea rând, o condiție de segmentare lacks_consent construiește un segment format exact din contactele care nu dețin nicio acordare activă pentru un anumit scop. În al treilea rând, exportul de segmente returnează adrese de e-mail și nume în clar, fără nicio condiție de consimțământ de marketing, iar un parametru opțional returnează suplimentar contactele care au înregistrat un bounce, au reclamat spam sau s-au dezabonat global; contactele dezabonate sunt întotdeauna prezente în exportul implicit, întrucât dezabonarea retrage consimțământul de marketing fără a seta indicatorul de suprimare.

Toate cele trei sunt autorizate prin grupul de permisiuni de marketing, pe care îl deține rolul neadministrativ marketer. Platforma definește patru roluri de personal — admin, moderator, marketer și staff — asociate cu trei grupuri de permisiuni (marketing, live, setări). Rolul staff nu deține niciun grup de permisiuni și este, în fapt, unul de tip „doar citire"; marketer deține grupul de marketing; moderator deține grupul live; admin le deține pe toate trei. Rolul este ales explicit la crearea contului; nu există un rol implicit de tip „doar citire". Privilegiile de administrator sunt necesare pentru un singur endpoint, acela de listare a jurnalului de audit. Orice altă acțiune distructivă — ștergerea webinarelor, a sesiunilor, a funnel-urilor, a segmentelor, a paginilor, a ofertelor, a sondajelor, a fișierelor încărcate și a testimonialelor — este autorizată prin grupul de permisiuni marketing sau live, pe care rolurile neadministrative marketer și moderator le îndeplinesc. Fiecare dintre cele trei acțiuni este consemnată în jurnalul de audit, însă niciuna nu este împiedicată de platformă. Dacă o anumită difuzare constituie un mesaj de serviciu ori marketing direct — și, prin urmare, dacă devin incidente art. 13 din Directiva 2002/58/CE (ePrivacy) și art. 12 din Legea nr. 506/2004 — se stabilește de Client în calitate de Operator, la fiecare trimitere.

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

Prezenta DPIA arăta anterior că, în întregime, comunicările de marketing se întemeiază pe un consimțământ explicit de tip opt-in. Platforma pune la dispoziția personalului trei căi care ajung la contacte lipsite de consimțământ de marketing — o difuzare către segmente filtrată numai după restricționarea prelucrării și după suprimarea e-mailului, o condiție de segmentare care selectează exact contactele fără acordare și un export de contacte în clar, fără nicio condiție de consimțământ — și niciuna dintre acestea nu este blocată de platformă. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.2 Testul de Echilibru al Interesului Legitim (Comunicări Tranzacționale)

Interesul urmărit: Livrarea serviciului de eveniment pentru care s-a înregistrat persoana vizată (notificări de reamintire, „începe acum", disponibilitatea replay-ului).

Necesitate: Fără comunicări tranzacționale, participanții pot rata evenimentele la care s-au înregistrat; livrarea serviciului ar fi afectată în mod substanțial.

Echilibrare: Persoanele vizate se așteaptă în mod rezonabil să primească notificări de reamintire și actualizări pentru serviciile la care s-au înregistrat. Prelucrarea este limitată la ceea ce este necesar (fără profilare comportamentală, fără partajare cu terți). Persoanele vizate pot dezactiva în orice moment notificările push tranzacționale din setările sistemului de operare.

Domeniul de aplicare al prezentului test: Prezentul test de echilibru acoperă exclusiv e-mailul tranzacțional. Notificările push tranzacționale și mesajele SMS tranzacționale nu sunt transmise în temeiul interesului legitim: fiecare impune o evidență de consimțământ push_notifications sau sms_notifications acordat și neretras, verificată în registrul consimțămintelor la momentul trimiterii. Mesajele SMS tranzacționale implică, suplimentar, un transfer către SendSMS.ro; a se vedea Secțiunea 4.2 R17.

Concluzie: Temeiul interesului legitim este justificat pentru e-mailul tranzacțional.

3.3 Testul de Echilibru al Interesului Legitim (Urmărirea Conversiilor Publicitare pe Server)

Interesul urmărit: Măsurarea eficacității campaniilor publicitare prin transmiterea evenimentelor de înregistrare către platformele publicitare, de la server la server, astfel încât organizația să poată optimiza cheltuielile de marketing și să reducă bugetul publicitar irosit. Există două integrări pe server: Meta Conversions API și TikTok Events API, cea din urmă activă începând cu 8 mai 2026. Nu există nicio integrare pe server pentru Google Ads și niciuna pentru LinkedIn: ambele figurează exclusiv ca structuri de configurare inerte, iar Google Ads Enhanced Conversions și LinkedIn Conversions API nu sunt implementate.

Necesitate: Fără datele de conversie de pe server, platformele publicitare nu pot atribui înregistrările unor campanii determinate, ceea ce duce la o targetare degradată a anunțurilor, la costuri mai mari per lead și la imposibilitatea de a măsura randamentul cheltuielilor publicitare. Urmărirea exclusiv client-side este nesigură din cauza blocantelor de anunțuri și a restricțiilor din browsere (ITP, ETP). Urmărirea conversiilor pe server este soluția standard în industrie, recomandată de toate platformele publicitare majore.

Echilibrare:

Minimizarea datelor — parțială: Către ambele platforme se transmit hash-uri SHA-256 ale adresei de e-mail, ale prenumelui și ale numelui, iar TikTok primește în plus un identificator extern sub formă de hash, derivat din înregistrare; Meta primește același identificator, în formă brută. Pe această cale nu se transmite niciun număr de telefon: câmpul rămâne gol la compunerea evenimentului, oricare ar fi numărul deținut în fișa contactului. Adresa IP brută a clientului și user agent-ul brut sunt transmise ambelor platforme alături de acele hash-uri; Meta primește suplimentar identificatorul evenimentului de înregistrare în formă brută, precum și valorile cookie-urilor _fbp și _fbc, acolo unde acestea există, iar TikTok primește suplimentar identificatorul de click ttclid brut și valoarea brută a cookie-ului _ttp. Prin urmare, afirmația potrivit căreia nu se transmit niciodată date cu caracter personal în formă brută nu este exactă: adresa IP este o dată cu caracter personal și este transmisă fără hash.
Accesul la browser — calea vizualizării de pagină citește totuși dispozitivul: evenimentul de înregistrare este un apel de la server la server, care nu scrie și nu citește cookie-uri pe dispozitivul persoanei vizate. Nu la fel stau lucrurile pe calea vizualizării de pagină, evaluată separat mai jos, unde un script inline aflat pe fiecare pagină de destinație generată citește cookie-urile _fbp și _fbc din browser înainte ca valorile să fie transmise mai departe către Meta. Citirea informațiilor deja stocate în echipamentul terminal al unui abonat intră sub incidența art. 5 alin. (3) din Directiva 2002/58/CE (ePrivacy), independent de locul din care pornește transferul ulterior, astfel încât pentru această prelucrare, privită în ansamblu, nu se poate invoca nicio excepție generală de la regulile ePrivacy.
Scop limitat: Datele sunt utilizate exclusiv pentru atribuirea conversiilor și optimizarea campaniilor, nu pentru construirea de profiluri independente ale utilizatorilor.
Retenția de către platforme: Platformele publicitare rețin datele sub formă de hash timp de 7–28 de zile pentru potrivire, apoi le șterg.
Așteptare rezonabilă: O persoană care dă click pe un anunț și se înregistrează pentru un eveniment se așteaptă în mod rezonabil ca advertiserul să măsoare dacă anunțul a condus la acea înregistrare. Acest argument este disponibil numai pentru evenimentul de înregistrare; el nu susține transferul vizualizării de pagină, evaluat mai jos.
Restricționarea prelucrării în temeiul GDPR este respectată: 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.
Nicio condiție de consimțământ: Pe calea de pe server nu există nicio condiție de consimțământ publicitar. Singura condiție, în afara restricționării în temeiul art. 18 GDPR, este ca integrarea să fi fost activată de Client.
Drept de opoziție disponibil: Persoanele vizate se pot opune acestei prelucrări în temeiul art. 21 GDPR, prin procedura DSAR.

Concluzie: Interesul legitim poate susține transferul aferent evenimentului de înregistrare, sub rezerva precizării că transferul nu se limitează la date pseudonimizate: adresa IP și user agent-ul persoanei vizate sunt transmise în clar. Afirmația din versiunile anterioare ale prezentei DPIA, potrivit căreia prelucrarea „utilizează numai date pseudonimizate", se retrage.

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

Prezenta DPIA arăta anterior că platformelor publicitare li se transmit numai adresa de e-mail și numele sub formă de hash, niciodată date cu caracter personal în formă brută, și că urmărirea conversiilor pe server se situează în afara domeniului de aplicare al Directivei ePrivacy, întrucât nu plasează și nu citește cookie-uri. Adresele IP brute și user agent-urile brute sunt transmise către Meta și TikTok la fiecare eveniment, TikTok primește suplimentar un identificator de click brut și o valoare brută de cookie, iar beacon-ul de pe pagina de destinație citește cookie-urile _fbp și _fbc din browserul vizitatorului înainte de a le transmite mai departe. Tot acolo figurau o integrare pe server pentru Google Ads și una pentru LinkedIn, dintre care niciuna nu există. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Evaluare separată — transferul aferent tuturor vizitatorilor paginii de destinație. Testul de mai sus a fost redactat pentru o persoană care a dat click pe un anunț și a finalizat o înregistrare. El nu susține transferul vizualizării de pagină, care trebuie evaluat pe temeiurile sale proprii.

Interesul urmărit: Măsurarea audienței paginilor de destinație, astfel încât organizația să poată atribui traficul campaniilor și să optimizeze cheltuielile, inclusiv acolo unde pixelul din browser este blocat.

Natura prelucrării: Fiecare pagină de destinație a unui funnel, odată generată, conține un script inline care produce un identificator de eveniment pentru fiecare cerere, citește cookie-urile _fbp și _fbc din browserul vizitatorului, preia orice valoare fbclid din șirul de interogare și solicită platformei o imagine de un pixel. Platforma consemnează vizualizarea în dreptul unui identificator persistent de vizitator, derivat din adresa IP și din user agent, și — acolo unde Clientul a activat integrarea Meta — transmite prin Meta Conversions API o vizualizare de pagină care poartă adresa IP brută a vizitatorului, user agent-ul brut, URL-ul paginii, identificatorul de click și valorile cookie-urilor. Acolo unde cookie-ul lipsește, situație întâlnită la vizitatorul care nu a acceptat cookie-urile publicitare, în locul său se sintetizează o valoare derivată din identificatorul de click. Singura condiție a transferului este ca integrarea Meta să fi fost activată de Client; pe această cale nu există nicio verificare a consimțământului. Vizualizările de pagină de pe server nu sunt oglindite către TikTok.

Categoriile de date: Adresa IP brută, user agent-ul brut, URL-ul paginii, referrer-ul, identificatorul de click și valorile cookie-urilor publicitare, împreună cu un hash persistent al adresei IP și al user agent-ului, păstrat de platformă.

Persoanele vizate: Fiecare vizitator uman al unei pagini de destinație a unui funnel, inclusiv persoanele care nu au nicio relație cu Clientul, care nu se înregistrează niciodată și care au ajuns pe pagină dintr-o altă sursă decât un anunț.

Echilibrare: Argumentul așteptării rezonabile, care susține evenimentul de înregistrare, nu este disponibil aici. O persoană care doar încarcă o pagină nu a inițiat nicio relație cu advertiserul și nu are niciun motiv să se aștepte ca vizita, adresa sa IP și user agent-ul său să fie transmise unei platforme publicitare dintr-o țară terță. Prelucrarea nu este necesară pentru livrarea vreunui serviciu către acea persoană. Atât restricționarea în temeiul art. 18 GDPR, cât și calea de opoziție prevăzută de art. 21 GDPR operează asupra unei fișe de contact identificate și, prin urmare, nu oferă niciun remediu practic vizitatorului neidentificat. Nimic din interfață nu dezvăluie transferul în momentul în care acesta are loc.

Concluzie: ⚠️ Nu a fost stabilită. Temeiul interesului legitim invocat pentru evenimentul de înregistrare nu se extinde, potrivit prezentei evaluări, asupra transferului vizualizării de pagină aferent tuturor vizitatorilor, iar citirea cookie-urilor _fbp și _fbc atrage aplicarea art. 5 alin. (3) din Directiva 2002/58/CE (ePrivacy), independent de analiza întemeiată pe art. 6 GDPR. Poziția trebuie stabilită de Operator.

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

Prezenta DPIA evalua anterior urmărirea conversiilor publicitare pe server ca pe o activitate unică, efectuată asupra persoanelor înregistrate care dăduseră click pe un anunț. În plus, un transfer de vizualizare de pagină pe server se declanșează pentru fiecare vizitator uman al unei pagini de destinație a unui funnel, fără înregistrare, fără relație anterioară și fără nicio verificare a consimțământului, și transmite către Meta adresa IP brută și user agent-ul brut ale vizitatorului. Pentru acest transfer nu fusese consemnat niciun test de echilibru, iar legalitatea sa nu este stabilită. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.4 Minimizarea Datelor

Măsură	Implementare
Adresa IP — neminimizată	O căutare geo la înregistrare derivă și stochează numai țara și orașul, astfel cum s-a descris anterior. Dincolo de această cale, în tabelul vizualizărilor de pagină ale funnel-urilor se scrie un hash SHA-256 persistent al adresei IP și al user agent-ului vizitatorului, pentru fiecare vizitator care nu este bot, pe fiecare pagină de destinație a unui funnel, fără nicio condiție de consimțământ; acel tabel nu se numără printre tipurile de date pe care jobul de retenție le recunoaște, astfel încât evidențele respective sunt păstrate pe termen nelimitat. Jurnalul de audit stochează adresa IP brută și user agent-ul utilizatorului din personal care acționează, la fiecare scriere auditată, și nu este nici el atins de jobul de retenție. Adrese IP brute sunt transmise către Meta și TikTok la fiecare eveniment de conversie și de vizualizare de pagină. În plus, șirul brut al user agent-ului este scris în metadatele de atribuire ale înregistrării — păstrate pe intrarea în funnel și pe documentul de înregistrare din Firestore — de scriptul client al formularului de înregistrare și este citit de acolo atunci când se transmite un eveniment de conversie pe server.
User-Agent — neminimizat	User agent-ul face parte din identificatorul persistent de vizitator descris mai sus, este stocat în formă brută și pe termen nelimitat în jurnalul de audit și este transmis în formă brută către Meta și TikTok.
Token-urile FCM sunt pseudonimizate	Cheiate pe email_hash, nu pe adresa de e-mail în clar
Datele comportamentale sunt condiționate de consimțământ — condiționare mai restrânsă decât s-a descris	Rândurile granulare de evenimente comportamentale nu sunt scrise în baza de date analitică în lipsa consimțământului `behavioral_tracking`, iar această condiție este aplicată de fiecare Cloud Function comportamentală. Ea nu se extinde mai departe. 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ă. Scrierea în sesiunea live și sincronizarea participării se întemeiază pe executarea contractului. Endpoint-ul de ingestie al serviciului nu reverifică în mod independent această condiție; el se bazează pe faptul că funcția apelantă a aplicat-o deja.
Datele de conversie publicitară sunt sub formă de hash — în parte	Către Meta și TikTok se transmit hash-uri SHA-256 ale adresei de e-mail și ale numelui, iar niciun număr de telefon nu este transmis; alături de acestea se transmit adresa IP brută și user agent-ul brut, Meta primește suplimentar identificatorul înregistrării în formă brută, iar TikTok primește suplimentar identificatorul de click brut și valoarea brută a cookie-ului `_ttp`
Livrarea push este legată de email_hash	Tabelul push_sends utilizează email_hash, nu adresa de e-mail
PostgreSQL este cheiat pe hash-ul adresei de e-mail — sub rezerva excepțiilor menționate	A se vedea nota privind pseudonimizarea, de sub prezentul tabel
Dovada consimțământului deținută de furnizorul de e-mail nu face credință	La reabonarea efectuată pe server, platforma transmite furnizorului de e-mail o adresă IP de opt-in fictivă (`0.0.0.0`), întrucât într-o sincronizare de pe server nu este disponibilă nicio adresă IP reală. Prin urmare, fișa de abonat a furnizorului atestă o origine care nu este cea a persoanei vizate. Evidența care face credință în temeiul art. 7 alin. (1) GDPR este registrul propriu al evenimentelor de consimțământ al platformei, iar nu fișa de abonat a furnizorului, iar acest registru este cel care trebuie prezentat ca dovadă a unui opt-in.

Notă privind pseudonimizarea. 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.

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.

O limitare suplimentară privește hash-ul însuși. Hash-ul adresei de e-mail este un SHA-256 fără sare criptografică, calculat pe adresa convertită în minuscule și lipsită de spațiile de la capete, astfel încât oricine cunoaște adresa de e-mail a unei persoane poate calcula identificatorul sub care sunt păstrate evidențele acesteia.

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

Prezenta DPIA arăta anterior că adresele IP nu sunt stocate, că user agent-urile sunt stocate numai acolo unde atribuirea de marketing o impune și că baza de date PostgreSQL nu conține date de contact în clar. În realitate, pentru fiecare vizitator al unei pagini de destinație se stochează pe termen nelimitat un identificator persistent derivat din adresa IP și din user agent, adresele IP și user agent-urile brute sunt stocate pe termen nelimitat în jurnalul de audit și transmise către Meta și TikTok, iar motorul de automatizări scrie în PostgreSQL adrese de e-mail și numere de telefon în clar. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

4. Identificarea Riscurilor

4.1 Registrul Riscurilor

#	Risc	Probabilitate	Severitate	Risc Inerent
R1	Acces neautorizat la datele cu caracter personal ale participanților (încălcarea securității datelor)	Scăzută	Ridicată	Mediu
R2	Scurgere de date între organizații (verificările de organizație lipsesc în afara PostgreSQL)	Ridicată	Critică	Ridicat
R3	Profilare excesivă, dincolo de scopurile declarate	Scăzută	Ridicată	Mediu
R4	Urmărire comportamentală fără consimțământ valabil	Scăzută	Medie	Scăzut-mediu
R5	Platforma publicitară primește date identificabile (adresa IP și user agent-ul brute, transmise alături de hash-uri; adecvarea hash-ului în jurisprudența CJUE)	Ridicată	Ridicată	Ridicat
R6	Furtul token-ului din aplicația mobilă (compromiterea Keychain/EncryptedSharedPreferences)	Foarte scăzută	Medie	Scăzut
R7	Consimțământul pentru notificări push nerespectat (retragerea neaplicată la momentul trimiterii)	Scăzută	Medie	Scăzut-mediu
R8	Eșecul fluxului de ștergere GDPR (ștergere incompletă, documentată)	Ridicată	Ridicată	Ridicat
R9	Încălcarea securității datelor la un subîmputernicit (nouă destinatari ai datelor participanților; acorduri restante cu patru dintre ei)	Scăzută	Ridicată	Mediu
R10	Retenția datelor comportamentale dincolo de durata relației cu Clientul	Ridicată	Medie	Mediu-ridicat
R11	Retenția pe termen nelimitat a conținutului sesiunilor live (textul mesajelor din chat, numele afișate ale participanților, prezența, voturile), lizibil de orice utilizator autentificat	Ridicată	Ridicată	Ridicat
R12	Încărcarea de conținut terț pe paginile de destinație și pe pagina de vizionare a participantului înainte de decizia privind consimțământul sau independent de aceasta, cu eliminarea controalelor de consimțământ de pe pagina de vizionare	Ridicată	Medie	Mediu-ridicat
R13	Ocolirea condiției de consimțământ de marketing, operată de personal, și exportul în masă al datelor de contact în clar	Medie	Ridicată	Ridicat
R14	Moderarea automată a conținutului de chat al participanților fără informarea persoanei vizate	Medie	Medie	Mediu
R15	Transferul testimonialelor participanților către un furnizor de AI din SUA, fără informare, fără condiție de consimțământ și fără a fi atinse de fluxul de ștergere	Medie	Medie	Mediu
R16	Afișarea către participanți a unui număr de participanți fabricat	Medie	Medie	Mediu
R17	Date cu caracter personal și acreditări consemnate în jurnalele de cereri ale furnizorului și în jurnalele de aplicație, pe calea SMS	Ridicată	Medie	Mediu-ridicat
R18	Slăbiciuni ale căii de autentificare a participanților și din aplicația mobilă (cod de unică folosință de 4 cifre, acreditare demonstrativă permanentă pentru analiza din magazinele de aplicații)	Medie	Ridicată	Ridicat

4.2 Detalii privind Riscurile

R1 — Acces neautorizat la datele cu caracter personal: Atacatori care vizează Firestore sau PostgreSQL pentru a extrage adresele de e-mail și numele participanților.

Atenuări: reguli de securitate Firebase, Row Level Security în PostgreSQL, autentificare API (Firebase JWT), rețea privată Railway, criptare la repaus.
Rezervă: regulile de securitate Firebase constituie numai un control parțial. Astfel cum se consemnează la R2, regula Firestore care guvernează documentele cu datele cu caracter personal ale contactelor admite orice principal autentificat, documentele de înregistrare pot fi citite fără autentificare, regulile Realtime Database autorizează exclusiv pe baza atributului role din token, iar regulile Cloud Storage acordă acces public necondiționat de citire pe fiecare dintre căile de organizație. Extragerea avută în vedere de prezentul risc nu impune, pentru aceste depozite, ca atacatorul să înfrângă vreun control.

R2 — Scurgere de date între organizații: Datele unui Client devin vizibile pentru altul. Izolarea datelor la nivel de organizație este impusă în PostgreSQL. Ea nu este impusă nici în Realtime Database, nici în regulile Firestore care guvernează documentele cu datele cu caracter personal ale contactelor și documentele de înregistrare, nici în Cloud Storage.

Control existent — PostgreSQL. Izolarea datelor la nivel de organizație în PostgreSQL este impusă prin Row Level Security. Treizeci și două dintre cele treizeci și trei de tabele au o coloană org_id și au Row Level Security activat, cu o politică ce restrânge atât citirile, cât și inserările la rândurile al căror org_id corespunde identificatorului de organizație stabilit pe conexiune; singura excepție este jurnalul rulărilor de joburi ale planificatorului, comun întregii platforme, care nu conține date cu caracter personal. Identificatorul organizației este stabilit prin SET LOCAL, în interiorul unei tranzacții, la începutul fiecărei cereri, iar aplicația se conectează printr-un rol dedicat, fără privilegii de superutilizator, căruia Row Level Security i se aplică. În producție, API-ul refuză să pornească dacă acel șir de conexiune dedicat lipsește, astfel încât calea cererilor nu poate reveni la conexiunea privilegiată.
Limitele reziduale ale controlului din PostgreSQL. Row Level Security este activat, dar nu forțat. Proprietarul unui tabel sau o conexiune de superutilizator nu se supune politicilor, așa că izolarea depinde de menținerea conectării aplicației prin rolul restricționat. Anumite căi publice de cerere folosesc deliberat conexiunea privilegiată, deoarece trebuie să rezolve un token opac înainte de a cunoaște organizația: căutarea token-ului de distribuire, căutarea token-ului de urmărire al unui funnel, căutarea pasului de funnel și a vizualizării de pagină și căutarea secretului de webhook al funnel-ului. Row Level Security nu oferă nicio plasă de siguranță pentru aceste interogări. Identificatorul organizației este interpolat în instrucțiunea SET LOCAL sub formă de șir de caractere, nu este legat ca parametru; în funcționarea normală provine dintr-un atribut de token verificat, însă pe calea de autentificare de serviciu și pe cea auxiliară de dezvoltare provine dintr-un antet furnizat de apelant. În stratul de bază de date există funcții auxiliare pentru un context administrativ de ocolire, însă acestea nu sunt utilizate, iar nicio politică din vreo migrare nu face referire la variabila de sesiune pe care o stabilesc, așa că nu conferă nimic — prin urmare, nu există nicio ocolire a Row Level Security la nivel de aplicație. Rolul dedicat de bază de date este creat în afara setului de migrări, astfel încât controlul nu poate fi reprodus și nici verificat exclusiv din depozitul de cod.
Control absent — Realtime Database. 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ă. Identificatorii de sesiune sunt furnizați de un endpoint public, neautentificat.
Control absent — datele cu caracter personal ale contactelor și documentele de înregistrare din Firestore. Documentul de la orgs/{orgId}/contacts/{emailHash}/pii/private, care conține adresa de e-mail în clar, numele și numărul de telefon ale contactului, poate fi citit de orice utilizator Firebase autentificat — inclusiv de orice participant web anonim și de orice utilizator mobil cu adresa de e-mail verificată, din orice organizație — cu condiția să cunoască identificatorul organizației și hash-ul adresei de e-mail. Hash-ul este un SHA-256 fără sare criptografică, calculat pe adresa convertită în minuscule și lipsită de spațiile de la capete, astfel încât calea documentului poate fi determinată direct de oricine cunoaște adresa persoanei vizate. Listarea colecției rămâne rezervată personalului organizației proprietare. Documentele de înregistrare pot fi citite fără autentificare, ceea ce expune starea înregistrării, hash-ul adresei de e-mail, marcajul temporal al înregistrării și metadatele acesteia; regula acordă read, ceea ce acoperă atât citirea individuală, cât și listarea colecției, în pofida unui comentariu din fișierul de reguli potrivit căruia listarea ar necesita calitatea de membru al personalului.
Control absent — Cloud Storage. 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.
Corectarea unei atenuări afirmate anterior. Nu este adevărat că toate rutele API impun middleware-ul AuthRequired(). Două grupuri de rute îl poartă; rutele publice de înregistrare, de urmărire, de distribuire și de configurare sunt neautentificate prin proiectare.

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

Prezenta DPIA arăta anterior că izolarea între organizații se întemeiază pe patru straturi — o coloană de organizație pe fiecare tabel, Row Level Security, middleware de autentificare pe toate rutele API și utilizatori de bază de date separați — și evalua riscul rezidual drept foarte scăzut. Trei dintre cele patru nu sunt prezente în forma descrisă: regulile Realtime Database nu conțin niciun identificator de organizație; regulile Firestore expun datele cu caracter personal ale contactelor oricărui principal autentificat, iar documentele de înregistrare, oricărui apelant neautentificat; regulile Cloud Storage acordă acces public necondiționat de citire pe fiecare dintre căile de organizație; iar middleware-ul de autentificare este aplicat pe două grupuri de rute, nu pe toate rutele. Izolarea la nivel de organizație în PostgreSQL, descrisă mai sus, nu este afectată. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R3 — Profilare excesivă: Date comportamentale utilizate în scopuri dincolo de cele declarate (de exemplu, vândute unor terți ori folosite pentru decizii automate, fără informare).

Atenuări: scopul prelucrării este documentat în ROPA și în Politica de Confidențialitate; [PLATFORM PROVIDER] nu efectuează nicio profilare între Clienți; datele comportamentale din PostgreSQL sunt accesibile numai organizației-Client care le-a colectat, prin efectul Row Level Security.
Rezervă: limitarea accesului este valabilă numai pentru PostgreSQL. Astfel cum se consemnează la R2, conținutul comportamental al sesiunilor live din Realtime Database nu face obiectul niciunei verificări de organizație, așa încât poate fi citit cu token-uri cu rol de personal aparținând altor organizații. Aceasta constituie mai degrabă o expunere a confidențialității decât o profilare, dar înlătură limitarea pe care se întemeia, fără nicio rezervă, atenuarea afirmată anterior.

R4 — Urmărire comportamentală fără consimțământ valabil: Cloud Functions înregistrează evenimente comportamentale pentru participanți care nu au acordat consimțământul behavioral_tracking.

Atenuări: o verificare a consimțământului comportamental este aplicată în fiecare Cloud Function de eveniment comportamental; consimțământul este stocat în Firestore și citit la momentul evenimentului; evidențele de consimțământ sunt auditabile.
Domeniul de aplicare al atenuării: verificarea suprimă numai rândurile granulare de evenimente comportamentale scrise în baza de date analitică. Conținutul sesiunilor live și sincronizarea participării nu sunt afectate — a se vedea Secțiunea 3.4 —, iar endpoint-ul de ingestie al serviciului nu reverifică în mod independent această condiție. Valabilitatea consimțământului însuși este calificată prin nota privind mecanica consimțământului din Secțiunea 3.1.

R5 — Platforma publicitară primește date identificabile: Datele transmise către Meta și TikTok permit reidentificarea persoanei vizate. Google Ads și LinkedIn nu primesc date de pe server, întrucât niciuna dintre cele două integrări nu este implementată.

Atenuări: câmpurile direct identificatoare care se transmit — adresa de e-mail, prenumele și numele — sunt transformate în hash SHA-256 înainte de transmitere, iar transformarea în hash este unidirecțională; nu se transmite niciun număr de telefon. Identificatorul înregistrării este transformat în hash pentru TikTok, dar este transmis către Meta în formă brută. Evenimentele de pe server sunt suprimate pentru contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR.
Limitele atenuării: nu există nicio condiție de consimțământ publicitar nici pe evenimentele de pe server, nici pe pixelii client-side, iar adresa IP brută și user agent-ul brut sunt transmise, fără a fi transformate în hash, alături de acestea, astfel încât transferul nu se limitează la date pseudonimizate.
Google Consent Mode v2: semnalul de consimțământ cu refuz implicit este implementat corect, însă se aplică numai containerului Google Tag Manager și numai acolo unde Clientul a configurat unul. Acolo unde nu este configurat niciun container, nu există niciun semnal de consimțământ care să fie refuzat implicit. Meta Pixel, TikTok Pixel și Microsoft Clarity sunt injectate direct de grupul de scripturi condiționate de consimțământ, din setările de integrare ale organizației, complet în afara Google Tag Manager și în afara Consent Mode. Fonturile Google de pe paginile de destinație generate cu AI nu se încarcă de la Google în browserul vizitatorului: prompturile de generare instruiesc modelul să emită link-ul către foaia de stil, iar aplicația publică îl rescrie către domeniul propriu al paginii și preia fonturile pe partea de server, astfel încât adresele IP și user agent-urile vizitatorilor nu ajung la Google. Aplicațiile Next.js proprii platformei își găzduiesc local fonturile.

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

Prezenta DPIA arăta anterior că datele de conversie de pe server se transmit numai acolo unde a fost acordat consimțământul pentru categoria publicitară de cookie-uri, că nu se transmit date cu caracter personal în clar și că Google Tag Manager, împreună cu Consent Mode v2, asigură neactivarea niciunui serviciu Google în lipsa unui consimțământ explicit. Pe nicio cale de conversie nu există o condiție de consimțământ publicitar, adresele IP și user agent-urile brute sunt transmise și Consent Mode guvernează numai containerul Google Tag Manager acolo unde există unul configurat. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R6 — Furtul token-ului din aplicația mobilă: Atacatorul extrage token-ul JWT Firebase Auth de pe un dispozitiv compromis.

Atenuări: token-ul JWT este stocat în iOS Keychain / Android EncryptedSharedPreferences (protejat de sistemul de operare); expirarea într-o oră limitează fereastra de atac; autentificarea prin link magic evită complet stocarea parolei; endpoint-urilor de autentificare li se aplică o limită de cereri.
Corectarea cifrelor privind limita de cereri: limita de cereri se aplică per adresă IP sau per utilizator autentificat, acolo unde există unul — niciodată per adresă de e-mail. Limitele configurate sunt: trimiterea link-ului 10 cereri pe minut, cu vârf de 3; verificarea link-ului 10 pe minut, cu vârf de 5; verificarea codului 10 pe minut, cu vârf de 5; reînnoirea 30 pe minut, cu vârf de 5. Limitatorul își ține contoarele în memoria procesului, astfel încât limitele se aplică per instanță de API, iar nu la nivelul întregii implementări; adresa clientului pe care o folosește drept cheie este preluată dintr-un antet furnizat de proxy.
Al doilea factor de autentificare, neevaluat anterior: un cod numeric de unică folosință, format din 4 cifre și transmis prin e-mail, este disponibil ca alternativă la link-ul magic. Codul are zece mii de valori posibile, este valabil 10 minute și este invalidat după 3 încercări eșuate. Fiind stabilită per cont, limita de încercări constituie controlul efectiv; limitele de cereri per adresă IP arătate mai sus nu îndeplinesc acest rol.
A se vedea R18 pentru acreditarea demonstrativă permanentă, destinată analizei din magazinele de aplicații, aflată pe aceeași cale de autentificare.

R7 — Consimțământul pentru push nerespectat: O notificare push ajunge la o persoană vizată după ce aceasta a retras consimțământul relevant.

Control existent: consimțământul este verificat pe server înainte de fiecare trimitere. Fiecare expediere push impune o evidență de consimțământ push_notifications acordat și neretras, citită din registrul consimțămintelor la momentul trimiterii, astfel încât o retragere produce efecte la următoarea trimitere, fără nicio dependență de sincronizarea de pe dispozitiv. Notificările push de marketing nu sunt implementate, așa încât scenariul de marketing după retragere, descris în versiunea anterioară, nu se poate produce.
Corectarea unor atenuări afirmate anterior: notificarea push silențioasă de sincronizare nu este declanșată de retragerea consimțământului. Ea este transmisă în două situații: la prelucrarea unei cereri de ștergere și la aplicarea unei restricționări a prelucrării. De asemenea, token-ul FCM nu este șters la retragerea consimțământului: token-urile de dispozitiv sunt eliminate de fluxul de ștergere, la cererea proprie a participantului din aplicația mobilă și prin curățarea token-urilor pe care serviciul de mesagerie le raportează ca fiind invalide.

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

Prezenta DPIA arăta anterior că o notificare push silențioasă este transmisă aplicației mobile ori de câte ori se retrage consimțământul și că token-ul de dispozitiv este șters la retragerea explicită. Niciunul dintre aceste mecanisme nu este legat de retragerea consimțământului: sincronizarea silențioasă se declanșează numai la ștergere și la restricționarea prelucrării, iar token-urile sunt eliminate numai prin ștergere, la cererea proprie a participantului sau prin curățarea token-urilor invalide. Verificarea consimțământului la momentul trimiterii, care este controlul ce previne efectiv riscul, era prezentată drept una dintre trei atenuări. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R8 — Eșecul fluxului de ștergere GDPR: Date cu caracter personal care supraviețuiesc unei cereri de ștergere. Anterior, situația era prezentată drept posibilitatea ca o eroare de program să lase evidențe orfane; caracterul incomplet expus mai jos este sistematic, iar nu accidental, și se produce la fiecare ștergere căreia i se aplică.

Atenuări: ștergeri în cascadă pe tabelul contactelor; ștergeri explicite pentru email_sends, push_sends, device_tokens și funnel_entries, după organizație și după hash-ul adresei de e-mail; etapele de ștergere sunt jurnalizate; fluxul poate fi executat de Client din tabloul de bord.
Descrierea „flux de ștergere testat" se retrage. Acoperirea automată cu teste din API se limitează la cinci fișiere de teste unitare, care acoperă handlerele de urmărire a e-mailurilor, utilitarele de e-mail, redirecționările prin link-uri urmărite și funcțiile auxiliare pentru pagini. Niciun test automat nu acoperă fluxul de ștergere, autentificarea, autorizarea, Row Level Security sau izolarea datelor la nivel de organizație și niciun test nu simulează o interogare între organizații.
Caracterul incomplet cunoscut al fluxului; fiecare element a fost verificat în raport cu implementarea actuală:
- 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.
- Markerii de deduplicare per actor și numărul de mesaje per actor din Realtime Database nu se numără printre nodurile pe care le elimină curățarea per actor.
- Se păstrează un singur identificator de actor per înregistrare, astfel încât, atunci când un participant s-a alăturat de pe mai multe dispozitive ori a revenit sub un nou identificator de actor, mesajele din chat, numele afișat și voturile asociate identificatorilor anteriori supraviețuiesc ștergerii.
- Atunci când un contact își schimbă adresa de e-mail din pagina de preferințe, cererea de ștergere este creată în raport cu hash-ul adresei anterioare, după ce acel hash a fost deja actualizat, astfel încât fluxul nu găsește niciun contact corespunzător, consemnează cererea drept finalizată și nu șterge nimic.
- Ștergerea nu ajunge la Cloud Storage: fluxul nu șterge niciun obiect din bucket.
- Ș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.
- 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.
- Memoria cache în proces, cu datele de contact în clar, descrisă în Secțiunea 3.4, este invalidată numai în instanța de API care efectuează ștergerea.

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

Prezenta DPIA descria anterior fluxul de ștergere drept testat și complet, cu excepția posibilității ca o eroare de program să lase evidențe orfane. Fluxul nu are nicio acoperire automată cu teste, iar șase categorii de date cu caracter personal supraviețuiesc, în mod cunoscut, unei ștergeri în temeiul art. 17 GDPR: evidențele de livrare a SMS-urilor, evidențele destinatarilor difuzărilor către segmente, anumite date de sesiune live per actor, datele de sesiune live păstrate sub un al doilea identificator de actor, obiectele din Cloud Storage și intrările din jurnalul de audit care consemnează hash-ul adresei de e-mail a persoanei vizate. O ștergere solicitată după schimbarea adresei de e-mail nu elimină absolut nimic. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R9 — Încălcarea securității datelor la un subîmputernicit: Un subîmputernicit suferă o încălcare a securității datelor care afectează datele clienților [PLATFORM PROVIDER]. Expunerea depășește cei doi furnizori menționați anterior: date cu caracter personal ale participanților sunt deținute sau primite de Google LLC, Railway Corp., NewsmanApp SRL, Cloudflare, Inc., Meta Platforms, Inc., TikTok Pte. Ltd., Microsoft Corporation, SendSMS.ro și Anthropic PBC.

Atenuări: Google LLC și Railway Corp. mențin programe mature de securitate (SOC 2, ISO 27001), iar Google Cloud Data Processing and Security Terms prevăd o obligație de notificare a încălcărilor de securitate; [PLATFORM PROVIDER] menține un plan de răspuns la încălcările securității datelor (data-breach-response-plan.md).
Limitele atenuării: nu există un acord de prelucrare a datelor la dosar pentru fiecare subîmputernicit. Acordurile și, acolo unde este cazul, mecanismele de transfer urmează să fie încheiate cu Railway Corp., TikTok Pte. Ltd., SendSMS.ro și Anthropic PBC. Începând cu 8 mai 2026, TikTok Events API transmite identificatori de contact sub formă de hash împreună cu adrese IP și user agent-uri brute, fără un acord încheiat la dosar. A se vedea Anexa III (annex-sub-processors.md) pentru stadiul actual al fiecăruia.

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

Prezenta DPIA identifica anterior expunerea la încălcări ale securității datelor la subîmputerniciți drept limitată la Google și Railway și arăta că sunt în vigoare acorduri de prelucrare a datelor cu obligații de notificare a încălcărilor. Nouă subîmputerniciți primesc date cu caracter personal ale participanților, iar acordurile urmează să fie încheiate cu Railway Corp., TikTok Pte. Ltd., SendSMS.ro și Anthropic PBC. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R10 — Date reținute dincolo de durata relației: Datele participanților nu sunt șterse după împlinirea perioadei de retenție ori după ce Clientul își reziliază abonamentul la [PLATFORM PROVIDER].

Atenuări: o politică de retenție a datelor este documentată; ștergerea inițiată de Client este disponibilă din tabloul de bord; ștergerea datelor la încetarea organizației este guvernată de Secțiunea 10 din DPA (Ștergerea și Restituirea Datelor cu Caracter Personal).
Afirmația potrivit căreia joburile programate impun perioadele de retenție se retrage în forma sa necalificată. 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. În consecință, în prezent nu are loc nicio ștergere în funcție de vechime pentru nicio organizație.
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.
Retenția rotativă de 60 de zile a token-urilor push mobile, descrisă în versiunile anterioare, nu există ca perioadă efectiv impusă. Cele 60 de zile reprezintă o valoare implicită afișată pe ecranul de setări pentru retenție — un ecran care nu poate salva.
Tipuri de date aflate cu totul în afara acțiunii jobului: tabelul vizualizărilor de pagină ale funnel-urilor, jurnalul de audit, registrul cererilor persoanelor vizate, datele sesiunilor live din Realtime Database (a se vedea R11) și obiectele din Cloud Storage. 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.

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

Prezenta DPIA arăta anterior că joburile programate ale [PLATFORM PROVIDER] impun perioadele de retenție și că token-urile push mobile fac obiectul unei retenții rotative impuse, de 60 de zile. Nu este preconfigurată nicio politică de retenție implicită, ecranul de setări transmite tipuri de date pe care API-ul le respinge, astfel încât nicio politică nu poate fi salvată, iar cifra de 60 de zile este o valoare implicită nesalvată. În prezent nu are loc nicio ștergere în funcție de vechime. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

R11 — Retenția pe termen nelimitat a conținutului sesiunilor live: 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 se acumulează fără limită în Realtime Database, rămânând totodată larg accesibile la citire.

Situația de astăzi: 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.
Factor agravant: astfel cum se consemnează la R2, fluxul de chat și directorul de actori — care conține numele afișate ale participanților — pot fi citite de orice utilizator autentificat, iar orice alt nod live poate fi citit cu un token cu rol de personal din orice organizație. Cele două expuneri se combină: o evidență păstrată pe termen nelimitat a ceea ce a spus fiecare participant identificat prin nume, lizibilă cu mult dincolo de organizația care a colectat-o.
Evaluare: aceasta este o chestiune de limitare a stocării în temeiul art. 5 alin. (1) lit. (e) GDPR. Pentru această categorie nu a fost stabilită nicio perioadă de retenție și nu este impusă niciuna.
Atenuări: niciuna automată. Ștergerea manuală a sesiunii sau a webinarului este singura metodă.

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

Versiunile anterioare ale prezentei DPIA și ale politicii de retenție 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.

R12 — Încărcarea de conținut terț înainte de decizia privind consimțământul sau independent de aceasta: Scripturi, resurse și conținuturi încorporate ale unor terți transmit adresa IP a vizitatorului, user agent-ul și contextul paginii înainte ca acesta să fi făcut o alegere privind cookie-urile ori pe pagini unde nu se poate face nicio alegere.

Pixeli publicitari: pixelii Meta și TikTok sunt clasificați ca necesari și transmit o vizualizare de pagină înainte de orice decizie privind consimțământul, într-o stare de consimțământ reținut, fără cookie-uri (fbq('consent','revoke') / ttq.holdConsent()); adresa IP, user agent-ul și URL-ul paginii ajung totuși la Meta și la TikTok anterior consimțământului. Legalitatea în temeiul art. 5 alin. (3) ePrivacy nu este stabilită — a se vedea caseta DEFICIENȚĂ CUNOSCUTĂ. Grupul de scripturi condiționate de consimțământ încarcă întregul set strict necesar imediat la inițializare, înainte de a citi cookie-ul de consimțământ stocat și înainte de afișarea bannerului, și nu reverifică acel set atunci când vizitatorul alege „Doar necesare".
Conținut video încorporat: pagina de vizionare a participantului încorporează fluxul într-un iframe www.youtube.com — nu în varianta fără cookie-uri —, fără nicio condiție de consimțământ și fără un substituent care să impună un click pentru încărcare, astfel încât un webinar găzduit pe YouTube transmite către Google adresa IP a participantului, user agent-ul și comportamentul de vizionare și setează cookie-uri Google pe durata sesiunii. URL-ul de redare este furnizat de organizație, așa încât un alt furnizor terț de găzduire video poate fi încorporat în același mod.
Controalele de consimțământ eliminate de pe pagina de vizionare: pe pagina de vizionare live, bannerul de cookie-uri și butonul flotant pentru setările cookie-urilor sunt suprimate, pe considerentul că participanților li s-au prezentat deja opțiunile privind consimțământul la înregistrare. Prin urmare, vizitatorul care deschide direct o pagină de vizionare nu primește nicio solicitare privind cookie-urile pe acea pagină și nu își poate modifica sau retrage preferințele din ea; scripturile clasificate ca strict necesare, inclusiv pixelii Meta și TikTok, se încarcă în continuare. Art. 7 alin. (3) GDPR impune ca retragerea consimțământului să fie la fel de simplă ca acordarea lui, iar participanții petrec cea mai mare parte a timpului pe această pagină.
Retragerea nu elimină cookie-urile deja plasate. Retragerea consimțământului oprește utilizarea ulterioară a serviciilor de publicitate și de analiză, dar nu șterge cookie-urile deja plasate pe dispozitiv. La retragerea consimțământului, platforma aplică excluderea (opt-out) pentru Microsoft Clarity, readuce pixelii Meta și TikTok în starea de consimțământ reținut și reîncarcă pagina; cookie-uri precum _fbp, _fbc, _ttp, _ga și _clck rămân în browserul vizitatorului până la expirarea lor naturală sau până când acesta le șterge.
Atenuări: Microsoft Clarity este încadrat corect la categoria de analiză, se încarcă numai după acordarea consimțământului pentru analiză și este omis complet în aplicația pentru participanți. Pixelii sunt menținuți într-o stare fără cookie-uri până la acordarea consimțământului publicitar. Fonturile Google de pe paginile de destinație generate sunt livrate de pe domeniul propriu al paginii și preluate pe partea de server, astfel încât nu mai ajung la Google din browserul vizitatorului.

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

Prezenta DPIA nu conținea anterior niciun risc privind încărcarea de conținut terț înaintea deciziei privind consimțământul și arăta că scripturile publicitare se încarcă numai după acordarea consimțământului. Pixelii publicitari și un player video terț încorporat se încarcă înainte de alegerea vizitatorului sau independent de aceasta, iar bannerul de cookie-uri și butonul de setări sunt eliminate cu totul de pe pagina de vizionare a participantului. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

R13 — Ocolirea condiției de consimțământ de marketing, operată de personal: Personalul Clientului folosește funcționalități din produs pentru a ajunge la contacte care nu dețin niciun consimțământ de marketing ori exportă date de contact în clar, în afara controalelor de suprimare și de retenție ale platformei.

Natura expunerii: astfel cum se arată în nota privind căile de ocolire operate de personal din Secțiunea 3.1, difuzarea tranzacțională către segmente nu este condiționată de consimțământul de marketing, o condiție de segmentare lacks_consent selectează exact contactele care nu dețin nicio acordare, iar exportul de segmente returnează adrese de e-mail și nume în clar, fără nicio condiție de consimțământ, și poate include opțional contactele care au înregistrat un bounce, au reclamat spam sau s-au dezabonat global. Contactele dezabonate sunt întotdeauna prezente în exportul implicit.
Atenuări: o restricționare a prelucrării în temeiul art. 18 GDPR exclude contactul din toate cele trei; indicatorul de suprimare a e-mailului exclude din difuzare contactele care au înregistrat un bounce sau o reclamație; fiecare acțiune este consemnată în jurnalul de audit, împreună cu utilizatorul care acționează, adresa IP și user agent-ul. Toate cele trei sunt disponibile rolului neadministrativ marketer.
Evaluare: dacă o anumită trimitere constituie un mesaj de serviciu ori marketing direct se stabilește de Client în calitate de Operator, la fiecare trimitere. Acolo unde constituie marketing direct, devin aplicabile art. 13 din Directiva 2002/58/CE (ePrivacy) și art. 12 din Legea nr. 506/2004, iar platforma nu oferă niciun control tehnic care să împiedice trimiterea. Datele de contact exportate, odată ieșite din platformă, se află în afara acțiunii retragerilor, suprimărilor, ștergerilor și politicilor de retenție ulterioare.

R14 — Moderarea automată a conținutului de chat al participanților: Mesajele participanților sunt evaluate, modificate sau eliminate automat, fără știrea acestora.

Natura prelucrării: o Cloud Function verifică fiecare mesaj de chat în raport cu o listă de cuvinte interzise, stabilită per sesiune. Potrivirile simple sunt mascate pe loc, în mesajul deja transmis de participant. Atunci când, după mascare, rămâne o scriere ofuscată, mesajul este eliminat din flux, iar textul integral original, împreună cu datele de actor ale autorului și cu un motiv al eliminării, este scris într-un nod al mesajelor eliminate, accesibil personalului. Participantul nu este informat în niciuna dintre cele două situații, iar mesajul pare în continuare a fi fost transmis. Un script de întreținere aplică aceeași logică, retroactiv, mesajelor deja transmise.
Retenție: mesajele eliminate sunt păstrate pe termen nelimitat în nodul mesajelor eliminate, în aceleași condiții ca restul datelor sesiunilor live, evaluate la R11.
Atenuări: lista de cuvinte nu poate fi citită de client; prelucrarea se limitează la textul publicat de participant într-o sesiune; nu se ia nicio decizie automată care să producă efecte juridice sau efecte similare semnificative.
Evaluare: lipsa informării este aspectul esențial în raport cu art. 12–14 GDPR, alături de aplicarea retroactivă asupra mesajelor transmise înainte de existența funcționalității. Termenii și Condițiile Clientului ar trebui să menționeze că mesajele pot fi modificate sau eliminate în mod automat.

R15 — Transferul testimonialelor participanților către un furnizor de AI: Testimonialele participanților sunt transmise către Anthropic PBC, în SUA, ca parte a unui prompt de generare cu AI.

Natura prelucrării: testimonialele aprobate — numele afișat al participantului, citatul său în format liber, compania și nota acordată — sunt inserate în promptul de generare folosit pentru textele și codul HTML ale paginilor de destinație. Aceasta este singura categorie de date cu caracter personal ale participanților care ajunge la Anthropic. Se mai transmit denumirea organizației, detaliile webinarului, instrucțiunile personalului, imaginile de referință încărcate de personal și textul extras din URL-uri de referință furnizate de personal. Nu se transmit: conținutul mesajelor din chat, evidențele de înregistrare, adresele de e-mail ale contactelor, numerele de telefon, răspunsurile la sondaje și evenimentele comportamentale.
Transfer: SUA. ⚠️ Mecanismul de transfer trebuie confirmat și consemnat; a se vedea R9 și Anexa III.
Atenuări: exclusiv pe partea de server — niciun dispozitiv al participanților nu contactează Anthropic și nu se setează niciun cookie. Testimonialele sunt transmise din proprie inițiativă de către participant și sunt aprobate de personal înainte de publicare.
Limite: nu există nicio condiție de consimțământ și nicio informare a autorului testimonialului cu privire la prelucrarea cu AI. Evidențele de generare stocate — promptul de sistem, promptul utilizatorului, instrucțiunile personalului, modelul, rezultatul integral și numărul de token-uri, împreună cu identificatorul membrului personalului care a inițiat generarea — nu sunt asociate unei fișe de contact și, prin urmare, nu sunt atinse de fluxul de ștergere, astfel încât citatul unui testimonial și numele autorului său persistă în promptul stocat după ștergerea contactului respectiv. Anthropic este angajat pe baza unei singure acreditări la nivel de platformă, așa încât Clientul nu poate dezactiva prelucrarea; a se vedea Secțiunea 1.3.

R16 — Număr de participanți fabricat, afișat participanților: Participanților li se afișează o cifră privind numărul de participanți care nu corespunde numărului de persoane prezente în realitate.

Natura prelucrării: acolo unde Clientul activează funcționalitatea, numărul afișat de participanți se calculează ca sumă între o bază configurată și numărul real de prezenți, înmulțit cu un factor configurat, cu o mică variație aleatorie aplicată în fiecare minut, astfel încât cifra să evolueze asemenea unui trafic organic. Interfața participantului afișează acea cifră alături de un indicator de transmisiune live. Regulile Realtime Database expun participanților numai cifra afișată; numărul real și lista de prezență sunt rezervate personalului, astfel încât un participant nu poate vedea numărul real. Panoul personalului afișează numărul real alături de cel prezentat participanților.
Evaluare: aceasta nu privește securitatea datelor cu caracter personal, ci caracterul echitabil al prelucrării în temeiul art. 5 alin. (1) lit. (a) GDPR, care impune ca datele cu caracter personal să fie prelucrate în mod echitabil și transparent față de persoana vizată. Atunci când o cifră fabricată privind audiența este folosită pentru a determina o înregistrare sau o achiziție, pot deveni incidente și Directiva 2005/29/CE privind practicile comerciale neloiale, inclusiv Anexa I la aceasta, precum și Legea nr. 363/2007.
⚠️ Determinare necesară: măsura în care [PLATFORM PROVIDER] permite Clienților să activeze această funcționalitate și condițiile în care o permite nu sunt stabilite în evidențele [PLATFORM PROVIDER]. Orice restricție adoptată ar trebui reflectată în prevederile privind utilizarea acceptabilă din Termenii și Condițiile SaaS, precum și în Ghidul de Conformitate pentru Clienți.

R17 — Date cu caracter personal și acreditări în jurnalele furnizorului și ale aplicației, pe calea SMS: Numărul de telefon al destinatarului, corpul mesajului și acreditările contului sunt consemnate în jurnale aflate în afara controlului [PLATFORM PROVIDER].

Natura expunerii: mesajele sunt transmise către SendSMS.ro printr-o cerere HTTP GET, prin TLS, cu toți parametrii — inclusiv numele de utilizator al contului, parola contului, numărul de telefon al destinatarului și textul mesajului — purtați în șirul de interogare. Parametrii din șirul de interogare sunt consemnați în mod obișnuit în jurnalele de acces ale serverelor web, așa încât aceste valori trebuie presupuse prezente în jurnalele furnizorului. Corpul mesajului conține titlul webinarului, timpul rămas și un URL urmărit, individualizat pentru fiecare destinatar.à r.l.) în calitate de destinatar ulterior și, în caz de revenire pe SMS, de operatorul de rețea mobilă al destinatarului. În plus, numărul de telefon este scris în jurnalul de aplicație atunci când o trimitere eșuează.
Atenuări: acreditările per organizație sunt păstrate în Google Secret Manager, iar în Firestore se stochează numai referința către secret; transportul se realizează prin TLS; un SMS este trimis numai dacă respectivul contact deține un consimțământ sms_notifications acordat și neretras și nu face obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR.
⚠️ Entitatea juridică ce contractează în spatele sendsms.ro, sediul său social și perioada sa de retenție pentru jurnalele de mesaje nu sunt documentate în evidențele [PLATFORM PROVIDER] și trebuie confirmate din contractul de servicii încheiat.

R18 — Slăbiciuni ale căii de autentificare a participanților și din aplicația mobilă: O persoană neautorizată obține o sesiune de participant și, odată cu ea, acces la înregistrarea, preferințele și datele de contact ale acelui participant.

Cod de unică folosință de 4 cifre: alternativa prin e-mail la link-ul magic emite un cod numeric de 4 cifre, cu zece mii de valori posibile, valabil 10 minute și invalidat după 3 încercări eșuate. Limita de încercări per cont constituie controlul efectiv; limitele de cereri consemnate la R6 sunt stabilite după adresa clientului, nu după cont.
Acreditare demonstrativă pentru analiza din magazinele de aplicații: o adresă de e-mail configurată poate fi autentificată cu un cod fix, care nu expiră, ocolind complet validarea codului stocat, inclusiv blocarea per cont. Comparația este exactă, pe adresa integrală, și se realizează în timp constant, astfel încât poate debloca numai acel unic cont, iar fiecare utilizare este scrisă în jurnalul de aplicație, la nivel de avertizare. Ea este destinată să fie prezentă în mediul de producție. Este o acreditare permanentă, fără expirare și fără un calendar de rotație, utilizarea sa nu produce nicio intrare în jurnalul de audit, iar adresa este scrisă în clar în jurnalul de aplicație.
Evaluare: acreditarea demonstrativă este o excepție deliberată și strict delimitată, iar nu un defect, însă constituie o ocolire permanentă a autentificării pentru un cont real din mediul de producție și, ca atare, își are locul în registrul riscurilor. Custodia și rotația sa nu sunt documentate.

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

Prezenta DPIA evalua anterior calea de autentificare din aplicația mobilă exclusiv drept o chestiune de furt al token-ului de pe un dispozitiv compromis și consemna o limită de trei cereri pe minut per adresă de e-mail. Limita de cereri se aplică per adresă a clientului și niciodată per adresă de e-mail; un cod de unică folosință de 4 cifre este disponibil ca alternativă la link-ul magic; iar o acreditare demonstrativă permanentă, destinată analizei din magazinele de aplicații, permite autentificarea unui cont configurat cu un cod fix, care nu expiră, în mediul de producție. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

5. Măsuri de Atenuare

5.1 Măsuri Tehnice

Măsură	Riscuri abordate
Row Level Security în PostgreSQL, cu `app.current_org_id`, pe 33 din 34 de tabele, impusă printr-un rol dedicat fără privilegii de superutilizator, cu o verificare la pornirea în producție care refuză pornirea pe conexiunea privilegiată	R1, R2
Nu este utilizată nicio ocolire a Row Level Security la nivel de aplicație: funcțiile auxiliare pentru contextul administrativ din stratul de bază de date nu sunt referite nicăieri, iar nicio politică nu consultă variabila de sesiune pe care o stabilesc	R2
Reguli de securitate Firebase (Firestore) care restrâng configurarea organizației, fișele utilizatorilor din personal, fișele de pagină, webinarele private, evidențele de consimțământ și subcolecția cu datele cu caracter personal ale înregistrărilor la membrii organizației proprietare și interzic orice acces al clienților la codurile de verificare și la link-urile magice. Ele nu restrâng documentele cu datele cu caracter personal ale contactelor și nici documentele de înregistrare — a se vedea Secțiunea 4.2 R2	R1, R2
⚠️ Regulile Realtime Database și Cloud Storage nu conțin nicio verificare de organizație și nu constituie un control de izolare a datelor la nivel de organizație — a se vedea Secțiunea 4.2 R2	—
Autentificare Firebase JWT pe grupurile de rute API ale tabloului de bord și ale aplicației pentru participanți. Rutele publice de înregistrare, de urmărire, de distribuire și de configurare sunt neautentificate prin proiectare	R1
Criptare la repaus (volume criptate Railway, criptare Firestore)	R1, R6, R9
Criptare în tranzit (TLS 1.2+ pe toate conexiunile)	R1, R9
Verificarea consimțământului comportamental în funcțiile de eveniment comportamental din Cloud Functions, care suprimă numai rândurile granulare de evenimente scrise în baza de date analitică	R4
Transformarea în hash SHA-256 a câmpurilor direct identificatoare înainte de transmiterea către platformele publicitare; adresa IP brută și user agent-ul brut sunt transmise alături de acestea	R5
Restricționarea prelucrării în temeiul art. 18 GDPR, aplicată ca restricție absolută asupra consimțământului, mesageriei, exporturilor, difuzărilor și evenimentelor de conversie de pe server	R5, R13
Token-ul JWT stocat în Keychain / EncryptedSharedPreferences	R6
Expirarea token-ului JWT într-o oră, cu reînnoire automată	R6
Limită de cereri pe endpoint-urile de autentificare a participanților, stabilită per adresă a clientului sau per utilizator autentificat — niciodată per adresă de e-mail: trimiterea link-ului 10/min, vârf 3; verificarea link-ului 10/min, vârf 5; verificarea codului 10/min, vârf 5; reînnoirea 30/min, vârf 5. Contoarele sunt ținute în memoria procesului, deci limitele se aplică per instanță de API	R6, R18
Cod de unică folosință de 4 cifre, transmis prin e-mail, invalidat după 3 încercări eșuate și după 10 minute	R18
Notificare push silențioasă de sincronizare la ștergere și la restricționarea prelucrării (nu la retragerea consimțământului)	R7
Verificarea consimțământului în registrul consimțămintelor, la momentul trimiterii, înaintea fiecărei expedieri push, SMS	R7
Flux de ștergere GDPR cu cascade și interogări explicite, cu lacunele documentate consemnate în Secțiunea 4.2 R8	R8
⚠️ Nu există nicio perioadă de retenție efectiv impusă pentru token-urile push mobile și nici pentru vreun alt tip de date, întrucât în prezent nicio politică de retenție nu poate fi salvată — a se vedea Secțiunea 4.2 R10	—
Google Consent Mode v2 cu refuz implicit, aplicat containerului Google Tag Manager acolo unde Clientul a configurat unul. El nu guvernează Meta Pixel, TikTok Pixel și nici Microsoft Clarity	R5, R12
Microsoft Clarity încadrat la categoria de analiză, încărcat numai după acordarea consimțământului pentru analiză și omis complet în aplicația pentru participanți	R12
Acreditări SMS per organizație, păstrate în Google Secret Manager, cu stocarea în Firestore numai a referinței către secret	R17
Jurnal de audit doar de adăugare: rolul de bază de date al aplicației deține numai privilegii de selectare și de inserare	R1, R3, R13

5.2 Măsuri Organizatorice

Măsură	Riscuri abordate
ROPA este menținut; revizuirea anuală este cadența avută în vedere, iar intervalul consemnat în Secțiunea 8 nu a fost respectat	R3, R10
Condiții de prelucrare a datelor în vigoare cu subîmputernicitul Google LLC. ⚠️ Acordurile și, acolo unde este cazul, mecanismele de transfer urmează să fie încheiate cu Railway Corp., TikTok Pte. Ltd., SendSMS.ro și Anthropic PBC	R9
Acord de Prelucrare a Datelor cu fiecare client	R3, R8
Jurnalizare de audit pe operațiunile de scriere din tabloul de bord, cu consemnarea utilizatorului care acționează, a rolului, a adresei IP și a user agent-ului	R1, R3, R13
Utilizatori de bază de date separați (rolul de aplicație, supus Row Level Security, față de rolul de superutilizator al planificatorului) pentru limitarea impactului. ⚠️ Rolul de aplicație este creat în afara setului de migrări, astfel încât controlul nu este reproductibil exclusiv din depozitul de cod	R2
Plan de răspuns la încălcările securității datelor, documentat	R9
Procedură DSAR pentru gestionarea cererilor de ștergere	R8
Accesul personalului la datele cu caracter personal, limitat la necesitățile operaționale. ⚠️ Există patru roluri de personal (`admin`, `moderator`, `marketer`, `staff`), iar orice acțiune distructivă, în afara listării jurnalului de audit, este disponibilă unui rol neadministrativ — a se vedea nota privind căile de ocolire operate de personal din Secțiunea 3.1	R1, R3, R13
Registrul de remediere a conformității, în care se consemnează fiecare neconcordanță marcată drept DEFICIENȚĂ CUNOSCUTĂ în prezentul document	Toate

6. Evaluarea Riscului Rezidual

#	Risc	Risc Rezidual	Acceptabil?
R1	Acces neautorizat la datele cu caracter personal	Scăzut-mediu	Sub rezerve — a se vedea Secțiunea 4.2 R1 și R2
R2	Scurgere de date între organizații	Ridicat	Nu — remediere în curs
R3	Profilare excesivă	Scăzut	Da
R4	Urmărire comportamentală fără consimțământ	Scăzut-mediu	Sub rezerve — a se vedea Secțiunea 4.2 R4 și nota privind mecanica consimțământului din Secțiunea 3.1
R5	Platforma publicitară primește date identificabile	Mediu-ridicat	Nu — remediere în curs
R6	Furtul token-ului mobil	Scăzut	Da
R7	Consimțământul pentru push nerespectat	Scăzut	Da
R8	Eșecul fluxului de ștergere	Mediu-ridicat	Nu — remediere în curs
R9	Încălcarea securității datelor la un subîmputernicit	Mediu	Nu — remediere în curs
R10	Supra-retenție	Ridicat	Nu — remediere în curs
R11	Retenția pe termen nelimitat a conținutului sesiunilor live	Ridicat	Nu — remediere în curs
R12	Încărcarea de conținut terț înainte de consimțământ sau independent de acesta	Mediu-ridicat	Nu — remediere în curs
R13	Ocolirea de către personal a condiției de consimțământ de marketing	Ridicat	Nu — remediere în curs
R14	Moderare automată fără informare	Mediu	Sub rezerve — a se vedea Secțiunea 4.2 R14
R15	Transferul testimonialelor către un furnizor de AI	Mediu	Nu — remediere în curs
R16	Număr de participanți fabricat	Mediu	⚠️ Determinare necesară — a se vedea Secțiunea 4.2 R16
R17	Date cu caracter personal și acreditări în jurnalele furnizorului	Mediu-ridicat	Nu — remediere în curs
R18	Slăbiciuni ale autentificării participanților și din aplicația mobilă	Mediu-ridicat	Nu — remediere în curs

Risc rezidual global: Ridicat. Evaluarea anterioară consemna fiecare risc drept rezidual scăzut și acceptabil. Acea concluzie se întemeia pe atenuări care, potrivit analizei consemnate în prezenta revizuire, nu sunt implementate în forma descrisă: izolarea datelor la nivel de organizație în afara PostgreSQL, aplicarea perioadelor de retenție, caracterul complet al fluxului de ștergere și o condiție de consimțământ pe pixelii publicitari. Acolo unde un control lipsește, în loc să fie doar imperfect, riscul inerent rămâne neschimbat și nu poate fi redus prin documentarea sa. Riscurile marcate mai sus cu „Nu — remediere în curs" sunt consemnate în registrul de remediere a conformității și nu sunt acceptate în starea lor actuală.

GAP-GOV-06 · PROCESS — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta DPIA concluziona anterior că toate riscurile identificate sunt atenuate la un nivel acceptabil și că riscul rezidual global este scăzut. Acel tabel a fost recalculat în raport cu platforma astfel cum este implementată, au fost adăugate încă opt riscuri, iar unsprezece riscuri sunt consemnate în prezent ca fiind neacceptate. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

7. Consultare

7.1 Consultare Internă

Rol	Contribuție
CTO / Director Inginerie	Măsuri tehnice, revizuirea arhitecturii
Juridic / DPO	Evaluarea temeiurilor juridice, proporționalitate, necesitate
Responsabil Securitate	Identificarea riscurilor, controale tehnice

7.2 Consultarea Autorității de Supraveghere

Necesară? ⚠️ Nu a fost determinată. Răspunsul anterior — potrivit căruia nu este necesară o consultare prealabilă cu autoritatea de supraveghere (ANSPDCP din România) — se întemeia pe tabelul riscurilor reziduale în forma anterioară prezentei revizuiri, în care fiecare risc era consemnat drept scăzut și acceptabil. Acel tabel a fost corectat în Secțiunea 6: mai multe dintre controalele pe care se sprijinea lipsesc, în loc să fie doar imperfecte, au fost adăugate încă opt riscuri, iar riscul rezidual global este evaluat în prezent drept ridicat.

Art. 36 alin. (1) GDPR impune consultarea prealabilă atunci când o evaluare a impactului asupra protecției datelor arată că prelucrarea ar genera un risc ridicat în lipsa unor măsuri luate de operator pentru atenuarea acestuia. Prin urmare, chestiunea trebuie reevaluată de Operator în raport cu tabelul corectat — fie după remedierea riscurilor marcate cu „Nu — remediere în curs" în Secțiunea 6, fie, acolo unde acestea nu pot fi remediate, pe tabelul în forma sa actuală. Raționamentul care susține concluzia la care se ajunge se consemnează în prezenta secțiune, iar nu numai concluzia.

Dacă modificările viitoare ale prelucrării cresc semnificativ riscul (de exemplu, luarea de decizii automate cu efecte juridice, prelucrarea datelor din categorii speciale), prezenta DPIA va fi actualizată, iar consultarea prealabilă va fi reevaluată.

GAP-GOV-06 · PROCESS — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta DPIA concluziona anterior că nu este necesară nicio consultare prealabilă cu autoritatea de supraveghere, pe considerentul că riscul rezidual este scăzut după atenuare. Tabelul riscurilor reziduale care susținea acea concluzie a fost corectat în Secțiunea 6 și consemnează în prezent un risc rezidual global ridicat, astfel încât chestiunea prevăzută de art. 36 alin. (1) GDPR se redeschide, iar în prezent nu este consemnată nicio concluzie. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

8. Ciclul de Revizuire

Prezenta DPIA trebuie revizuită:

Anual, ca revizuire de rutină
Când prelucrarea se modifică semnificativ — funcționalități noi, subîmputerniciți noi, activități noi cu risc ridicat, categorii noi de date
După un incident de securitate care relevă o lacună în evaluarea riscurilor
Când orientările autorității de supraveghere se modifică într-un mod care afectează analiza riscurilor

Evidența revizuirilor. Prezenta DPIA a fost revizuită la 4 septembrie 2026, în raport cu platforma astfel cum era atunci implementată. Evaluarea nu mai fusese revizuită din 27 martie 2026, deși mai multe dintre condițiile de declanșare arătate mai sus s-au îndeplinit în intervalul scurs. Modificările care ar fi trebuit să determine o revizuire includ: activarea TikTok Events API pe server; reclasificarea pixelilor Meta și TikTok drept scripturi necesare, care se încarcă înaintea deciziei privind consimțământul; introducerea unui transfer de vizualizare de pagină pe server, aplicabil fiecărui vizitator al unei pagini de destinație; adăugarea difuzărilor tranzacționale către segmente și a unei condiții de segmentare care selectează contactele lipsite de consimțământ; preluarea datelor privind achizițiile și comenzile din webhook-urile magazinelor de comerț electronic ale clienților; moderarea automată a chatului participanților; numărul simulat de participanți; generarea de conținut asistată de AI, cu Anthropic PBC în calitate de nou subîmputernicit; livrarea de SMS-uri, cu SendSMS.ro în calitate de nou subîmputernicit; precum și introducerea unei acreditări demonstrative permanente, destinate analizei din magazinele de aplicații, în mediul de producție.

În prezent, niciun proces nu impune revizuirea prezentei evaluări atunci când se introduce un subîmputernicit, un destinatar de date de urmărire, o categorie nouă de date sau o activitate nouă de prelucrare cu risc ridicat. Instituirea unui asemenea proces este o condiție pentru ca prezentul document să rămână o evidență exactă în temeiul art. 35 GDPR.

9. Aprobare

Rol	Nume	Dată	Semnătură
Responsabil cu protecția datelor (sau consilier desemnat)	[DPO Name]	[DATE]	_____________
CTO	[CTO Name]	[DATE]	_____________
CEO / Reprezentant Legal	[CEO Name]	[DATE]	_____________

Versiunea Documentului: 1.0 (DRAFT) Întocmit de: [Legal Team / Engineering] Stadiul Revizuirii: ⚠️ NECESITĂ REVIZUIRE JURIDICĂ — Trebuie revizuit și semnat de un DPO calificat sau de un consilier juridic specializat în GDPR înainte de desfășurarea în producție.

Ultima actualizare: [DATE] Următoarea revizuire: [DATE + 1 year] sau la o modificare semnificativă a prelucrării

Evaluarea Impactului asupra Protecției Datelor (DPIA) ​

1. Introducere și Domeniu de Aplicare ​

1.1 Scop ​

1.2 De Ce Este Necesară o DPIA ​

1.3 Domeniul de Aplicare al Prezentei DPIA ​

2. Descrierea Prelucrării ​

2.1 Natura Prelucrării ​

2.2 Scopul Prelucrării ​

2.3 Persoanele vizate ​

2.4 Categoriile de Date ​

3. Necesitate și Proporționalitate ​

3.1 Temeiuri Juridice ​

3.2 Testul de Echilibru al Interesului Legitim (Comunicări Tranzacționale) ​

3.3 Testul de Echilibru al Interesului Legitim (Urmărirea Conversiilor Publicitare pe Server) ​

3.4 Minimizarea Datelor ​

4. Identificarea Riscurilor ​

4.1 Registrul Riscurilor ​

4.2 Detalii privind Riscurile ​

5. Măsuri de Atenuare ​

5.1 Măsuri Tehnice ​

5.2 Măsuri Organizatorice ​

6. Evaluarea Riscului Rezidual ​

7. Consultare ​

7.1 Consultare Internă ​

7.2 Consultarea Autorității de Supraveghere ​

8. Ciclul de Revizuire ​

9. Aprobare ​