RestartiX Webinars

Română

English

Română

English

Appearance

Anexa II: Măsuri Tehnice și Organizatorice de Securitate ​

Acord de Prelucrare a Datelor între [CUSTOMER] și [PLATFORM PROVIDER]Ultima actualizare: [DATE]

Introducere ​

Prezenta Anexă descrie măsurile tehnice și organizatorice implementate de [PLATFORM PROVIDER] pentru a asigura un nivel de securitate corespunzător riscului, în conformitate cu art. 32 din Regulamentul (UE) 2016/679 (GDPR).

Evaluarea Riscurilor: [PLATFORM PROVIDER] a efectuat o evaluare a riscurilor luând în considerare:

  • Probabilitatea și gravitatea riscurilor la adresa drepturilor și libertăților Persoanelor Vizate
  • Stadiul actual al tehnologiei de protecție a datelor
  • Costurile de implementare
  • Natura, domeniul de aplicare, contextul și scopurile prelucrării
  • Categoriile de Date cu Caracter Personal prelucrate (nume, e-mail, date comportamentale, adrese IP)

Clasificare: Datele cu Caracter Personal prelucrate sunt considerate risc mediu (nu aparțin categoriilor speciale, dar implică monitorizare comportamentală sistematică la scară largă).

1. Măsuri Tehnice de Securitate ​

1.1 Criptare ​

1.1.1 Criptare în Tranzit ​

  • TLS 1.2+ pentru toate comunicațiile externe:
    • Site public (events.{domain}) → HTTPS impus
    • Aplicație participanți (live.{domain}) → HTTPS impus
    • Tablou de bord (dashboard.{domain}) → HTTPS impus
    • Go API → HTTPS impus
    • Conexiuni Firebase SDK → TLS 1.2+
  • Suite de cifruri: Numai cifruri puternice activate (AES-256, ChaCha20), cifruri slabe dezactivate (RC4, DES)
  • Gestionarea certificatelor: Reînnoire automată Let's Encrypt pentru aplicațiile web, certificate gestionate de Railway
  • HSTS (HTTP Strict Transport Security): Setat explicit pe răspunsurile Go API; Railway și Firebase Hosting impun HTTPS și setează anteturi HSTS pe domeniile gestionate în mod implicit
  • Anteturi de securitate în răspuns: fiecare răspuns al Go API poartă X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, o Permissions-Policy care refuză accesul la cameră, microfon, geolocalizare, plăți și USB, X-XSS-Protection: 0, X-DNS-Prefetch-Control: off, Cache-Control: no-store, no-cache, private, Strict-Transport-Security: max-age=31536000; includeSubDomains, precum și o Content-Security-Policy (default-src 'none'; frame-ancestors 'none' pe rutele de API; în rest, o politică ce restrânge scripturile, stilurile, imaginile, fonturile și conexiunile la aceeași origine)

Excepție de transport — SMS tranzacțional. Mesajele sunt transmise furnizorului de mesagerie prin TLS, însă sub forma unei cereri HTTP GET în care numele de utilizator al contului, parola contului, numărul de telefon al destinatarului în clar și corpul integral al mesajului figurează ca parametri în șirul de interogare al URL-ului. Parametrii din șirul de interogare sunt consemnați în mod obișnuit în jurnalele de acces ale serverelor web, astfel încât aceste valori trebuie presupuse prezente în jurnalele furnizorului, în pofida transportului criptat. Prin urmare, criptarea transportului nu protejează, singură, această cale.

Resurse externe la care fac trimitere paginile de destinație generate. Prompturile folosite pentru generarea cu AI a paginilor de destinație instruiesc modelul să facă trimitere la cdn.tailwindcss.com și la unpkg.com. Ambele trimiteri sunt eliminate la compilare ori încorporate inline la publicare, astfel încât o pagină de destinație publicată nu le mai solicită, iar niciuna dintre cele două gazde nu este subîmputernicit. Etapa de compilare Tailwind nu blochează publicarea în caz de eșec: acolo unde binarul compilatorului lipsește din imaginea de execuție, etapa este omisă cu o avertizare, caz în care trimiterea ar supraviețui în pagina publicată și ar fi solicitată de fiecare vizitator. Separat, panoul de previzualizare a paginilor din tabloul de bord încarcă cdn.tailwindcss.com în browserul membrului personalului pe durata editării unei pagini, ceea ce divulgă acelei rețele de distribuție a conținutului adresa IP și user agent-ul respectivului membru al personalului.

1.1.2 Criptare în Repaus ​

  • Baza de date PostgreSQL (Railway):
    • Criptare completă a discului (AES-256)
    • Copii de rezervă automate criptate cu cheie separată
    • Conține totodată promptul de sistem, promptul utilizatorului, instrucțiunile personalizate și rezultatul modelului pentru fiecare generare cu AI, împreună cu identificatorul membrului personalului care a inițiat-o (a se vedea §2.6)
  • Firestore (Google Cloud):
    • Criptare implicită în repaus (AES-256, chei gestionate de Google)
    • Opțiune pentru Chei de Criptare Gestionate de Client (CMEK) disponibilă la cerere
  • Firebase Cloud Storage:
    • Criptare implicită în repaus (AES-256)
    • Codul HTML al paginilor de destinație, biblioteca media a organizației, elementele de brand, șabloanele de pagină și imaginile webinarelor și ale ofertelor sunt criptate în bucket-urile de stocare. A se vedea §1.4 pentru regulile de acces aplicabile acestor obiecte
  • Google Secret Manager:
    • Acreditările de integrare cu terți, per organizație — Meta, Cloudflare, NewsmanApp SRL și SendSMS.ro — protejate prin criptare de tip envelope (DEK + KEK). Google Secret Manager este folosit exclusiv pentru aceste acreditări; secretele la nivel de platformă sunt păstrate ca variabile de mediu ale platformei de găzduire (a se vedea §1.8)
    • Chei de criptare gestionate de Google, cu rotație automată (gestionată de infrastructura Google Cloud)
    • Acreditările API ale terților sunt actualizate de administratorii organizației prin tabloul de bord atunci când sunt rotite la furnizor

Copii de rezervă: Toate copiile de rezervă ale bazelor de date sunt păstrate timp de 30 de zile, criptate separat față de datele de producție. ⚠️ Perioada de retenție nu este probată în evidențele [PLATFORM PROVIDER] și trebuie confirmată din configurarea efectivă a furnizorului de găzduire.

1.1.3 Pseudonimizare ​

  • Transformarea adreselor de e-mail în hash: 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.
  • Identificatorii de actor: Firebase Anonymous Auth generează identificatori pseudonimi pentru actorii din Realtime Database. Identificatorul de actor este totuși legat de identitatea contactului în interiorul Realtime Database: o memorie cache de identitate aflată la live/{sessionId}/identityCache/{actorId} asociază identificatorul de actor cu hash-ul adresei de e-mail a contactului, împreună cu identificatorii organizației, ai webinarului și ai înregistrării. Adresa de e-mail în clar nu este scrisă în Realtime Database.

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.

Limitare: Transformarea în hash este reversibilă dacă atacatorul deține adresa de e-mail originală (rainbow table), astfel încât [PLATFORM PROVIDER] se bazează, suplimentar, pe controale de acces și pe criptare.

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

Prezenta anexă descria anterior datele cu caracter personal în clar ca fiind stocate exclusiv în Firestore, iar identificatorii de actor din Realtime Database ca nefiind legați de o adresă de e-mail. PostgreSQL conține în plus adrese de e-mail și numere de telefon în clar în rezultatele execuției pașilor de automatizare, stratul API menține în proces o memorie cache fără termen de expirare, cu datele de contact în clar, iar memoria cache de identitate din Realtime Database asociază fiecare identificator de actor cu hash-ul adresei de e-mail a contactului. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

1.2 Controlul Accesului și Autentificare ​

1.2.1 Accesul Personalului la Sistemele de Producție ​

Autentificare cu Mai Mulți Factori (MFA):

  • Obligatorie pentru conturile proprii ale [PLATFORM PROVIDER] la furnizorii terți (Firebase Console, Railway, GitHub, Google Cloud)
  • Bazată pe TOTP (Google Authenticator, Authy) sau pe token-uri hardware (YubiKey)
  • ⚠️ Aceasta este o practică administrativă internă, aplicată pe consolele terților, și nu constituie un control al Serviciilor. Serviciile în sine nu oferă nicio autentificare cu mai mulți factori sau cu doi factori: utilizatorii tabloului de bord ai Clientului 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 patru cifre, descris mai jos la „Participanți prin Aplicație Mobilă", este o alternativă la link-ul magic destinat participanților, nu un al doilea factor

Controlul Accesului Bazat pe Rol (RBAC):

  • Firebase Console: Admin (control total), Vizualizator (numai citire)
  • Railway: Admin (implementare, variabile de mediu), Developer (numai implementare), Vizualizator (numai jurnale)
  • PostgreSQL: api_user (Row Level Security impus, citire/scriere limitate prin org_id), scheduler_user (superutilizator pentru joburile cron), admin_user (DBA, numai acces de urgență). Rolul api_user este creat separat, printr-un script de configurare; nicio migrare nu îl creează, astfel încât nici rolul, nici privilegiile sale nu pot fi reproduse numai din setul de migrări
  • Tablou de Bord (Utilizatori Client): patru roluri — admin, moderator, marketer și staff — descrise imediat mai jos

Rolurile din tabloul de bord:

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

Prezenta anexă descria anterior un model cu două roluri în tabloul de bord, format dintr-un administrator cu acces complet și un rol de personal cu acces doar în citire, și arăta, la §2.7, că noilor utilizatori din personal li se atribuie implicit rolul cu acces doar în citire. Platforma definește patru roluri, rolul este ales explicit la crearea contului, fără un implicit de tip „doar citire", iar orice operațiune distructivă, alta decât citirea jurnalului de audit, este autorizată prin grup de permisiuni, iar nu prin calitatea de administrator. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Principiul Privilegiului Minim:

  • Inginerii au acces numai la serviciile pe care le întrețin
  • Personalul de suport are acces numai în citire (nu poate modifica date)
  • Acreditările administratorului de baze de date sunt păstrate în managerul de parole (1Password) și rotite la fiecare 90 de zile

1.2.2 Autentificarea Utilizatorilor Finali ​

Participanți la Evenimente (Web):

  • Autentificare anonimă (fără parolă, fără cont)
  • registrationId (UUID) acordă acces (stocat în localStorage)
  • Limitarea numărului de cereri pe API-ul public, aplicată pe utilizatorul autentificat acolo unde există unul și, în lipsa acestuia, pe adresa IP a clientului — niciodată pe adresa de e-mail. Limita este stabilită prin variabile de mediu configurabile de operator și se situează în prezent la 1.200 de cereri pe minut, cu un vârf de 300; fiind reglabilă de operator, valoarea în vigoare la un moment dat reprezintă un element de configurare, iar nu un angajament contractual. Contoarele sunt ținute în memoria fiecărui proces al API-ului, astfel încât limitele nu se cumulează între instanțe și sunt resetate de fiecare repornire sau implementare. Cererile a căror origine aparentă este o adresă dintr-o rețea privată ocolesc limitatorul

Participanți prin Aplicație Mobilă:

  • Autentificare prin link e-mail (magic link) prin Firebase Auth (prin proxy API — aplicația mobilă nu include Firebase SDK pentru evenimente; operațiunile de autentificare sunt gestionate server-side de Go API)
  • JWT Firebase Auth (idToken) obținut după verificarea link-ului e-mail; expiră după 1 oră
  • Token de reîmprospătare (refreshToken) utilizat pentru obținerea de noi idToken-uri fără re-autentificare
  • Stocarea token-urilor: idToken + refreshToken stocate în stocare securizată de platformă — iOS Keychain / Android EncryptedSharedPreferences — niciodată în SharedPreferences obișnuit, UserDefaults sau localStorage necriptat
  • Reîmprospătare proactivă: Aplicația mobilă verifică expirarea token-ului înainte de fiecare cerere (reîmprospătare proactivă dacă expiră în 5 minute). La răspuns 401, reîmprospătarea este încercată o dată; dacă reîmprospătarea eșuează (token revocat), token-urile stocate sunt șterse, iar utilizatorului i se solicită să se autentifice din nou
  • Limitarea numărului de cereri: endpoint-urile de autentificare a participanților sunt limitate per adresă IP sau, acolo unde există un utilizator autentificat, per utilizator — niciodată per adresă de e-mail. Trimiterea link-ului magic este limitată la 10 cereri pe minut, cu un vârf de 3; verificarea link-ului și verificarea codului, la 10 cereri pe minut, cu un vârf de 5 fiecare; reîmprospătarea token-ului, la 30 de cereri pe minut, cu un vârf de 5
  • Expirarea oobCode: Codurile de link magic sunt de unică folosință, cu expirare de 1 oră (impusă de Firebase Auth)
  • Cod de unică folosință transmis prin e-mail, ca variantă de rezervă: acolo unde link-ul magic nu poate fi folosit, se transmite prin e-mail un cod numeric. Codul are patru cifre, este extras dintr-o sursă aleatorie sigură din punct de vedere criptografic, este valabil 10 minute și este invalidat după trei încercări eșuate. Se păstrează un singur cod per adresă de e-mail la un moment dat. Dincolo de limitele per adresă IP menționate mai sus, nu există nicio limitare per adresă la verificarea codului
  • Cont demonstrativ pentru analiza din magazinele de aplicații: este creat un singur cont demonstrativ, nominalizat, pentru ca magazinele de aplicații mobile să poată analiza aplicația. Acolo unde — și numai acolo unde — atât adresa demonstrativă, cât și codul demonstrativ sunt stabilite ca variabile de mediu, o cerere de autentificare ce corespunde exact acelei adrese și acelui cod este acceptată fără verificările asupra codului stocat și fără blocarea contului. Adresa este comparată exact — niciodată după prefix, domeniu sau tipar —, codul este comparat în timp constant, iar mecanismul este inert atunci când oricare dintre cele două variabile nu este stabilită. Codul nu expiră și nu este rotit automat. O autentificare pe această cale este scrisă în jurnalul aplicației, dar nu este consemnată în jurnalul de audit

Personal Client:

  • Firebase Auth cu e-mail/parolă sau Google OAuth
  • Atribute personalizate din token (org_id, role) impun izolarea la nivel de organizație
  • Expirare JWT: 1 oră (reîmprospătare automată)
  • Politica de parole: minimum șase caractere atunci când un administrator stabilește direct o parolă, ceea ce reprezintă totodată minimul implicit al Firebase Authentication. Platforma nu impune nicio cerință de complexitate, de nereutilizare sau de rotație

Riscuri reziduale în configurarea autentificării:

  • Verificarea token-urilor tabloului de bord este condiționată de prezența identificatorului proiectului Firebase în mediu. Acolo unde acea variabilă lipsește, API-ul revine la un substitut de dezvoltare care acordă încredere, ca atare, antetelor X-User-ID, X-Org-ID și X-Role furnizate de apelant. Nicio verificare specifică producției nu împiedică această revenire, spre deosebire de conexiunea la baza de date, unde API-ul refuză să pornească în producție dacă șirul de conexiune restricționat lipsește.
  • Acolo unde este stabilită variabila de mediu ce indică gazda emulatorului Firebase Authentication, atât token-urile tabloului de bord, cât și cele ale participanților sunt interpretate fără verificarea semnăturii, a expirării sau a emitentului, iar pe calea participanților se omite suplimentar verificarea adresei de e-mail.
  • Autentificarea între servicii acceptă orice bearer token atunci când secretul de serviciu nu este stabilit și, în această stare, acordă un context administrativ, cu organizația preluată dintr-un antet furnizat de apelant.

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

Prezenta anexă descria anterior trimiterea link-ului magic ca fiind limitată per adresă de e-mail, iar parolele personalului ca având minimum opt caractere. Niciunul dintre aceste controale nu există: limitarea numărului de cereri se aplică exclusiv pe adresa IP sau pe utilizatorul autentificat, iar o parolă stabilită de administrator este acceptată la șase caractere. Cele trei variante de rezervă ale autentificării, dependente de mediu, descrise mai sus, precum și contul demonstrativ pentru analiza din magazinele de aplicații, nu erau nici ele divulgate. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

1.3 Securitate de Rețea ​

Reguli Firewall:

  • Railway: Traficul de intrare limitat la HTTPS (portul 443), PostgreSQL (portul 5432 numai intern)
  • Firebase: Gestionat de Google Cloud (protecție DDoS, WAF)

Proxy invers și protecție DDoS:

  • În producție, Cloudflare este un proxy invers obligatoriu, plasat în fața traficului participanților. Acesta termină TLS pentru fiecare cerere a participanților și, prin urmare, o vede — inclusiv trimiterile de formulare de înregistrare care poartă o adresă de e-mail, un nume și un număr de telefon în clar —, iar pentru acest trafic adresa IP a clientului pe care platforma o consemnează sau o transmite mai departe este preluată dintr-un antet furnizat de Cloudflare, antet pe care funcția sa auxiliară de extragere a adresei IP îl verifică înaintea oricărui alt antet de proxy. Pentru acest trafic, Cloudflare nu este o rețea de distribuție a conținutului opțională pentru Client
  • Cloudflare asigură atenuarea atacurilor DDoS L3/L4/L7 asupra traficului pe care îl intermediază
  • Railway include protecție de bază împotriva atacurilor DDoS
  • Întrucât atât limitatorul numărului de cereri, cât și adresa IP a clientului consemnată acordă încredere antetului furnizat de Cloudflare, o cerere care ajunge la originea de găzduire fără a trece prin Cloudflare poate prezenta o valoare arbitrară în acel antet. Restrângerea accesului la origine exclusiv la Cloudflare este un complement necesar al limitatorului, iar lipsa acesteia constituie un risc rezidual

Protecție împotriva boților (Cloudflare Turnstile):

  • Cloudflare Turnstile este injectat în paginile de destinație publicate care conțin un formular de funnel, în afara grupului de scripturi condiționate de consimțământ. Verificarea pe partea de server transmite către Cloudflare adresa IP a vizitatorului
  • Domeniul său de aplicare este restrâns: se aplică exclusiv la trimiterea formularelor de funnel și numai acolo unde organizația a configurat un secret Turnstile. Nu se aplică endpoint-ului de înregistrare la webinar
  • Prin proiectare, verificarea nu blochează trimiterea în caz de eșec: acolo unde secretul nu poate fi obținut sau serviciul de verificare este inaccesibil, trimiterea este acceptată

Detectarea intruziunilor:

  • Jurnalizare la nivel de aplicație (toate cererile API sunt consemnate cu adresa IP a clientului, endpoint-ul, codul de status, latența și identificatorul cererii)
  • Nu există niciun serviciu de detectare automată a intruziunilor, de alertare la anomalii de trafic sau de monitorizare a evenimentelor de securitate. Detectarea este manuală și reactivă; a se vedea §1.5

Rețele Private:

  • PostgreSQL accesibil numai din rețeaua internă Railway (nu pe internet public)
  • Firebase Admin SDK autentificat prin cheie de cont de serviciu (neexpusă clienților)

1.4 Izolarea Bazelor de Date (Row Level Security) ​

Politici RLS 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. În consecință, nu există nicio cale de ocolire a Row Level Security utilizată la nivelul aplicației.

Reguli de Securitate 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 document arăta anterior că toate colecțiile Firestore sunt imbricate sub o cale de organizație, că regulile compară atributul de organizație din token-ul apelantului cu identificatorul organizației și că documentele de înregistrare pot fi citite numai de personalul aceleiași organizații. Documentele cu datele cu caracter personal ale contactelor pot fi citite de orice utilizator Firebase autentificat care cunoaște identificatorul organizației și hash-ul adresei de e-mail, documentele de înregistrare pot fi citite fără autentificare, iar colecțiile care conțin coduri de verificare și link-uri magice se află în afara arborelui de organizație, accesibile exclusiv componentelor de server. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Reguli de Securitate RTDB:

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

Singurul control din descrierea anterioară care se confirmă este restricția de scriere aplicată participanților: un participant poate scrie numai în nodurile cheiate pe propriul identificator de actor, iar unui actor aflat pe lista celor blocați ai sesiunii i se împiedică scrierea chiar la nivelul regulilor.

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

Prezenta anexă descria anterior izolarea datelor la nivel de organizație în baza de date a sesiunilor live ca fiind echivalentă cu izolarea impusă în PostgreSQL. Regulile de securitate ale Realtime Database nu conțin niciun identificator de organizație și nu fac nicio comparație între organizația apelantului și organizația proprietară a sesiunii; accesul cu privilegii de personal este autorizat exclusiv pe baza atributului role din token-ul apelantului, astfel încât un utilizator autentificat al tabloului de bord, din orice organizație, poate citi datele live ale unei sesiuni dacă îi cunoaște identificatorul. Izolarea la nivel de organizație în PostgreSQL, descrisă mai sus, nu este afectată. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Reguli de Securitate 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.

Bucket-ul conține mai mult decât codul HTML al paginilor de destinație: biblioteca media a organizației, elementele de brand, șabloanele de pagină și imaginile webinarelor și ale ofertelor sunt stocate sub aceleași prefixe, iar aceste materiale pot înfățișa persoane identificabile. Ștergerea în temeiul art. 17 GDPR nu ajunge în prezent la obiectele stocate.

Testare: nu există niciun test automat al izolării datelor la nivel de organizație. Acoperirea automată cu teste din API se limitează la cinci fișiere de teste unitare, care acoperă handlerele de urmărire a e-mailurilor, utilitarele de e-mail, redirecționările prin link-uri urmărite și funcțiile auxiliare pentru pagini; niciun test automat nu exercită Row Level Security, autentificarea, autorizarea sau izolarea datelor la nivel de organizație, iar niciun script nu simulează, nicăieri, o interogare între organizații.

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

Prezenta anexă descria anterior politicile de Row Level Security ca fiind testate prin scripturi automate care simulează interogări între organizații și verifică faptul că nu se returnează niciun rând. Un asemenea test sau script nu există. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

1.5 Jurnalizare și Monitorizare ​

Jurnale de aplicație:

  • Fiecare cerere API este consemnată cu: marcajul temporal, metoda HTTP, calea cererii, inclusiv șirul său de interogare, codul de status, latența, adresa IP a clientului și identificatorul cererii. Jurnalul de acces nu consemnează identificatorul organizației, utilizatorul care acționează și nici user agent-ul. Atribuirea unei acțiuni a personalului către un utilizator și o organizație se obține din jurnalul de audit descris mai jos, nu din jurnalul de acces
  • Jurnalele sunt păstrate timp de 90 de zile
  • În jurnalele de aplicație apar date cu caracter personal. Adrese de e-mail în clar sunt scrise de căile de autentificare a participanților, de import în masă, de administrare a utilizatorilor din personal și de trimitere a formularelor de funnel; numărul de telefon în clar al destinatarului este scris atunci când un SMS dintr-o automatizare eșuează; iar, întrucât modulul de jurnalizare a accesului adaugă la calea consemnată șirul de interogare brut, secretul webhook-ului de funnel — furnizat ca parametru de interogare — este consemnat la fiecare apel de webhook primit

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

Prezenta anexă descria anterior jurnalele de aplicație ca neconținând date cu caracter personal, ci numai hash-uri ale adreselor de e-mail, și arăta că fiecare cerere este consemnată împreună cu identificatorul organizației, identificatorul utilizatorului și user agent-ul. În jurnalele de aplicație se scriu adrese de e-mail în clar, numere de telefon în clar și o acreditare de webhook, iar înregistrarea din jurnalul de acces nu conține niciunul dintre cele trei elemente de atribuire. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Jurnale de audit (acces la datele cu caracter personal):

  • În tabelul audit_log se consemnează o intrare pentru fiecare scriere inițiată de personal prin API-ul tabloului de bord — aproximativ șaptezeci de acțiuni distincte, care acoperă crearea, modificarea și ștergerea webinarelor, a sesiunilor, a funnel-urilor, a paginilor, a ofertelor, a sondajelor, a segmentelor, a automatizărilor, a fișierelor media și a integrărilor — precum și pentru operațiunile asupra datelor cu caracter personal, între care exporturile de contacte și de segmente, importurile de înregistrări, acțiunile de moderare, modificările setărilor de retenție, crearea și eliminarea conturilor de personal și soluționarea cererilor persoanelor vizate. Endpoint-urile publice, cele ale participanților, cele de serviciu și cele de webhook se află, prin proiectare, în afara domeniului de audit
  • Fiecare intrare consemnează: organizația, utilizatorul care acționează, rolul acestuia, acțiunea, tipul și identificatorul țintei, metadate în format JSON, adresa IP a utilizatorului care acționează, user agent-ul și identificatorul cererii
  • Tabelul este de tip „doar adăugare" la nivelul privilegiilor de bază de date: rolul de bază de date al aplicației deține asupra sa numai SELECT și INSERT, fără UPDATE sau DELETE
  • Retenție: 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 nimic altceva din platformă nu șterge din el, deci crește nelimitat. Aceeași situație se aplică registrului cererilor persoanelor vizate. 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. Întrucât rolul de bază de date al aplicației nu deține privilegiul de ștergere, jurnalul de audit nu poate fi golit nici prin conexiunea acesteia

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

Prezentul document arăta anterior că intrările din jurnalul de audit sunt păstrate timp de doi ani. Nicio perioadă de retenție nu este impusă asupra jurnalului de audit sau asupra registrului cererilor persoanelor vizate; ambele sunt păstrate pe termen nelimitat și conțin adresa IP a membrului personalului care acționează, iar în unele intrări și hash-ul adresei de e-mail a persoanei vizate. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Monitorizarea securității:

  • Firebase Authentication aplică propria limitare automată în cazul tentativelor repetate de autentificare eșuată; pragul este stabilit de Google și nu este configurat de platformă
  • Nu există nicio detectare a tiparelor neobișnuite de utilizare a API-ului, nicio detectare a anomaliilor privind volumul cererilor persoanelor vizate și nicio monitorizare a comportamentului conexiunilor la baza de date

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-PROC-02 · PROCESS — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezenta anexă descria anterior alerte prin e-mail către echipa de inginerie pentru erorile critice, o integrare de mesagerie pentru incidentele de securitate, o rotație de gardă pentru întreruperile din producție și detectarea automată a tiparelor neobișnuite de utilizare a API-ului și a creșterilor bruște ale conexiunilor la baza de date. Nu există nicio integrare de urmărire a erorilor, de alertare sau de apelare a echipei de gardă, iar detectarea automată a vreuneia dintre aceste situații nu este în funcțiune. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

1.6 Gestionarea Vulnerabilităților ​

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.

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

Prezenta anexă descria anterior un serviciu automat de actualizare a dependențelor care deschide pull request-uri pentru actualizările de securitate, un audit al dependențelor rulat la fiecare build de integrare continuă și care oprește build-ul la constatările de severitate ridicată, precum și o scanare săptămânală a vulnerabilităților modulelor Go. Nu există nicio configurare de integrare continuă, de actualizare a dependențelor sau de scanare, de niciun fel, iar niciunul dintre aceste controale nu rulează. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Teste de Penetrare:

  • Test de penetrare anual, efectuat de o firmă independentă de securitate (planificat pentru [Q4 2026])
  • Program de bug bounty (viitor, post-ISO 27001)

Gestionarea Patch-urilor:

  • Vulnerabilități critice: Patch aplicat în 7 zile
  • Vulnerabilități ridicate: Patch aplicat în 30 de zile
  • Vulnerabilități medii/scăzute: Patch aplicat în 90 de zile sau la următorul ciclu de release

Revizuirea codului:

  • Modificările sunt revizuite de echipa de inginerie înainte de implementare, iar cele sensibile din punctul de vedere al securității (autentificare, Row Level Security, criptare) sunt revizuite cu o atenție deosebită. Revizuirea de către colegi este o practică de lucru, iar nu o condiție impusă automat: nicio configurare prezentă în depozitul de cod nu impune o revizuire înainte de integrare și nici nu poate fi probată din acesta. A se vedea §1.8

1.7 Copii de Rezervă și Recuperare în Caz de Dezastru ​

Copii de Rezervă PostgreSQL (Railway):

  • Copii de rezervă zilnice automate (păstrate 30 de zile)
  • Recuperare la un moment dat (PITR) în fereastra de retenție
  • Copii de rezervă criptate cu cheie separată
  • Replicare geografică în altă regiune UE (recuperare în caz de dezastru)

Copii de Rezervă Firestore:

  • Copii de rezervă zilnice automate Google Cloud Firestore
  • Recuperare la un moment dat în 7 zile
  • Exporturi manuale în Cloud Storage (săptămânal)

RTDB:

  • Nu se realizează nicio copie de rezervă a Realtime Database
  • Definițiile sondajelor și ale ofertelor există și în Firestore. Întrebările transmise în timpul unei sesiuni există exclusiv în Realtime Database și nu au niciun corespondent în Firestore

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

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

Prezenta anexă descria anterior datele de sesiune din Realtime Database ca fiind efemere și limitate la sesiune. Nu există nicio funcție programată de curățare, iar arhivarea unei sesiuni nu îi elimină datele: evidențele sesiunilor live — textul mesajelor din chat, numele afișate ale participanților, prezența, participarea, voturile la sondaje, reacțiile, click-urile pe oferte și feedbackul — sunt eliminate numai atunci când un membru al personalului șterge sesiunea sau webinarul asociat. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Obiectivul Timpului de Recuperare (RTO): 4 ore pentru restaurarea completă a serviciului Obiectivul Punctului de Recuperare (RPO): 24 de ore (pierdere maximă de date = 1 zi de la ultima copie de rezervă)

Testare: ⚠️ Acestea sunt obiective, nu valori validate. Nu este menținută nicio procedură documentată de restaurare, nu a fost efectuată și cronometrată nicio restaurare pe date de producție și niciun job programat nu efectuează o restaurare de verificare, astfel încât recuperarea trebuie tratată drept obligație de mijloace până la efectuarea unei restaurări cronometrate. Aceeași poziție este consemnată la Secțiunea 4.3 din Planul de Răspuns la Breșe de Date.

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

Prezenta anexă descria anterior planul de recuperare în caz de dezastru ca fiind testat anual prin restaurarea copiilor de rezervă într-un mediu de staging și prezenta obiectivul de patru ore pentru timpul de recuperare și pe cel de douăzeci și patru de ore pentru punctul de recuperare drept angajamente validate. Nu există nicio procedură documentată de restaurare, nu a fost efectuată și cronometrată nicio restaurare pe date de producție și nu se păstrează nicio evidență a unui asemenea exercițiu. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

1.8 Ciclul de Viață al Dezvoltării Securizate ​

Depozitul de cod:

  • GitHub (depozite private)
  • În depozit nu există nicio configurare de protecție a ramurilor și nici de impunere a revizuirii; implementarea este declanșată de un push pe ramura implementată

Dezvoltare și implementare:

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.

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

Prezenta anexă descria anterior o linie de integrare și de implementare continuă, care rula teste unitare și de integrare automate la fiecare pull request, testare statică de securitate a aplicației și verificări ale dependențelor, o etapă obligatorie de implementare în staging și un pas de aprobare manuală pentru producție. O astfel de linie nu există: depozitul de cod nu conține nicio configurare de integrare continuă, de niciun fel, iar implementarea este declanșată direct de un push pe ramura implementată. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Gestionarea secretelor:

  • Secretele la nivel de platformă — șirurile de conexiune la baza de date, acreditarea contului de serviciu Firebase, cheia API web Firebase, secretul pentru autentificarea între servicii și cheia API a furnizorului de AI — sunt păstrate ca variabile de mediu ale platformei de găzduire, criptate în repaus de furnizorul de găzduire
  • Google Secret Manager păstrează exclusiv acreditările de integrare cu terți, per organizație (Meta, Cloudflare, NewsmanApp SRL, SendSMS.ro)
  • Secretele de dezvoltare locală se află în .env.local (gitignored)
  • Niciun secret nu este introdus în depozitul de cod

GAP-SEC-04 · CONFIG — DEFICIENȚĂ CUNOSCUTĂ, REMEDIERE ÎN CURS

Prezentul document arăta anterior că niciun secret nu este păstrat în variabile de mediu și că secretele de producție sunt păstrate în Google Secret Manager. Fiecare secret la nivel de platformă, inclusiv acreditarea contului de serviciu Firebase și cheia API a furnizorului de AI, este citit dintr-o variabilă de mediu a platformei de găzduire; Google Secret Manager este folosit exclusiv pentru acreditările de integrare cu terți, per organizație. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2. Măsuri Organizatorice de Securitate ​

2.1 Instruire și Conștientizare a Personalului ​

Stadiu. Nu a fost stabilit niciun program de instruire a personalului în materie de protecție a datelor și nu se păstrează nicio evidență de instruire, de prezență sau de finalizare. Registrul intern de conformitate al [PLATFORM PROVIDER] enumeră instruirea GDPR a personalului printre acțiunile restante. Prin urmare, măsurile prezentate mai jos reprezintă programul avut în vedere, iar nu controale aflate în funcțiune în prezent, și nicio evidență de instruire nu poate fi produsă ca răspuns la o cerere de audit a Clientului formulată în temeiul Acordului de Prelucrare a Datelor.

Instruire GDPR avută în vedere:

  • Toți inginerii, personalul de suport și managementul finalizează instruirea GDPR în termen de 30 de zile de la angajare
  • Instruire anuală de reîmprospătare (1 oră, obligatorie)
  • Subiecte: principii GDPR, drepturile Persoanelor Vizate, consimțământ, notificarea încălcărilor securității datelor, codare securizată

Conștientizare a securității avută în vedere:

  • Simulare de phishing trimestrială (testează capacitatea personalului de a identifica e-mailuri rău-intenționate)
  • Igiena parolelor (utilizarea managerului de parole obligatorie)
  • Conștientizarea ingineriei sociale (verificarea cererilor de acces la date)

Instruire specializată avută în vedere:

  • Administratori de baze de date: configurare RLS, restaurarea copiilor de rezervă
  • Ingineri frontend: stocare securizată (evitarea datelor cu caracter personal în localStorage), prevenirea XSS
  • Ingineri backend: injecție SQL, ocolirea autentificării, erori de autorizare

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

Prezenta anexă descria anterior programul de instruire și de conștientizare din această secțiune ca fiind stabilit și obligatoriu, iar Acordul de Prelucrare a Datelor oferă evidențele de instruire a personalului drept probe ce pot fi inspectate la un audit al Clientului. Niciun program de instruire nu a fost stabilit și nu există nicio evidență de instruire, astfel încât acea probă nu poate fi produsă. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2.2 Confidențialitate și Verificarea Antecedentelor ​

Acorduri de Confidențialitate:

  • Tot personalul semnează NDA înainte de accesarea sistemelor de producție
  • NDA-urile supraviețuiesc încetării contractului pe termen nelimitat
  • Contractorii și consultanții semnează DPA-uri separate dacă prelucrează Date cu Caracter Personal

Verificarea Antecedentelor:

  • Verificări ale cazierului judiciar pentru personalul cu acces la baza de date de producție (în măsura permisă de legislația română)
  • Verificări de referințe pentru toți angajații

2.3 Ciclul de Viață al Gestionării Accesului ​

Integrare:

  1. Managerul solicită acces (tichet Jira, aprobat de CTO)
  2. IT furnizează conturile (Firebase, Railway, GitHub)
  3. MFA activat înainte de primul login
  4. Personalul finalizează instruirea GDPR înainte de accesul la producție — a se vedea §2.1: în prezent nu este stabilit niciun program de instruire, astfel încât acest pas nu este operativ

Încetarea Raporturilor de Muncă:

  1. Managerul notifică IT în termen de 24 de ore de la încetarea contractului
  2. IT revocă imediat toate accesele (Firebase, Railway, GitHub, e-mail)
  3. Dispozitivele sunt returnate și șterse
  4. Jurnalul de audit revizuit pentru activitate suspectă în ultimele 30 de zile

Revizuire Acces:

  • Revizuire trimestrială a tuturor acceselor personalului (HR + IT)
  • Eliminarea conturilor neutilizate (fără login timp de 90 de zile)
  • Retrogradarea conturilor cu privilegii excesive

2.4 Gestionarea Furnizorilor ​

Listă de Verificare pentru Noi Subîmputerniciți:

  1. Solicitați DPA-ul furnizorului (trebuie să respecte art. 28 GDPR)
  2. Solicitați lista de subîmputerniciți (dacă furnizorul este el însuși persoană împuternicită de operator)
  3. Verificați certificările de securitate (ISO 27001, SOC 2 sau echivalent)
  4. Confirmați locația datelor (preferabil UE, SUA acceptabil cu SCC-uri)
  5. Evaluați SLA-ul de notificare a încălcărilor securității datelor (trebuie să notifice în 24-48 de ore)
  6. Semnați DPA înainte de integrare
  7. Adăugați furnizorul în Anexa III la DPA (Lista Subîmputerniciților)
  8. Notificați clienții (perioadă de obiecție de 30 de zile)

Stadiul de conformitate al listei de verificare. Doi subîmputerniciți au fost introduși în producție fără parcurgerea listei de verificare. Furnizorul de modele AI (Anthropic PBC, angajat de [PLATFORM PROVIDER] printr-o unică acreditare la nivel de platformă) și furnizorul de mesagerie tranzacțională (SendSMS.ro) prelucrau deja date cu caracter personal înainte ca vreunul dintre ei să fie adăugat în Anexa III și înainte de emiterea vreunei notificări de schimbare a subîmputerniciților, astfel încât pașii 4, 6, 7 și 8 nu au fost efectuați pentru niciunul dintre ei. Ambii sunt acum consemnați în Anexa III.

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

Prezenta anexă descria anterior lista de verificare pentru noii subîmputerniciți drept un control operativ, iar Acordul de Prelucrare a Datelor obligă [PLATFORM PROVIDER] să transmită o notificare înainte ca un nou subîmputernicit să înceapă prelucrarea. Doi subîmputerniciți au fost angajați și au început prelucrarea datelor cu caracter personal fără un acord de prelucrare a datelor încheiat, fără consemnarea unui mecanism de transfer acolo unde transferul se face către o țară terță, fără a fi adăugați în Anexa III și fără transmiterea notificării contractuale. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Revizuire Anuală a Furnizorilor:

  • Revizuiți DPA-urile subîmputerniciților pentru modificări
  • Verificați incidentele de securitate din ultimul an (solicitați certificare de la furnizor)
  • Verificați menținerea valabilității certificărilor (ISO 27001, SOC 2)

2.5 Răspuns la Incidente ​

Echipa de Răspuns la Incidente:

  • Comandant Incident: CTO
  • Lider Tehnic: Inginer Senior Backend
  • Consilier Juridic: Avocat extern (contract de asistență juridică permanentă)
  • DPO: [Name] (dacă este desemnat)
  • Comunicare: CEO (notificări către clienți)

Planul de Răspuns la Incidente: A se vedea documentul separat: data-breach-response-plan.md

Exerciții Trimestriale Tabletop:

  • Simularea Incidentelor de Securitate (ransomware, acces neautorizat, ștergere accidentală)
  • Testarea procedurilor de notificare (pot fi notificați toți clienții în 24 de ore?)
  • Revizuirea și actualizarea planului pe baza lecțiilor învățate
  • ⚠️ De la adoptarea Planului de Răspuns la Breșe de Date nu a fost consemnat niciun exercițiu de tip tabletop, astfel încât ritmul trimestrial indicat aici reprezintă un angajament, iar nu o practică stabilită. Aceeași poziție este consemnată la Secțiunea 5.2 din acel plan

2.6 Minimizarea și Retenția Datelor ​

Principii de Minimizare a Datelor:

  • Înregistrarea necesită numai adresa de e-mail și numele (numărul de telefon este opțional)
  • Nicio colectare de categorii speciale de date (stare de sănătate, religie etc.)
  • Urmărirea comportamentală este consemnată în baza de date analitică numai acolo unde există consimțământ; a se vedea §2.7 pentru domeniul exact al acestei condiții
  • Adresele IP. La înregistrarea la un webinar, adresa IP este folosită tranzitoriu pentru îmbogățirea geografică și nu este stocată; se păstrează numai țara și orașul deduse. Se aplică trei calificări: adresa IP a membrului personalului care acționează este stocată în jurnalul de audit și în jurnalul rulărilor de joburi ale planificatorului; un identificator pseudonim stabil de vizitator, derivat din adresa IP și din user agent-ul acestuia, este stocat pentru fiecare vizitator care nu este bot al fiecărei pagini de destinație a unui funnel, fără nicio condiție de consimțământ și fără nicio perioadă de retenție; iar adresa IP brută și user agent-ul brut ale vizitatorului sunt transmise către Meta și către TikTok pe căile de conversie de pe server, acolo unde organizația a activat aceste integrări. Șirul user agent brut este scris suplimentar în metadatele de atribuire ale înregistrării — păstrate pe intrarea în funnel și pe documentul de înregistrare din Firestore — de scriptul client al formularului de înregistrare și este citit de acolo atunci când se transmite un eveniment de conversie de pe server.
  • Token-urile FCM de dispozitiv sunt pseudonime (legate de email_hash, nu de adresa de e-mail în clar). Token-ul în sine nu încorporează nicio dată cu caracter personal.
  • Numerele de telefon sunt citite din Firestore la momentul trimiterii și transmise furnizorului de mesagerie în clar; ele nu sunt niciodată stocate în PostgreSQL. A se vedea §1.1.1 pentru limitarea aferentă acestui transport
  • Generarea de conținut asistată de AI. Atunci când un membru al personalului inițiază o generare, promptul transmis furnizorului de modele AI conține denumirea organizației, titlul, descrierea și tipul webinarului, brief-ul paginii, instrucțiunile redactate de personal, imaginile de referință încărcate de personal și incluse inline în cerere, textul extras din orice URL de referință furnizat de personal, precum și testimoniale aprobate ale participanților — numele afișat al participantului, citatul în format liber, denumirea companiei și nota acordată. Nu se transmit niciodată: conținutul mesajelor din chat, evidențele de înregistrare, adresele de e-mail ale contactelor, numerele de telefon, răspunsurile la sondaje, datele de participare și evenimentele comportamentale. Cererea este efectuată pe partea de server; niciun dispozitiv al participanților nu contactează furnizorul și nu sunt implicate cookie-uri. Fiecare prompt de sistem, prompt de utilizator, rezultat al modelului și număr de token-uri este păstrat în PostgreSQL, împreună cu identificatorul membrului personalului care a inițiat jobul, iar aceste evidențe sunt cheiate pe o entitate, iar nu pe un contact, astfel încât nu sunt atinse de fluxul de ștergere. Autorului testimonialului nu i se solicită niciun consimțământ și nu i se transmite nicio informare cu privire la această transmitere

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

Prezenta anexă descria anterior adresele IP ca fiind prelucrate tranzitoriu pentru îmbogățirea geografică și nestocate în nicio bază de date. Adresele IP ale personalului sunt stocate în jurnalul de audit și în jurnalul rulărilor de joburi ale planificatorului, un identificator stabil de vizitator derivat din adresa IP este stocat pentru fiecare vizitator al unei pagini de destinație a unui funnel, fără nicio condiție de consimțământ, iar adresele IP brute sunt transmise către Meta și către TikTok pe căile de conversie de pe server. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Politici de Retenție:

  • Perioadele de retenție se configurează per organizație și nu este preconfigurată nicio politică implicită. Jobul de aplicare a retenției acționează exclusiv asupra politicilor existente, astfel încât o organizație care nu a configurat niciuna nu are date șterse în funcție de vechime. Ecranul de setări pentru retenție transmite în prezent opt tipuri de date, în timp ce API-ul acceptă cinci, iar API-ul validează întreaga transmitere înainte de a scrie orice parte din ea; prin urmare, orice încercare de salvare este respinsă și nicio politică de retenție nu poate fi configurată din produs
  • 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
  • Acolo unde o politică poate fi activată, intervalul configurabil este de la 30 la 3.650 de zile
  • Contacte: păstrate pe durata relației de afaceri; șterse numai la o cerere de ștergere a persoanei vizate sau la încetarea organizației
  • Evenimente comportamentale: fără ștergere automată în lipsa unei politici de retenție în vigoare
  • Token-uri FCM de dispozitiv: fără ștergere automată. Ecranul de setări pentru retenție oferă o valoare implicită de 60 de zile pentru acest tip de date, însă acea valoare este un implicit nesalvat, pe un ecran care nu poate salva. Token-urile de dispozitiv sunt totuși șterse imediat la un răspuns UNREGISTERED din partea furnizorului de notificări push, precum și la ștergere
  • Evidențe de livrare push (push_sends): șterse la ștergere; în practică, fără ștergere în funcție de vechime, din motivul arătat mai sus
  • Jurnalul de audit și registrul cererilor persoanelor vizate: fără ștergere automată — a se vedea §1.5
  • Firestore: nicio colecție Firestore nu are configurată o politică de expirare automată (time-to-live). Documentele de înregistrare și documentele cu datele cu caracter personal ale contactelor sunt eliminate numai printr-o cerere de ștergere sau prin ștergerea manuală a webinarului ori a sesiunii din care fac parte
  • Realtime Database: fără ștergere automată — a se vedea §1.7
  • Evidențele de consimțământ: tabelul cu starea curentă a consimțămintelor este șters în cascadă, odată cu fișa contactului. Istoricul evenimentelor de consimțământ, de tip „doar adăugare", nu este șters: la ștergere, legătura sa cu contactul este setată pe null, iar rândul este păstrat, conținând identificatorii organizației, ai webinarului și ai înregistrării, scopul, acțiunea, metoda, versiunea politicii și marcajul temporal. Este păstrat ca dovadă a modului în care a fost obținut consimțământul, în temeiul art. 7 alin. (1) GDPR
  • Alte două tabele care conțin date cu caracter personal cheiate pe hash-ul adresei de e-mail nu sunt atinse de rutina de ștergere și nu au nicio cheie străină către fișa contactului, deci nu sunt eliminate nici în cascadă: jurnalul de livrare a SMS-urilor și jurnalul destinatarilor difuzărilor către segmente. Prin urmare, o evidență individuală a mesajelor SMS trimise — hash-ul adresei de e-mail, webinarul și sesiunea, tipul de șablon, codul de urmărire, identificatorul de mesaj al furnizorului, starea livrării și marcajele temporale de livrare și de click — persistă după o ștergere în temeiul art. 17 GDPR, iar niciunul dintre cele două tabele nu este inclus în exportul de date în temeiul art. 15 GDPR

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

Prezenta anexă descria anterior configurarea de către Clienți a unor perioade de retenție per organizație din tabloul de bord, token-urile de dispozitiv ca fiind supuse unei retenții rulante de 60 de zile, impusă zilnic de un job programat, iar evenimentele comportamentale și token-urile de dispozitiv expirate ca fiind șterse automat. Nicio politică de retenție nu poate fi salvată din produs, întrucât ecranul de setări transmite tipuri de date pe care API-ul le respinge, iar API-ul validează întreaga transmitere înainte de a scrie orice parte din ea; nu este preconfigurată nicio politică implicită; iar aplicarea se oprește suplimentar pentru orice politică al cărei volum restant depășește zece mii de rânduri. 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ă evidențele de consimțământ sunt șterse în cascadă, odată cu fișa contactului, fără nicio ștergere independentă în funcție de timp. Acest lucru este valabil numai pentru tabelul cu starea curentă a consimțămintelor; istoricul evenimentelor de consimțământ, de tip „doar adăugare", supraviețuiește ștergerii, cu legătura către contact setată pe null, și este păstrat pe termen nelimitat. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Drepturile Persoanelor Vizate:

  • Ștergere anticipată, disponibilă la cerere (prevalează asupra politicii de retenție)
  • Jurnalele de audit urmăresc toate ștergerile
  • 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
  • Fișierele exportate ies din sfera de control a platformei. Un membru al personalului care deține grupul de permisiuni marketing poate exporta membrii unui segment într-un fișier ce conține adresa de e-mail în clar și numele fiecărui membru. Exportul nu impune existența unui consimțământ de marketing; atunci când se folosește opțiunea de includere a contactelor marcate, exportul returnează și contactele suprimate pentru bounce, reclamație de spam sau dezabonare globală; iar contactele care s-au dezabonat sunt întotdeauna incluse, întrucât dezabonarea retrage consimțământul de marketing fără a seta un indicator de suprimare. Contactele care fac obiectul unei restricționări a prelucrării în temeiul art. 18 GDPR sunt întotdeauna excluse, iar exportul în sine este consemnat în jurnalul de audit. Fișierul rezultat se află însă în afara fluxului de retenție și de ștergere al platformei: o cerere de ștergere nu îl poate atinge, iar răspunderea pentru manipularea, stocarea și ștergerea sa revine Clientului în calitate de Operator

2.7 Confidențialitate prin Proiectare și Implicit ​

Principii de Confidențialitate prin Proiectare:

  1. Proactiv, nu reactiv: Row Level Security proiectat înaintea primei linii de cod, condiție de consimțământ integrată în Cloud Functions
  2. Confidențialitate în mod implicit: urmărirea comportamentală este cu opt-in, nu cu opt-out, iar casetele de consimțământ nu sunt bifate în prealabil. Consimțământul este totuși grupat și, pentru un scop, dedus în loc să fie colectat separat pe scopuri — a se vedea „Cum este colectat și aplicat în realitate consimțământul", mai jos
  3. Confidențialitate integrată: securitatea nu este adăugată ulterior — Row Level Security, criptarea și pseudonimizarea fac parte din arhitectura de bază
  4. Funcționalitate completă: confidențialitatea nu reduce funcționalitățile evenimentului (participanții pot participa pe deplin fără a consimți la urmărire)
  5. Securitate end-to-end: criptare în tranzit și în repaus, plus controale de acces la fiecare nivel
  6. Vizibilitate și transparență: jurnale de audit, politică de confidențialitate în limbaj clar, export de date disponibil. Exportul în temeiul art. 15 GDPR nu ajunge la fiecare depozit care conține date cu caracter personal ale persoanei vizate — a se vedea §2.6
  7. Respectul față de confidențialitatea utilizatorului: un flux de ștergere conform GDPR și retragerea consimțământului din pagina de preferințe a participantului. Retragerea nu este disponibilă pe pagina de vizionare live, unde bannerul de cookie-uri și controlul pentru setările cookie-urilor sunt eliminate din pagină

Cum este colectat și aplicat în realitate consimțământul:

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.

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

Pe pagina de vizionare live, bannerul de cookie-uri și butonul flotant pentru setările cookie-urilor sunt suprimate, pe considerentul că participanților li s-au prezentat deja opțiunile privind consimțământul la înregistrare. Prin urmare, vizitatorul care deschide direct o pagină de vizionare nu primește nicio solicitare privind cookie-urile pe acea pagină și nu își poate modifica sau retrage preferințele din ea; scripturile clasificate ca strict necesare, inclusiv pixelii Meta și TikTok, se încarcă în continuare.

Numărul simulat de participanți în direct. Acolo unde o organizație activează funcționalitatea, numărul de participanți afișat participanților în timpul unei sesiuni live nu este numărul real de participanți simultani: el este calculat pornind de la o valoare de bază configurabilă, la care se adaugă numărul real înmulțit cu un factor configurabil, cu o mică variație aleatorie aplicată la fiecare reconciliere. Personalul vede numărul real; participanții văd cifra calculată.

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

Această secțiune afirma anterior că respectarea confidențialității este starea implicită, că retragerea consimțământului este facilă și că nu se folosesc tipare înșelătoare. Consimțământul pentru termeni, pentru prelucrarea datelor cu caracter personal și pentru notificările SMS este grupat în spatele unei singure bife ori este dedus din prezența unui număr de telefon, în loc să fie colectat separat pe scopuri; retragerea nu este disponibilă pe pagina de vizionare live, unde controalele de consimțământ sunt eliminate din pagină; iar cifra privind audiența, afișată participanților, poate fi o valoare calculată, iar nu numărul real. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Pixelii publicitari și bannerul de cookie-uri.

Meta Pixel și TikTok Pixel intră în grupul de scripturi strict necesare și, prin urmare, se încarcă la fiecare vizualizare de pagină, înainte de decizia vizitatorului în bannerul de cookie-uri și independent de aceasta. Fiecare transmite în acel moment câte o vizualizare de pagină către Meta, respectiv către TikTok, astfel încât ambele platforme primesc adresa IP a vizitatorului, user agent-ul și URL-ul paginii înainte de acordarea vreunui consimțământ. Ambii sunt încărcați într-o stare de consimțământ reținut — fbq('consent','revoke') pentru Meta și ttq.holdConsent() pentru TikTok — menită să împiedice scrierea cookie-urilor publicitare de identificare (_fbp, _fbc, _ttp, _ttclid) până când vizitatorul acceptă categoria publicitară, moment în care starea consimțământului este comutată pe acordat. Absența unui cookie este motivul pentru care aceste scripturi sunt clasificate în prezent ca necesare; ea nu reprezintă o constatare potrivit căreia încărcarea anterioară consimțământului ar fi permisă în temeiul art. 5 alin. (3) din Directiva 2002/58/CE (ePrivacy), iar clasificarea face obiectul unei analize.

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.

Confidențialitate în mod implicit:

  • Organizații noi: contactele sunt păstrate pe durata relației de afaceri (fără ștergere automată în funcție de timp); evenimentele comportamentale sunt păstrate pe termen nelimitat, întrucât în prezent nicio politică de retenție nu poate fi configurată din produs — a se vedea §2.6
  • Evenimente noi: e-mailurile de marketing sunt dezactivate implicit (clienții le activează dacă este necesar)
  • Utilizatori noi din personal: rolul este ales explicit la crearea contului; nu există un implicit de tip „doar citire" — a se vedea §1.2.1

2.8 Documentare și Conformitate ​

Documentație Menținută:

  • Prezentul document privind Măsurile de Securitate (actualizat anual)
  • Acordul de Prelucrare a Datelor (actualizat în funcție de modificările GDPR)
  • Registrul Activităților de Prelucrare (ROPA) (actualizat la lansările de funcționalități)
  • Evaluarea impactului asupra protecției datelor (DPIA) (revizuită anual)
  • Planul de Răspuns la Breșe de Date (testare trimestrială asumată; niciun exercițiu consemnat — a se vedea §2.5)
  • Evidențele de instruire a angajaților — nu sunt menținute; niciun program de instruire nu a fost stabilit (a se vedea §2.1)
  • DPA-urile și certificările furnizorilor (păstrate în dosarul documentelor juridice) — incomplete; a se vedea §2.4

Stadiul întreținerii. Prezenta Anexă a fost revizuită de fond ultima dată înaintea unei serii de modificări materiale ale platformei, între care introducerea modelului de permisiuni cu patru roluri, modificarea limitelor publice privind numărul de cereri, numărul simulat de participanți în direct și contul demonstrativ pentru analiza din magazinele de aplicații; corecturile din prezenta revizuire o readuc în acord cu platforma astfel cum este implementată. Ritmurile anuale și trimestriale enumerate mai sus reprezintă angajamente, iar nu o practică probată: împreună cu documentația juridică nu se păstrează nicio evidență datată a unei revizuiri anuale de securitate, a unui exercițiu trimestrial de tip tabletop sau a unei testări trimestriale a planului privind încălcările securității datelor, astfel încât niciuna nu poate fi produsă ca probă de audit.

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

Prezenta anexă descria anterior propriul ritm de întreținere — revizuirea anuală a prezentului document, revizuirea anuală a evaluării de impact, testarea trimestrială a planului de răspuns la încălcările securității datelor și menținerea evidențelor de instruire și a celor privind furnizorii — drept practică stabilită. Prezentul document a rămas nerevizuit pe parcursul unei perioade întinse de modificări materiale ale platformei, iar pentru niciunul dintre aceste exerciții recurente nu există vreo evidență datată. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Audituri de Conformitate:

  • Audit intern anual (CTO revizuiește toate măsurile de securitate)
  • Audit extern (ISO 27001 sau SOC 2) planificat pentru [2026]
  • Audituri ale clienților (la cerere, în conformitate cu Secțiunea 11 din DPA)

3. Securitate Fizică (Centre de Date) ​

[PLATFORM PROVIDER] nu operează centre de date fizice. Toată infrastructura este găzduită în cloud:

Railway (Regiune UE) ​

  • Certificat SOC 2 Type II
  • Securitate fizică: Centre de date Google Cloud Platform (ISO 27001, acces biometric, supraveghere 24/7)
  • Locație: UE (germany-west sau similar)

Google Cloud / Firebase ​

  • Certificat ISO 27001, SOC 2, SOC 3
  • Securitate fizică: Controale de acces pe mai multe niveluri, intrări mantrap, personal de securitate, supraveghere video
  • Locație: europe-west3 (Frankfurt) pentru Cloud Functions, europe-west1 pentru Realtime Database, multi-regiune UE pentru Firestore. ⚠️ Locația bucket-ului Cloud Storage nu este probată în evidențele [PLATFORM PROVIDER] și trebuie confirmată din configurarea proiectului

NewsmanApp SRL (Furnizor E-mail) ​

  • Cu sediul în România (UE)
  • Securitate fizică: [Request details from Newsman]

Biroul [PLATFORM PROVIDER] (Dezvoltare):

  • Nicio dată de producție stocată pe laptopurile dezvoltatorilor (acces numai prin SSH/HTTPS)
  • Criptare completă a discului obligatorie (BitLocker pe Windows, FileVault pe Mac)
  • Laptopurile blocate când sunt nesupravegheate (blocare automată după 5 min)
  • Registru de vizitatori

4. Securitatea Subîmputerniciților ​

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

Toți subîmputerniciții enumerați în Anexa III sunt obligați să implementeze măsuri de securitate echivalente:

  • Criptare în tranzit și în repaus
  • Controale de acces (MFA, RBAC)
  • Audituri de securitate periodice (ISO 27001 sau SOC 2)
  • Notificarea încălcărilor securității datelor în 24-48 de ore
  • Ștergerea datelor la încetarea contractului

Stadiu. Aceste cerințe reprezintă standardul pe care [PLATFORM PROVIDER] îl aplică atunci când angajează un subîmputernicit; ele nu sunt probate astăzi pentru fiecare subîmputernicit. Nu există la dosar câte un acord de prelucrare a datelor pentru fiecare, iar pentru doi dintre ei — furnizorul de modele AI și furnizorul de mesagerie tranzacțională — prelucrarea a început înainte de încheierea vreunui acord și înainte de consemnarea unui mecanism de transfer. A se vedea §2.4 și Anexa III.

Verificare: [PLATFORM PROVIDER] revizuiește anual documentația de securitate a subîmputerniciților (solicită rapoarte SOC 2, documente tehnice de securitate).

5. Îmbunătățire Continuă ​

Revizuire Anuală a Securității:

  • CTO efectuează revizuirea în fiecare ianuarie
  • Evaluează noile amenințări (actualizări OWASP Top 10, CVE-uri în dependențe)
  • Actualizează măsurile de securitate după necesitate
  • Alocarea bugetului pentru îmbunătățiri de securitate

Revizuiri Post-Incident:

  • După fiecare Incident de Securitate (chiar minor), se efectuează analiza cauzei principale
  • Se actualizează măsurile de securitate pentru a preveni recurența
  • Se împărtășesc lecțiile învățate cu echipa de inginerie (în formă anonimizată)

Monitorizare Reglementară:

  • Urmărirea actualizărilor ghidurilor GDPR ale EDPB (Comitetul European pentru Protecția Datelor)
  • Urmărirea deciziilor autorităților de supraveghere (în special ANSPDCP din România)
  • Actualizarea măsurilor pentru alinierea la noile interpretări

6. Măsuri Specifice Clientului (La Cerere) ​

Următoarele măsuri îmbunătățite sunt disponibile la cererea Clientului (pot implica taxe suplimentare):

  • Chei de Criptare Gestionate de Client (CMEK): Clientul controlează cheile de criptare pentru datele Firestore (necesită configurare Google Cloud KMS)
  • Instanță de Baze de Date Dedicată: Datele Clientului izolate într-o instanță PostgreSQL separată (nu partajată multi-tenant)
  • Politici de Retenție Personalizate: perioade de retenție per organizație pentru tipurile de date acceptate, într-un interval de la 30 la 3.650 de zile. Neoperabile în prezent: astfel cum se arată la §2.6, nicio politică de retenție nu poate fi salvată din produs, deci această măsură nu poate fi livrată până la corectarea situației
  • Lista Albă IP: Restricționarea accesului la tabloul de bord la adresele IP ale biroului Clientului
  • SAML SSO: Înlocuirea Firebase Auth cu furnizorul de identitate al Clientului (Okta, Azure AD)
  • Suport Dedicat: Suport telefonic 24/7 pentru Incidente de Securitate

Controlul Documentului ​

Versiunea Documentului: 1.0 (DRAFT) Ultima revizuire: [DATE] Următoarea revizuire: [DATE + 1 year] Responsabil: CTO, [PLATFORM PROVIDER] Aprobat de: [Legal Team, DPO]

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

Sfârșitul Anexei II