Registrul Activităților de Prelucrare (ROPA)

[PLATFORM PROVIDER] — Acționând în calitate de Persoană împuternicită de operatorArt. 30 alin. (2) din Regulamentul (UE) 2016/679 (GDPR)Ultima actualizare: [DATE]

---

Introducere

Prezentul Registru al Activităților de Prelucrare (ROPA) documentează categoriile de prelucrare a datelor cu caracter personal desfășurate de [PLATFORM PROVIDER] în calitate de Persoană împuternicită de operator în numele clienților săi (Operatorii de date).

Cerință legală: Art. 30 alin. (2) GDPR impune tuturor persoanelor împuternicite de operator să țină evidențe scrise ale categoriilor de prelucrare.

Disponibilitate: Prezentul ROPA este ținut intern și pus la dispoziția autorităților de supraveghere (ANSPDCP în România) la cerere. El este, suplimentar, publicat pe site-ul public de documentație juridică al [PLATFORM PROVIDER], care nu impune nicio autentificare.

Domeniu de aplicare și rol. Prezentul registru este o evidență a persoanei împuternicite, ținută în temeiul art. 30 alin. (2) GDPR. Două operațiuni de prelucrare din producție nu sunt, astfel cum sunt implementate, determinate de Client. Generarea de conținut asistată de AI rulează pe o unică acreditare la nivel de platformă, deținută de [PLATFORM PROVIDER]; furnizorul modelului, modelele și retenția prompturilor și a rezultatelor sunt alese de [PLATFORM PROVIDER], nu există nicio acreditare per organizație și niciun comutator per organizație (Activitatea de Prelucrare 7). Măsurarea publicitară pe server descrisă la Activitatea de Prelucrare 3 funcționează pe baza unei evaluări a interesului legitim, expusă în Evaluarea impactului asupra protecției datelor, iar nu pe baza unei instrucțiuni consemnate într-un Acord de Prelucrare a Datelor. Atunci când o persoană împuternicită determină scopurile și mijloacele prelucrării, art. 28 alin. (10) GDPR o tratează drept operator pentru acea prelucrare. Pentru niciuna dintre cele două operațiuni nu a fost întocmită nici evidența operatorului prevăzută de art. 30 alin. (1) GDPR, nici informarea prevăzută de art. 13 sau de art. 14 GDPR.

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

Prezentul Registru al Activităților de Prelucrare descria anterior [PLATFORM PROVIDER] drept persoană împuternicită de operator pentru fiecare operațiune pe care o efectuează, fără excepție. Două operațiuni — generarea de conținut asistată de AI și măsurarea publicitară pe server — sunt decise de [PLATFORM PROVIDER] pe baza propriilor acreditări și a propriului temei juridic invocat, ceea ce constituie o determinare proprie unui operator, în sensul art. 28 alin. (10) GDPR, iar pentru niciuna dintre ele nu există evidența prevăzută de art. 30 alin. (1) GDPR ori informarea prevăzută de art. 13 sau de art. 14 GDPR. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

---

Informații despre Persoana împuternicită de operator

Câmp	Valoare
Denumire Persoană împuternicită	[PLATFORM PROVIDER]
Număr de înregistrare la Registrul Comerțului	[Romanian CUI Number]
Adresă	[Street Address] [City, Postal Code] România
E-mail de contact	[email protected]
Reprezentant (dacă este cazul)	[Name, Title]
Responsabil cu protecția datelor (DPO)	[Name, Email] (dacă este desemnat)
Contact DPO (dacă este cazul)	[email protected]

---

Activitatea de Prelucrare 1: Găzduirea Evenimentelor și Gestionarea Participanților

Denumirea și Descrierea Prelucrării

Operarea platformei de evenimente: găzduirea evenimentelor live și înregistrate, gestionarea înregistrărilor participanților, furnizarea funcționalităților în timp real (chat, sondaje, oferte, întrebări și răspunsuri).

Operatorul (Operatorii) de Date

Organizațiile abonate la serviciile [PLATFORM PROVIDER] (mai mulți Operatori de date, câte unul pentru fiecare organizație)

• Fiecare organizație-client este un Operator de date independent
• [PLATFORM PROVIDER] prelucrează datele în numele fiecărui Operator, în temeiul unui Acord de Prelucrare a Datelor (DPA) individual

Reprezentantul Operatorului de Date

Astfel cum este indicat în fiecare DPA încheiat cu organizația-client

Categoriile de Persoane Vizate

1. Participanți la evenimente (utilizatori finali B2C)

   • Persoane care se înregistrează și participă la evenimentele găzduite de organizațiile-client
   • Volum estimat: 10.000 - 100.000 de participanți pe an (pentru toți clienții)

2. Utilizatori din personalul Clientului (angajați B2B)

   • Angajați și colaboratori ai organizațiilor-client cu acces la tabloul de bord
   • Roluri: admin, moderator, marketer, staff (a se vedea Rolurile personalului mai jos)
   • Volum estimat: 500 - 2.000 de utilizatori din personal pe an

Rolurile personalului. 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.

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

Prezentul Registru al Activităților de Prelucrare descria anterior un model cu două roluri, format dintr-un administrator cu acces complet și personal cu acces de tip „doar citire" la analize, și se întemeia pe acel model drept garanție de control al accesului. În realitate există patru roluri, dintre care două sunt neadministrative și pot efectua acțiuni distructive, iar administratorilor le este rezervată numai listarea jurnalului de audit. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Categoriile de Date cu Caracter Personal

Categorie	Elemente de Date	Sursă
Date de înregistrare	- Adresă de e-mail - Prenume - Nume de familie - Număr de telefon (opțional)	Furnizate direct de Persoana vizată în momentul înregistrării la eveniment
Date comportamentale	- Mesaje de chat - Voturi la sondaje (răspunsuri) - Click-uri pe oferte - Reacții (emoji-uri) - Întrebări Q&A - Marcaje temporale de prezență (ora de intrare/ieșire) - Durata sesiunii - Numărul de sesiuni (reconectări)	Generate automat în timpul participării la eveniment
Date tehnice	- Țara de înregistrare (cod ISO 3166-1 alpha-2, ex. „RO") — derivată din adresa IP prin baza de date locală MaxMind GeoLite2; adresa IP brută nu este stocată pe fișa de înregistrare - Orașul de înregistrare (denumire în engleză, ex. „Bucharest") — derivat din adresa IP; adresa IP brută nu este stocată pe fișa de înregistrare - Tipul dispozitivului (mobile / tablet / desktop / bot) — derivat din User-Agent; șirul brut de User-Agent este, suplimentar, stocat în metadatele de atribuire ale înregistrării - Familia de sisteme de operare (ios / android / windows / macos / linux / other) — derivată din User-Agent; șirul brut de User-Agent este, suplimentar, stocat în metadatele de atribuire ale înregistrării - Familia de browsere (chrome / firefox / safari / edge / opera / samsung / other) — derivată din User-Agent; șirul brut de User-Agent este, suplimentar, stocat în metadatele de atribuire ale înregistrării - Fus orar (IANA, ex. „Europe/Bucharest") — transmis de API-ul Intl al browserului la momentul înregistrării - UID Firebase Anonymous Auth (actor_id) — identificator pseudonim, efemer, per browser, pentru participarea în RTDB - UID Firebase Auth (firebaseUid) — stocat pe documentul de contact al aplicației mobile din Firestore; permite căutarea UID→contact pentru autentificarea prin proxy API. Nu este asociat adresei de e-mail a participantului în RTDB. - Token push FCM (device token) — identificator pseudonim de dispozitiv, utilizat pentru livrarea notificărilor push prin Firebase Cloud Messaging. Stocat în tabelul Postgres device_tokens, cheiat pe (org_id, email_hash, fcm_token). Platformă: android sau ios. Un contact poate avea mai multe token-uri (mai multe dispozitive).	Derivate la momentul înregistrării din trei surse: cererea HTTP (adresa IP → căutare geografică prin baza de date locală MaxMind, User-Agent → clasificarea dispozitivului, a sistemului de operare și a browserului) și API-ul Intl.DateTimeFormat al browserului (fusul orar). Adresa IP brută nu este stocată drept atribut al participantului pe fișa de înregistrare. Șirul brut de user agent este, în plus, scris de scriptul client al formularului de înregistrare în metadatele de atribuire ale înregistrării — păstrate pe intrarea în funnel și pe documentul de înregistrare din Firestore — și este citit de acolo atunci când se transmite un eveniment de conversie pe server. Ambele valori sunt, suplimentar, păstrate ori transmise în alte locuri: un hash SHA-256 stabil al adresei IP și al user agent-ului este stocat pentru fiecare vizitator în funnel_page_views (Activitatea de Prelucrare 5), adresa IP brută și user agent-ul brut ale utilizatorului care acționează sunt stocate pentru fiecare acțiune a personalului în audit_log, iar ambele valori brute sunt transmise platformelor publicitare pe căile server-side descrise la Activitatea de Prelucrare 3. Token-urile FCM sunt înregistrate de aplicația mobilă după acordarea permisiunii push la nivelul sistemului de operare. UID-ul Firebase Auth este stocat numai pentru utilizatorii aplicației mobile. Temei juridic: interes legitim (art. 6 alin. (1) lit. (f) GDPR) — analiză de produs, detectarea fraudei și livrarea serviciului (notificări push).
Date de atribuire	- Parametri UTM (utm_source, utm_medium, utm_campaign, utm_content, utm_term) - Identificatori de click publicitar (fbclid, gclid, ttclid, li_fat_id) - Platforma de click (meta, google, tiktok, linkedin) - URL-ul paginii de destinație - URL-ul de proveniență - Token-ul link-ului de distribuire prin recomandare (dacă persoana a ajuns printr-un link de distribuire de la alt participant)	Captate din parametrii URL la vizitarea paginii de destinație și stocate drept coloane pe funnel_entries, asociate contactului (a se vedea Activitatea de Prelucrare 5)
Date de distribuire prin recomandare	- Token de distribuire (identificator aleatoriu de 12 caractere) - Canalul de distribuire (whatsapp, email) - Sursa distribuirii (lobby, pagina de vizionare, e-mail de confirmare, e-mail de reamintire etc.) - Numărul de click-uri pentru fiecare link de distribuire - Numărul de înregistrări pentru fiecare link de distribuire	Generate atunci când Persoana vizată utilizează butoanele de distribuire din lobby-ul evenimentului, din pagina de vizionare sau din e-mailurile tranzacționale
Date de livrare a e-mailurilor	- Identificator de trimitere (corelare Newsman) - Tipul e-mailului (confirmare, reamintire, începe acum, replay) - Starea livrării (livrat, respins, spam, refuzat) - Evenimente de interacțiune (deschis, accesat, dezabonat) - Marcaje temporale	Consemnate de furnizorul de livrare a e-mailurilor (Newsman) prin webhook-uri. Asociate hash-ului adresei de e-mail, nu adresei în clar.
Evidențe de consimțământ	- Datele de acordare/retragere a consimțământului - Scopurile consimțământului — în registru există exact zece scopuri valide: data_processing, tos_acceptance, email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications, sms_marketing. Orice cerere care indică un scop din afara acestei liste este respinsă. Consimțămintele data_processing și tos_acceptance nu pot fi retrase din pagina de preferințe. - Metoda de consimțământ (checkbox la înregistrare sau în pagina de preferințe / app_onboarding pentru aplicația mobilă / import pentru contactele încărcate în masă / newsman_sync_reconcile atunci când o dezabonare consemnată la furnizorul de e-mail retrage consimțământul email_marketing). Bannerul de cookie-uri nu constituie o metodă de consimțământ în acest context — a se vedea nota de mai jos. - Versiunea consimțământului (versiunea politicii de confidențialitate la momentul consimțământului; versiunea în vigoare este "1.0") Notă privind scopurile care nu condiționează nimic: whatsapp_notifications și whatsapp_marketing sunt acceptate și afișate, dar nu condiționează nimic — nu există nicio cale de trimitere prin WhatsApp. Nici push_marketing și sms_marketing nu condiționează nimic. Notă privind consimțămintele push: notificările push tranzacționale (reamintire, începe acum, replay) impun o evidență de consimțământ push_notifications acordată în mod explicit, combinată cu permisiunea push la nivelul sistemului de operare; ele nu sunt acoperite de data_processing. Consimțământul push_marketing este colectat drept opt-in pentru push-ul de marketing, prin fluxul de preferințe post-înregistrare din aplicația mobilă, însă nicio cale de trimitere a push-ului de marketing nu este implementată. Notă privind consimțământul din bannerul de cookie-uri: rezultatul bannerului de cookie-uri este stocat exclusiv într-un cookie propriu, pe dispozitivul vizitatorului (rx_cookie_consent, o valoare JSON 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 și nu poate proba ulterior o decizie privind consimțământul pentru cookie-uri. Categoriile bannerului de cookie-uri (necessary, analytics, advertising) constituie un vocabular distinct și nu sunt scopuri valide în registrul consimțămintelor. Notă privind GTM și Consent Mode v2: Google Tag Manager (GTM) este încărcat drept tehnologie „necesară". Containerul în sine nu colectează date cu caracter personal și nu setează cookie-uri. Toate tag-urile din interiorul GTM respectă semnalele Google Consent Mode v2, care sunt setate implicit pe „denied" pentru toate tipurile de consimțământ (analytics_storage, ad_storage, ad_user_data, ad_personalization). Semnalele sunt actualizate pe „granted" numai atunci când participantul acordă consimțământul prin bannerul de cookie-uri. Pixelii Meta și TikTok nu sunt tag-uri GTM și nu sunt guvernați de aceste semnale — a se vedea Activitatea de Prelucrare 3.	Consemnate atunci când Persoana vizată bifează casetele de consimțământ la înregistrare, în lobby (scopurile legate de numărul de telefon), prin fluxul de onboarding/post-înregistrare din aplicația mobilă, atunci când un contact este încărcat prin importatorul în masă sau atunci când furnizorul de e-mail raportează o dezabonare. Opțiunile din bannerul de cookie-uri nu sunt consemnate aici.
Date de livrare push	- Evidența trimiterii notificării push (tipul de șablon, identificatorul de mesaj FCM, starea trimiterii: sent / failed / unregistered) - Evenimentul de deschidere (marcajul temporal al momentului în care utilizatorul atinge notificarea push — raportat de client) - Contextul evenimentului și al sesiunii (event_id, session_id, pentru analiza livrării) - Detaliile erorii, dacă trimiterea a eșuat	Consemnate la trimiterea notificărilor push tranzacționale. Nicio cale de trimitere a push-ului de marketing nu este implementată, deci nu se creează nicio evidență de push de marketing. Urmărirea deschiderilor este raportată de client, prin POST /v1/attendee/push-opened. Datele sunt asociate lui email_hash (pseudonim), nu adresei de e-mail în clar. Reproduce modelul de analiză a livrărilor din email_sends.
Date ale personalului	- Adresă de e-mail - Nume - Rol (admin, moderator, marketer, staff) - UID Firebase Auth - Evidența în jurnalul de audit a fiecărei acțiuni a personalului: identificatorul utilizatorului care acționează, rolul, acțiunea, tipul și identificatorul țintei, metadatele acțiunii, adresa IP brută, User-Agent-ul brut și identificatorul cererii	Furnizate de organizația-client (angajator) la crearea contului de utilizator din personal. Câmpurile din jurnalul de audit sunt generate automat la fiecare acțiune de scriere pe care un utilizator din personal o efectuează în tabloul de bord.
Date de măsurare a funnel-urilor	- Identificator pseudonim persistent de vizitator: un hash SHA-256 al adresei IP și al User-Agent-ului vizitatorului, consemnat o singură dată pe vizitator, pe pas de funnel și pe zi, în funnel_page_views. Hash-ul este stabil în timp — același vizitator produce aceeași valoare la fiecare vizită — și constituie, prin urmare, un identificator pseudonim persistent. - Coloanele de campanie, de dispozitiv și de localizare aproximativă de pe funnel_entries (a se vedea Date de atribuire mai sus)	Generate la fiecare vizită care nu provine de la un robot pe un funnel publicat sau pe o pagină de destinație, de către un pixel de urmărire pe server care funcționează fără nicio condiție de consimțământ (a se vedea Activitatea de Prelucrare 5)
Date privind achizițiile și tranzacțiile	- Identificatorul comenzii, valoarea totală, moneda și starea plății, stocate ca metadate ale intrării în funnel - Adresa de e-mail a cumpărătorului, folosită pentru a identifica o fișă de contact existentă - Pentru webhook-urile generice și pentru cele ale furnizorilor de formulare, întregul corp brut al cererii, stocat ca atare drept metadate ale intrării în funnel, care poate conține răspunsuri arbitrare de formular	Platforma de comerț electronic sau de formulare a Clientului (MerchantPro, WooCommerce, Tally ori un expeditor generic), printr-un webhook de intrare — nu sunt colectate de la Persoana vizată (a se vedea Activitatea de Prelucrare 5)
Evidențe de execuție a automatizărilor	- Evidența înscrierii: identificatorul contactului, pasul curent, starea, marcajele temporale de înscriere și de finalizare și o copie JSON a evenimentului declanșator - Evidența execuției fiecărui pas: starea, marcajul temporal al execuției și un document JSON cu rezultatul - Documentul cu rezultatul execuției unui pas conține adresa de e-mail în clar a destinatarului pentru pașii de e-mail și numărul său de telefon în clar pentru pașii de SMS	Generate atunci când un contact este înscris într-o automatizare și la executarea fiecărui pas (a se vedea Activitatea de Prelucrare 6)
Evidențe de generare cu AI	- Promptul de sistem, promptul utilizatorului, instrucțiunile personalizate, identificatorul modelului, rezultatul integral al modelului, numărul de token-uri de intrare și de ieșire și durata - Testimoniale aprobate ale participanților, încorporate în promptul de generare: numele afișat al participantului, citatul său în format liber, denumirea companiei și nota acordată - Identificatorul membrului personalului care a inițiat generarea și al celui care a acceptat-o	Generate atunci când un membru al personalului inițiază o generare cu AI din editorul de pagini sau din editorul de sondaje al tabloului de bord (a se vedea Activitatea de Prelucrare 7)
Date de livrare SMS	- Hash-ul adresei de e-mail, identificatorii webinarului și ai sesiunii, tipul de șablon, codul de urmărire - Identificatorul de mesaj al furnizorului, starea livrării, textul erorii, marcajele temporale de livrare și de click	Consemnate atunci când un mesaj tranzacțional sau de automatizare este transmis furnizorului de mesagerie și atunci când furnizorul raportează livrarea (a se vedea Activitatea de Prelucrare 8). Numărul de telefon în sine este citit din Firestore la momentul trimiterii și nu este stocat în PostgreSQL.
Evidențe ale difuzărilor către segmente	- Jurnalul destinatarilor: hash-ul adresei de e-mail, identificatorul segmentului, cheia de campanie și marcajul temporal al trimiterii - Conținutul mesajului: subiectul, titlul, corpul, eticheta și URL-ul îndemnului la acțiune și identificatorul membrului personalului care l-a compus	Generate atunci când un membru al personalului transmite un e-mail unic membrilor unui segment salvat (a se vedea Activitatea de Prelucrare 9)
Evidențe de moderare	- Mesajul de chat eliminat: textul original integral al mesajului, identificatorul de actor și numele afișat ale autorului, marcajul temporal al eliminării și motivul eliminării - Mesajul de chat mascat: mesajul astfel cum a fost modificat pe loc; în acest caz, textul original nu este păstrat	Generate automat atunci când un mesaj de chat corespunde listei de cuvinte interzise configurate pentru sesiune și atunci când un membru al personalului elimină manual un mesaj
Fișiere stocate (Cloud Storage)	- Biblioteca media a organizației, elementele de brand, șabloanele de pagină, imaginile ofertelor și ale webinarelor, materialele personalului și fișierele paginilor de destinație publicate. Acestea sunt materiale de marketing ale Clientului și pot înfățișa persoane identificabile.	Încărcate de personalul Clientului prin tabloul de bord, importate dintr-un URL indicat de personal sau scrise de platformă la publicarea unei pagini de destinație

Categorii speciale de date (art. 9 GDPR): niciuna colectată în mod intenționat. Dacă Persoanele vizate dezvăluie voluntar informații sensibile (stare de sănătate, opinii politice, religie) în mesajele de chat, organizația-client (Operatorul de date) răspunde pentru analiza și eliminarea mesajului. Filtrarea automată a conținutului de chat este descrisă mai jos și nu detectează categorii speciale de date.

Moderarea automată a conținutului de chat. Fiecare mesaj de chat este filtrat de o Cloud Function în raport cu o listă de cuvinte interzise, configurată pentru fiecare sesiune de personalul Clientului. Potrivirile simple sunt mascate pe loc, printr-o înlocuire de lungime fixă. Atunci când o scriere deghizată supraviețuiește mascării, mesajul este eliminat din fluxul live, iar textul original integral, împreună cu identificatorul de actor și cu numele afișat ale autorului, este scris într-un depozit de mesaje eliminate, accesibil personalului. Participantul nu este înștiințat că mesajul său a fost modificat sau eliminat. Aceeași mascare și aceeași eliminare pot fi aplicate retroactiv mesajelor deja transmise.

GAP-PROD-02 · PRODUCT — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezentul Registru al Activităților de Prelucrare enumera anterior mesajele de chat drept categorie de date comportamentale și plasa integral răspunderea pentru moderare și eliminare în sarcina Clientului în calitate de Operator, fără nicio mențiune privind filtrarea automată. În realitate, mesajele de chat sunt filtrate automat, pot fi modificate pe loc ori eliminate fără înștiințarea participantului, iar textul original integral al unui mesaj eliminat este păstrat într-un depozit separat, accesibil personalului. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

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. Obiectelor stocate nu li se aplică nicio perioadă de retenție, iar fluxul de ștergere în temeiul art. 17 GDPR nu elimină niciun obiect din bucket.

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

Prezentul Registru al Activităților de Prelucrare nu conținea anterior nicio poziție pentru fișierele păstrate în Cloud Storage, iar anexa subîmputerniciților arăta că bucket-ul păstrează exclusiv fișiere ale paginilor de destinație. Bucket-ul păstrează, pe lângă fișierele paginilor de destinație, biblioteca media a organizației, elementele de brand, șabloanele de pagină și materialele personalului; fiecare cale delimitată pe organizație poate fi citită public, fără autentificare, și poate fi scrisă de orice utilizator autentificat; iar obiectele stocate nu sunt atinse de nicio perioadă de retenție și de nicio cale de ștergere. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Scopurile Prelucrării

Scop	Temei juridic (determinat de Operator)	Descriere
Furnizarea accesului la eveniment	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Asigurarea accesului în sala evenimentului, afișarea numelui participantului în chat, activarea participării în timp real (sondaje, chat, oferte, Q&A)
Confirmarea înregistrării	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Transmiterea unui e-mail de confirmare a înregistrării reușite și furnizarea link-ului de acces la eveniment
Notificări de reamintire pentru eveniment	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Transmiterea de e-mailuri de reamintire (cu o oră înainte de începere, „începe acum"), pentru ca participanții să nu rateze evenimentul live
Notificări de replay	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Înștiințarea participanților atunci când înregistrarea de tip replay devine disponibilă
Calificarea prospecților	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Analiza datelor comportamentale (activitatea în chat, implicarea în sondaje, click-urile pe oferte) pentru evaluarea gradului de implicare al participantului, în vederea urmăririi comerciale. Numai dacă Persoana vizată își dă consimțământul pentru „urmărire comportamentală"
Comunicări de marketing	Consimțământ (art. 6 alin. (1) lit. (a) GDPR) pentru sincronizarea către furnizorul de e-mail de marketing; în rest, determinat de Operator	Transmiterea de invitații la evenimente viitoare și de conținut educațional. Consimțământul email_marketing condiționează un singur lucru: dacă respectivul contact este sincronizat î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 inițiată de personal și difuzarea către segment — funcționează exclusiv pe condiția tranzacțională (contactul nu este suprimat pentru bounce, reclamație sau dezabonare globală și nu face obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR). Retragerea consimțământului email_marketing nu elimină un contact dintr-o difuzare către segment — a se vedea Activitatea de Prelucrare 9.
Notificări SMS	Consimțământ (art. 6 alin. (1) lit. (a) GDPR)	Transmiterea notificărilor de reamintire pentru eveniment, a mesajelor „începe acum" și „replay disponibil", precum și a pașilor SMS din automatizări. Se trimit numai acolo unde contactul 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. Pe formularul public de funnel, acest consimțământ este însă acordat implicit prin simpla prezență a unui număr de telefon în formular; nu există o bifă separată pentru SMS. A se vedea Activitatea de Prelucrare 8.
Notificări WhatsApp și marketing WhatsApp/SMS	Nu are loc nicio prelucrare	Interfața de preferințe colectează consimțămintele whatsapp_notifications, whatsapp_marketing și sms_marketing, însă nu există nicio cale de trimitere prin WhatsApp, iar sms_marketing nu condiționează, la rândul său, nicio cale de trimitere. Aceste opt-in-uri sunt consemnate în registrul consimțămintelor și afișate Persoanei vizate; niciun mesaj nu este transmis vreodată în temeiul lor și nicio prelucrare nu se efectuează pentru aceste scopuri.
Notificări push (tranzacționale)	Consimțământ (art. 6 alin. (1) lit. (a) GDPR) + permisiune push la nivelul sistemului de operare	Transmiterea de notificări push tranzacționale către utilizatorii aplicației mobile: confirmarea înregistrării, notificarea de reamintire (implicit, cu 15 minute înainte de începere), „începe acum", replay disponibil. Impune o evidență de consimțământ push_notifications acordată în mod explicit, permisiunea push la nivelul sistemului de operare acordată de Persoana vizată și un token FCM înregistrat. Consimțământul data_processing nu este, prin el însuși, suficient.
Notificări push (marketing)	Nu are loc nicio prelucrare	Consimțământul push_marketing este colectat prin fluxul de preferințe post-înregistrare din aplicația mobilă, însă nicio cale de trimitere a push-ului de marketing nu este implementată și nicio notificare push de marketing nu este transmisă.
Urmărirea conversiilor publicitare	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Transmiterea de evenimente de conversie pe server (identificatori sub formă de hash, adresa IP brută, User-Agent-ul brut, identificatori de click) către platformele publicitare, pentru atribuirea campaniilor. Pe această cale nu există nicio condiție de consimțământ publicitar. Singura suprimare aplicată efectiv este restricționarea prelucrării în temeiul art. 18 GDPR. A se vedea Activitatea de Prelucrare 3 și testul de echilibru din DPIA, Secțiunea 3.3.
Trimiteri tranzacționale inițiate de personal	Executarea contractului (art. 6 alin. (1) lit. (b) GDPR)	Un membru al personalului poate, la cerere, să reemită e-mailul de confirmare al unei anumite persoane înregistrate ori să retrimită un e-mail deja transmis unui destinatar determinat. Ambele acțiuni generează link-uri personalizate noi de acces, de anulare și de preferințe pentru contactul respectiv și ocolesc setarea de confirmare automată a organizației. Ambele sunt consemnate în jurnalul de audit ca sent_registration_confirmation și resent_email și ambele sunt la dispoziția grupului de permisiuni marketing — nu doar a administratorilor.
Moderarea automată a conținutului	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Filtrarea fiecărui mesaj de chat în raport cu o listă de cuvinte interzise, configurată pentru fiecare sesiune de personalul Clientului; mascarea pe loc a potrivirilor simple și eliminarea mesajelor a căror scriere deghizată supraviețuiește mascării, cu păstrarea textului original integral și a identității autorului într-un depozit de mesaje eliminate, accesibil personalului. Participantului nu i se transmite nicio înștiințare.
Securitatea platformei	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Prevenirea spam-ului în chat, detectarea înregistrărilor frauduloase (de exemplu, detectarea boților prin device_type), protecția împotriva amenințărilor de securitate. Interes legitim: integritatea platformei și drepturile celorlalți participanți prevalează față de impactul minim asupra vieții private
Îmbogățirea cu date geografice și de dispozitiv la înregistrare	Interes legitim (art. 6 alin. (1) lit. (f) GDPR)	Derivarea țării, a orașului, a tipului de dispozitiv, a familiei de sisteme de operare, a familiei de browsere și a fusului orar la momentul înregistrării, din trei surse: adresa IP a clientului (MaxMind GeoLite2, căutare locală — nicio dată nu este transmisă către MaxMind la fiecare cerere), șirul User-Agent (tipul de dispozitiv, sistemul de operare, browserul) și API-ul Intl al browserului (fusul orar IANA). Stocate drept coloane pe funnel_entries — country_code, city, device_type, device_os, device_browser, device_timezone — asociate fișei contactului. Adresa IP brută și User-Agent-ul brut nu sunt stocate pe acea fișă, însă un hash SHA-256 stabil al ambelor este stocat pentru fiecare vizitator în funnel_page_views, iar ambele valori brute sunt transmise platformelor publicitare pe căile server-side de la Activitatea de Prelucrare 3. Utilizate pentru analiza audienței, pentru programarea optimă a evenimentelor (fusul orar) și pentru îmbunătățirea produsului.
Conformitate GDPR	Obligație legală (art. 6 alin. (1) lit. (c) GDPR)	Soluționarea cererilor privind drepturile Persoanelor vizate (acces, ștergere, portabilitate, opoziție, restricționare), ținerea jurnalelor de audit, formularea răspunsurilor la solicitările autorității de supraveghere. Rectificarea se efectuează, dar nu poate fi consemnată drept tip de cerere — a se vedea Activitatea de Prelucrare 4.

Cum este colectat și consemnat în realitate consimțământul. Afirmațiile de mai jos califică fiecare temei juridic întemeiat pe consimțământ din tabelul de mai sus.

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. Importul creează totodată o evidență de înregistrare și declanșează un e-mail de confirmare.

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ă.

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.

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

Prezentul Registru al Activităților de Prelucrare descria anterior consimțământul drept condiția operativă pentru comunicările de marketing, pentru mesageria WhatsApp și SMS, pentru push-ul de marketing și pentru măsurarea publicitară pe server; el arăta totodată că push-ul tranzacțional este acoperit de consimțământul data_processing. În sistemul implementat, email_marketing condiționează numai sincronizarea către furnizorul de e-mail de marketing, scopurile WhatsApp, push de marketing și SMS marketing nu condiționează nicio cale de trimitere, măsurarea publicitară pe server nu este condiționată de niciun consimțământ publicitar, iar push-ul tranzacțional impune un consimțământ push_notifications explicit, pe care prezentul registru nu îl enumera printre scopurile valide. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

Categoriile de Destinatari

Categorie destinatar	Scop	Locație	Garanții
Organizația-client (Operator de date)	Acces la toate datele prelucrate, prin tabloul de bord și prin API (Clientul este Operatorul)	Astfel cum indică Clientul	Nu se aplică (Operatorul primește datele de la Persoana împuternicită de operator)
Google LLC (Firebase, Google Cloud)	Stocarea bazelor de date (Firestore, RTDB), autentificare, funcții cloud, stocarea fișierelor, gestionarea secretelor	UE — Cloud Functions în europe-west3, Realtime Database în europe-west1, Firestore în multiregiunea UE. ⚠️ Locația bucket-ului Cloud Storage nu este atestată în evidențele [PLATFORM PROVIDER] și trebuie confirmată din configurația proiectului	Google Cloud DPA, SCC-uri, ISO 27001, SOC 2
Railway Corp.	Găzduirea bazei de date PostgreSQL, găzduirea API-ului, găzduirea aplicațiilor	Regiune UE	Railway DPA (solicitat), SOC 2 Type II
NewsmanApp SRL	Livrarea e-mailurilor tranzacționale și de marketing; sincronizarea în masă a adresei de e-mail în clar, a prenumelui și a numelui de familie, în loturi de până la o sută de mii de abonați; apartenența la segmente pentru fiecare abonat; precum și returnarea evenimentelor de vizualizare, click, bounce, reclamație și dezabonare, pe care platforma le păstrează. Prin urmare, Newsman deține date comportamentale de deschidere și de click, nu doar jurnale de livrare. Alături de conturile per organizație există și un cont Newsman la nivel de platformă.	UE (România)	Newsman DPA (solicitat), conform GDPR
Meta Platforms, Inc.	Urmărirea conversiilor publicitare pe server la înregistrare și o vizualizare de pagină pe server pentru fiecare vizitator al unei pagini de destinație a unui funnel (ori de câte ori Clientul activează integrarea Meta; nu se verifică niciun consimțământ al participantului)	SUA	Termenii Instrumentelor de Business Meta, SCC-uri, transformarea în hash a câmpurilor direct identificatoare. Adresa IP brută și User-Agent-ul brut sunt transmise fără hash.
Google LLC (Google Ads)	Urmărirea conversiilor publicitare pe server — neimplementată; nu primește nicio dată	SUA	Nu se aplică atât timp cât integrarea este neimplementată
TikTok Pte. Ltd.	Urmărirea conversiilor publicitare pe server (CompleteRegistration la fiecare înregistrare) — activă începând cu 8 mai 2026, ori de câte ori Clientul activează integrarea TikTok; nu se verifică niciun consimțământ al participantului	SUA / Singapore	⚠️ Niciun DPA și nicio SCC la dosar. Transformarea în hash a câmpurilor direct identificatoare; adresa IP brută, User-Agent-ul brut, ttclid brut și _ttp brut sunt transmise fără hash.
LinkedIn Corporation (Microsoft)	LinkedIn Insight Tag și Conversions API — neimplementate; nu primesc nicio dată	SUA	Nu se aplică atât timp cât integrarea este neimplementată
Cloudflare, Inc.	Proxy invers obligatoriu, aflat pe traseul cererilor, pentru domeniile participanților în producție: termină conexiunea TLS pentru fiecare cerere a participanților și o vede, inclusiv trimiterile formularului de înregistrare, care poartă adresa de e-mail, numele și numărul de telefon în clar. Pentru acest trafic, platforma preia adresa IP a clientului pe care o consemnează sau o transmite mai departe 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. Cloudflare Turnstile este, suplimentar, injectat în paginile de destinație publicate, în afara grupului condiționat de consimțământ, iar verificarea pe server transmite adresa IP a vizitatorului către Cloudflare.	Rețea edge globală	Cloudflare DPA și SCC-uri; TLS în tranzit
Microsoft Corporation, contractată pentru clienții din UE prin Microsoft Ireland Operations Limited (MIOL)	Microsoft Clarity — înregistrări de sesiune, heatmap-uri și analize comportamentale pe paginile publice, acolo unde Clientul activează serviciul. Se încarcă numai după ce vizitatorul acceptă categoria de cookie-uri de analiză și este omis integral în aplicația pentru participanți.	SUA / UE	Termenii Microsoft Clarity; EU-US Data Privacy Framework (Microsoft certificat); SCC-uri
SendSMS.ro	Livrarea SMS-urilor tranzacționale și a SMS-urilor din automatizări, acolo unde Clientul configurează acreditările SendSMS. Primește numărul de telefon al destinatarului, în clar și corpul integral al mesajului.	UE (România)	⚠️ Niciun DPA la dosar. Acreditări per organizație, păstrate în Google Secret Manager. ⚠️ Acreditările și datele cu caracter personal sunt transmise ca parametri în șirul de interogare al unei cereri HTTP GET, astfel încât numărul de telefon al destinatarului, corpul mesajului și parola contului trebuie presupuse consemnate în jurnalele de cereri ale furnizorului.
Anthropic PBC	Generare cu AI de brief-uri pentru pagini de destinație, de cod HTML pentru pagini de destinație, de texte de marketing și de întrebări pentru sondaje. Angajată de [PLATFORM PROVIDER] printr-o singură acreditare la nivel de platformă — nu este o integrare furnizată de Client și nu poate fi dezactivată pentru o anumită organizație. Primește testimoniale aprobate ale participanților (numele afișat, citatul, denumirea companiei, nota acordată), încorporate în promptul de generare, imagini de referință încărcate de personal și conținut al Clientului.	SUA	⚠️ DPA și mecanismul de transfer nu au fost stabilite. Exclusiv pe partea de server; niciun dispozitiv al participanților nu contactează furnizorul și nu se setează niciun cookie.
Google LLC (Google Fonts)	Prompturile de generare a paginilor instruiesc modelul să includă un <link> Google Fonts ori de câte ori tipografia aleasă impune acest lucru, iar calea brief-ului de design îl instruiește astfel în toate cazurile. Aplicația publică livrează aceste fonturi de pe domeniul propriu al paginii și le preia de la Google pe partea de server, astfel încât adresele IP și User-Agent-urile vizitatorilor nu ajung la Google. Previzualizarea din editorul de pagini nu este rescrisă: atunci când un membru al personalului previzualizează o pagină generată în tabloul de bord, browserul acestuia încarcă fonturile direct de la Google. Serviciul este prestat în temeiul condițiilor proprii ale Google, nu al Google Cloud DPA.	Global (rețeaua edge Google)	⚠️ Numai previzualizarea personalului; niciun DPA distinct
Furnizori terți de găzduire video (de regulă Google LLC / YouTube)	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 cu încărcare la click, astfel încât un webinar găzduit pe YouTube transmite către Google adresa IP, User-Agent-ul și comportamentul de vizionare ale participantului și setează cookie-uri Google pe durata sesiunii. URL-ul de redare este furnizat de organizație, deci un alt furnizor terț de găzduire video poate fi încorporat în același mod.	Astfel cum stabilește furnizorul de găzduire (Google: global)	⚠️ Nicio condiție de consimțământ. Alegerea furnizorului de găzduire aparține Operatorului; cookie-urile și transferurile pe care le determină sunt în răspunderea Operatorului.
Personalul propriu al Clientului, în afara platformei (export CSV)	Exporturile de segmente și de contacte descarcă adresele de e-mail și numele în clar pe dispozitivul membrului personalului care efectuează exportul. Exportul nu impune, în mod deliberat, un consimțământ email_marketing, iar o opțiune îl extinde asupra contactelor suprimate pentru bounce, reclamație de spam sau dezabonare globală. Contactele dezabonate rămân în exportul implicit, întrucât dezabonarea retrage consimțământul email_marketing fără a activa indicatorul de suprimare.	Astfel cum stabilește Clientul	Rezervat grupului de permisiuni marketing și consemnat în jurnalul de audit. Contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR sunt întotdeauna excluse.
Autorități de supraveghere	Anchete de reglementare, audituri, notificări privind încălcarea securității datelor cu caracter personal	UE (ANSPDCP în România, altele)	Obligație legală de cooperare

Transferuri ulterioare: [PLATFORM PROVIDER] nu transferă date cu caracter personal către destinatari din afara tabelului de mai sus, cu următoarele excepții. Atunci când un vizitator urmează o redirecționare urmărită, platforma transmite mai departe, către URL-ul de destinație, parametrii de campanie și identificatorii de click publicitar — utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, ttclid, li_fat_id și sursa de recomandare — iar acest URL aparține frecvent unui site terț ales de Client. Atunci când un membru al personalului indică un URL de referință pentru generarea cu AI, platforma adresează o cerere operatorului acelei pagini.

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

Prezentul Registru al Activităților de Prelucrare enumera anterior opt categorii de destinatari, descria integrările TikTok și LinkedIn drept viitoare, prezenta Cloudflare drept rețea condiționată de livrare a conținutului și nu indica niciun furnizor de mesagerie, niciun furnizor de AI, niciun furnizor de analiză și niciun furnizor terț de găzduire video. TikTok Events API funcționează începând cu 8 mai 2026 și transmite, la fiecare înregistrare, identificatori sub formă de hash împreună cu adresa IP și User-Agent-ul participantului, în formă brută, fără un DPA sau Clauze Contractuale Standard la dosar; Cloudflare este un proxy obligatoriu, aflat pe traseul cererilor, care vede fiecare cerere a participanților; iar destinatarii de mesagerie, AI, analiză și găzduire video enumerați mai sus primesc date cu caracter personal în prezent. Preavizul de 30 de zile privind subîmputerniciții, consemnat mai jos, nu a fost acordat pentru destinatarii divulgați pentru prima dată în prezenta revizie. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Transferuri Internaționale (În Afara SEE)

Țara de destinație	Destinatar	Garanții
SUA	Google Cloud (Firebase)	EU-US Data Privacy Framework (Google certificat) + Clauze Contractuale Standard (2021) + ISO 27001
SUA	Meta (Conversions API)	Clauze Contractuale Standard (2021) + transformarea în hash (SHA-256) a câmpurilor direct identificatoare. ⚠️ Adresa IP brută și User-Agent-ul brut sunt transmise fără hash, la înregistrare și la fiecare vizită pe o pagină de destinație.
SUA	Google Ads (Enhanced Conversions)	⚠️ Neimplementat — nu se transferă nicio dată
SUA	Railway (dacă s-ar folosi regiunea SUA)	⚠️ Neutilizat — se impune regiunea UE
SUA / Singapore	TikTok (Events API) — activ începând cu 8 mai 2026	⚠️ Nicio Clauză Contractuală Standard și niciun DPA la dosar. Transformarea în hash (SHA-256) a adresei de e-mail, a prenumelui, a numelui de familie și a identificatorului extern — niciun număr de telefon nu este transmis; adresa IP brută, User-Agent-ul brut, ttclid brut și _ttp brut sunt transmise fără hash.
SUA	LinkedIn (Microsoft)	⚠️ Neimplementat — nu se transferă nicio dată
SUA	Anthropic PBC (Claude API)	⚠️ Mecanismul de transfer nu a fost stabilit. Prompturile care conțin testimoniale aprobate ale participanților, imagini de referință încărcate de personal și conținut al Clientului sunt transmise pe partea de server către api.anthropic.com.
SUA / UE	Microsoft Corporation (Microsoft Clarity), contractată pentru clienții din UE prin Microsoft Ireland Operations Limited	EU-US Data Privacy Framework (Microsoft certificat) + Clauze Contractuale Standard. Se încarcă numai după consimțământul pentru analiză.
Rețea edge globală	Cloudflare, Inc. (proxy invers, Turnstile)	Cloudflare DPA + Clauze Contractuale Standard. Vede în clar fiecare cerere a participanților, după încheierea conexiunii TLS, inclusiv trimiterile formularului de înregistrare.
Rețea edge globală	Google LLC (Google Fonts)	⚠️ Niciun mecanism de transfer distinct consemnat. Adresa IP și User-Agent-ul unui membru al personalului ajung la Google atunci când acesta previzualizează o pagină generată în editorul de pagini. Browserele vizitatorilor paginilor de destinație nu contactează Google Fonts.
Astfel cum stabilește furnizorul de găzduire	Furnizori terți de găzduire video (de regulă Google LLC / YouTube)	⚠️ Nicio condiție de consimțământ. Alegerea furnizorului de găzduire aparține Operatorului; transferul pe care aceasta îl determină este în răspunderea Operatorului.

Evaluarea impactului transferului (Schrems II): finalizată la [DATE] — riscurile au fost evaluate ca acceptabile, având în vedere: (1) certificările EU-US DPF, (2) SCC-urile în vigoare, (3) minimizarea datelor (date cu caracter personal sub formă de hash pentru platformele publicitare), (4) absența categoriilor speciale de date. ⚠️ Acea evaluare acoperă numai destinatarii consemnați la momentul efectuării ei. Ea nu acoperă TikTok Pte. Ltd., Anthropic PBC, Cloudflare, Inc., Microsoft Corporation, SendSMS.ro, Google Fonts și nici furnizorii terți de găzduire video, iar data efectuării sale este anterioară divulgării faptului că adresele IP brute și User-Agent-urile brute sunt transmise fără hash platformelor publicitare. Evaluarea trebuie repetată înainte ca prezentul registru să fie invocat.

Revizuire anuală: riscurile de transfer sunt revizuite anual. Dacă legislația de supraveghere din SUA prezintă un risc inacceptabil (în conformitate cu orientările autorității de supraveghere), transferurile vor fi suspendate.

Perioadele de Retenție a Datelor

Tip de date	Perioadă de retenție	Motiv	Metodă de ștergere
Date de înregistrare (adresă de e-mail, nume, telefon)	Durata relației active dintre organizație și contact. Fără ștergere automată — a se vedea nota privind configurarea retenției, de mai jos.	Interesul legitim al Operatorului în relația de afaceri continuă și în livrarea serviciului	Ștergere definitivă din Firestore (orgs/{orgId}/contacts/{emailHash}/pii/private) + din tabelul PostgreSQL contacts (CASCADE)
Evenimente comportamentale (chat, sondaje, oferte)	Fără ștergere automată în practică. Jobul de aplicare acceptă behavioral_events, însă nicio politică implicită nu este preconfigurată și nicio politică nu poate fi salvată în prezent — a se vedea nota de mai jos.	Calificarea prospecților întemeiată pe consimțământ (analiză pe termen scurt)	Ștergere definitivă din tabelul PostgreSQL behavioral_events. Evidențele corespunzătoare ale sesiunii live din Realtime Database nu sunt șterse — a se vedea rândul următor.
Datele sesiunilor live (Realtime Database)	Fără ștergere automată. Păstrate pe termen nelimitat, pe toată durata de existență a fișei webinarului.	Funcționalitatea sesiunii live; niciun control de retenție implementat	Ștergere manuală a sesiunii sau a webinarului asociat. Nicio altă operațiune nu elimină un nod de sesiune live.
Evidențe de participare	Durata relației active dintre organizație și contact. Fără ștergere automată.	Evidențe contractuale + analiză — necesare pentru livrarea serviciului, pentru accesul la replay și pentru istoricul participanților	Ștergere definitivă din PostgreSQL webinar_registrations, prin CASCADE din contacts. Participarea este păstrată în coloanele attended_via și attended_at din acel tabel; nu există un tabel separat de prezență. Îmbogățirea cu date de campanie, geografice și de dispozitiv se află pe funnel_entries (country_code, city, device_type, device_os, device_browser, device_timezone) și este ștearsă prin interogare explicită în fluxul de ștergere.
Evidențe de consimțământ	Șterse odată cu fișa contactului (CASCADE la o cerere de ștergere în temeiul GDPR sau la încetarea activității organizației). Fără ștergere independentă în funcție de vechime.	Obligație legală (dovada consimțământului valabil — art. 7 alin. (1) GDPR)	Ștergere definitivă din PostgreSQL consents + Firestore consents/{id}. consent_events, istoricul de tip „doar adăugare", constituie o excepție deliberată: referința sa către contact este setată pe null la ștergere, iar rândul în sine este păstrat, cu identificatorii organizației, webinarului și înregistrării, scopul, acțiunea, metoda, versiunea politicii și marcajul temporal, cu titlu de dovadă de responsabilitate în temeiul art. 7 alin. (1) GDPR.
Jurnale de audit (accesul personalului la date cu caracter personal)	Fără ștergere automată. Jurnalul de audit nu se numără printre tipurile de date pe care jobul de retenție le recunoaște, iar rolul de bază de date al aplicației deține numai privilegii de selectare și de inserare asupra lui, ceea ce îl face să fie doar de adăugare pentru aplicație, dar înseamnă totodată că nu poate fi golit prin conexiunea acesteia.	Responsabilitate în materie de securitate (art. 5 alin. (2) GDPR)	Nicio cale de ștergere și nicio anonimizare. 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, alături de adresa IP brută și de User-Agent-ul brut ale membrului personalului care a acționat.
Conturi de utilizator din personal	Durata angajării + 30 de zile	Executarea contractului (relația angajator-angajat, organizația-client fiind angajatorul)	Ștergere din Firestore orgs/{orgId}/users/{userId} + Firebase Auth. Istoricul din jurnalul de audit al membrului personalului, inclusiv adresele IP și User-Agent-urile sale, nu este șters.
Token-uri de dispozitiv FCM	Fără ștergere automată. Configurabile pentru fiecare client, dar dezactivate implicit, iar nicio politică nu poate fi salvată în prezent. Șterse la un răspuns FCM UNREGISTERED (token inactiv), la o ștergere în temeiul GDPR sau la revocarea explicită de către utilizatorul aplicației.	Token-urile FCM expiră dacă aplicația nu este deschisă (token-urile devin inactive).	Ștergere definitivă din tabelul PostgreSQL device_tokens (identificat prin org_id + email_hash). Fără dependență de cheie străină — ștergerea se face prin interogare explicită.
Evidențe de livrare a e-mailurilor (email_sends)	Fără ștergere automată. Jobul de aplicare acceptă acest tabel, însă API-ul nu îl acceptă drept tip de date configurabil, astfel încât nicio politică nu poate fi salvată. Șterse la o ștergere în temeiul GDPR sau la încetarea activității organizației.	Analiza livrării + responsabilitate	Ștergere definitivă din PostgreSQL email_sends (identificat prin org_id + email_hash), în fluxul de ștergere.
Evidențe de livrare push (push_sends)	Fără ștergere automată. Aceeași poziție ca email_sends. Șterse la o ștergere în temeiul GDPR sau la încetarea activității organizației.	Analiza livrării + responsabilitate (reproduce urmărirea livrării e-mailurilor). Marcajele temporale de deschidere (raportate de client) sunt date de analiză, nu critice pentru serviciu.	Ștergere definitivă din tabelul PostgreSQL push_sends (identificat prin org_id + email_hash). Fără dependență de cheie străină.
Evidențe de livrare SMS (sms_sends)	Fără ștergere automată. Jobul de aplicare acceptă acest tabel, însă API-ul îl respinge ca tip de date configurabil, astfel încât nicio politică nu poate fi salvată.	Analiza livrării + responsabilitate	Nicio cale de ștergere. Cheiat pe email_hash, fără cheie străină către contacts, astfel încât tabelul nu este atins nici de fluxul de ștergere, nici în cascadă, și este absent din exportul de date în temeiul art. 15 GDPR.
Evidențe ale difuzărilor către segmente (segment_broadcasts, segment_broadcast_sends)	Fără ștergere automată — niciunul dintre cele două tabele nu este un tip de date configurabil.	Suprimarea duplicatelor la retrimitere; reutilizarea conținutului unei difuzări anterioare	Nicio cale de ștergere. Jurnalul destinatarilor este cheiat pe email_hash, fără cheie străină către contacts, astfel încât nu este atins nici de fluxul de ștergere, nici în cascadă, și este absent din exportul de date în temeiul art. 15 GDPR.
Intrări în funnel (funnel_entries)	Fără ștergere automată — nu este un tip de date configurabil.	Atribuirea campaniilor și măsurarea conversiilor	Ștergere explicită după contact în fluxul de ștergere; CASCADE din funnel-ul sau din pasul din care fac parte. Omise din exportul în temeiul art. 15 și al art. 20 GDPR.
Vizualizări de pagină ale funnel-urilor (funnel_page_views)	Fără ștergere automată — nu este un tip de date configurabil.	Măsurarea vizitatorilor unici pentru fiecare pas de funnel	Numai CASCADE din funnel-ul sau din pasul din care fac parte. Nu sunt atinse de fluxul de ștergere — rândul nu poartă nicio legătură cu o fișă de contact.
Înscrieri în automatizări și execuții ale pașilor	Fără ștergere automată — niciunul dintre cele patru tabele de automatizări nu este un tip de date configurabil.	Istoricul execuției parcursurilor	CASCADE din contacts pentru înscrieri și din înscriere pentru execuțiile pașilor. Această cascadă este singurul mecanism care elimină adresele de e-mail și numerele de telefon în clar păstrate în documentele cu rezultatul pașilor.
Joburi de generare cu AI (ai_jobs)	Fără ștergere automată — nu este un tip de date configurabil.	Urmărirea costurilor, versionarea și reproductibilitatea generărilor	Nicio cale de ștergere. Rândurile sunt cheiate pe o entitate și pe un utilizator din personal, nu pe o fișă de contact, deci nu sunt atinse nici de fluxul de ștergere, nici în cascadă. Citatul unui testimonial și numele autorului său persistă în promptul și în rezultatul stocate și după ștergerea contactului.
Scoruri de calificare (lead_scores)	Fără ștergere automată în practică. lead_scores este unul dintre cele cinci tipuri de date pe care API-ul le acceptă, însă ecranul de setări pentru retenție nu poate salva nicio politică — a se vedea nota de mai jos. Șterse prin CASCADE la ștergerea contactului (art. 17 GDPR). Scorurile nu sunt calculate pentru contactele cu processing_restricted = true.	Derivate din evenimentele comportamentale (întemeiate pe consimțământ). Scorurile vechi, provenite din evenimente depășite, pot fi golite independent.	Ștergere definitivă prin jobul de aplicare a retenției sau CASCADE din tabelul contacts. Incluse în exportul de date în temeiul art. 15 GDPR.
Fișiere stocate (Cloud Storage)	Fără ștergere automată. Niciunui obiect din bucket nu i se aplică o perioadă de retenție.	Materiale de marketing și fișiere ale paginilor de destinație publicate	Nicio cale de ștergere. Fluxul de ștergere în temeiul art. 17 GDPR nu elimină niciun obiect din Cloud Storage.
Configurarea scoringului (scoring_configs)	Durata abonamentului organizației (date la nivel de organizație, fără date cu caracter personal)	Date de configurare ale organizației, nu date cu caracter personal	Șterse la încetarea activității organizației
Evidențe ale cererilor în temeiul GDPR	Fără ștergere automată. Registrul cererilor nu se numără printre tipurile de date pe care jobul de retenție le recunoaște și nimic altceva din platformă nu șterge din el.	Obligație legală (dovada conformității)	Nicio cale de ștergere și nicio anonimizare. Registrul păstrează pe termen nelimitat tipul cererii, hash-ul adresei de e-mail a persoanei vizate, datele calendaristice și metoda de soluționare.

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

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.

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

Prezentul Registru al Activităților de Prelucrare descria anterior retenția configurabilă pentru fiecare client, cu un minim de 30 de zile și un maxim de zece ani, drept control operațional, atribuia perioade fixe de retenție de doi ani jurnalului de audit, de trei ani registrului cererilor și de 60 de zile token-urilor de dispozitiv și arăta că datele sesiunilor live din Realtime Database sunt efemere și se șterg automat după încheierea sesiunii. În prezent, nicio politică de retenție nu poate fi salvată din produs, niciuna nu este preconfigurată implicit, niciuna dintre cele trei perioade fixe nu este implementată, iar datele sesiunilor live nu sunt șterse decât prin ștergerea manuală a sesiunii sau a webinarului asociat. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

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

Prezentul document arăta anterior că datele cu caracter personal din jurnalul de audit sunt anonimizate prin înlocuirea hash-ului adresei de e-mail cu o valoare substituent și că datele de identificare din registrul cererilor persoanelor vizate sunt anonimizate după soluționare. Niciuna dintre cele două rutine nu există: nu se efectuează nicio anonimizare în vreunul dintre cele două tabele, iar niciunul nu poate fi golit prin conexiunea de bază de date a aplicației. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Ștergere anticipată: Persoanele vizate pot solicita ștergerea înainte de expirarea perioadei de retenție (art. 17 GDPR). Fluxul de ștergere este automat odată declanșat, însă declanșarea este o acțiune manuală a personalului: un membru al personalului care deține grupul de permisiuni setări trebuie să soluționeze cererea. Valoarea de 24 de ore este un obiectiv operațional, nu un comportament al sistemului — nu există niciun cronometru, nicio golire de coadă și nicio impunere a unui nivel de serviciu. Ștergerea în regim de autoservire este disponibilă participanților numai în cazul contactelor deja marcate pentru bounce automat sau pentru respingere și care nu sunt marcate drept capcane de spam; orice altă Persoană vizată trebuie să se adreseze organizației-client.

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

Prezentul document arăta anterior că [PLATFORM PROVIDER] execută ștergerea în 24 de ore, printr-un flux automat. Fluxul rulează numai atunci când un membru al personalului soluționează cererea, iar ștergerea în regim de autoservire pentru participanți este limitată la contactele a căror adresă de e-mail a fost deja marcată pentru bounce sau pentru respingere. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Ștergerea datelor push: fluxul de ștergere în temeiul GDPR (POST /v1/gdpr/requests/:id/process) acoperă rândurile din device_tokens și din push_sends identificate prin (org_id, email_hash). La retragerea consimțământului pe server (inclusiv retragerea data_processing), se transmite o notificare push silențioasă către aplicația mobilă, pentru a declanșa o sincronizare /me — aplicația detectează astfel retragerea și încetează să mai înregistreze token-uri noi. Token-urile existente sunt șterse de flux.

Tabelele atinse de fluxul de ștergere. Fluxul șterge prin interogare explicită email_sends, push_sends, device_tokens și funnel_entries, apoi șterge fișa contactului, ceea ce determină ștergerea în cascadă a behavioral_events, segment_members, consents, webinar_registrations și shares. El elimină totodată datele de contact în clar din Firestore și transmite adresa către lista de suprimare a furnizorului de e-mail.

Două tabele care conțin date cu caracter personal cheiate pe hash-ul adresei de e-mail nu sunt atinse de rutina de ștergere și nu au nicio cheie străină către fișa contactului, deci nu sunt eliminate nici în cascadă: jurnalul de livrare a SMS-urilor și jurnalul destinatarilor difuzărilor către segmente. Prin urmare, o evidență individuală a mesajelor SMS trimise — hash-ul adresei de e-mail, webinarul și sesiunea, tipul de șablon, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării și marcajele temporale de livrare și de click — persistă după o ștergere în temeiul art. 17, iar niciunul dintre cele două tabele nu este inclus în exportul de date în temeiul art. 15. Nici joburile de generare cu AI și nici vizualizările de pagină ale funnel-urilor nu sunt atinse, iar niciun obiect din Cloud Storage nu este șters.

Ș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.

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

Prezentul Registru al Activităților de Prelucrare identifica anterior tabelele atinse de fluxul de ștergere ca fiind exclusiv tabelul token-urilor de dispozitiv și cel al livrărilor push și nu divulga nicio excludere de la ștergere. Jurnalul de livrare a SMS-urilor, jurnalul destinatarilor difuzărilor către segmente, jurnalul joburilor de generare cu AI, vizualizările de pagină ale funnel-urilor și fiecare obiect din Cloud Storage supraviețuiesc unei ștergeri în temeiul art. 17 GDPR, iar istoricul consimțămintelor de tip „doar adăugare" este păstrat, cu referința sa către contact setată pe null. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Ștergerea copiilor de rezervă: copiile de rezervă sunt păstrate 30 de zile (PostgreSQL) sau 7 zile (Firestore). ⚠️ Niciuna dintre cele două valori nu este atestată în evidențele [PLATFORM PROVIDER]; ambele trebuie confirmate din configurația efectivă a furnizorilor de găzduire. Datele cu caracter personal din copiile de rezervă sunt șterse pe măsură ce acestea expiră (nu se poate șterge selectiv din copii de rezervă imuabile).

Măsuri Tehnice și Organizatorice de Securitate (art. 32 GDPR)

A se vedea Anexa II: Măsuri Tehnice și Organizatorice de Securitate (document separat: annex-security-measures.md).

Rezumat:

• Criptare în tranzit (TLS 1.2+) și în repaus (AES-256)
• Pseudonimizare (hash SHA-256 al adresei de e-mail în baza de date analitică) — calificată mai jos
• Row Level Security (RLS) pe tabelele PostgreSQL (izolare pe org_id) — calificată mai jos
• Reguli de securitate Firestore (control al accesului delimitat pe organizație pentru configurarea organizației, fișele personalului, fișele de pagină, webinarele private, evidențele de consimțământ la nivel de contact și subcolecția cu datele cu caracter personal ale înregistrărilor) — calificate mai jos
• Control al accesului bazat pe roluri, pentru patru roluri de personal asociate cu trei grupuri de permisiuni (a se vedea Rolurile personalului mai sus)
• Un set complet de antete de securitate pe răspunsurile API, inclusiv o politică de securitate a conținutului de forma default-src 'none'; frame-ancestors 'none'
• Un jurnal de audit de tip „doar adăugare" la nivelul privilegiilor din baza de date: rolul de bază de date al aplicației deține numai privilegii de selectare și de inserare asupra lui
• O verificare la pornire, în producție, care refuză pornirea API-ului dacă nu este configurată conexiunea de bază de date supusă Row Level Security
• Notificarea încălcării securității datelor cu caracter personal în 24 de ore (de la persoana împuternicită către operator)
• Acorduri de confidențialitate pentru întreg personalul

Calificări aduse rezumatului de mai sus.

Fără autentificare cu mai mulți factori. Serviciile nu pun la dispoziție nicio autentificare cu mai mulți factori sau cu doi factori pentru utilizatorii tabloului de bord: membrii personalului se autentifică printr-o adresă de e-mail și o parolă ori prin Google OAuth, iar autentificarea este cu un singur factor. Codul de unică folosință de 4 cifre descris în Anexa II este o alternativă la link-ul magic pentru participanți, nu un al doilea factor. Orice cerință de autentificare cu mai mulți factori aplicată conturilor proprii ale [PLATFORM PROVIDER] la furnizorii terți de găzduire și de consolă constituie o practică administrativă internă și nu este un control al Serviciilor.

Fără audituri de securitate și fără teste de penetrare. Niciun audit de securitate efectuat de un terț și niciun test de penetrare nu sunt atestate în evidențele [PLATFORM PROVIDER].

Formarea personalului în materia protecției datelor. ⚠️ Nu sunt atestate în evidențele [PLATFORM PROVIDER] nici un program formal de formare în materia protecției datelor, nici evidențe de formare. A se vedea Anexa II.

Gestionarea vulnerabilităților. Scanarea dependențelor și a vulnerabilităților se realizează manual. În depozitul de cod nu există nicio linie de integrare continuă, niciun serviciu automat de actualizare a dependențelor și nicio scanare automată de securitate a commit-urilor, a dependențelor sau a imaginilor de container. Vulnerabilitățile sunt identificate prin analiza manuală a avertizărilor privind dependențele și prin notele de securitate publicate de furnizorii de găzduire și de întreținătorii framework-urilor, iar remedierea se face prin realizarea și implementarea directă a modificării de către un dezvoltator.

Ciclul de dezvoltare securizată. Modificările sunt redactate și revizuite de echipa de inginerie și verificate local cu ajutorul comenzilor de lint, vet, verificare de tipuri și build din depozitul de cod, înainte de implementare. Nu există nicio linie automată care să impună aceste verificări: depozitul nu conține nicio configurare de integrare continuă, astfel încât verificările au caracter orientativ și depind de rularea lor de către dezvoltator. Acoperirea automată cu teste se limitează la cinci fișiere de teste unitare din Go API, 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; nu există teste automate pentru autentificare, autorizare, Row Level Security sau izolarea datelor la nivel de organizație și niciun test automat nu simulează o interogare între organizații.

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

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

Prezentul document afirma anterior existența autentificării cu mai mulți factori pentru accesul personalului, a auditurilor anuale de securitate și a testelor de penetrare, precum și a unui model de acces cu două roluri, și se întemeia pe toate trei drept măsuri prevăzute de art. 32 GDPR. Niciun mecanism de autentificare cu mai mulți factori nu există, niciun audit efectuat de un terț și niciun test de penetrare nu sunt atestate, iar modelul de roluri este cel cu patru roluri descris mai sus. Nu există, în plus, nicio linie de integrare continuă, nicio scanare automată a dependențelor sau de securitate, nicio acoperire automată cu teste pentru autentificare, autorizare, Row Level Security ori izolarea datelor la nivel de organizație și nicio infrastructură de urmărire a erorilor sau de alertare. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Pseudonimizare. 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.

Izolarea datelor la nivel de organizație în 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 sale reziduale sunt următoarele:

• 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; 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.

Izolarea în 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ă.

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

Prezentul Registru al Activităților de Prelucrare descria anterior izolarea datelor la nivel de organizație drept aplicabilă în mod uniform în bazele de date ale platformei. Izolarea la nivel de organizație este impusă în PostgreSQL astfel cum se arată mai sus, însă regulile de securitate ale Realtime Database nu conțin niciun identificator de organizație și autorizează citirile cu privilegii de personal exclusiv pe baza atributului role din token-ul apelantului, iar mai multe noduri de sesiune live pot fi citite de orice utilizator autentificat, inclusiv de participanții anonimi. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Limitele regulilor Firestore. Regulile de securitate Firestore restrâng configurarea organizației, fișele utilizatorilor din personal, fișele de pagină, webinarele private, evidențele de consimțământ la nivel de contact și subcolecția cu datele cu caracter personal ale înregistrărilor la membrii autentificați ai organizației proprietare și interzic orice acces al clienților la colecțiile de nivel superior care conțin coduri de verificare și link-uri magice. Ele nu restrâng două categorii de date cu caracter personal:

• Datele cu caracter personal ale contactelor. 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. Documentele de la orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}/registrations/{registrationId} 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. Documentele de înregistrare pot fi și create fără autentificare — acesta este mecanismul prin care funcționează formularul public de înregistrare.

Documentele de sesiune, documentele webinarelor care nu sunt private, sondajele, ofertele și testimonialele sunt, la rândul lor, lizibile public, iar testimonialele și sesizările de abuz pot fi create public, prin proiectare.

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

Prezentul Registru al Activităților de Prelucrare descria anterior regulile de securitate Firestore drept un control al accesului delimitat pe organizație asupra datelor cu caracter personal păstrate în Firestore. Regulile lasă documentul cu datele cu caracter personal ale contactului lizibil pentru orice utilizator Firebase autentificat care cunoaște identificatorul organizației și hash-ul adresei de e-mail — hash calculat din adresa de e-mail fără sare criptografică — și lasă documentele de înregistrare lizibile fără autentificare. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

Activitatea de Prelucrare 2: Analize de Marketing și Calificarea Prospecților

Denumirea și Descrierea Prelucrării

Analize comportamentale și segmentare: analiza gradului de implicare a participanților la eveniment (activitatea în chat, participarea la sondaje, interesul față de oferte) pentru calificarea prospecților în beneficiul echipelor de vânzări ale Clientului.

Operatorul (Operatorii) de Date

Identici cu cei de la Activitatea de Prelucrare 1 (organizațiile-client)

Categoriile de Persoane Vizate

Participanți la eveniment care și-au dat consimțământul pentru „urmărire comportamentală" în momentul înregistrării

Categoriile de Date cu Caracter Personal

• Adresa de e-mail (sub formă de hash SHA-256 în baza de date analitică)
• Numele — preluat din Firestore la momentul exportului sau al trimiterii; nu este stocat în baza de date analitică
• Evenimente comportamentale:
  • Mesaje de chat (conținut integral, marcaj temporal, event_id)
  • Voturi la sondaje (poll_id, option_id, marcaj temporal)
  • Click-uri pe oferte (offer_id, marcaj temporal, boolean clicked)
  • Durata participării, numărul de sesiuni
• Apartenența la segmente (date derivate: „implicare ridicată", „interesat de Produsul X" etc.)
• Scoruri de calificare (scoruri de implicare materializate pentru fiecare eveniment + agregat):
  • Scorul (număr întreg, sumă ponderată a evenimentelor comportamentale)
  • Detalierea (totaluri de puncte pentru fiecare tip de eveniment: chat_message, chat_reply, poll_vote, offer_clicked, reaction, feedback_submitted, event_joined, attendance_duration_bonus)
  • Marcajul temporal al calculului
• Configurarea scoringului (ponderi per organizație pentru fiecare tip de eveniment — la nivel de organizație, fără date cu caracter personal)

Scopurile Prelucrării

• Calificarea prospecților (calculul nivelului de implicare)
• Segmentare (întemeiată pe reguli: „a participat la 3+ evenimente", „a votat în sondajul despre prețuri")
• Targetarea campaniilor de marketing (exportul membrilor unui segment către CRM-ul sau platforma de e-mail a Clientului)
• Exportul în masă al membrilor unui segment sub forma unui fișier CSV care conține adresa de e-mail în clar și numele fiecărui membru, descărcat pe dispozitivul membrului personalului care efectuează exportul. Exportul nu impune un consimțământ email_marketing, iar o opțiune îl extinde asupra contactelor suprimate pentru bounce, reclamație de spam sau dezabonare globală. Contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR sunt întotdeauna excluse.
• Compunerea și transmiterea unui e-mail unic către membrii unui segment — a se vedea Activitatea de Prelucrare 9

Temeiul Juridic (determinat de Operator)

Consimțământ (art. 6 alin. (1) lit. (a) GDPR) — Persoana vizată bifează explicit „Consimt la urmărirea comportamentală pentru calificarea prospecților" în momentul înregistrării.

Acel consimțământ guvernează consemnarea evenimentelor comportamentale și scorurile derivate din ele. El nu condiționează cele două operațiuni de export și de difuzare enumerate mai sus: exportul de segmente și difuzarea către segment filtrează numai după faptul că respectivul contact nu face obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR și, în mod implicit, nu este suprimat pentru bounce, reclamație sau dezabonare globală. Apartenența la un segment poate fi ea însăși derivată din evenimente comportamentale consemnate în temeiul acestui consimțământ. A se vedea Activitatea de Prelucrare 9.

Destinatari

• Organizația-client (Operator de date) — primește rapoarte de analiză, liste de segmente, exporturi de evenimente comportamentale
• Subîmputerniciți: identici cu cei de la Activitatea de Prelucrare 1 (Google Cloud pentru stocare, Railway pentru interogările analitice PostgreSQL)

Transferuri Internaționale

Identice cu cele de la Activitatea de Prelucrare 1.

Perioada de Retenție

Fără ștergere automată în practică. Evenimentele comportamentale sunt unul dintre cele cinci tipuri de date pe care API-ul le acceptă drept configurabile, însă nicio politică implicită nu este preconfigurată și nicio politică nu poate fi salvată în prezent din produs, astfel încât evenimentele comportamentale sunt păstrate pe durata relației de afaceri. Acolo unde o politică există totuși, limitele configurabile sunt de la 30 la 3.650 de zile, iar jobul de aplicare nu șterge nimic pentru o politică al cărei volum restant depășește zece mii de rânduri într-o singură rulare. A se vedea Configurarea retenției la Activitatea de Prelucrare 1.

Retragerea consimțământului: dacă Persoana vizată retrage consimțământul privind urmărirea comportamentală după eveniment, evenimentele comportamentale viitoare nu mai sunt consemnate în baza de date analitică (condiția de consimțământ din Cloud Functions împiedică scrierea). Evenimentele comportamentale existente rămân supuse politicii de retenție configurate și pot fi șterse printr-o cerere separată de ștergere (a se vedea Politica de Confidențialitate, Secțiunea 8.2). Scorurile de calificare nu sunt recalculate pentru contactele cu processing_restricted = true — scorurile existente rămân până la ștergerea contactului sau până la golirea lor prin politica de retenție.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1, la care se adaugă o condiție de consimțământ:

• Condiție de consimțământ în Cloud Functions: înainte de a scrie un eveniment comportamental în PostgreSQL, Cloud Function verifică subcolecția Firestore consents/{id}. Dacă behavioral_tracking = false, evenimentul NU este scris.

Domeniul de aplicare al acestei condiții este restrâns. 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ă.

---

Activitatea de Prelucrare 3: Urmărirea Conversiilor Publicitare pe Server

Denumirea și Descrierea Prelucrării

Atribuire publicitară: transmiterea către platformele publicitare a evenimentelor de înregistrare și de vizualizare a paginilor de destinație, pentru măsurarea performanței campaniilor, precum și livrarea pixelilor publicitari client-side care le însoțesc. Sunt acoperite două operațiuni distincte:

1. Evenimente de conversie pe server, la înregistrare — CompleteRegistration transmis către Meta Platforms, Inc. și către TikTok Pte. Ltd. pentru fiecare înregistrare, acolo unde Clientul a activat integrarea corespunzătoare.
2. Vizualizare de pagină pe server, la fiecare vizită pe o pagină de destinație — transmisă către Meta Platforms, Inc. pentru fiecare vizitator uman al unei pagini de destinație a unui funnel, acolo unde Clientul a activat integrarea Meta, indiferent dacă acel vizitator se înregistrează sau nu.

Operatorul (Operatorii) de Date

Organizațiile-client care au activat integrările cu platforme publicitare în tabloul de bord (Setări → Integrări)

Categoriile de Persoane Vizate

1. Fiecare vizitator al unui funnel publicat sau al unei pagini de destinație aparținând unei organizații-client care a activat integrarea Meta, indiferent dacă se înregistrează sau nu și independent de orice decizie în bannerul de cookie-uri (operațiunea 2).
2. Fiecare persoană înregistrată la un eveniment găzduit de o organizație-client care a activat integrarea Meta sau TikTok, independent de orice decizie în bannerul de cookie-uri (operațiunea 1).

Niciuneia dintre cele două operațiuni nu i se aplică vreo condiție de consimțământ publicitar. Singura suprimare aplicată efectiv este restricționarea prelucrării în temeiul art. 18 GDPR, care se aplică operațiunii 1.

Categoriile de Date cu Caracter Personal Prelucrate

Operațiunea 1 — evenimente de conversie pe server, la înregistrare:

• Adresa de e-mail sub formă de hash (SHA-256, litere mici, curățată de spații înainte de transformare) — niciodată transmisă în clar
• Niciun număr de telefon. Câmpul este lăsat gol la compunerea evenimentului, oricare ar fi numărul păstrat pe contact, astfel încât niciun număr nu este transmis vreuneia dintre platforme
• Prenumele sub formă de hash și numele de familie sub formă de hash (SHA-256, litere mici, curățate de spații) — niciodată transmise în clar
• Identificatorul extern (identificatorul înregistrării) — sub formă de hash pentru TikTok, transmis către Meta fără hash
• Adresa IP brută a clientului și User-Agent-ul brut — transmise fără hash către ambele platforme
• Identificatorul de click (fbclid, ttclid) și valorile brute ale cookie-urilor _fbp, _fbc și _ttp, acolo unde acestea există — din parametrii URL și din cookie-urile de pe pagina de destinație
• Metadate de eveniment: marcajul temporal al înregistrării, identificatorul de eveniment (pentru deduplicarea față de pixelul din browser), URL-ul paginii de destinație și URL-ul de proveniență

Operațiunea 2 — vizualizare de pagină pe server, la fiecare vizită pe o pagină de destinație:

• Adresa IP brută a clientului și User-Agent-ul brut
• URL-ul paginii, identificatorul de click fbclid și valorile cookie-urilor _fbp / _fbc, acolo unde acestea există; în lipsa cookie-ului — situație întâlnită la vizitatorul care nu a acceptat cookie-urile publicitare — se folosește exclusiv identificatorul de click pentru a reconstitui o valoare fbc
• Identificatorul de eveniment, pentru deduplicarea față de pixelul din browser

NU se prelucrează:

• Adresa de e-mail sau numele în clar (transformate în hash înainte de transmitere); niciun număr de telefon nu este transmis. Identificatorul înregistrării nu intră în această categorie: Meta îl primește fără hash
• Mesajele de chat, voturile la sondaje, click-urile pe oferte (nu sunt transmise platformelor publicitare)

Vizualizarea de pagină pe server nu este, în mod deliberat, oglindită către TikTok, întrucât PageView nu figurează pe lista de evenimente standard a TikTok.

Scopurile Prelucrării

• Atribuirea campaniilor publicitare: corelarea înregistrărilor și a vizitelor pe paginile de destinație cu click-urile pe reclame, pentru măsurarea randamentului cheltuielilor publicitare
• Optimizarea audienței: platformele publicitare folosesc datele transmise pentru îmbunătățirea targetării (audiențe similare, retargetare)

Nu se efectuează nicio prelucrare de tip listă de excludere. Nicio adresă de e-mail sub formă de hash nu este încărcată în Meta Custom Audiences ori în vreo altă interfață de gestionare a audiențelor, nicio audiență negativă sau de suprimare nu este menținută la vreo platformă publicitară, iar finalizarea unei ștergeri în temeiul GDPR nu generează niciun apel către Meta ori către TikTok. Singurele integrări existente sunt cei doi expeditori de conversii descriși mai sus, care transmit fără confirmare de primire.

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

Prezentul document arăta anterior că adresele de e-mail sub formă de hash sunt încărcate în Meta Custom Audiences drept audiențe negative, pentru ca persoanele înregistrate, cele care au refuzat și cele șterse să fie excluse din targetarea publicitară, și prezenta acea excludere drept garanție care operează în interesul persoanei vizate. Niciun apel de gestionare a audiențelor nu este efectuat către vreo platformă publicitară, iar ștergerea nu declanșează nicio comunicare către Meta sau TikTok, deci o astfel de excludere nu are loc. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Temeiul Juridic (determinat de Operator)

Interes legitim (art. 6 alin. (1) lit. (f) GDPR) pentru ambele operațiuni. Evenimentele de conversie pe server și vizualizările de pagină pe server sunt transmise independent de orice decizie în bannerul de cookie-uri. A se vedea DPIA, Secțiunea 3.3, pentru testul de echilibru; ⚠️ acel test a fost întocmit pentru persoana care ajunge printr-un click publicitar și se înregistrează ulterior; el nu tratează operațiunea 2, care atinge fiecare vizitator al unei pagini de destinație, inclusiv pe cei ce nu se înregistrează niciodată.

Restricționarea prelucrării în temeiul art. 18 GDPR reprezintă suprimarea operativă pentru operațiunea 1: pentru un contact restricționat nu se transmite niciun eveniment de conversie. Operațiunea 2 nu beneficiază de nicio suprimare, întrucât vizitatorul nu este încă identificat drept contact.

Pe fișa de înregistrare este colectată și stocată în continuare o valoare advertising_consent, însă nicio cale de cod nu o citește drept condiție a vreunei transmiteri. Ea constituie un instantaneu al stării bannerului la momentul înregistrării, folosit exclusiv pentru audit, și nu produce niciun efect asupra prelucrării.

Transparență: ⚠️ Politica de Confidențialitate arată că platformelor publicitare le sunt transmise adrese de e-mail și nume sub formă de hash, iar nu în clar. Ea nu divulgă faptul că se transmit deopotrivă adresa IP brută și User-Agent-ul brut, faptul că transmiterea nu este condiționată de consimțământul publicitar și nici faptul că se transmite o vizualizare de pagină pentru fiecare vizitator al unei pagini de destinație. Politica de Confidențialitate trebuie corectată înainte ca prezentul registru să fie invocat.

Destinatari

• Meta Platforms, Inc. (SUA) — Meta Conversions API: CompleteRegistration la înregistrare și PageView la fiecare vizită pe o pagină de destinație. Activ.
• TikTok Pte. Ltd. (SUA/Singapore) — TikTok Events API: CompleteRegistration la înregistrare. Activ începând cu 8 mai 2026.
• Google LLC (SUA) — Google Ads Enhanced Conversions: neimplementat; nu primește nicio dată.
• LinkedIn Corporation (SUA) — LinkedIn Conversions API: neimplementat; nu primește nicio dată.

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

Prezentul Registru al Activităților de Prelucrare descria anterior TikTok Events API drept o integrare viitoare. Integrarea pe partea de server funcționează începând cu 8 mai 2026 și transmite către TikTok, la fiecare înregistrare, identificatori de contact sub formă de hash împreună cu adresa IP și User-Agent-ul participantului, în formă brută, fără un DPA sau Clauze Contractuale Standard la dosar și fără nicio condiție de consimțământ publicitar. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Transferuri Internaționale

Toate transferurile către SUA (Meta) și către SUA / Singapore (TikTok):

• Garanții: Meta — Clauze Contractuale Standard (2021) și transformarea în hash a câmpurilor direct identificatoare. TikTok — ⚠️ nicio Clauză Contractuală Standard și niciun DPA la dosar, exclusiv transformarea în hash a câmpurilor direct identificatoare.
• ⚠️ Adresele IP brute și User-Agent-urile brute sunt transmise fără hash către ambele platforme, astfel încât descrierea acestor transferuri drept minimizare a datelor, cu date exclusiv sub formă de hash, nu se mai susține.
• Evaluarea impactului transferului: trebuie repetată pentru a acoperi TikTok Pte. Ltd. și transmiterea adreselor IP și a User-Agent-urilor fără hash.

Perioada de Retenție

De către [PLATFORM PROVIDER]: evenimentele de conversie și vizualizările de pagină sunt transmiteri fără confirmare de primire; niciun tabel local de evenimente nu le consemnează. Datele subiacente de înregistrare și de funnel sunt păstrate astfel cum se arată la Activitățile de Prelucrare 1 și 5. De către platformele publicitare: 7-28 de zile (în conformitate cu politicile fiecărei platforme; de exemplu, Meta păstrează datele sub formă de hash 7 zile pentru potrivire, apoi le șterge)

Măsuri de Securitate

• Transformare în hash înainte de transmitere: SHA-256, cu preprocesare prin conversie în minuscule și eliminarea spațiilor de la capete (standard în industrie pentru API-urile de conversie), aplicată adresei de e-mail, prenumelui și numelui de familie și — numai pentru TikTok — identificatorului extern. Pe această cale nu se transmite niciun număr de telefon: câmpul este lăsat gol la compunerea evenimentului, oricare ar fi numărul păstrat pe contact. Adresa IP și User-Agent-ul nu sunt transformate în hash, iar Meta primește identificatorul extern fără hash.
• Apeluri API HTTPS: toate evenimentele de conversie sunt transmise prin TLS 1.2+ (criptate în tranzit)
• Deduplicarea evenimentelor: event_id împiedică dubla contorizare între pixelul din browser și evenimentul de pe server
• Suprimare: contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR sunt excluse de la operațiunea 1.

Pixelii publicitari client-side. 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Ă.

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.

Google Tag Manager, Google Analytics și Microsoft Clarity nu sunt afectate de clasificarea de mai sus. Google Analytics nu este implementat de [PLATFORM PROVIDER]: niciun tag Analytics nu este emis, iar Analytics ajunge la un vizitator numai printr-un container Google Tag Manager pe care organizația-client îl configurează ori printr-un script pe care aceasta îl introduce în setările sale de scripturi de urmărire. Semnalele Google Consent Mode v2 de refuz implicit pentru analytics_storage, ad_storage, ad_user_data și ad_personalization sunt emise numai alături de un astfel de container și guvernează exclusiv tag-urile din interiorul lui; ele nu au guvernat niciodată Meta Pixel, TikTok Pixel sau tag-ul Microsoft Clarity, injectate direct. Microsoft Clarity este încadrat drept script de analiză care se încarcă numai după consimțământul pentru analiză și este omis integral în aplicația pentru participanți.

Vizualizarea de pagină pe server, către Meta. Independent de pixelii din browser, pentru fiecare vizitator uman al unei pagini de destinație a unui funnel se transmite, pe partea de server, o vizualizare de pagină prin Meta Conversions API, atunci când organizația a activat integrarea Meta. Aceasta poartă adresa IP brută a vizitatorului, user agent-ul brut, URL-ul paginii, identificatorul de click fbclid și valorile cookie-urilor _fbp / _fbc, acolo unde acestea există; în lipsa cookie-ului — situație întâlnită la vizitatorul care nu a acceptat cookie-urile publicitare — se folosește exclusiv identificatorul de click pentru a reconstitui o valoare fbc. Pe această cale nu există nicio verificare a consimțământului; singura condiție este ca organizația să fi activat integrarea Meta.

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

Prezentul Registru al Activităților de Prelucrare limita anterior prezenta activitate la participanții care acceptaseră cookie-urile publicitare și se înregistraseră la un eveniment și arăta că evenimentele de conversie se transmit o singură dată, la înregistrare. Către Meta se transmite o vizualizare de pagină pe server, care poartă adresa IP brută și User-Agent-ul brut ale vizitatorului, pentru fiecare vizitator uman al unei pagini de destinație a unui funnel, indiferent dacă acesta se înregistrează sau nu și independent de orice decizie în bannerul de cookie-uri, iar testul de echilibru invocat pentru prezenta activitate nu acoperă persoanele care nu se înregistrează. Această neconcordanță este consemnată în registrul de remediere a conformității; clasificarea face obiectul unei analize.

---

Activitatea de Prelucrare 4: Gestionarea Drepturilor Persoanelor vizate în temeiul GDPR

Denumirea și Descrierea Prelucrării

Cereri privind drepturile persoanelor vizate: soluționarea cererilor de acces, de ștergere, de portabilitate, de opoziție și de restricționare în numele organizațiilor-client. Rectificarea se efectuează ca acțiune operațională — un membru al personalului modifică fișa contactului ori Persoana vizată folosește fluxul public de schimbare a adresei — dar nu poate fi consemnată în registrul cererilor, întrucât registrul respinge rectification drept tip de cerere. Prin urmare, o rectificare este dovedită exclusiv prin jurnalul de audit.

Operatorul (Operatorii) de Date

Organizațiile-client ([PLATFORM PROVIDER] asistă în calitate de Persoană împuternicită de operator)

Categoriile de Persoane Vizate

Participanți la evenimente care depun cereri în temeiul GDPR

Categoriile de Date cu Caracter Personal Prelucrate

• Categoriile incluse în exportul în temeiul art. 15 și al art. 20 GDPR: fișa contactului, înregistrările, evenimentele comportamentale, consimțămintele, evenimentele de consimțământ, apartenența la segmente, evidențele de livrare a e-mailurilor, evidențele de livrare push, token-urile de dispozitiv, scorurile de calificare, datele cu caracter personal ale contactului din Firestore, consimțămintele din Firestore și înregistrările din Firestore, precum și evidențele contactului din sesiunile live.
• ⚠️ Exportul nu acoperă fiecare categorie consemnată în prezentul document. Intrările în funnel — unde se află toți parametrii de campanie, identificatorii de click, URL-ul paginii de destinație și cel de proveniență, țara, orașul și datele de dispozitiv — sunt omise, la fel ca jurnalul de livrare a SMS-urilor, jurnalul destinatarilor difuzărilor către segmente, jurnalul joburilor de generare cu AI, vizualizările de pagină ale funnel-urilor, înscrierile în automatizări și execuțiile pașilor, precum și fiecare obiect din Cloud Storage.
• Metadate ale cererii în temeiul GDPR:
  • Tipul cererii — registrul acceptă access, deletion, portability, objection și restriction. rectification este respins și nu poate fi consemnat.
  • Data cererii, data soluționării
  • Detalii de verificare a identității Persoanei vizate (confirmare prin e-mail)

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

Prezentul document arăta anterior că o cerere de acces produce un export integral al tuturor categoriilor de la Activitățile de Prelucrare 1-3 și enumera rectificarea printre tipurile de cereri pe care registrul le conține. Exportul omite intrările în funnel și, prin urmare, toate datele de atribuire, geografice și de dispozitiv, precum și evidențele de livrare SMS, evidențele difuzărilor către segmente, evidențele de automatizare și evidențele de generare cu AI; iar o cerere de rectificare este respinsă de registru și poate fi dovedită numai prin jurnalul de audit. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Scopurile Prelucrării

• Obligație legală (art. 6 alin. (1) lit. (c) GDPR): îndeplinirea obligațiilor Operatorului de date în temeiul art. 15-22 GDPR

Destinatari

• Organizația-client (Operator de date) — exportul JSON este returnat membrului personalului care a soluționat cererea
• Persoana vizată — livrarea ulterioară a exportului sau a unei confirmări către Persoana vizată este efectuată de organizația-client; platforma nu transmite ea însăși Persoanei vizate niciun export și nicio confirmare

Perioada de Retenție

Evidențele cererilor în temeiul GDPR: fără ștergere automată. Registrul cererilor nu se numără printre tipurile de date pe care jobul de retenție le recunoaște și nimic altceva din platformă nu șterge din el, astfel încât evidențele sunt păstrate pe termen nelimitat, cu titlu de dovadă de responsabilitate în temeiul art. 5 alin. (2) GDPR. Datele exportate: exportul este returnat inline, în răspunsul la cererea de soluționare; niciun fișier nu este stocat pe sistemele [PLATFORM PROVIDER] și niciun link de descărcare nu este emis. Orice copie păstrată ulterior se află la membrul personalului sau la Persoana vizată care a primit-o.

Măsuri de Securitate

• Verificarea identității: link de confirmare transmis prin e-mail (la adresa de e-mail înregistrată)
• Transport: exportul este returnat în format JSON, prin TLS, în răspunsul la cererea de soluționare. Nu există niciun link de descărcare cu termen de expirare și niciun fișier de export stocat separat.
• Jurnalizare de audit: toate acțiunile aferente cererilor în temeiul GDPR sunt consemnate în jurnal (cine a soluționat, când, ce date au fost exportate sau șterse). Intrările de audit create de acest flux consemnează în metadatele lor hash-ul adresei de e-mail a persoanei vizate, care supraviețuiește, prin urmare, unei ștergeri.
• Control al accesului: soluționarea unei cereri în temeiul GDPR impune grupul de permisiuni setări, pe care îl deține numai rolul admin. Crearea unei cereri este deschisă oricărui utilizator autentificat din personal, inclusiv rolului staff, de tip „doar citire".

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

Prezentul document arăta anterior că datele exportate sunt păstrate paisprezece zile și puse la dispoziție printr-un link de descărcare securizat, cu termen de expirare, că registrul cererilor este golit la trei ani de la soluționare, cu anonimizarea datelor Persoanei vizate, și că numai administratorii pot acționa asupra cererilor. Niciun mecanism de link de descărcare nu există — exportul este returnat inline; registrul nu este golit niciodată și nicio rutină de anonimizare nu există; iar orice utilizator autentificat din personal, inclusiv unul cu acces de tip „doar citire", poate crea o cerere. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

Activitatea de Prelucrare 5: Operarea Funnel-urilor, Atribuirea Campaniilor și Măsurarea Paginilor de Destinație

Denumirea și Descrierea Prelucrării

Funnel-uri de achiziție: operarea unor funnel-uri de achiziție cu mai mulți pași — pagini publice de destinație și de înregistrare, link-uri urmărite de distribuire și de redirecționare, măsurarea vizitatorilor unici pe paginile funnel-ului și webhook-uri de intrare pentru comenzi și formulare — precum și atribuirea contactelor și a conversiilor către campaniile de marketing.

Operatorul (Operatorii) de Date

Organizațiile-Client (a se vedea Activitatea de Prelucrare 1).

Categoriile de Persoane Vizate

• Vizitatorii paginilor de destinație ale funnel-urilor Clientului, indiferent dacă se înregistrează sau nu
• Participanții la evenimente și persoanele înregistrate
• Cumpărătorii din magazinul de comerț electronic al Clientului, atunci când este configurat un webhook de comenzi

Categoriile de Date cu Caracter Personal

• Identificator pseudonim de vizitator: un hash SHA-256 al adresei IP și al user agent-ului vizitatorului, consemnat o singură dată pe vizitator, pe pas de funnel și pe zi. Hash-ul este stabil în timp — același vizitator produce aceeași valoare la fiecare vizită — și constituie, prin urmare, un identificator pseudonim persistent.
• Date de atribuire pe intrarea în funnel, asociate contactului: utm_source, utm_medium, utm_campaign, utm_content, utm_term, identificatorul de click publicitar și platforma de click, URL-ul paginii de destinație, URL-ul de proveniență și metadate de atribuire în format liber.
• Dispozitiv și localizare aproximativă, asociate contactului: codul de țară, orașul, tipul dispozitivului, sistemul de operare, browserul și fusul orar al browserului. Adresa IP în sine este folosită numai pentru a deduce țara și orașul și nu este stocată pe intrarea în funnel.
• Lanț de recomandare: sursa de recomandare și identificatorul link-ului de distribuire care a adus contactul.
• Payload-uri de webhook: pentru webhook-urile generice și pentru cele ale furnizorilor de formulare, întregul corp brut al cererii este stocat ca metadate ale intrării și poate conține răspunsuri arbitrare de formular. Pentru webhook-urile de comenzi din comerțul electronic, adresa de e-mail a cumpărătorului este folosită pentru a identifica un contact existent, iar identificatorul comenzii, valoarea totală, moneda și starea plății sunt stocate ca metadate ale intrării — categorie de date privind achizițiile și tranzacțiile, provenită din magazinul Clientului, iar nu colectată de la persoana vizată.

Scopurile Prelucrării

• Măsurarea vizitatorilor unici și a ratelor de conversie pentru fiecare pas al unui funnel
• Atribuirea înregistrărilor și a achizițiilor către campaniile de marketing și către link-uri individuale de distribuire
• Declanșarea automatizărilor ulterioare la trimiterea unui formular

Temeiul Juridic (determinat de Operator)

Determinat de Client în calitate de Operator. Astfel cum este implementată, măsurarea vizitatorilor unici și consemnarea click-urilor pe link-uri urmărite funcționează fără nicio condiție de consimțământ și se întemeiază pe interesul legitim (art. 6 alin. (1) lit. (f)); migrarea-sursă descrie pixelul de vizualizare a paginii ca fiind scutit de consimțământ. Trimiterea formularului se întemeiază pe consimțământul consemnat ca data_processing și tos_acceptance, colectat împreună, în spatele unei singure bife.

Destinatari

• Organizația-Client (Operator)
• Subîmputerniciți: Railway (PostgreSQL), Google LLC (Firestore, Cloud Storage), Cloudflare
• Meta Platforms, Inc., care primește, pe partea de server, o vizualizare de pagină cu adresa IP brută și user agent-ul brut ale vizitatorului, pentru fiecare vizită pe o pagină de destinație unde integrarea Meta este activată
• Destinația oricărui link urmărit. Atunci când un vizitator urmează o redirecționare urmărită, platforma transmite mai departe, către URL-ul de destinație, parametrii de campanie și identificatorii de click publicitar — utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, ttclid, li_fat_id, sursa de recomandare — iar acest URL aparține frecvent unui site terț
• Surse de intrare: platforma de comerț electronic sau de formulare a Clientului (MerchantPro, WooCommerce, Tally sau un expeditor generic), care transmite date cu caracter personal către platformă

Transferuri Internaționale

Identice cu cele de la Activitatea de Prelucrare 1, la care se adaugă transferurile către Meta Platforms, Inc. (SUA) pe calea vizualizării de pagină de pe server, precum și orice transfer implicat de destinația aleasă de Client pentru link-ul urmărit.

Perioada de Retenție

Fără ștergere automată. Nici intrările în funnel, nici vizualizările de pagină ale funnel-urilor nu se numără printre tipurile de date pe care jobul de retenție le recunoaște și niciunele nu pot fi configurate din ecranul de setări pentru retenție. Intrările în funnel sunt șterse la ștergerea fișei de contact a persoanei vizate și la ștergerea funnel-ului din care fac parte; vizualizările de pagină ale funnel-urilor sunt eliminate numai la ștergerea funnel-ului sau a pasului din care fac parte și nu sunt atinse de fluxul de ștergere, întrucât nu poartă nicio legătură cu un contact.

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

Subsistemul de funnel-uri lipsea din prezentul Registru al Activităților de Prelucrare și din Politica de Retenție a Datelor. Intrările în funnel poartă date de campanie, de dispozitiv și de localizare aproximativă, asociate unui contact identificat, iar vizualizările de pagină ale funnel-urilor poartă un identificator pseudonim persistent de vizitator, derivat din adresa IP și din user agent-ul acestuia și colectat fără nicio condiție de consimțământ; niciuna dintre aceste categorii nu are o perioadă de retenție aplicată automat, iar intrările în funnel sunt omise din exportul de date în temeiul art. 15 și al art. 20. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1. Se reține că interogările publice de rezolvare a token-urilor, folosite de link-urile urmărite, de vizualizările de pagină ale funnel-urilor și de webhook-urile de funnel, rulează pe conexiunea privilegiată de bază de date, care nu este supusă Row Level Security, deoarece un token opac trebuie rezolvat înainte de a cunoaște organizația.

---

Activitatea de Prelucrare 6: Parcursuri Automate ale Contactelor (Automatizări)

Denumirea și Descrierea Prelucrării

Automatizări: înscrierea contactelor în parcursuri configurabile, declanșate de trimiterea unui formular, de înregistrarea la un webinar, de intrarea într-un segment, de deschiderea unei sesiuni sau de o acțiune manuală, urmată de executarea unei secvențe ordonate de pași de așteptare și de acțiune asupra contactului respectiv.

Operatorul (Operatorii) de Date

Organizațiile-Client (a se vedea Activitatea de Prelucrare 1).

Categoriile de Persoane Vizate

Contactele înscrise într-o automatizare — în practică, persoane înregistrate, persoane aflate pe lista de așteptare și membri ai segmentelor.

Categoriile de Date cu Caracter Personal

• Evidența înscrierii: identificatorul contactului, pasul curent, starea, marcajele temporale de înscriere și de finalizare și o copie JSON a evenimentului declanșator
• Evidența execuției fiecărui pas: starea, marcajul temporal al execuției și un document JSON cu rezultatul
• Documentul cu rezultatul execuției unui pas conține adresa de e-mail în clar a destinatarului pentru pașii de e-mail și numărul său de telefon în clar pentru pașii de SMS, deci păstrează în PostgreSQL date direct identificatoare

Scopurile Prelucrării

• Transmiterea de e-mailuri și SMS-uri de urmărire, după un calendar raportat la un declanșator
• Adăugarea contactelor în segmente și eliminarea lor din segmente
• Înregistrarea contactelor la o sesiune, în numele acestora

Temeiul Juridic (determinat de Operator)

Determinat de Client în calitate de Operator. Astfel cum sunt implementați, pașii de e-mail sunt condiționați numai de faptul că respectivul contact nu este suprimat pentru bounce, reclamație sau dezabonare globală și nu face obiectul unei restricționări a prelucrării în temeiul art. 18 — nu se verifică niciun consimțământ de marketing — și se întemeiază, prin urmare, pe necesitatea executării serviciului ori pe interesul legitim. Pașii de SMS impun, suplimentar, un consimțământ sms_notifications acordat și neretras.

Destinatari

• Organizația-Client (Operator)
• NewsmanApp SRL (livrare e-mail)
• SendSMS.ro (livrare SMS)
• Subîmputerniciți: Railway (PostgreSQL), Google LLC

Transferuri Internaționale

Identice cu cele de la Activitatea de Prelucrare 1. Livrarea e-mailurilor și a SMS-urilor se realizează în interiorul UE.

Perioada de Retenție

Fără ștergere automată. Niciunul dintre cele patru tabele de automatizări nu se numără printre tipurile de date pe care jobul de retenție le recunoaște. Înscrierile sunt asociate fișei contactului și sunt eliminate în cascadă la ștergerea contactului, iar evidențele de execuție a pașilor sunt eliminate în cascadă din înscriere — acesta este singurul mecanism care elimină adresele de e-mail și numerele de telefon în clar păstrate în documentele cu rezultatul pașilor. Definițiile automatizărilor și ale pașilor persistă pe toată durata de existență a organizației.

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

Subsistemul de automatizări lipsea din prezentul Registru al Activităților de Prelucrare, din Politica de Retenție a Datelor și din documentația privind ștergerea. Evidențele de execuție a pașilor de automatizare păstrează în PostgreSQL adresa de e-mail și numărul de telefon ale destinatarului, în clar, ceea ce se abate de la limita arhitecturală descrisă în alte părți ale prezentului document, potrivit căreia PostgreSQL păstrează numai identificatori pseudonimizați. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1, cu Row Level Security aplicat tuturor celor patru tabele de automatizări.

---

Activitatea de Prelucrare 7: Generarea de Conținut Asistată de AI

Denumirea și Descrierea Prelucrării

Generare cu AI: generarea și rafinarea brief-urilor de pagină de destinație, a codului HTML al paginilor de destinație și a textelor de marketing, precum și generarea întrebărilor pentru sondajele din webinare, prin transmiterea unui prompt compus de personal către un furnizor terț de modele lingvistice de mari dimensiuni și prin stocarea promptului și a rezultatului modelului.

Operatorul (Operatorii) de Date

Organizațiile-Client (a se vedea Activitatea de Prelucrare 1). Se reține că furnizorul modelului este angajat de [PLATFORM PROVIDER] printr-o unică acreditare la nivel de platformă, iar nu de Client.

Categoriile de Persoane Vizate

• Participanții la evenimente care au transmis un testimonial aprobat de personal
• Persoanele înfățișate în imaginile de referință încărcate de personal, dacă există
• Membrii personalului Clientului care inițiază o generare

Categoriile de Date cu Caracter Personal

• Testimoniale aprobate ale participanților — numele afișat, citatul în format liber, denumirea companiei și nota acordată — încorporate în promptul de generare
• Imagini de referință încărcate de personal din biblioteca media a organizației, transmise inline; acestea sunt materiale de marketing ale Clientului și pot înfățișa persoane identificabile
• Text extras din pagini de referință terțe indicate de un membru al personalului
• Denumirea organizației, titlul, descrierea și tipul webinarului, brief-ul paginii și instrucțiunile personalizate redactate de personal
• Identificatorul membrului personalului care a inițiat generarea și al celui care a acceptat-o
• Promptul de sistem, promptul utilizatorului și rezultatul modelului, în integralitatea lor, păstrate în PostgreSQL

Scopurile Prelucrării

• Producerea de texte de marketing și de cod pentru paginile de destinație ale campaniilor Clientului
• Producerea întrebărilor pentru sondajele dintr-un webinar
• Urmărirea costurilor, versionarea și reproductibilitatea generărilor

Temeiul Juridic (determinat de Operator)

Determinat de Client în calitate de Operator. Astfel cum este implementată, generarea este o acțiune inițiată de personal, întemeiată pe interesul legitim de a produce conținut de marketing (art. 6 alin. (1) lit. (f)). Autorului testimonialului nu i se solicită niciun consimțământ pentru transmiterea către furnizorul modelului, iar pe această cale nu există nicio condiție de consimțământ.

Destinatari

• Anthropic PBC (SUA) — furnizorul modelului, angajat de [PLATFORM PROVIDER] în calitate de subîmputernicit
• Operatorii oricărei pagini de referință terțe indicate de un membru al personalului, care primesc o cerere din partea modulului de extragere al platformei
• Subîmputerniciți: Railway (PostgreSQL), Google LLC

Transferuri Internaționale

SUA — prompturile și imaginile sunt transmise către Anthropic PBC, la api.anthropic.com. Mecanismul de transfer trebuie confirmat; a se vedea Anexa III, subîmputernicitul 11.

Perioada de Retenție

Fără ștergere automată. Tabelul joburilor de generare nu se numără printre tipurile de date pe care jobul de retenție le recunoaște, iar rândurile sale nu sunt asociate unei fișe de contact, deci nu sunt eliminate nici de fluxul de ștergere, nici în cascadă. Prin urmare, citatul unui testimonial și numele autorului său persistă în promptul și în rezultatul stocate și după ștergerea contactului.

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

Generarea de conținut asistată de AI lipsea din prezentul Registru al Activităților de Prelucrare, iar furnizorul modelului lipsea din anexa subîmputerniciților. Testimonialele aprobate ale participanților — numele autorului și citatul în format liber — sunt transmise unui furnizor de modele din Statele Unite fără un consimțământ specific și fără informarea acestuia, iar promptul și rezultatul stocate nu sunt atinse de fluxul de ștergere, astfel încât acel conținut supraviețuiește unei ștergeri în temeiul art. 17. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1. Cererile sunt efectuate pe partea de server, prin TLS; niciun dispozitiv al participanților nu contactează furnizorul modelului și nu sunt implicate cookie-uri.

---

Activitatea de Prelucrare 8: Notificări SMS

Denumirea și Descrierea Prelucrării

Mesagerie tranzacțională: transmiterea notificărilor de reamintire pentru webinar, a mesajelor „începe acum" și „replay disponibil", precum și a pașilor SMS din automatizări, către participanții care au furnizat un număr de telefon și au optat pentru primirea acestora, împreună cu consemnarea rezultatelor de livrare și de click.

Operatorul (Operatorii) de Date

Organizațiile-Client (a se vedea Activitatea de Prelucrare 1).

Categoriile de Persoane Vizate

Persoanele înregistrate și participanții care au furnizat un număr de telefon și dețin un consimțământ sms_notifications.

Categoriile de Date cu Caracter Personal

• Numărul de telefon, în clar, citit din documentul Firestore cu datele cu caracter personal ale contactului la momentul trimiterii și transmis furnizorului de mesagerie. Nu este stocat niciodată în PostgreSQL.
• Corpul mesajului, care conține titlul webinarului, timpul rămas până la începere sau termenul-limită al replay-ului și un URL de acces urmărit, individualizat pentru fiecare destinatar
• Evidența livrării: hash-ul adresei de e-mail, identificatorii webinarului și ai sesiunii, tipul de șablon, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării, textul erorii și marcajele temporale de livrare și de click

Scopurile Prelucrării

• Anunțarea persoanelor înregistrate că un webinar urmează să înceapă, că este în desfășurare sau că a devenit disponibil un replay
• Executarea pașilor de SMS din cadrul unei automatizări
• Măsurarea succesului livrării și a ratei de click

Temeiul Juridic (determinat de Operator)

Consimțământ (art. 6 alin. (1) lit. (a)) — 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. Pe formularul public de funnel, însă, acest consimțământ este acordat implicit prin simpla prezență a unui număr de telefon în formular; nu există o bifă separată pentru SMS.

Destinatari

• SendSMS.ro (România) — furnizorul de mesagerie
• Operatorul de rețea mobilă al destinatarului
• Subîmputerniciți: Railway (PostgreSQL), Google LLC (Firestore, Secret Manager)

Transferuri Internaționale

Mesajele sunt transmise către un endpoint din România (UE). Pe această cale nu intervine niciun transfer în afara SEE.

Perioada de Retenție

Fără ștergere automată în practică. Jobul de aplicare a retenției poate goli în funcție de vechime jurnalul de livrare a SMS-urilor, însă lista tipurilor de date configurabile din API nu îl include, astfel încât nicio organizație nu poate configura acea politică din produs. În plus, jurnalul de livrare nu este eliminat de fluxul de ștergere — este cheiat pe hash-ul adresei de e-mail, fără cheie străină către fișa contactului — și nu este inclus în exportul de date în temeiul art. 15.

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

Notificările prin SMS lipseau din prezentul Registru al Activităților de Prelucrare și din Politica de Retenție a Datelor, iar furnizorul de mesagerie lipsea din anexa subîmputerniciților. Jurnalul de livrare a SMS-urilor nu este eliminat de fluxul de ștergere și nu este inclus în exportul de date în temeiul art. 15, astfel încât o evidență individuală a mesajelor trimise persistă după o ștergere în temeiul art. 17. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1, la care se adaugă: acreditări per organizație păstrate în Google Secret Manager și o verificare a consimțământului și a restricționării prelucrării înaintea fiecărei trimiteri. Se reține că API-ul furnizorului este apelat prin TLS, cu numărul de telefon al destinatarului, corpul mesajului și parola contului transmise ca parametri în șirul de interogare, care trebuie presupuși consemnați în jurnalele de cereri ale furnizorului, precum și că jurnalele de aplicație ale platformei consemnează numărul de telefon al destinatarului atunci când o trimitere eșuează.

---

Activitatea de Prelucrare 9: Difuzări către Segmente

Denumirea și Descrierea Prelucrării

Difuzări către segmente: compunerea unui e-mail unic — subiect, titlu, corp și îndemn la acțiune — și transmiterea acestuia membrilor unui segment salvat, cu consemnarea fiecărui destinatar, astfel încât o retrimitere sub aceeași cheie de campanie să ajungă numai la membrii care nu l-au primit deja.

Operatorul (Operatorii) de Date

Organizațiile-Client (a se vedea Activitatea de Prelucrare 1).

Categoriile de Persoane Vizate

Contactele care sunt membre ale segmentului selectat la momentul trimiterii.

Categoriile de Date cu Caracter Personal

• Identificarea destinatarului: hash-ul adresei de e-mail, identificatorul segmentului, cheia de campanie și marcajul temporal al trimiterii
• Conținutul mesajului: subiectul, titlul, corpul, eticheta și URL-ul îndemnului la acțiune și identificatorul membrului personalului care l-a compus
• Adresa de e-mail în clar și numele destinatarului sunt preluate din Firestore la momentul trimiterii și transmise furnizorului de e-mail; ele nu sunt stocate în niciunul dintre cele două tabele de difuzare
• Atunci când segmentul este exportat în loc să fie difuzat, fișierul de export conține adresa de e-mail în clar și numele fiecărui membru

Scopurile Prelucrării

• Transmiterea unei comunicări unice către un public determinat
• Prevenirea livrării duplicate la o retrimitere
• Reîncărcarea și reutilizarea conținutului unei difuzări anterioare

Temeiul Juridic (determinat de Operator)

Determinat de Client în calitate de Operator. Astfel cum este implementată, nu se verifică niciun consimțământ de marketing: interogarea destinatarilor filtrează numai după faptul că respectivul contact nu face obiectul unei restricționări a prelucrării în temeiul art. 18 și nu este suprimat pentru bounce, reclamație sau dezabonare globală. Funcționalitatea este documentată intern ca fiind un canal tranzacțional, iar răspunderea pentru utilizarea ei drept canal de marketing revine expeditorului. Este pusă la dispoziție, suplimentar, o condiție de segmentare care selectează exact acele contacte care nu dețin nicio acordare activă pentru un anumit scop, ceea ce face posibilă construirea și adresarea unui public format din contacte care au refuzat consimțământul de marketing.

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

Prezentul Registru al Activităților de Prelucrare descria anterior consimțământul de marketing drept condiție a oricărei comunicări de marketing. Canalul de difuzare către segmente transmite mesaje membrilor segmentului fără a verifica vreun scop de consimțământ de marketing, iar produsul pune la dispoziție o condiție de segmentare care selectează contactele fără nicio acordare activă pentru un anumit scop, ceea ce permite adresarea contactelor care au refuzat consimțământul de marketing. Singurele limite aplicate efectiv sunt restricționarea prelucrării în temeiul art. 18 și indicatorii de suprimare pentru bounce, reclamație și dezabonare globală. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Destinatari

• NewsmanApp SRL (livrare e-mail)
• Organizația-Client (Operator), inclusiv în calitate de destinatar al exporturilor CSV de segmente
• Subîmputerniciți: Railway (PostgreSQL), Google LLC (Firestore)

Transferuri Internaționale

Identice cu cele de la Activitatea de Prelucrare 1. Livrarea e-mailurilor se realizează în interiorul UE.

Perioada de Retenție

Fără ștergere automată. Nici tabelul cu conținutul difuzărilor, nici jurnalul destinatarilor nu se numără printre tipurile de date pe care jobul de retenție le recunoaște. Jurnalul destinatarilor este cheiat pe hash-ul adresei de e-mail, fără cheie străină către fișa contactului, deci nu este eliminat nici de fluxul de ștergere, nici în cascadă, și nu este inclus în exportul de date în temeiul art. 15.

Măsuri de Securitate

Identice cu cele de la Activitatea de Prelucrare 1. Exporturile de segmente și difuzările sunt consemnate în jurnalul de audit.

---

Subîmputerniciți

A se vedea Anexa III: Lista Subîmputerniciților (document separat: annex-sub-processors.md).

[PLATFORM PROVIDER] angajează unsprezece subîmputerniciți, enumerați în Anexa III.

Rezumat:

1. Google LLC (Firebase, Google Cloud) — Baze de date, autentificare, funcții cloud, stocare, Secret Manager (păstrează acreditările FCM și de mesagerie ale fiecărei organizații). Notă: livrarea push prin FCM utilizează proiectele Firebase furnizate de Client — a se vedea secțiunea „Integrări Furnizate de Client" din Anexa III.
2. Railway Corp. — Găzduire PostgreSQL (contacte, evenimente comportamentale, consimțăminte, device_tokens, push_sends, sms_sends, intrări în funnel și vizualizări de pagină, evidențe de automatizare, joburi de generare cu AI, difuzări către segmente), găzduire API, găzduire aplicații
3. NewsmanApp SRL — Livrarea e-mailurilor tranzacționale și de marketing, sincronizarea în masă a abonaților și returnarea evenimentelor de vizualizare, click, bounce, reclamație și dezabonare
4. Meta Platforms, Inc. — Urmărirea conversiilor publicitare la înregistrare și o vizualizare de pagină pe server la fiecare vizită pe o pagină de destinație (opt-in pentru fiecare organizație; nicio condiție de consimțământ al participantului)
5. Google LLC (Google Ads) — Urmărirea conversiilor publicitare: neimplementată; nu primește nicio dată
6. TikTok Pte. Ltd. — Urmărirea conversiilor publicitare: activă începând cu 8 mai 2026 (opt-in pentru fiecare organizație; nicio condiție de consimțământ al participantului)
7. LinkedIn Corporation (Microsoft) — neimplementată; nu primește nicio dată
8. Cloudflare, Inc. — Proxy invers obligatoriu, aflat pe traseul cererilor, pentru domeniile participanților, plus protecția Turnstile împotriva boților pe paginile de destinație publicate
9. Microsoft Corporation, contractată pentru clienții din UE prin Microsoft Ireland Operations Limited (MIOL) — Microsoft Clarity, înregistrări de sesiune și heatmap-uri, acolo unde Clientul activează serviciul
10. SendSMS.ro — transmiterea SMS-urilor tranzacționale și rapoartele de livrare.
11. Anthropic PBC — Generare cu AI de brief-uri pentru pagini de destinație, de cod HTML pentru pagini de destinație, de texte de marketing și de întrebări pentru sondaje, angajată de [PLATFORM PROVIDER] printr-o singură acreditare la nivel de platformă

Managementul schimbărilor: Clienții sunt notificați cu 30 de zile înainte de adăugarea unor subîmputerniciți noi, cu drept de opoziție. ⚠️ Acel preaviz nu a fost acordat pentru subîmputerniciții divulgați pentru prima dată în prezenta revizie, dintre care mai mulți se aflau deja în producție.

---

Încălcări ale Securității Datelor cu Caracter Personal

Obligația de documentare (art. 33 alin. (5) GDPR): [PLATFORM PROVIDER] are obligația de a ține un registru al tuturor încălcărilor securității datelor cu caracter personal, în care se consemnează:

• Faptele care constituie breșa de date (data, ora, natura, sistemele afectate)
• Efectele și consecințele (persoanele vizate afectate, categoriile de date compromise)
• Măsurile de remediere luate (limitare, notificare, corecții)

Locația registrului breșelor de date: ⚠️ În prezent nu se ține niciun registru al breșelor de date. Registrul trebuie constituit ca evidență internă ținută la zi, pusă la dispoziția autorității de supraveghere la cerere, și completat retroactiv cu situațiile identificate mai jos; structura de coloane pe care trebuie să o adopte este stabilită la Secțiunea 8 din Planul de Răspuns la Breșe de Date. Intrările urmează a fi păstrate trei ani, în acord cu angajamentul din Secțiunea 9.4 din Acordul de Prelucrare a Datelor.

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

Prezentul document arăta anterior că un registru al tuturor breșelor de date este ținut într-o locație internă indicată. Un astfel de registru nu există în nicio locație și niciun incident nu a fost evaluat ori consemnat într-unul, astfel încât respectarea art. 33 alin. (5) GDPR nu poate fi dovedită în prezent. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Notificarea Operatorilor: în 24 de ore de la momentul luării la cunoștință (în conformitate cu Secțiunea 9 din DPA)

Stadiul registrului breșelor de date: la data de [DATE], [PLATFORM PROVIDER] nu a notificat nicio breșă de date unei autorități de supraveghere sau unui operator. Au fost identificate două situații care necesită o evaluare și o intrare în registrul prevăzut de art. 33 alin. (5) GDPR; niciuna nu a fost încă evaluată și nu s-a stabilit dacă vreuna dintre ele este notificabilă.

1. Nodul cu statisticile sesiunilor live, lizibil fără autentificare. Până la 11 iunie 2026, nodul din Realtime Database care conținea statisticile fiecărei sesiuni putea fi citit de oricine, în timp ce sub el se scriau registre per actor — numărul de mesaje per actor și marcajele de sincronizare per actor. Întrucât directorul de actori, care asociază un identificator de actor numelui afișat al unui participant, poate fi citit de orice utilizator autentificat, un participant putea asocia nume reale cu numărul de mesaje și cu indicatorii de click pe ofertă ai fiecărei persoane. Regula de citire a fost înlocuită la 11 iunie 2026 cu o expresie condiționată de rol, iar registrele per actor au fost mutate în afara nodului de statistici la 31 iulie 2026.
2. Reabonarea contactelor dezabonate anterior. În perioada 16 mai 2026 - 3 iulie 2026, jobul de sincronizare cu furnizorul de e-mail a reabonat contacte care se dezabonaseră anterior. Comportamentul a fost modificat la 3 iulie 2026, astfel încât dezabonările consemnate la furnizor să fie respectate.

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

Prezentul document arăta anterior, fără nicio rezervă, că [PLATFORM PROVIDER] nu a suferit nicio breșă de date notificabilă. Mai sus sunt descrise două situații care nu au fost evaluate și nu sunt consemnate în registrul prevăzut de art. 33 alin. (5) GDPR, astfel încât afirmația necalificată nu putea fi susținută. O decizie motivată potrivit căreia notificarea nu este necesară constituie ea însăși dovada pe care o impune art. 33 alin. (5) GDPR, iar o astfel de decizie nu a fost consemnată. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

Evaluarea Impactului asupra Protecției Datelor (DPIA)

Statut DPIA: ⚠️ NECESITĂ APROBARE — Proiect finalizat (a se vedea dpia.md). Trebuie revizuit și semnat de Responsabilul cu protecția datelor sau de un consilier juridic specializat în GDPR înainte de punerea în producție.

Concluzie: prelucrarea este cu risc ridicat, din cauza monitorizării sistematice (urmărirea comportamentală). Măsurile de atenuare invocate și domeniul lor efectiv de aplicare sunt următoarele:

• Consimțământul explicit pentru urmărirea comportamentală — care suprimă numai rândurile granulare de evenimente din baza de date analitică, nu și evidențele sesiunilor live ori evidența de participare
• Row Level Security în PostgreSQL (izolarea datelor la nivel de organizație), cu limitele reziduale consemnate la Activitatea de Prelucrare 1; regulile Realtime Database nu conțin nicio verificare a organizației
• Criptarea în tranzit și în repaus, precum și pseudonimizarea în PostgreSQL, sub rezerva excepției privind automatizările, consemnată la Activitatea de Prelucrare 1
• Un flux de ștergere a datelor Persoanei vizate, automat odată ce un membru al personalului îl declanșează și care nu atinge jurnalul de livrare a SMS-urilor, jurnalul destinatarilor difuzărilor către segmente, jurnalul joburilor de generare cu AI, vizualizările de pagină ale funnel-urilor și nici Cloud Storage
• Garanțiile privind subîmputerniciții, care sunt ⚠️ restante pentru Railway Corp., TikTok Pte. Ltd., SendSMS.ro și Anthropic PBC

⚠️ Data întocmirii DPIA este anterioară subsistemelor de funnel-uri, de automatizări, de generare cu AI, de SMS și de difuzări către segmente, consemnate la Activitățile de Prelucrare 5-9, vizualizării de pagină pe server pentru paginile de destinație, consemnată la Activitatea de Prelucrare 3, și moderării automate a conținutului de chat, consemnată la Activitatea de Prelucrare 1. DPIA trebuie revizuită pentru a le acoperi.

Ciclu de revizuire: anual sau atunci când prelucrarea se modifică semnificativ (funcționalități noi, subîmputerniciți noi, activități noi cu risc ridicat)

---

Cooperarea cu Autoritățile de Supraveghere

Autoritatea desemnată: ANSPDCP (Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal, România) Contact: https://www.dataprotection.ro, [email protected]

Obligații de cooperare:

• Furnizarea prezentului ROPA la cerere
• Formularea răspunsului la solicitări în 30 de zile (sau în termenul indicat de autoritate)
• Permiterea inspecțiilor la sediu (cu un preaviz rezonabil)
• Punerea în aplicare a măsurilor corective dispuse de autoritate

Până în prezent: nicio solicitare și nicio inspecție din partea autorității de supraveghere.

---

Controlul Documentului

Versiunea Documentului: 1.0 (DRAFT) Ultima actualizare: [DATE] Următoarea revizuire: Anual (sau atunci când activitățile de prelucrare se modifică) Responsabil: Responsabil cu protecția datelor (sau CTO dacă nu este desemnat un DPO) Aprobat de: [Legal Team, Management] Acces: Document intern, disponibil autorității de supraveghere la cerere și publicat, suplimentar, pe site-ul public de documentație juridică

Declanșatori de întreținere (actualizați ROPA atunci când):

• Este adăugat un subîmputernicit nou
• Este introdus un scop de prelucrare nou (de exemplu, o funcționalitate nouă care colectează date cu caracter personal)
• Intervine o schimbare semnificativă a măsurilor de securitate
• Survine o breșă de date
• Autoritatea de supraveghere solicită actualizarea
• Se împlinește ciclul de revizuire anuală

Stadiul Revizuirii: ⚠️ NECESITĂ REVIZUIRE JURIDICĂ — Prezentul document este un DRAFT pentru consultare cu avocatul

---

Sfârșitul ROPA

---

Anexă: Model ROPA pentru Organizațiile-Client (Operatori de Date)

[PLATFORM PROVIDER] pune la dispoziție orientări menite să ajute organizațiile-client să își îndeplinească propriile obligații în temeiul art. 30 alin. (1) GDPR. Clienții trebuie să le adapteze cu detaliile lor specifice.

⚠️ În prezent nu se distribuie niciun model de ROPA. Reviziile anterioare ale prezentului document îndrumau clienții către un ecran „Setări → Conformitate GDPR → Descărcare Model ROPA" din tabloul de bord. Nu există nici o astfel de zonă de setări, nici o descărcare de model. Până la publicarea unui model, clienții trebuie să folosească orientările privind art. 30 GDPR din Ghidul de Conformitate GDPR pentru Clienți, împreună cu categoriile de date, scopurile, destinatarii, transferurile și perioadele de retenție consemnate în prezentul document.