Planul de Răspuns la Breșe de Date

[PLATFORM PROVIDER] — Platforma de EvenimentArticolele 33 și 34 GDPRUltima actualizare: [DATE]

---

1. Scop și Domeniu de Aplicare

Prezentul Plan de Răspuns la Breșe de Date stabilește procedurile de detectare, limitare, investigare și gestionare a breșelor de date cu caracter personal care afectează platforma de eveniment [PLATFORM PROVIDER].

Definiții (art. 4 pct. 12 din Regulamentul (UE) 2016/679 (GDPR)):

• Încălcarea securității datelor cu caracter personal (breșă de date): înseamnă o încălcare a securității care duce, în mod accidental sau ilegal, la distrugerea, pierderea, modificarea sau divulgarea neautorizată a datelor cu caracter personal transmise, stocate sau prelucrate într-un alt mod ori la accesul neautorizat la acestea.

Exemple:

• Acces neautorizat la bazele de date ale clienților (PostgreSQL, Firestore)
• Ransomware care criptează datele de producție
• Expunerea accidentală a datelor cu caracter personal (reguli de securitate Firestore, Realtime Database sau Cloud Storage configurate greșit)
• Laptop pierdut sau furat, care conține copii de rezervă necriptate ale bazelor de date
• Amenințare internă (angajat rău intenționat care extrage date)
• Breșă la un terț (compromiterea unui subîmputernicit precum Railway Corp. sau Google LLC)
• Configurare greșită a platformei, care dezactivează autentificarea, astfel încât cererile sunt considerate de încredere pe baza antetelor furnizate de apelant ori a unor token-uri neverificate (a se vedea Secțiunea 5.2, Scenariul 5)
• Compromiterea proxy-ului invers ce termină conexiunea TLS pentru traficul participanților (Cloudflare, Inc.) ori interceptarea la nivelul acestuia; prin el trece în clar fiecare formular de înregistrare transmis de un participant

Domeniu de aplicare: Se aplică tuturor datelor cu caracter personal prelucrate de [PLATFORM PROVIDER] în calitate de Persoană împuternicită de operator, în numele organizațiilor-client (Operatori de date).

Obiective:

1. Detectarea rapidă a breșelor (reducerea la minimum a ferestrei de expunere)
2. Limitarea breșei (împiedicarea oricărui acces neautorizat suplimentar)
3. Evaluarea impactului (câte Persoane Vizate sunt afectate, ce date)
4. Notificarea părților afectate (clienții în 24h, autoritatea de supraveghere în 72h, dacă este necesar)
5. Remedierea cauzei principale (împiedicarea repetării)

---

2. Roluri și Responsabilități

Echipa de Răspuns la Incidente (IRT)

Rol	Responsabilități	Contact
Comandant Incident	Coordonarea generală a incidentului, luarea deciziilor, escaladare	CTO ([Email], [Phone])
Lider Tehnic	Investigare tehnică, limitare, remediere	Inginer Senior Backend ([Email], [Phone])
Consilier Juridic	Obligații legale, elaborarea notificărilor, legătura cu autoritatea de supraveghere	Avocat Extern ([Firm Name], [Email], [Phone])
Responsabil cu protecția datelor (DPO)	Supravegherea conformității GDPR, evaluarea riscurilor, contactul cu autoritatea de supraveghere	[Name, Email, Phone] (dacă este desemnat)
Responsabil Comunicare	Notificarea clienților, declarații publice (dacă este necesar), relația cu presa	CEO ([Email], [Phone])
Suport Clienți	Asistența clienților, preluarea solicitărilor primite, reasigurare	Manager Suport Clienți ([Email])

Escaladare și Disponibilitate

• Contact principal: Liderul Tehnic, contactat direct pe baza datelor din Secțiunea 7. Nu este pusă la dispoziție nicio platformă de apelare a echipei de gardă și nu se ține niciun program de rotație într-un sistem de evidență, astfel încât escaladarea este manuală, iar contactul în afara programului depinde de posibilitatea de a ajunge direct la o persoană anume.
• Escaladare: Comandantul Incidentului (CTO), contactat telefonic.
• Rolurile din tabelul de mai sus sunt funcții, iar nu o garanție a existenței unor persoane distincte. Atunci când o singură persoană deține mai multe roluri, această situație și orice verificare compensatorie se consemnează în evidența incidentului.
• Neconcordanța dintre această situație și mecanismele descrise în versiunile anterioare ale prezentului plan este consemnată în caseta de la Secțiunea 3.1.

---

3. Detectare și Raportare

3.1 Mecanisme de Detectare

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.

Detectarea în practică. Detectarea este manuală și reactivă. Ea se realizează prin:

• Divulgarea din partea unui cercetător în securitate (divulgare responsabilă, prin [email protected])
• Sesizarea unui client (activitate neobișnuită în datele organizației sale)
• Observația personalului (comportament suspect, acces neașteptat la date, analiza jurnalelor de aplicație)
• Notificarea unui terț (breșă la un subîmputernicit sau înștiințare apărută în consola proprie a unui furnizor de găzduire)

Latența detectării. Întrucât niciun canal nu este monitorizat automat, un incident care nu produce niciun simptom vizibil pentru client poate rămâne nedetectat până când o persoană citește jurnalele de aplicație sau căsuța poștală de securitate. Termenul de 72 de ore prevăzut la art. 33 alin. (1) GDPR curge din momentul în care [PLATFORM PROVIDER] ia cunoștință de o breșă, astfel încât fereastra de expunere anterioară luării la cunoștință poate fi semnificativ mai lungă decât termenul de notificare ulterior acesteia. Acest lucru se menționează explicit în orice notificare adresată unui Operator sau autorității de supraveghere, iar evaluarea impactului se realizează pornind de la ipoteza cea mai defavorabilă, pentru întreaga perioadă în care situația a existat, iar nu numai pentru perioada ulterioară observării ei.

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

Prezentul document arăta anterior că detectarea și alertarea se sprijină pe alerte automate de securitate din partea furnizorului de găzduire și a Firebase, pe o capacitate centralizată de analiză a jurnalelor, pe un canal de chat dedicat incidentelor, care alerta automat echipa de răspuns, pe o rotație de gardă și pe o căsuță poștală de securitate monitorizată permanent. Niciunul dintre aceste elemente de infrastructură nu există: platforma nu dispune de niciun serviciu de urmărire a erorilor, de nicio integrare de apelare a echipei de gardă, de niciun canal de chat pentru incidente și de nicio formă de alertare automată, iar termenele de confirmare de două ore și de patru ore indicate anterior nu erau susținute de niciun canal monitorizat și de nicio măsurătoare. Detectarea este astăzi manuală și reactivă, potrivit descrierii de mai sus, iar intrările privind instrumentele din Secțiunea 6.1 au fost corectate în consecință. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.2 Canale de Raportare

Raportare Internă (Personal):

• E-mail: [email protected]
• Telefon: Liderul Tehnic sau Comandantul Incidentului, pe baza datelor din Secțiunea 7. Acesta este singurul canal care ajunge la o persoană atât timp cât căsuța poștală nu este citită.

Raportare Externă (Cercetători, Clienți):

• E-mail: [email protected]
• Formular web: (viitor) https://restartix.ro/security-disclosure
• Confirmare de primire: o sesizare este confirmată la următoarea citire a căsuței poștale. Nimic nu direcționează automat către o persoană o sesizare primită, astfel încât o sesizare sosită în afara programului de lucru poate fi văzută abia în ziua lucrătoare următoare. În prezent, niciun nivel de serviciu privind confirmarea de primire nu este susținut de un canal monitorizat; a se vedea caseta de la Secțiunea 3.1.

Raportare Obligatorie (Obligația Personalului):

• Tot personalul TREBUIE să raporteze imediat breșele suspectate (fără așteptare, fără investigare pe cont propriu)
• „Dacă observi ceva, raportează" — o alarmă falsă este preferabilă unui răspuns întârziat
• Fără represalii pentru raportările făcute cu bună-credință

---

4. Fazele Răspunsului la Incident

Faza 1: Detectare și Evaluare Inițială (0-2 ore)

Acțiuni:

1. Sesizare primită: o sesizare ajunge la [email protected], un membru al personalului ori un client ridică direct problema sau un subîmputernicit transmite o înștiințare. Nu există nicio alertă automată (Secțiunea 3.1).
2. Convocarea echipei: Comandantul Incidentului contactează IRT telefonic și prin e-mail, în termen de 30 de minute.
3. Confirmarea breșei: Este vorba despre un incident real de securitate sau despre un fals pozitiv?
   • Analiza jurnalelor, în limitele lor. Jurnalul de acces HTTP consemnează metoda cererii, calea completă a cererii, inclusiv șirul de interogare, statusul răspunsului, latența, o adresă IP a clientului și un identificator de cerere. El nu consemnează identificatorul organizației, utilizatorul care acționează și nici user agent-ul, astfel încât nu poate stabili, prin el însuși, cine a accesat și ce anume. Atribuirea la nivel de cerere există numai pentru acțiunile personalului scrise în jurnalul de audit; traficul public, cel al participanților, cel dintre servicii și cel al webhook-urilor nu lasă nicio evidență a actorului, per cerere.
   • Verificarea stării sistemelor (consolele furnizorului de găzduire și Firebase)
   • Discuția cu persoana care a raportat (dacă sesizarea provine de la personal sau de la un client)
4. Clasificare inițială:
   • Severitate: Scăzută / Medie / Ridicată / Critică
     • Critică: Date cu caracter personal în clar, expuse public, exfiltrare la scară largă (>10.000 de Persoane Vizate)
     • Ridicată: Acces neautorizat la baza de date de producție, ransomware
     • Medie: Acces neautorizat la datele unui singur client (<1.000 de Persoane Vizate)
     • Scăzută: Tentativă de breșă (blocată de măsurile de securitate), fără exfiltrare de date
   • Amploare: Câți clienți sunt afectați? Câte Persoane Vizate?
   • Categorii de date: Ce tipuri de date cu caracter personal? Acestea se enumeră pe baza listei de verificare a straturilor de stocare din Faza 3, punctul 2, iar nu din memorie.
5. Activarea planului: Comandantul Incidentului declară nivelul incidentului și atribuie rolurile

Punct de decizie: Dacă nu este vorba despre o breșă de date cu caracter personal (de exemplu, atac DDoS, întreruperea serviciului, fără implicarea unor date cu caracter personal) → escaladare către răspunsul standard la incidente IT (nu prezentul plan). Dacă da → se continuă cu Faza 2.

---

Faza 2: Limitare (2-6 ore)

Obiectiv: Oprirea hemoragiei — împiedicarea oricărui acces neautorizat suplimentar sau a pierderii de date.

Acțiuni Imediate:

1. Izolarea Sistemelor Afectate:

   • Dacă baza de date este compromisă: Revocarea acreditărilor compromise, rotirea parolelor bazei de date
   • Dacă API-ul este vulnerabil: Implementarea unor reguli de firewall pentru blocarea intervalelor IP ale atacatorului
   • Dacă este vorba despre ransomware: Oprirea serverelor afectate (Railway: oprirea implementării, izolarea bazei de date)
   • Dacă regulile de securitate sunt configurate greșit: Corectarea regulilor Firestore/RTDB, implementare imediată (firebase deploy --only firestore:rules,database)

2. Păstrarea Probelor:

   • NU ștergeți jurnalele (sunt necesare pentru investigația criminalistică)
   • Exportați jurnalele de aplicație din depozitul de jurnale al furnizorului de găzduire într-o locație aflată în afara infrastructurii proprii a platformei și faceți acest lucru ca primă acțiune. Retenția acestor jurnale este guvernată de fereastra de retenție proprie a furnizorului de găzduire, iar nu de [PLATFORM PROVIDER], astfel încât amânarea exportului duce la pierderea probelor prin expirare.
   • Nu folosiți bucket-ul Cloud Storage al platformei drept depozit de probe. Regulile sale de securitate se încheie cu o regulă finală, cu caracter general (catch-all), care acordă drept de citire și de scriere oricărui utilizator autentificat, iar căile delimitate pe organizație, situate deasupra acelei reguli, pot fi citite necondiționat, fără autentificare (Secțiunea 5.2).
   • Tratați jurnalele exportate ca material sensibil în sine. Jurnalul de acces consemnează calea completă a cererii, inclusiv șirul de interogare, astfel încât orice acreditare transmisă ca parametru de interogare — de exemplu, secretul de webhook al funnel-ului — se regăsește în fișierul exportat.
   • Realizați un snapshot al bazei de date înainte de orice modificare.
   • Realizați capturi de ecran ale sistemelor afectate, ale instrumentelor atacatorului și ale mesajelor de eroare
   • Rezervă privind atribuirea. Adresa IP consemnată în intrările din jurnalul de audit este preluată din antetele de redirecționare furnizate de client, care sunt acceptate fără validarea unui proxy de încredere și pot fi, prin urmare, stabilite de apelant. Ea nu poate fi prezentată unui client sau ANSPDCP drept probă fiabilă a originii unei cereri.

3. Revocarea Accesului:

   • Acreditări compromise: Resetarea parolelor pentru toate conturile afectate (Firebase Authentication, furnizorul de găzduire, găzduirea codului-sursă)
   • Autentificarea participanților: atunci când aplicația pentru participanți se află în perimetrul incidentului, eliminați, ca primă măsură de limitare, configurarea demonstrativă destinată analizei din magazinele de aplicații. Această configurare permite unei singure adrese de e-mail indicate să se autentifice în aplicația pentru participanți cu un cod fix, care ocolește în întregime codul de unică folosință trimis prin e-mail și emite un token de autentificare complet. Ea nu expiră, este menită să fie stabilită în producție și nu lasă nicio intrare în jurnalul de audit — numai o linie de avertizare în jurnalul de aplicație.
   • Secretele platformei — se rotesc pe baza unui inventar nominal: șirurile de conexiune pentru rolul de bază de date privilegiat și pentru cel restricționat, secretul partajat pentru comunicarea dintre servicii, acreditarea contului de serviciu Firebase, cheia API Firebase Web, cheia API a furnizorului de modele și acreditările demonstrative pentru analiza din magazinele de aplicații. Toate sunt păstrate ca variabile de mediu pe platforma de găzduire, astfel încât rotirea constă într-o modificare de configurare, urmată de o reimplementare.
   • Secretele de integrare per organizație: rotiți acreditările păstrate în Google Secret Manager pentru fiecare organizație afectată, respectiv cele ale integrărilor de mesagerie, de e-mail, de livrare de conținut și de publicitate. Atunci când furnizorul de mesagerie SMS se află în perimetrul incidentului, trebuie să se prezume, suplimentar, că acreditările sale se regăsesc în jurnalele de cereri ale furnizorului respectiv, întrucât numele de utilizator și parola contului sunt transmise ca parametri în șirul de interogare al URL-ului, la fiecare trimitere.
   • Conturile de serviciu Firebase și autentificările în consolele terților: rotiți acreditările și analizați accesul.
   • Conturi de personal suspecte: Suspendarea accesului până la finalizarea investigației (dacă se suspectează o amenințare internă)

4. Închiderea Vectorului de Atac:

   • Corectarea codului vulnerabil (implementarea remedierii în producție)
   • Actualizarea dependențelor (dacă există un CVE într-un pachet npm sau într-un modul Go)
   • Dezactivarea funcționalității vulnerabile (dacă remedierea durează >24h, dezactivarea temporară a funcționalității pentru a opri exploatarea)

Termen: Limitarea se finalizează în 6 ore de la alerta inițială (incidente critice: 2 ore).

Comunicare în Timpul Limitării:

• Comandantul Incidentului transmite IRT actualizări la fiecare 30 de minute, telefonic sau prin e-mail; nu este pus la dispoziție niciun canal de chat pentru incidente (Secțiunea 6.1)
• NICIO comunicare externă în această etapă (clienții nu sunt notificați până la finalizarea evaluării)

---

Faza 3: Evaluare și Notificare (6-24 de ore)

Obiectiv: Determinarea impactului și notificarea părților afectate.

3.1 Evaluarea Impactului

Întrebări la care trebuie răspuns:

1. Câte Persoane Vizate sunt afectate?

   • PostgreSQL nu păstrează nicio evidență a citirilor, per rând. Tabelul de contacte nu are o coloană de ultim acces, astfel încât amploarea unui incident nu poate fi dedusă din evidențele de contact în sine. Accesul dinspre personal se reconstituie din jurnalul de audit, care consemnează, pentru fiecare acțiune auditată a personalului, organizația, utilizatorul care acționează și rolul acestuia, acțiunea, ținta, metadatele, o adresă IP și un marcaj temporal — inclusiv vizualizările de contacte, vizualizările membrilor unui segment și exporturile de contacte și de segmente. Selectați acțiunile auditate care se încadrează în fereastra de expunere și deduceți din ele organizațiile afectate.
   • Restul nu poate fi atribuit. Pentru orice cale care nu trece prin tabloul de bord al personalului — traficul public, cel al participanților, cel dintre servicii și cel al webhook-urilor — nu există nicio evidență a citirilor, per rând. Amploarea se deduce, în acest caz, din privilegiile acreditării compromise ori din întinderea regulii configurate greșit și se evaluează pornind de la ipoteza cea mai defavorabilă.
   • Realtime Database: nu există niciun jurnal de audit al citirilor pentru Realtime Database și niciunul nu poate fi produs retroactiv. Orice expunere a datelor sesiunilor live se evaluează pornind de la premisa că tot ceea ce putea fi citit în temeiul regulii afectate a fost efectiv citit.
   • Firestore și Cloud Storage: consemnarea citirilor, per document, presupune jurnalele Cloud Audit Data Access, care sunt dezactivate implicit și nu sunt activate în configurația actuală a platformei. Dacă situația nu s-a schimbat până la momentul incidentului, nu există nicio evidență a citirilor individuale de documente și se aplică aceeași ipoteză, cea mai defavorabilă.

   În ipoteza cea mai defavorabilă, expunerea datelor unei sesiuni live are o amploare foarte mare, întrucât aceste date nu sunt niciodată eliminate:

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

Această secțiune afirma anterior că amploarea unui incident se stabilește pornind de la o coloană de bază de date care consemnează ultimul acces al fiecărui contact, de la jurnalele de acces ale Realtime Database și de la jurnalele de audit Firestore, care ar fi arătat cine a citit fiecare document. Niciuna dintre aceste surse nu există: tabelul de contacte nu are o astfel de coloană, Realtime Database nu are niciun jurnal de audit al citirilor, iar jurnalizarea Cloud Audit Data Access nu este activată pe proiectul de producție. Amploarea se reconstituie, în schimb, din jurnalul de audit pentru acțiunile personalului și se evaluează pornind de la ipoteza cea mai defavorabilă pentru orice altă cale de acces. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

2. Ce date au fost accesate sau exfiltrate?

   • Exfiltrare confirmată: Atacatorul a descărcat date (creștere bruscă a traficului de rețea de ieșire, probe deținute de furnizor)
   • Acces potențial: Atacatorul a deținut acreditări, dar nu se știe cu certitudine dacă datele au fost copiate (se pornește de la ipoteza cea mai defavorabilă)
   • Categorii: nu se lucrează pe baza unei liste fixe din prezentul plan. Inventarul de referință al datelor cu caracter personal prelucrate de platformă este Registrul Activităților de Prelucrare (ROPA), citit împreună cu Politica de Retenție a Datelor. Categoriile afectate se enumeră din aceste documente, pentru ca cifrele comunicate în temeiul art. 33 alin. (3) lit. (b) și (c) GDPR să nu se îndepărteze de realitate pe măsură ce produsul evoluează.
   • Straturi de stocare de enumerat, pe rând:
     • PostgreSQL — evidențele de contact și de înregistrare, evidențele de consimțământ, evenimentele comportamentale, intrările în funnel (atribuirea campaniilor, datele privind dispozitivul și localizarea aproximativă, payload-urile de webhook și datele privind achizițiile primite din magazinul unui client), vizualizările paginilor de funnel (un identificator pseudonim persistent de vizitator, derivat din adresa IP și din user agent-ul vizitatorului), evidențele de livrare a SMS-urilor, evidențele destinatarilor difuzărilor către segmente, înscrierile în automatizări și evidențele de execuție a pașilor, joburile de generare cu AI, jurnalul de audit și registrul cererilor persoanelor vizate.
     • Firestore — datele cu caracter personal ale contactelor (adresa de e-mail, numele și numărul de telefon, în clar), documentele de înregistrare și subcolecția lor cu date cu caracter personal, evidențele de consimțământ, codurile de verificare și link-urile magice.
     • Realtime Database — nodurile sesiunilor live: fluxul de chat, fluxul mesajelor eliminate prin moderare (care păstrează textul original al mesajului și autorul acestuia), directorul de actori, care conține numele afișate ale participanților, prezența, participarea, voturile la sondaje, reacțiile, click-urile pe oferte, răspunsurile de feedback, numărul de mesaje per actor și memoria cache de identitate, care asociază identificatorul anonim de actor cu hash-ul unei adrese de e-mail.
     • Cloud Storage — fișierele media ale organizației, elementele de brand, fișierele paginilor de destinație, șabloanele de pagină și fișierele încărcate de personal.
     • Jurnalele de aplicație păstrate de furnizorul de găzduire — inclusiv adresele de e-mail în clar scrise de către căile de import în masă, de invitare a personalului și de autentificare a participanților, precum și căile complete ale cererilor, inclusiv șirurile de interogare.
     • Memoria cache din procesul API-ului, cu datele de contact — a se vedea punctul 4 de mai jos.

3. Ce clienți (organizații) sunt afectați?

   • Listați toate valorile org_id din datele afectate
   • Prioritizați notificarea (mai întâi cei mai mari clienți, cele mai sensibile date)

4. Datele erau criptate sau pseudonimizate?

   • La repaus: Da (PostgreSQL și Firestore sunt criptate), ÎNSĂ un atacator cu acces la baza de date vede datele în clar (criptarea protejează împotriva furtului de disc, nu împotriva accesului autorizat, dar rău intenționat)
   • În tranzit: Dacă atacatorul a interceptat traficul de rețea, era TLS activat? (se prezumă că da, toate conexiunile sunt TLS 1.2+)
   • Pseudonimizarea — situația generală: 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.
   • Excepțiile: 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.
   • Memoria cache din proces: 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.
   • Jurnalele de aplicație: adresele de e-mail în clar sunt scrise în depozitul de jurnale al furnizorului de găzduire de către căile de import în masă, de invitare a personalului și de autentificare a participanților.
   • Rezistența pseudonimului: hash-ul adresei de e-mail este un SHA-256 fără sare criptografică, calculat pe adresa convertită în minuscule și lipsită de spațiile de la capete, așa încât poate fi recalculat de oricine cunoaște adresa, iar regulile Firestore permit oricărui apelant autentificat să obțină documentul cu datele cu caracter personal ale contactului, păstrat la acea cale. Prin urmare, hash-ul se tratează drept cheie de căutare, iar nu drept măsură care face datele neinteligibile.
   • Consecința pentru evaluare: o compromitere limitată la PostgreSQL se evaluează, cu toate acestea, drept compromitere a unor date cu caracter personal în clar, cu excepția cazului în care evidențele de execuție a pașilor de automatizare, memoria cache din proces și jurnalele de aplicație se dovedesc, toate, a fi în afara perimetrului incidentului. Stabiliți de la caz la caz care depozite au fost vizate; nu introduceți în evaluare o concluzie prestabilită.

5. Care este probabilitatea unui prejudiciu pentru Persoanele Vizate?

   • Risc ridicat: Adresa de e-mail în clar + numele + mesajele din chat, expuse public (risc de phishing, de hărțuire, de prejudiciu reputațional)
   • Risc mediu: Numai adresa de e-mail și numele (risc de spam, de phishing)
   • Risc scăzut: Numai hash-uri ale adreselor de e-mail și numai atunci când s-a stabilit că niciun depozit cu date în clar nu a fost vizat — datele cu caracter personal ale contactelor din Firestore, evidențele de execuție a pașilor de automatizare, memoria cache din proces și jurnalele de aplicație — și că atacatorul nu deține nicio listă de adrese posibile din care hash-urile să poată fi recalculate. Aceasta este o concluzie la care se ajunge pe baza faptelor incidentului; ea nu se prezumă niciodată din simpla împrejurare că depozitul afectat a fost PostgreSQL.

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

Prezentul document arăta anterior că o compromitere a PostgreSQL expune numai hash-uri ale adreselor de e-mail, trata această situație drept un rezultat cu risc scăzut și se întemeia pe funcția de hash drept măsură de protecție în sensul art. 34 alin. (3) lit. (a) GDPR, aptă să înlăture obligația de notificare a persoanelor vizate. PostgreSQL nu conține exclusiv hash-uri — evidențele de execuție a pașilor de automatizare conțin adresa de e-mail și numărul de telefon ale destinatarului, în clar —, API-ul menține în memoria procesului o memorie cache fără termen de expirare, cu datele de contact în clar, adresele de e-mail în clar ajung în depozitul de jurnale al furnizorului de găzduire, iar hash-ul însuși este un SHA-256 fără sare criptografică al adresei, pe care oricine cunoaște adresa îl poate recalcula. Prin urmare, atât concluzia privind riscul, cât și posibilitatea invocării exceptării prevăzute la art. 34 alin. (3) lit. (a) GDPR se stabilesc pe baza faptelor fiecărui incident. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

3.2 Matricea Deciziei de Notificare

Scenariu	Notificarea Clienților (Operatori)?	Notificarea Autorității de Supraveghere (ANSPDCP)?	Notificarea Persoanelor Vizate?
Acces neautorizat, <250 de Persoane Vizate, numai adresa de e-mail și numele, nicio exfiltrare confirmată	✅ Da (în 24h)	❌ Nu (risc scăzut, puțin probabil să genereze un risc pentru drepturi și libertăți)	❌ Nu (clientul decide)
Acces neautorizat, >1.000 de Persoane Vizate, adresa de e-mail + numele + mesajele din chat, exfiltrare probabilă	✅ Da (în 24h)	✅ Da (în 72h de la luarea la cunoștință)	⚠️ Clientul decide (dar art. 34 GDPR o impune, probabil, având în vedere riscul ridicat)
Ransomware criptează copiile de rezervă, datele de producție rămân intacte, fără acces la datele în clar	✅ Da (în 24h, din considerente de transparență)	✅ Da (în 72h, pierdere sau distrugere de date)	❌ Probabil nu (datele nu au fost divulgate unei părți neautorizate)
Reguli de securitate Firebase configurate greșit timp de 2 ore, remediate imediat; nu există niciun jurnal al citirilor care să poată confirma sau exclude accesul	✅ Da (în 24h, chiar dacă nu se detectează niciun acces)	⚠️ Se evaluează pornind de la ipoteza cea mai defavorabilă: lipsa unui jurnal al citirilor nu constituie dovada că accesul nu a avut loc, așa încât, dacă accesul a fost posibil → Da	⚠️ Clientul decide, în raport cu amploarea din ipoteza cea mai defavorabilă, iar nu cu accesul confirmat
Un subîmputernicit (de exemplu, Railway Corp.) transmite o înștiințare privind o breșă care afectează datele prelucrate de platformă	✅ Da (imediat după înștiințarea subîmputernicitului)	✅ Da (în 72h de la luarea la cunoștință prin intermediul subîmputernicitului)	⚠️ Clientul decide (depinde de amploarea breșei subîmputernicitului)

Art. 33 GDPR (Notificarea autorității de supraveghere):

• Declanșator: Breșa este susceptibilă să genereze un risc pentru drepturile și libertățile Persoanelor Vizate
• Termen: 72 de ore de la luarea la cunoștință (nu de la producere, ci de la descoperire)
• Exceptare: Dacă este puțin probabil ca breșa să genereze un risc (de exemplu, date criptate, fără compromiterea cheilor)

Art. 34 GDPR (Notificarea persoanelor vizate):

• Declanșator: Breșa este susceptibilă să genereze un RISC RIDICAT pentru drepturile și libertățile Persoanelor Vizate
• Termen: Fără întârziere nejustificată
• Exceptări:
  • Aplicarea unor măsuri de protecție adecvate (de exemplu, criptarea la repaus, atunci când cheile înseși nu au fost compromise). Funcția de hash aplicată adreselor de e-mail nu îndeplinește această condiție, în forma în care este implementată: hash-ul este un SHA-256 fără sare criptografică al adresei convertite în minuscule și poate fi recalculat pornind de la orice adresă cunoscută, așa încât nu face datele neinteligibile în sensul art. 34 alin. (3) lit. (a) GDPR. A se vedea punctul 4 din evaluarea impactului de mai sus.
  • Măsuri luate pentru reducerea riscului (de exemplu, resetarea forțată a parolei, monitorizarea gratuită a creditului)
  • Efort disproporționat (>10.000 de Persoane Vizate → comunicare publică în locul e-mailurilor individuale)

Responsabilitatea [PLATFORM PROVIDER] în raport cu responsabilitatea Clientului:

• [PLATFORM PROVIDER] (Persoana împuternicită de operator): Notifică clienții (Operatorii) în 24h și furnizează toate detaliile
• Clientul (Operator): Decide dacă notifică autoritatea de supraveghere și Persoanele Vizate ([PLATFORM PROVIDER] acordă asistență cu informații)
• Excepție: Dacă breșa provine din sistemele [PLATFORM PROVIDER] ȘI afectează mai mulți clienți, [PLATFORM PROVIDER] poate notifica direct ANSPDCP (cu coordonarea clientului)

3.3 Notificarea Clientului (În 24 de Ore)

Metoda de notificare:

• E-mail: Fișa organizației nu conține niciun câmp de contact de securitate înregistrat și nu există nicio setare prin care un client să poată desemna unul. Notificarea se adresează, prin urmare, adreselor de e-mail ale utilizatorilor cu rol de administrator ai organizației, preluate din fișele utilizatorilor din personalul acelei organizații. Atunci când un client a indicat, în corespondență, un alt contact, acea adresă se folosește suplimentar, iar nu în locul celorlalte.
• Telefon: Pentru incidentele critice (>10.000 de Persoane Vizate), Comandantul Incidentului îi apelează pe cei mai mari clienți afectați, pe baza datelor de contact păstrate în afara platformei.

Nu există niciun banner de incident în produs și niciun ecran destinat clienților pentru raportarea breșelor. Fiecare element descris mai jos — e-mailul de notificare, raportul criminalistic și lista persoanelor vizate afectate — este întocmit și transmis manual.

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

Această secțiune afirma anterior că notificarea se transmite la o adresă de contact de securitate înregistrată pe fișa organizației, că în tabloul de bord apare un banner roșu de incident și că există un ecran „Setări → GDPR → Raport Breșă" din care clientul poate exporta lista persoanelor vizate afectate. Niciunul dintre cele trei elemente nu există: fișa organizației nu are un câmp de contact de securitate, niciun banner de incident nu este implementat, iar tabloul de bord nu are niciun ecran de raportare a breșelor. Notificarea și lista persoanelor vizate afectate se întocmesc manual, potrivit prezentei secțiuni. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Șablon de e-mail:

Subiect: URGENT — Notificare privind o breșă de date cu caracter personal

Stimate/Stimată [Customer Organization Name],

Vă scriem pentru a vă informa cu privire la o breșă de date cu caracter personal care afectează datele organizației dumneavoastră pe platforma de eveniment [PLATFORM PROVIDER].

REZUMATUL INCIDENTULUI:
- Data/Ora detectării: [YYYY-MM-DD HH:MM UTC]
- Natura breșei: [Acces neautorizat / Ransomware / Configurare greșită / etc.]
- Categorii de date afectate: [se enumeră din Registrul Activităților de Prelucrare; de exemplu: adresa de e-mail, numele, telefonul, mesajele din chat, voturile la sondaje]
- Număr estimat de Persoane Vizate afectate: [Număr]
- Exfiltrare confirmată: [Da / Nu / Incert]

DETALII:
[Descriere de 2-3 paragrafe a ceea ce s-a întâmplat, a modului în care atacatorul a obținut accesul și a datelor expuse]

ACȚIUNI DE LIMITARE ÎNTREPRINSE:
- [Acțiunea 1: de exemplu, revocarea acreditărilor compromise]
- [Acțiunea 2: de exemplu, corectarea vulnerabilității din API]
- [Acțiunea 3: de exemplu, implementarea unor reguli de firewall]
- Limitare finalizată: [YYYY-MM-DD HH:MM UTC]

OBLIGAȚIILE DUMNEAVOASTRĂ (Operator de date):
În conformitate cu art. 33 GDPR, aveți obligația să evaluați dacă prezenta breșă impune notificarea autorității dumneavoastră de supraveghere (în 72 de ore de la primirea prezentei notificări).

În conformitate cu art. 34 GDPR, aveți obligația să evaluați dacă Persoanele Vizate trebuie notificate (în cazul unui risc ridicat pentru drepturile și libertățile acestora).

[PLATFORM PROVIDER] recomandă: [Evaluarea noastră: Notificați / Nu notificați — cu motivare]

ASISTENȚĂ DIN PARTEA [PLATFORM PROVIDER]:
- Raport criminalistic detaliat: Atașat (PDF)
- Lista Persoanelor Vizate afectate: Atașată (CSV), întocmită pentru organizația dumneavoastră
- Suport juridic: Consilierul nostru extern este disponibil pentru consultare (contactați [email protected])

CAUZA PRINCIPALĂ ȘI PREVENIREA:
[Scurtă descriere a motivului producerii și a măsurilor luate pentru împiedicarea repetării]

CONTACT:
Comandant Incident: [Name, Email, Phone] (disponibil 24/7 pe durata incidentului)
Suport: [email protected]

Ne cerem sincer scuze pentru acest incident și ne angajăm să împiedicăm producerea unor incidente similare în viitor.

Cu stimă,
[Incident Commander Name]
CTO, [PLATFORM PROVIDER]

Anexe:

• Raport criminalistic (PDF): Cronologie, date afectate, acțiuni de limitare, cauza principală
• Export CSV: Lista Persoanelor Vizate afectate, pentru notificarea proprie a clientului. Nu există niciun export în regim de autoservire. Fișierul este întocmit manual de un membru al personalului, prin selectarea evidențelor afectate în PostgreSQL — care furnizează hash-ul adresei de e-mail și identificatorul de înregistrare — și prin obținerea, din Firestore, a adresei de e-mail și a numelui fiecărui contact, în clar, Firestore fiind singurul depozit care le păstrează. Fișierul livrat conține, pentru fiecare persoană vizată, adresa de e-mail, numele, acolo unde a fost furnizat, hash-ul adresei de e-mail și identificatorul de înregistrare.

3.4 Notificarea Autorității de Supraveghere (În 72 de Ore)

Dacă este necesar (în conformitate cu matricea deciziei de mai sus):

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

Metoda de notificare:

• Formular online: Site-ul web ANSPDCP (preferat)
• E-mail: [email protected] (dacă formularul nu este disponibil)
• Telefon: [Linie de urgență ANSPDCP] (incidente critice)

Informații de furnizat (art. 33 alin. (3) GDPR):

1. Natura breșei:

   • Descriere: [Acces neautorizat / Ransomware / Configurare greșită]
   • Data/ora producerii (dacă se cunoaște): [YYYY-MM-DD HH:MM]
   • Data/ora la care [PLATFORM PROVIDER] a luat cunoștință: [YYYY-MM-DD HH:MM]

2. Categoriile și numărul aproximativ de Persoane Vizate:

   • Categorii: Participanți la evenimente, utilizatori din personalul clientului
   • Număr: [de exemplu, 15.000 de participanți din 50 de organizații]

3. Categoriile și numărul aproximativ de înregistrări de date cu caracter personal:

   • Categorii: se enumeră din Registrul Activităților de Prelucrare și din lista de verificare a straturilor de stocare din evaluarea impactului de mai sus, iar nu dintr-o listă fixă a prezentului plan. În funcție de amploare, acestea pot cuprinde datele de înregistrare și de contact (adresa de e-mail, numele, numărul de telefon), evidențele de consimțământ, conținutul sesiunilor live (mesaje din chat, inclusiv mesajele eliminate prin moderare, voturi la sondaje, reacții, feedback, nume afișate, prezență și participare), evenimentele comportamentale, atribuirea în funnel, împreună cu datele privind dispozitivul și localizarea aproximativă, un identificator pseudonim persistent de vizitator pentru vizitatorii paginilor de destinație, datele privind achizițiile primite din magazinul de comerț electronic al unui client, evidențele de livrare a SMS-urilor, evidențele destinatarilor difuzărilor către segmente, evidențele de execuție a pașilor de automatizare care conțin adrese de e-mail și numere de telefon în clar, prompturile și rezultatele generărilor cu AI care conțin testimoniale aprobate ale participanților, precum și intrările din jurnalul de audit care consemnează adrese IP și user agent-uri.
   • Înregistrări: [de exemplu, 15.000 de evidențe de contact, 50.000 de evidențe de evenimente comportamentale]

4. Numele și datele de contact ale DPO (dacă este cazul):

   • [DPO Name, [email protected], Phone]

5. Consecințele probabile:

   • Risc de atacuri de phishing (adrese de e-mail expuse)
   • Risc de prejudiciu reputațional (mesaje din chat expuse)
   • Risc de furt de identitate (în combinație cu alte seturi de date)

6. Măsurile luate sau propuse:

   • Imediate: Revocarea acreditărilor, corectarea vulnerabilității, resetarea forțată a parolei
   • Pe termen scurt: Audit de securitate, teste de penetrare
   • Pe termen lung: Monitorizare îmbunătățită, nivel suplimentar de criptare, formarea personalului

7. Dacă notificarea depășește 72h, se explică întârzierea:

   • [Motiv: Investigație în curs pentru determinarea amplorii, consultarea consilierului juridic etc.]

Urmărire: Dacă notificarea inițială este incompletă (de exemplu, dacă evaluarea amplorii este în curs), se transmit notificări etapizate:

• Etapa 1 (în 72h): Notificare preliminară, cu faptele cunoscute
• Etapa 2 (în 7 zile): Notificare actualizată, cu evaluarea completă a impactului

3.5 Notificarea Persoanelor Vizate (Dacă Este Necesar)

Rolul [PLATFORM PROVIDER]: Punerea la dispoziția clientului a instrumentelor necesare notificării Persoanelor Vizate (clientul ia decizia finală)

Modul în care se întocmește lista Persoanelor Vizate afectate: manual, potrivit descrierii de la Notificarea Clientului, de mai sus. Nu există niciun ecran de raportare a breșelor în tabloul de bord și niciun export în regim de autoservire: un membru al personalului selectează evidențele afectate în PostgreSQL, obține din Firestore adresa de e-mail și numele în clar și transmite fișierul clientului, împreună cu notificarea.

Șablonul de notificare al Clientului (pus la dispoziție de [PLATFORM PROVIDER]):

Subiect: Notificare importantă de securitate — Datele înregistrării dumneavoastră la eveniment

Stimate/Stimată [First Name],

Vă scriem pentru a vă informa cu privire la un incident de securitate care ar fi putut afecta datele dumneavoastră cu caracter personal.

CE S-A ÎNTÂMPLAT:
La data de [data], furnizorul platformei noastre de eveniment ([PLATFORM PROVIDER]) a suferit o breșă de date. Persoane neautorizate ar fi putut accesa informațiile dumneavoastră de înregistrare.

CE DATE AU FOST AFECTATE:
- Adresa dumneavoastră de e-mail: [email]
- Numele dumneavoastră: [name]
- [Dacă este cazul: Mesajele din chat trimise în cursul evenimentelor, voturile la sondaje etc.]

CE FACEM:
- Breșa a fost limitată, iar vulnerabilitatea a fost corectată.
- Efectuăm o analiză completă de securitate.
- Am raportat acest incident autorității de supraveghere competente.

CE PUTEȚI FACE:
- Fiți vigilent față de e-mailurile de phishing (nu vă vom solicita niciodată parola sau informații de plată prin e-mail)
- Monitorizați-vă conturile pentru a identifica orice activitate suspectă
- Dacă ați utilizat numele sau adresa de e-mail de la eveniment și în altă parte, luați în considerare schimbarea parolelor pentru acele conturi

ÎNTREBĂRI:
Contactați-ne la [[email protected]] pentru orice nelămurire.

Ne cerem sincer scuze pentru acest incident și ne angajăm să vă protejăm datele.

Cu stimă,
[Your Organization Name]

---

Faza 4: Remediere și Recuperare (24 de ore - 2 săptămâni)

Obiectiv: Remedierea cauzei principale, restabilirea operațiunilor normale, împiedicarea repetării.

4.1 Analiza Cauzei Principale (RCA)

Cadru: 5 De Ce-uri Exemplu:

1. De ce a obținut atacatorul accesul? → Parolă slabă pe baza de date Railway
2. De ce era parola slabă? → A fost generată manual de inginer (nu automat, ca parolă puternică)
3. De ce a fost generată manual? → Nicio politică de parole nu era impusă în Railway
4. De ce lipsea politica? → Lista de verificare a onboarding-ului nu includea „impunerea MFA + parole puternice"
5. De ce lipsea lista de verificare? → Proces informal de onboarding, fără standarde de securitate scrise

Cauza principală: Lipsa unei liste de verificare formale de securitate pentru onboarding

Acțiune corectivă: Crearea unei liste de verificare obligatorii de securitate (MFA, manager de parole, privilegiu minim), impusă înainte de acordarea accesului la producție

4.2 Acțiuni de Remediere

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. Prin urmare, orice etapă de remediere de mai jos care depinde de detectarea unei vulnerabilități se planifică drept analiză manuală, iar nu drept rezultat al unei linii automate.

Imediate (în 48 de ore):

• [ ] Corectarea vulnerabilității (implementarea remedierii de cod în producție)
• [ ] Rotirea tuturor acreditărilor din inventarul nominal de la Faza 2 (șirurile de conexiune la baza de date, secretul partajat pentru comunicarea dintre servicii, acreditarea contului de serviciu, cheile API, acreditările demonstrative pentru analiza din magazinele de aplicații, secretele de integrare per organizație)
• [ ] Resetarea forțată a parolei pentru toți utilizatorii din personal (dacă sistemul de autentificare a fost compromis)
• [ ] Adăugarea de jurnalizare pe calea afectată și stabilirea în scris a ceea ce trebuie urmărit de o persoană și cu ce frecvență; nu există nicio alertare automată (Secțiunea 3.1), astfel încât jurnalizarea suplimentară schimbă ceea ce poate fi aflat ulterior, iar nu ceea ce este detectat pe loc

Pe termen scurt (în 2 săptămâni):

• [ ] Realizarea unui audit de securitate (intern sau prin consultant extern)
• [ ] Teste de penetrare (retestarea vulnerabilității corectate + scanare mai amplă)
• [ ] Analiza și actualizarea politicilor de securitate (politica de parole, controlul accesului, impunerea MFA)
• [ ] Reinstruirea personalului (conștientizarea riscurilor de securitate, raportarea incidentelor)

Pe termen lung (în 3 luni):

• [ ] Implementarea unor măsuri de securitate îmbunătățite (de exemplu, criptarea bazei de date cu chei gestionate de client, analiză centralizată a jurnalelor, detecție a intruziunilor)
• [ ] Obținerea unei certificări de securitate (ISO 27001, SOC 2 Type II)
• [ ] Program bug bounty (stimularea divulgării responsabile)

Cele trei elemente pe termen lung de mai sus sunt obiective, iar nu controale existente. Nu a fost obținută nicio certificare de securitate, nu se operează niciun program bug bounty și nu există nicio capacitate centralizată de analiză a jurnalelor sau de detecție a intruziunilor. Niciunul dintre ele nu poate fi prezentat unui client, unei persoane vizate sau autorității de supraveghere drept măsură existentă.

4.3 Recuperarea Sistemului

Restaurarea datelor (dacă este necesar):

• Restaurarea din ultima copie de rezervă curată, realizată înainte de incident, cu ajutorul funcțiilor de copiere de rezervă ale furnizorului de găzduire și ale Firebase
• Verificarea integrității copiei de rezervă (scanare antimalware, verificarea completitudinii datelor)
• Recuperare incrementală (restaurarea bazei de date de producție din copia de rezervă, reluarea jurnalelor de tranzacții)

Termen: RTO (Obiectiv de Timp de Recuperare) = 4 ore, RPO (Obiectiv de Punct de Recuperare) = 24 de ore (pierdere maximă de date). Acestea sunt obiective, iar nu valori validate. Nu se ține niciun runbook de restaurare, nicio restaurare nu a fost efectuată și cronometrată pe datele de producție și niciun job programat nu exersează o astfel de operațiune, astfel încât recuperarea se tratează drept obligație de mijloace, până la efectuarea unei restaurări cronometrate și la consemnarea rezultatului acesteia.

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

Prezentul document arăta anterior că obiectivul de timp de recuperare de patru ore și obiectivul de punct de recuperare de douăzeci și patru de ore reprezintă angajamente, iar criteriile de evaluare din Secțiunea 5.2 porneau de la premisa că o restaurare poate fi exersată în raport cu acestea. Nu există nicio procedură de restaurare documentată, nicio restaurare nu a fost efectuată și cronometrată pe datele de producție și niciun job programat nu exersează o astfel de operațiune, așa încât niciunul dintre cele două obiective nu este probat. Ransomware-ul este primul scenariu avut în vedere de prezentul plan, ceea ce face din calea de restaurare nevalidată cea mai mare distanță dintre prezentul document și un incident real. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

Reluarea serviciului:

• Implementare etapizată (restaurare în staging → testare → producție)
• Comunicare către client: „Servicii restaurate, breșă limitată, securitate îmbunătățită"

---

Faza 5: Revizuire Post-Incident (raportul către client în 14 zile; revizuirea internă în 2-4 săptămâni)

Obiectiv: Învățarea din incident, îmbunătățirea apărării, demonstrarea responsabilității.

5.1 Raportul Post-Incident

Termen: raportul de incident destinat clienților se transmite în termen de 14 zile de la luarea la cunoștință, potrivit angajamentului asumat în Secțiunea 9.1 a Acordului de Prelucrare a Datelor. Procesul intern de analiză a lecțiilor învățate poate continua și după această dată, dar nu poate întârzia raportul către clienți.

Secțiuni:

1. Rezumat Executiv (1 pagină)
   • Ce s-a întâmplat, impactul, rezolvarea, lecțiile învățate
2. Cronologie (detaliată)
   • [YYYY-MM-DD HH:MM] - Breșă produsă (estimat)
   • [YYYY-MM-DD HH:MM] - Breșă detectată
   • [YYYY-MM-DD HH:MM] - IRT convocată
   • [YYYY-MM-DD HH:MM] - Limitare finalizată
   • [YYYY-MM-DD HH:MM] - Clienți notificați
   • [YYYY-MM-DD HH:MM] - Autoritate de supraveghere notificată
   • [YYYY-MM-DD HH:MM] - Remediere finalizată
3. Analiza Cauzei Principale (5 De Ce-uri)
4. Evaluarea Impactului (Persoane Vizate afectate, categorii de date, exfiltrare confirmată)
5. Eficacitatea Răspunsului (ce a funcționat, ce nu)
6. Acțiuni Corective (finalizate + planificate)
7. Recomandări (îmbunătățiri de proces, îmbunătățiri de securitate)

Distribuție:

• Internă: Tot personalul (anonimizat, dacă este sensibil)
• Clienți: Transmis fiecărui client afectat în termen de 14 zile de la luarea la cunoștință, în conformitate cu Secțiunea 9.1 a Acordului de Prelucrare a Datelor, cu redactări limitate strict la ceea ce impune confidențialitatea celorlalți clienți; transmis celorlalți clienți la cerere
• Autoritatea de Supraveghere: Dacă este solicitat în cursul investigației

5.2 Sesiunea de Lecții Învățate

Participanți: IRT + întreaga echipă de inginerie Format: Post-mortem fără reproșuri (fără învinovățiri, cu accent pe sisteme și procese)

Discuție:

• Ce a mers bine? (de exemplu, detectare rapidă, roluri clare, limitare eficace)
• Ce a mers prost? (de exemplu, notificare întârziată, jurnale lipsă, escaladare neclară)
• Ce a fost surprinzător? (de exemplu, o vulnerabilitate neanticipată, tehnica atacatorului)
• Ce se poate îmbunătăți? (de exemplu, monitorizare mai bună, corectare mai rapidă, runbook-uri mai clare)

Rezultat: Acțiuni, fiecare cu un responsabil nominalizat și cu un termen, consemnate în evidența incidentului și urmărite până la finalizare

5.3 Actualizarea Prezentului Plan

Revizuiri pe baza incidentului:

• Adăugarea de noi mecanisme de detectare (dacă incidentul a scos la iveală un unghi mort)
• Actualizarea șabloanelor de notificare (dacă din șablonul inițial lipseau informații esențiale)
• Clarificarea rolurilor (dacă au existat confuzii în timpul incidentului)
• Adăugarea de întrebări frecvente (întrebări curente din partea clienților)

Controlul versiunilor: Incrementarea numărului de versiune, documentarea modificărilor în jurnalul de modificări

---

5. Formare și Testare

5.1 Formarea Personalului

Frecvență: Anual (obligatoriu pentru tot personalul cu acces la date cu caracter personal) Subiecte:

• Ce este o breșă de date cu caracter personal (exemple și contraexemple)
• Cum se raportează ([email protected], fără întârziere, fără investigare pe cont propriu)
• Conștientizarea riscului de phishing (fără accesarea link-urilor suspecte, cu verificarea expeditorului)
• Igiena parolelor (manager de parole, MFA, fără reutilizare)
• Inginerie socială (verificarea identității înainte de acordarea accesului la date)

Test: Promovare cu 80% pentru finalizarea formării. ⚠️ Nu a fost identificat niciun sistem de evidență a finalizării formării, astfel încât finalizarea acesteia nu poate fi probată în prezent.

5.2 Exerciții de Tip Tabletop

Frecvență: Trimestrial (de 4 ori pe an). ⚠️ De la adoptarea prezentului plan nu a fost consemnat niciun exercițiu de tip tabletop, astfel încât ritmicitatea indicată aici reprezintă un angajament, iar nu o practică stabilită. Format: Scenariu simulat de breșă, cu durata de 1 oră (niciun sistem real afectat)

Scenarii exemplificative:

• Scenariul 1: Ransomware criptează baza de date PostgreSQL (testarea procesului de restaurare din copia de rezervă)
• Scenariul 2: Reguli de securitate configurate greșit, astfel încât datele unor organizații diferite de cea a apelantului pot fi citite timp de 2 ore (testarea notificării a peste 100 de clienți). Acest scenariu se rulează în raport cu situațiile de fapt permanente prezentate mai jos, iar nu în raport cu o ipoteză
• Scenariul 3: Amenințare internă — un inginer exfiltrează datele clientului (testarea procedurilor de offboarding, analiza jurnalelor de audit)
• Scenariul 4: Un subîmputernicit transmite o înștiințare privind o breșă (testarea escaladării către subîmputernicit, a notificării clientului)
• Scenariul 5: O modificare de configurare dezactivează autentificarea — API-ul pornește fără identificatorul de proiect al platformei de identitate, fără secretul partajat pentru comunicarea dintre servicii ori în raport cu un emulator de autentificare —, astfel încât cererile sunt considerate de încredere pe baza antetelor furnizate de apelant ori a unor token-uri cărora nu li se verifică semnătura, expirarea și emitentul. Limitarea constă într-o modificare de configurare și o reimplementare; amploarea cuprinde toate cererile servite în intervalul respectiv, pe care jurnalul de acces nu le poate enumera, întrucât nu consemnează nici organizația, nici utilizatorul care acționează

Evaluare:

• Pot fi notificați toți clienții în 24 de ore? (testarea trimiterii e-mailurilor, acuratețea listei de contacte)
• Poate fi elaborată notificarea către autoritatea de supraveghere în <2 ore? (testarea șablonului, colectarea informațiilor)
• Poate fi realizată restaurarea din copia de rezervă în 4 ore? (testarea RTO — nicio restaurare nu a fost încă efectuată și cronometrată; a se vedea Faza 4, Secțiunea 4.3)

Rezultat: Lecții învățate → actualizarea planului, remedierea deficiențelor (de exemplu, listă de contacte depășită, acreditări lipsă)

Situațiile de fapt permanente în raport cu care se rulează aceste scenarii. Cele de mai jos descriu configurația actuală, iar nu una simulată.

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.

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

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.

Alte trei situații, dependente de configurare, privesc Scenariul 5. Atunci când identificatorul de proiect al platformei de identitate nu este configurat, API-ul revine la autentificarea pe bază de antete și acceptă organizația, utilizatorul și rolul afirmate de apelant. Atunci când secretul partajat pentru comunicarea dintre servicii nu este configurat, middleware-ul de autentificare a serviciilor acceptă orice token de tip bearer, acordă privilegii de administrator și preia identificatorul organizației dintr-un antet furnizat de apelant. Atunci când este configurată o gazdă de emulator de autentificare, atât calea de autentificare a personalului, cât și cea a participanților analizează token-urile fără a verifica semnătura, expirarea sau emitentul. Niciuna dintre cele trei nu este verificată la pornire, așa cum este verificată conexiunea restricționată la baza de date, și niciuna nu ar fi detectată, întrucât nu există nicio alertare.

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

Această secțiune afirma anterior că expunerea datelor între organizații, ca urmare a unor reguli de securitate configurate greșit, reprezintă exclusiv un scenariu de instruire. Situațiile prezentate imediat mai sus constituie configurația actuală a platformei, iar nu o simulare: documentele cu datele cu caracter personal ale contactelor pot fi citite de orice apelant autentificat, documentele de înregistrare pot fi citite chiar și fără autentificare, regulile Realtime Database nu conțin nicio verificare a organizației, iar regulile Cloud Storage acordă acces public necondiționat de citire asupra căilor delimitate pe organizație și se încheie cu o regulă finală, cu caracter general, aplicabilă oricărui utilizator autentificat. Cu privire la aceste situații nu a fost efectuată și nici consemnată vreo evaluare în temeiul art. 33 alin. (1) GDPR. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

6. Instrumente și Resurse

6.1 Instrumente de Comunicare

Instrument	Scop	Acces
E-mail ([email protected])	Sesizări primite, coordonarea IRT, notificarea clienților	IRT + echipa de suport
Telefon (lista din Secțiunea 7)	Convocarea IRT și escaladarea în afara programului; singurul canal care ajunge la o persoană atât timp cât căsuța poștală nu este citită	Membrii IRT
Consolele furnizorului de găzduire și Firebase	Starea sistemelor și înștiințările de incident din partea furnizorilor	Utilizatori admin

Nu este pus la dispoziție niciun canal de chat pentru incidente, nicio platformă de apelare a echipei de gardă, nicio sală video dedicată și niciun banner de incident destinat clienților. Versiunile anterioare ale prezentului plan le enumerau pe toate patru; a se vedea caseta de la Secțiunea 3.1.

6.2 Instrumente Tehnice

Instrument	Scop	Acces
CLI-ul și consola furnizorului de găzduire	Acces la baza de date, restaurarea copiilor de rezervă, exportul jurnalelor de aplicație	Lider Tehnic, Comandant Incident
Firebase Console	Reguli de securitate, indicatori de utilizare, profilerul Realtime Database. Nici Firestore, nici Realtime Database nu oferă un jurnal de audit al citirilor	Utilizatori admin
Google Cloud Console	Jurnale Cloud Functions, Secret Manager	Utilizatori admin
Wireshark / tcpdump	Analiza traficului de rețea, exclusiv pe mașini controlate local; platforma rulează pe găzduire administrată, unde captura de pachete nu este disponibilă	Lider Tehnic
PostgreSQL CLI (psql)	Interogări criminalistice asupra jurnalului de audit și a tabelelor afectate	Lider Tehnic

6.3 Șabloane de Documentație

Document	Locație	Scop
E-mail de Notificare a Clientului	Secțiunea 4, Faza 3, §3.3 din prezentul plan	Șablon de copiere-lipire, se completează parantezele
Notificarea Autorității de Supraveghere	Site-ul web ANSPDCP (https://www.dataprotection.ro)	Formular online, generare automată
Notificarea Persoanei Vizate	Secțiunea 4, Faza 3, §3.5 din prezentul plan	Șablon pus la dispoziția clienților
Raport Post-Incident	Secțiunea 4, Faza 5, §5.1 din prezentul plan	Structura pe secțiuni este redată integral în acel loc; ⚠️ nu se ține niciun fișier-șablon separat

---

7. Informații de Contact

Contacte Interne

Rol	Nume	Email	Telefon	Disponibilitate
Comandant Incident	[CTO Name]	[[email protected]]	[+40 XXX XXX XXX]	24/7
Lider Tehnic	[Engineer Name]	[[email protected]]	[+40 XXX XXX XXX]	24/7, prin contact telefonic direct; fără rotație de gardă (Secțiunea 2)
Consilier Juridic	[Lawyer Name]	[[email protected]]	[+40 XXX XXX XXX]	Program de lucru + linie de urgență
DPO (dacă este desemnat)	[DPO Name]	[email protected]	[+40 XXX XXX XXX]	Program de lucru

Contacte Externe

[PLATFORM PROVIDER] angajează unsprezece subîmputerniciți, enumerați în Anexa III. Fiecare subîmputernicit care prelucrează efectiv date cu caracter personal trebuie să figureze în tabelul de mai jos, întrucât o breșă survenită la oricare dintre ei poate constitui o breșă a datelor cu caracter personal prelucrate în numele unui client. Google LLC apare o singură dată aici, deși ocupă două rânduri în Anexa III (Firebase și Google Cloud; Google Analytics și Google Ads), iar LinkedIn Corporation este omisă, întrucât acea integrare nu este implementată.

Entitate	Contact	Scop
ANSPDCP (autoritatea română de supraveghere)	[email protected] https://www.dataprotection.ro	Notificarea autorității de supraveghere (art. 33 GDPR)
Autoritatea Română de Securitate Cibernetică (CERT-RO)	[email protected] https://cert.ro	Incidente de infrastructură critică (dacă este cazul)
Railway Corp.	https://railway.app/support	Găzduirea PostgreSQL, a Go API și a aplicațiilor Next.js; retenția jurnalelor de aplicație
Google LLC	https://cloud.google.com/support	Firebase (Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Functions) și Secret Manager; de asemenea, materialele YouTube încorporate, încărcate direct de browserele vizitatorilor, Google Fonts (preluate pe partea de server de aplicația publică și, în previzualizarea din editorul de pagini, de browserele personalului), precum și entitatea Google Ads și Analytics, enumerată separat în Anexa III
NewsmanApp SRL	[[email protected]]	Livrarea e-mailurilor tranzacționale și de marketing; deține adrese de e-mail în clar, nume, apartenența la segmente și datele comportamentale privind deschiderile și click-urile
Cloudflare, Inc.	⚠️ Nu a fost stabilit.	Proxy invers, CDN și Turnstile. Termină conexiunea TLS pentru traficul participanților în producție, astfel încât fiecare formular de înregistrare transmis de un participant trece prin el în clar, iar fiecare adresă IP de client pe care platforma o consemnează sau o transmite mai departe este preluată dintr-un antet furnizat de Cloudflare
Meta Platforms, Inc.	⚠️ Nu a fost stabilit.	Meta Pixel și Meta Conversions API; primește identificatori de contact sub formă de hash, împreună cu adresa IP brută și user agent-ul brut
TikTok Pte. Ltd.	Politica de confidențialitate TikTok	TikTok Pixel și TikTok Events API; primește identificatori de contact sub formă de hash, împreună cu adresa IP brută și user agent-ul brut
Microsoft Corporation, contractată pentru clienții din UE prin Microsoft Ireland Operations Limited (MIOL)	⚠️ Nu a fost stabilit.	Analiza sesiunilor prin Microsoft Clarity
Anthropic PBC	https://privacy.anthropic.com	Generarea cu AI a conținutului paginilor de destinație și de marketing, precum și a întrebărilor de sondaj; prompturile pot conține testimoniale aprobate ale participanților
SendSMS.ro	https://www.sendsms.ro	Livrarea SMS-urilor tranzacționale; primește numărul de telefon al destinatarului în clar și corpul integral al mesajului

⚠️ Pentru niciunul dintre furnizorii de mai sus nu este stabilit un contact de securitate dedicat și niciun nivel de serviciu privind notificarea breșelor; datele indicate sunt rute generale de suport. Confirmarea unui contact de securitate și a termenului contractual de notificare pentru fiecare furnizor constituie o acțiune restantă și trebuie realizată în cadrul încheierii acordurilor de prelucrare a datelor identificate ca restante în Anexa III.

---

8. Registrul Breșelor (art. 33 alin. (5) GDPR)

Locație: ⚠️ În prezent nu se ține niciun registru al breșelor. Versiunile anterioare ale prezentului plan indicau o cale de fișier internă și un proiect de ticketing; niciunul nu există și nicio intrare nu a fost vreodată consemnată în vreunul dintre ele. Registrul trebuie constituit ca evidență internă ținută la zi, pusă la dispoziția autorității de supraveghere la cerere, înainte ca prezentul plan să poată fi invocat drept dovadă a conformității cu art. 33 alin. (5) GDPR. Structura pe coloane de mai jos este structura pe care acesta trebuie să o aibă.

Retenție: Trei ani, în acord cu angajamentul asumat în Secțiunea 9.4 a Acordului de Prelucrare a Datelor. Intrările din registru pot conține hash-ul adresei de e-mail a unei persoane vizate care și-a exercitat între timp dreptul la ștergere; aceasta este o consecință asumată a obligației de documentare prevăzute la art. 33 alin. (5) GDPR și a principiului responsabilității consacrat la art. 5 alin. (2) GDPR, iar nu o deficiență a fluxului de ștergere.

Coloane:

ID Breșă	Data detectării	Data producerii (est.)	Natura	Persoane Vizate afectate	Categorii de date	Exfiltrare?	Autoritate notificată?	Persoane Vizate notificate?	Data rezolvării	Cauza principală
BR-2026-001	[YYYY-MM-DD]	[YYYY-MM-DD]	[Acces neautorizat]	[15.000]	[E-mail, nume, chat]	[Da/Nu]	[Da/Nu]	[Da/Nu]	[YYYY-MM-DD]	[Parolă slabă]

Chiar dacă NU este notificabil (risc scăzut), fiecare incident se consemnează pentru urmărirea internă și pentru analiza tendințelor.

Completarea retroactivă. La constituirea registrului, acesta se completează retroactiv, iar nu de la data creării sale. Analiza internă a identificat situații istorice de configurare și o deficiență de suprimare a e-mailurilor, care impun o evaluare retrospectivă în temeiul art. 33 alin. (1) GDPR și o decizie consemnată — inclusiv, acolo unde aceasta este concluzia, o decizie motivată de a nu notifica. Acestea sunt: perioada în care nodurile de prezență și de statistici ale sesiunilor live din Realtime Database puteau fi citite fără autentificare, în timp ce nodul de statistici conținea și registre per actor care puteau fi asociate numelor afișate ale participanților; situațiile de fapt permanente privind regulile de securitate, descrise în Secțiunea 5.2; precum și perioada cuprinsă între 16 mai 2026 și 3 iulie 2026, în care sincronizarea cu furnizorul de e-mail a reabonat contacte care se dezabonaseră anterior.

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

Prezentul document arăta anterior că registrul breșelor se ține la o locație internă anume și că fiecare incident se consemnează în el, indiferent dacă este sau nu notificabil. Un astfel de registru nu există în nicio locație și niciun incident nu a fost evaluat sau consemnat într-unul, astfel încât [PLATFORM PROVIDER] nu poate proba în prezent conformitatea cu art. 33 alin. (5) GDPR; situațiile istorice enumerate imediat mai sus nu au fost evaluate. Această neconcordanță este consemnată în registrul de remediere a conformității și face obiectul unei analize.

---

9. Actualizări și Întreținere

Ciclul de Revizuire: Anual (sau după fiecare breșă) Responsabil: Comandantul Incidentului (CTO) + DPO (dacă este desemnat) Aprobare: CEO, Consilier Juridic

Declanșatori pentru Actualizare:

• Modificări ale orientărilor GDPR (avize EDPB, hotărâri judecătorești)
• O modificare a Anexei III (Subîmputerniciți). Adăugarea, eliminarea sau redefinirea perimetrului unui subîmputernicit în cuprinsul acesteia impune, prin aceeași modificare, actualizarea tabelului Contactelor Externe din Secțiunea 7 a prezentului plan. Cele două liste se reconciliază ori de câte ori una dintre ele este modificată
• O modificare semnificativă a regulilor de securitate ale platformei, a configurării autentificării, a jurnalizării ori a straturilor de stocare; fiecare dintre acestea schimbă ceea ce prezentul plan poate stabili în cursul unui incident
• Schimbări organizaționale (noi membri ai IRT, instrumente noi)
• Lecții învățate dintr-un exercițiu de tip tabletop sau dintr-un incident real

⚠️ Între adoptarea sa și prezenta revizuire, prezentul plan nu a fost revizuit, deși declanșatorul privind subîmputerniciții, prevăzut mai sus, s-a activat în mai multe rânduri — între altele, prin activarea TikTok Events API, prin adăugarea unei vizualizări de pagină transmise pe server prin Meta Conversions API, prin introducerea Cloudflare drept proxy invers obligatoriu, aflat pe traseul traficului participanților, precum și prin angajarea Anthropic PBC și a SendSMS.ro. Secțiunea 7 a rămas, în mod corespunzător, neactualizată și a fost reconciliată cu Anexa III prin prezenta revizuire.

Controlul Versiunilor:

Versiune	Dată	Modificări	Aprobat de
1.0	[DATE]	Proiect inițial	[Legal Team]

---

10. Anexe

Anexa A: Matricea de Severitate a Breșelor

Severitate	Persoane Vizate	Categorii de date	Exfiltrare	Timp de răspuns (limitare)	Exemplu
Critică	>10.000	Date cu caracter personal în clar + conținut sensibil (chat, sănătate)	Exfiltrare confirmată, cu datele făcute publice	2 ore	Copie de rezervă a bazei de date scursă într-un depozit public de cod; ori o modificare de configurare care dezactivează autentificarea, astfel încât granița dintre organizații se pierde, pentru toate acestea, pe durata intervalului
Ridicată	1.000 - 10.000	Adresa de e-mail, numele, telefonul, mesajele din chat	Exfiltrare probabilă (atacatorul a avut acces >24h)	6 ore	Ransomware criptează baza de date de producție, atacatorul a copiat datele în prealabil
Medie	100 - 1.000	Adresa de e-mail, numele	Acces potențial (reguli configurate greșit; nu există niciun jurnal al citirilor care să poată confirma sau exclude accesul)	12 ore	Reguli de securitate Firebase configurate greșit timp de 4 ore, acces nici confirmat, nici exclus
Scăzută	<100	Numai hash-ul adresei de e-mail și numai atunci când s-a demonstrat că orice depozit cu date în clar se află în afara perimetrului incidentului (a se vedea Faza 3, punctul 4)	Fără exfiltrare (tentativă de breșă, blocată)	24 de ore	Atac de forță brută eșuat asupra API-ului, fără autentificare reușită

O severitate stabilită la nivelul Scăzut sau Mediu pe considerentul că au fost expuși exclusiv identificatori sub formă de hash impune consemnarea depozitelor verificate și constatate în afara perimetrului incidentului. Atunci când amploarea unui incident nu poate fi determinată — situație valabilă pentru orice cale de acces, cu excepția acțiunilor auditate ale personalului —, severitatea se stabilește potrivit ipotezei celei mai defavorabile compatibile cu probele, iar nu pe baza lipsei probelor privind accesul.

Anexa B: Lista de Verificare pentru Notificarea Clientului

• [ ] Identificarea clienților afectați (din acțiunile auditate ale personalului, consemnate în jurnalul de audit; în rest, din întinderea acreditării compromise sau a regulii configurate greșit)
• [ ] Obținerea adreselor de e-mail ale utilizatorilor cu rol de administrator ai fiecărei organizații afectate; nu există niciun câmp de contact de securitate înregistrat
• [ ] Elaborarea e-mailului de notificare (se folosește șablonul din Secțiunea 4, Faza 3, §3.3)
• [ ] Generarea raportului criminalistic (anexă PDF)
• [ ] Întocmirea manuală a listei Persoanelor Vizate afectate pentru fiecare client (selecție în PostgreSQL, urmată de obținerea datelor în clar din Firestore); nu există niciun export în regim de autoservire
• [ ] Trimiterea e-mailurilor în 24 de ore de la detectare
• [ ] Urmărirea prin apeluri telefonice (incidente critice, cei mai mari clienți afectați)
• [ ] Urmărirea răspunsurilor clienților în evidența incidentului, cu închiderea fiecăruia la confirmarea primirii de către client

Anexa C: Lista de Verificare Juridică (Cronologia de 72 de Ore)

Ora 0-24 (de la detectare la limitare):

• [ ] Detectarea breșei
• [ ] Convocarea IRT
• [ ] Limitarea breșei
• [ ] Evaluarea impactului (Persoane Vizate, categorii de date)
• [ ] Notificarea clienților (Operatori de date)

Ora 24-48 (de la evaluare la decizia de notificare):

• [ ] Finalizarea investigației criminalistice
• [ ] Stabilirea necesității de a notifica autoritatea de supraveghere (pragul de risc de la art. 33 GDPR)
• [ ] Elaborarea notificării către autoritatea de supraveghere (dacă este necesar)
• [ ] Consultarea consilierului juridic (evaluarea riscurilor, formularea notificării)

Ora 48-72 (termenul final de notificare):

• [ ] Transmiterea notificării către ANSPDCP (dacă este necesar)
• [ ] Punerea la dispoziția clienților a șablonului de notificare a Persoanelor Vizate (dacă art. 34 GDPR este aplicabil)
• [ ] Documentarea notificării în registrul breșelor

După 72h:

• [ ] Monitorizarea răspunsului autorității de supraveghere (aceasta poate solicita informații suplimentare)
• [ ] Cooperarea în cadrul oricărei investigații
• [ ] Implementarea măsurilor corective
• [ ] Informarea clienților cu privire la progresul remedierii la fiecare 48 de ore, până la rezolvare, în conformitate cu Secțiunea 9.1 a Acordului de Prelucrare a Datelor
• [ ] Transmiterea raportului final de incident clienților afectați în termen de 14 zile de la luarea la cunoștință, în conformitate cu Secțiunea 9.1 a Acordului de Prelucrare a Datelor
• [ ] Consemnarea incidentului, a evaluării și a deciziei de notificare în registrul breșelor (Secțiunea 8)

---

Versiunea Documentului: 1.0 (DRAFT) Întocmit de: [Security Team] Stadiul Revizuirii: ⚠️ NECESITĂ REVIZUIRE JURIDICĂ — Prezentul document este un proiect destinat consultării cu avocatul

CRITIC: Testați prezentul plan printr-un exercițiu de tip tabletop ÎNAINTE de producerea unei breșe reale.

---

Sfârșitul Planului de Răspuns la Breșe de Date