Atac cibernetic la furnizorul tău SaaS: cine răspunde între operator și împuternicit după o breșă GDPR

aprilie 5, 2026

Comunicatul ANSPDCP din 25.03.2026 privind Renault Commercial Roumanie este important tocmai fiindcă nu se limitează la ideea simplă că „a existat un atac cibernetic”. Autoritatea a reținut încălcarea art. 32 alin. (1) lit. b) și d), alin. (2), coroborat cu art. 28 alin. (1) din GDPR, după un atac asupra unei aplicații administrate prin împuternicit, și a aplicat o amendă de 637.262,50 lei, echivalentul a 125.000 euro, pornind de la o notificare de breșă transmisă chiar de operator în temeiul art. 33 GDPR Comunicat ANSPDCP 25.03.2026, art. 28 GDPR, art. 32 GDPR, art. 33 GDPR.

Mai concret, ANSPDCP a arătat că, în urma atacului, au fost accesate și divulgate neautorizat, prin publicare pe o platformă, date aparținând unui număr foarte mare de persoane vizate, inclusiv nume, prenume, numere de telefon personale și profesionale, adrese de domiciliu și poștale, adrese de e-mail, număr permis de conducere, CNP, seria de șasiu, data nașterii, seria și numărul cărții de identitate, funcția, angajatorul și numărul personal de identificare pentru angajați Comunicat ANSPDCP 25.03.2026.

Pentru orice companie care folosește CRM în cloud, aplicații HR, e-commerce, ticketing, marketing automation, software medical sau alt SaaS extern, mesajul juridic este direct: faptul că infrastructura compromisă este „la vendor” nu mută automat răspunderea în afara operatorului. Dacă tu stabilești scopurile și cadrul prelucrării, autoritatea va analiza nu doar incidentul tehnic, ci și ce ai verificat înainte, ce ai cerut contractual, cum ai supravegheat vendorul și cât de repede ai reacționat după incident Comunicat ANSPDCP 25.03.2026, art. 28 GDPR, Avizul EDPB 22/2024.

Ce s-a întâmplat în comunicatul ANSPDCP și ce învățăm din el

Din comunicatul oficial rezultă două constatări-cheie. Prima este una de securitate: operatorul nu a implementat măsuri tehnice și organizatorice adecvate pentru un nivel de securitate corespunzător riscului, inclusiv capacitatea de a asigura confidențialitatea sistemelor și serviciilor și existența unui proces de testare, evaluare și apreciere periodică a eficacității măsurilor. A doua este una de guvernanță a lanțului de furnizori: operatorul nu s-a asigurat că recurge doar la persoane împuternicite care oferă garanții suficiente pentru punerea în aplicare a unor măsuri adecvate Comunicat ANSPDCP 25.03.2026, art. 32 GDPR, art. 28 alin. (1) GDPR.

Tocmai această dublă abordare face speța utilă pentru mediul de business. ANSPDCP nu spune doar „serverul a fost spart”, ci transmite că într-un ecosistem SaaS răspunderea se citește pe două niveluri: securitatea efectivă a prelucrării și modul în care ai selectat, autorizat și urmărit împuternicitul. Cu alte cuvinte, dacă buba vine din vendor stack, întrebarea autorității va fi și „ce controale avea furnizorul?”, dar și „ce controale ai avut tu asupra furnizorului?” Comunicat ANSPDCP 25.03.2026, Avizul EDPB 22/2024.

În practică, acesta este motivul pentru care un simplu DPA semnat la onboarding nu te „salvează” automat. Art. 28 GDPR cere să folosești numai împuterniciți care oferă garanții suficiente, iar art. 32 cere măsuri adecvate raportate la risc. Dacă ai un contract impecabil pe hârtie, dar accesul vendorului este slab controlat, backup-ul nu este testat, nu există o separare adecvată a mediilor sau nu poți demonstra ce ai verificat înainte de semnare și după go-live, contractul nu acoperă golurile de arhitectură și de guvernanță art. 28 GDPR, art. 32 GDPR, Orientările EDPB 07/2020, Avizul EDPB 22/2024.

Cine răspunde juridic între operator și împuternicit

GDPR definește operatorul ca entitatea care stabilește scopurile și mijloacele prelucrării și împuternicitul ca entitatea care prelucrează date în numele operatorului. EDPB insistă că aceste concepte sunt funcționale: rolurile se stabilesc după realitatea faptică, nu după eticheta convenită formal. Contractul poate ajuta la identificarea rolurilor, dar nu este decisiv; alocarea rolurilor trebuie să reiasă din circumstanțele concrete și nu este negociabilă ca simplă formulă de drafting art. 4 pct. 7 și 8 GDPR, Orientările EDPB 07/2020.

Asta înseamnă că atunci când compania ta folosește un furnizor SaaS pentru a-și gestiona clienții, angajații sau comenzile, tu rămâi, de regulă, operatorul pentru că tu decizi de ce sunt colectate datele, ce tipuri de date sunt încărcate, cine are acces din organizația ta, cât timp le păstrezi și în ce procese de business intră ele. Vendorul rămâne, de regulă, împuternicit dacă procesează acele date exclusiv pentru a-ți presta serviciul, în baza instrucțiunilor tale și în interesul tău Orientările EDPB 07/2020.

Dar există o nuanță critică: dacă furnizorul își depășește rolul și începe să stabilească el însuși scopurile și mijloacele pentru anumite prelucrări, art. 28 alin. (10) spune clar că el va fi considerat operator pentru acea prelucrare. În practică, asta apare atunci când vendorul folosește datele clientului pentru propriile scopuri autonome, de exemplu dezvoltare de produs, profilare comercială proprie, analytics independente sau reutilizare în afara instrucțiunilor primite art. 28 alin. (10) GDPR, Orientările EDPB 07/2020.

În fața autorității, însă, operatorul are obligații proprii care nu dispar fiindcă infrastructura este externalizată. Art. 33 alin. (1) pune pe operator obligația de a notifica autoritatea de supraveghere fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la momentul în care a luat cunoștință de breșă. Processorul are obligația separată de a notifica operatorul fără întârzieri nejustificate după ce află despre breșă art. 33 alin. (1) și (2) GDPR.

EDPB mai face două precizări foarte utile pentru contractele SaaS. Prima: operatorul trebuie considerat, în principiu, că „ia cunoștință” de breșă atunci când împuternicitul îl informează despre incident. A doua: GDPR nu dă un termen exact în ore pentru notificarea de la processor la controller, dar EDPB recomandă ca împuternicitul să transmită de îndată o notificare inițială și apoi informații suplimentare în etape, pe măsură ce apar detalii, tocmai pentru a permite operatorului să respecte fereastra de 72 de ore Orientările EDPB 9/2022 privind notificarea breșelor.

Pe latura despăgubirilor, art. 82 GDPR spune că orice persoană care a suferit un prejudiciu material sau moral are dreptul la despăgubiri. Operatorul este răspunzător pentru prejudiciul cauzat de o prelucrare care încalcă regulamentul, iar împuternicitul răspunde dacă nu și-a respectat obligațiile care îi revin în mod specific sau dacă a acționat în afara ori împotriva instrucțiunilor legale ale operatorului. Dacă mai mulți actori sunt implicați în aceeași prelucrare și sunt responsabili pentru prejudiciu, fiecare poate fi ținut pentru întregul prejudiciu față de persoana vizată, urmând apoi recursul intern între ei potrivit părții de responsabilitate art. 82 GDPR.

Tradus în limbaj de business, răspunsul la întrebarea „cine răspunde?” este: în fața ANSPDCP răspunde în mod direct și operatorul pentru propriile sale obligații, iar uneori și împuternicitul pentru obligațiile sale proprii; față de persoanele vizate poate exista răspundere civilă și la operator, și la împuternicit, după regulile art. 82; iar între voi, contractual, discutați separat cine suportă costul final, în funcție de culpa tehnică, de breach clauses, de indemnities și de nivelul de cooperare dovedit în incident.

Ce obligații ai înainte de incident

Prima obligație reală nu începe în ziua atacului, ci în ziua în care alegi vendorul. Art. 28 alin. (1) nu vorbește despre un simplu furnizor „cunoscător”, ci despre împuterniciți care oferă garanții suficiente pentru a implementa măsuri tehnice și organizatorice adecvate. EDPB a explicat în 2024 că operatorul trebuie să exercite diligența necesară la selectarea și supravegherea împuternicitului și că această obligație este una continuă, nu o bifă unică făcută la procurement art. 28 alin. (1) GDPR, Avizul EDPB 22/2024.

Mai mult, EDPB spune că operatorul trebuie să aibă acces imediat, oricând, la informațiile privind identitatea tuturor persoanelor împuternicite și subcontractanților implicați în lanțul de prelucrare, iar processorul trebuie să furnizeze proactiv aceste informații și să le actualizeze permanent. Dacă folosești un SaaS cu mai multe layere de subprocesatori, iar la incident nu știi cine a operat concret mediul, cine a avut acces administrativ sau în ce jurisdicții au circulat datele, ai deja o problemă de conformitate, nu doar o problemă de comunicare Avizul EDPB 22/2024, art. 28 alin. (2) și (4) GDPR.

Din perspectiva art. 32, atât operatorul, cât și împuternicitul trebuie să implementeze măsuri adecvate raportate la risc, inclusiv, unde este cazul, pseudonimizare și criptare, capacitatea de a asigura confidențialitatea, integritatea, disponibilitatea și reziliența sistemelor și serviciilor, capacitatea de a restabili disponibilitatea datelor în timp util și un proces de testare, evaluare și apreciere periodică a eficacității măsurilor. Așadar, nu este suficient ca vendorul să-ți spună generic că este „secure by design”; trebuie să poți corela controlul promis cu riscul real al seturilor tale de date art. 32 GDPR.

Ca minim practic, înainte de incident trebuie să ai un due diligence documentat pe securitate și protecția datelor: tipurile de date prelucrate, criticitatea procesului, locațiile de stocare, identitatea subprocesatorilor, certificări și rapoarte relevante, controale de acces, segregarea mediilor, politica de backup, testarea restaurării, managementul vulnerabilităților, procedura de incident response și conținutul minim al notificării de breșă din partea vendorului. EDPB arată că pentru verificarea garanțiilor operatorul poate cere documentație relevantă, se poate baza pe informații publice, certificări sau rapoarte de audit de la terți de încredere și poate efectua audituri la fața locului; certificările pot ajuta, dar nu înlocuiesc analiza proprie Avizul EDPB 22/2024, art. 28 alin. (5) GDPR, art. 32 alin. (3) GDPR.

Pe partea tehnică, recomandările oficiale ENISA și CERT-EU sunt foarte utile pentru a transforma obligația abstractă din art. 32 în controale concrete: autentificare multifactor pentru servicii expuse, control strict al accesului terților la sisteme și rețele, hardening al mediilor cloud, separarea administrării cloud de administrarea on-prem, strategie de backup de tip 3-2-1, acces la backup controlat, limitat și logat, testarea periodică a restaurării și segmentarea rețelei pentru limitarea mișcării laterale a atacatorilor ENISA & CERT-EU, Boosting your Organisation’s Cyber Resilience, art. 32 GDPR.

Un alt element adesea uitat este pregătirea procedurală. EDPB spune expres că fiecare operator și fiecare împuternicit ar trebui să aibă planuri și proceduri pentru gestionarea breșelor, linii clare de raportare și persoane responsabile pentru diferitele etape ale recuperării. Tot EDPB arată că operatorul și processorul trebuie să poată detecta, remedia și raporta breșa, iar log analyzers și datele din jurnale sunt un instrument relevant pentru depistarea neregulilor și auditabilitate EDPB Guidelines 01/2021, Orientările EDPB 9/2022.

Pe scurt, înainte de incident trebuie să poți răspunde documentat la cinci întrebări: de ce acest vendor, ce date îi dai, ce măsuri are, cine sunt subprocesatorii lui și cum te anunță dacă apare o breșă. Dacă nu poți răspunde clar la aceste întrebări înainte de atac, vei răspunde greu și după atac.

Ce faci în primele 24–72 de ore

Primele ore nu sunt despre perfecțiune, ci despre control. EDPB spune că operatorul nu ar trebui să aștepte finalizarea unei examinări criminalistice detaliate înainte să evalueze dacă breșa este susceptibilă să genereze risc și, deci, dacă trebuie notificată. Accentul trebuie pus pe acțiunea promptă, pe investigația inițială rezonabilă, pe limitarea incidentului și pe documentarea lui pe măsură ce evoluează EDPB Guidelines 01/2021, Orientările EDPB 9/2022.

0–6 ore: izolare, probă, escaladare

Activezi imediat playbook-ul intern de incident și pui la aceeași masă IT, security, juridic, DPO, management și owner-ul de business al aplicației afectate, pentru că EDPB cere linii clare de raportare și persoane responsabile pentru fiecare etapă a recuperării EDPB Guidelines 01/2021.
Escaladezi formal vendorul și ceri notificare scrisă inițială cu ora la care a devenit aware, sistemele afectate, tipul incidentului, măsurile de containment, categoriile de date posibil afectate și subcontractanții implicați, pentru că art. 33 alin. (2) obligă processorul să notifice operatorul fără întârzieri nejustificate, iar EDPB recomandă notificare imediată urmată de completări în etape art. 33 alin. (2) GDPR, Orientările EDPB 9/2022.
Izolezi conturile, token-urile, cheile și conexiunile compromise, blochezi accesul terților unde este necesar și conservi logurile, snapshot-urile și celelalte artefacte tehnice, deoarece art. 33 alin. (5) cere documentarea faptelor, efectelor și acțiunilor de remediere, iar ENISA recomandă control strict al accesului terților și logarea accesului la backup-uri și sisteme sensibile art. 33 alin. (5) GDPR, ENISA & CERT-EU.

6–24 ore: calificare juridică și evaluare de risc

În această fază trebuie să răspunzi dacă ai sau nu o „încălcare a securității datelor cu caracter personal” în sensul art. 4 pct. 12 GDPR, adică o breșă de securitate care a dus la distrugere, pierdere, alterare, divulgare neautorizată sau acces neautorizat la date. Nu orice alertă de securitate este automat breșă de date, dar odată ce ai un grad rezonabil de certitudine că datele personale au fost compromise, fereastra de 72 de ore devine operațională pentru controller art. 4 pct. 12 GDPR, Orientările EDPB 9/2022.

Concret, faci rapid o matrice de impact: ce categorii de date au fost afectate, câte persoane sunt implicate aproximativ, dacă sunt date speciale sau identificatori puternici, dacă datele au fost exfiltrate, publicate, criptate sau doar indisponibilizate, dacă există copii curate, dacă datele erau criptate sau altfel făcute neinteligibile și ce consecințe probabile există pentru persoane. Aceste informații sunt chiar nucleul notificării prevăzute de art. 33 alin. (3) și al testului de risc pentru art. 34 art. 33 alin. (3) GDPR, art. 34 GDPR.

24–72 ore: decizie de notificare, draft de mesaje, completări

Dacă rezultă că breșa este susceptibilă să prezinte un risc pentru drepturile și libertățile persoanelor, notifici ANSPDCP fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore. Dacă nu ai toate informațiile, GDPR permite notificarea în etape, fără întârzieri suplimentare nejustificate. Asta înseamnă, practic, că în fereastra de 72 de ore nu trebuie să ai dosarul complet de forensic, ci o notificare inițială suficient de serioasă, cu un plan de update art. 33 alin. (1), (3) și (4) GDPR, EDPB Guidelines 01/2021.

În paralel, pregătești mesajul către persoanele vizate dacă analiza indică risc ridicat, validezi canalul de comunicare care nu a fost compromis, stabilești recomandările concrete pentru persoane și verifici dacă există incidente conexe de transfer internațional, de continuitate operațională sau de acces de către subprocesatori. Tot în această etapă documentezi fiecare decizie: cine a știut ce, când, ce măsuri au fost dispuse, ce informații au venit de la vendor și de ce ai notificat sau nu ai notificat art. 33 alin. (5) GDPR, Orientările EDPB 9/2022.

Când și cum notifici ANSPDCP

Regula de bază este din art. 33 alin. (1): notifici autoritatea competentă atunci când breșa este susceptibilă să prezinte un risc pentru drepturile și libertățile persoanelor fizice. Excepția este doar situația în care este puțin probabil să existe un asemenea risc. Dacă notificarea nu este făcută în 72 de ore, ea trebuie însoțită de motivele întârzierii art. 33 alin. (1) GDPR.

Conținutul minim al notificării este, tot potrivit art. 33 alin. (3), următorul: natura breșei, inclusiv categoriile și numărul aproximativ de persoane și înregistrări afectate, datele de contact ale DPO-ului sau altui punct de contact, consecințele probabile și măsurile luate sau propuse pentru remediere și atenuare. Dacă nu poți furniza toate aceste elemente simultan, le poți transmite fazat art. 33 alin. (3) și (4) GDPR.

În România, ANSPDCP are o secțiune dedicată pentru „Notificare Breșă RGPD” pe site-ul oficial și o pagină specială pentru notificarea încălcării securității datelor cu caracter personal, unde este menționată și Decizia nr. 128/2018 privind aprobarea formularului tipizat și opțiunea de depunere notificare online. Ca practică de lucru, merită să verifici direct înainte de depunere atât pagina de notificare, cât și site-ul principal ANSPDCP, pentru a vedea fluxul actual și documentele relevante.

Foarte important: faptul că processorul îți spune că va „gestiona el raportarea” nu mută obligația juridică de pe tine. EDPB admite că împuternicitul poate face notificarea în numele operatorului dacă este autorizat și acest mecanism există contractual, dar subliniază expres că răspunderea juridică pentru notificare rămâne a operatorului Orientările EDPB 9/2022.

Din punct de vedere practic, o notificare bună către ANSPDCP nu este una „defensivă”, ci una ordonată: spui ce știi, ce nu știi încă, ce ai făcut deja, ce urmează să faci, când revii cu completări și care este evaluarea ta de risc la acel moment. O notificare vagă, fără cronologie, fără tipuri de date, fără măsuri de containment și fără explicația relației cu vendorul îți slăbește poziția din primul moment.

Când informezi persoanele vizate

Art. 34 GDPR ridică pragul față de art. 33: persoanele vizate trebuie informate atunci când breșa este susceptibilă să genereze un risc ridicat pentru drepturile și libertățile lor. EDPB subliniază că nu toate breșele notificabile autorității trebuie comunicate și persoanelor; pragul pentru comunicarea către persoane este mai ridicat, tocmai pentru a evita excesul de înștiințări inutile art. 34 GDPR, Orientările EDPB 9/2022.

Mesajul către persoanele vizate trebuie să descrie, într-un limbaj clar și simplu, natura breșei și să includă cel puțin datele de contact ale punctului de contact, consecințele probabile și măsurile luate sau propuse pentru remediere și atenuare. EDPB mai recomandă ca, acolo unde este cazul, operatorul să ofere sfaturi practice persoanelor, de exemplu resetarea parolelor sau măsuri de vigilență împotriva tentativelor de fraudă art. 34 alin. (2) GDPR, Orientările EDPB 9/2022.

Pe metodă, EDPB este foarte clar: notificarea ar trebui, în principiu, comunicată direct persoanelor, iar mesajele despre breșă nu ar trebui amestecate cu newslettere, update-uri comerciale sau mesaje standard. O notificare limitată la un comunicat de presă sau la un blog corporativ nu este, de regulă, un mijloc eficace atunci când contactarea directă este posibilă. Mai mult, operatorul trebuie să fie prudent dacă vrea să folosească un canal compromis de incident, pentru că același canal poate fi exploatat de atacatori pentru spoofing și phishing Orientările EDPB 9/2022.

Există și trei situații de excepție în care art. 34 alin. (3) spune că informarea persoanelor nu este necesară: dacă ai implementat și aplicat măsuri care fac datele neinteligibile pentru persoane neautorizate, cum este criptarea; dacă ai luat ulterior măsuri care fac improbabilă materializarea riscului ridicat; sau dacă informarea ar implica un efort disproporționat, caz în care trebuie făcută o comunicare publică sau o măsură similară, la fel de eficace. Dacă te bazezi pe una dintre aceste excepții, trebuie să poți demonstra de ce se aplică art. 34 alin. (3) GDPR, Orientările EDPB 9/2022.

În cazuri excepționale, EDPB arată și că informarea persoanelor poate fi coordonată cu autoritatea și, dacă există motive legitime legate de ancheta penală sau de prevenirea unei afectări suplimentare a investigației, poate exista un scurt decalaj justificat. Dar regula rămâne comunicarea fără întârzieri nejustificate și cât mai curând posibil în mod rezonabil Orientările EDPB 9/2022.

Ce trebuie să scrie în contractul cu vendorul

Art. 28 alin. (3) GDPR enumeră elementele obligatorii ale relației operator–împuternicit și merită citit direct, nu din rezumate. Contractul trebuie să fie obligatoriu pentru processor, să descrie obiectul și durata prelucrării, natura și scopul ei, tipurile de date și categoriile de persoane vizate, precum și drepturile și obligațiile operatorului. Apoi trebuie să includă, printre altele, prelucrarea numai pe instrucțiuni documentate, confidențialitatea personalului autorizat, măsurile art. 32, regulile privind subprocesatorii, asistența pentru drepturile persoanelor, asistența pentru obligațiile din art. 32–36, ștergerea sau returnarea datelor și obligația de a pune la dispoziție informațiile necesare pentru demonstrarea conformității și pentru audit art. 28 alin. (3) GDPR.

O definiție clară a serviciilor și a operațiunilor de prelucrare acoperite, ca să nu existe zone gri între „hosting”, „support”, „analytics” și „managed services” art. 28 alin. (3) GDPR.
Instrucțiuni documentate și un mecanism de actualizare a lor, inclusiv pentru transferuri, ștergere, retenție și export de date art. 28 alin. (3) lit. (a) GDPR.
Obligații tehnice detaliate de securitate, nu doar formulări generale, corelate cu riscul și cu seturile de date concrete; art. 32 cere măsuri adecvate, iar în practică acestea trebuie traduse în control access, logging, segmentation, backup, patching, MFA, vulnerability management și testare art. 32 GDPR, ENISA & CERT-EU.
Regula pentru subprocesatori: autorizație specifică sau generală în scris, obligația de a menține lista actualizată și dreptul operatorului de a obiecta la schimbări relevante art. 28 alin. (2) și (4) GDPR, Avizul EDPB 22/2024.
Un SLA de incident separat de SLA-ul comercial, cu notificare inițială foarte rapidă, actualizări în etape, conținut minim obligatoriu și obligația processorului de a furniza toate datele necesare pentru art. 33 și 34 art. 33 alin. (2) GDPR, Orientările EDPB 9/2022.
Drepturi de audit și de acces la informații care să fie utilizabile în practică, nu doar decorative, pentru că processorul trebuie să facă disponibile informațiile necesare pentru demonstrarea conformității și să permită audituri și inspecții art. 28 alin. (3) lit. (h) GDPR.
Asistență expresă la DPIA, consultare prealabilă, răspunsuri la cereri ale persoanelor vizate, investigații ale autorității și conservarea probelor art. 28 alin. (3) lit. (e) și (f) GDPR.
Clauze clare privind returnarea sau ștergerea datelor la încetare, inclusiv copii de backup, perioade tranzitorii și formatul exportului art. 28 alin. (3) lit. (g) GDPR.
Dacă există transferuri internaționale, anexe și instrucțiuni separate pentru transfer, nu simple formulări generale ascunse în termeni standard art. 28 GDPR, Avizul EDPB 22/2024.
Ca instrument practic, poți folosi și clauzele contractuale standard ale Comisiei pentru relația controller–processor, dar ele trebuie adaptate la serviciul concret și nu înlocuiesc anexele tehnice serioase privind securitatea, incident response și subprocesatorii Decizia de punere în aplicare (UE) 2021/915.

Contractul bun cu vendorul nu este cel mai lung, ci cel care îți permite, la ora 2 noaptea când apare alerta, să știi exact cine raportează, în câte ore, ce dovadă păstrează, cine aprobă subprocesatorii, cum se face auditul, cine are drept de a ordona containment și cine suportă costurile dacă procesorul nu cooperează.

Probe și audit trail: ce trebuie să poți arăta după incident

Într-o investigație ANSPDCP, diferența dintre o poziție credibilă și una vulnerabilă stă de multe ori în audit trail. Art. 33 alin. (5) spune că operatorul trebuie să documenteze orice breșă, incluzând faptele, efectele și acțiunile corective. Art. 28 alin. (3) lit. (h) cere de la processor informațiile necesare pentru demonstrarea conformității și participarea la audit. EDPB adaugă că documentarea breșei trebuie să se facă pe măsură ce aceasta evoluează art. 33 alin. (5) GDPR, art. 28 alin. (3) lit. (h) GDPR, Orientările EDPB 9/2022.

Loguri de autentificare, acces, export, modificare și ștergere, plus cronologia lor păstrată într-un mod care să evite suprascrierea sau alterarea; EDPB amintește expres rolul analizatorilor de fluxuri și jurnale în detectarea neregulilor Orientările EDPB 9/2022.
Lista persoanelor și conturilor cu access administrativ, inclusiv conturi tehnice, conturi de support și terți, pentru că art. 32 cere confidențialitate, integritate și reziliență, iar ENISA recomandă control strict al accesului terților și segmentare art. 32 GDPR, ENISA & CERT-EU.
DPA-ul semnat, anexele de securitate, lista subprocesatorilor aprobați, notificările de schimbare și istoricul obiecțiilor, pentru că EDPB cere acces permanent la identitatea actorilor din lanțul de prelucrare Avizul EDPB 22/2024.
Dosarul de due diligence: chestionare de securitate, răspunsuri ale vendorului, rapoarte de audit, certificări, teste, call notes și aprobările interne de procurement sau legal, pentru a demonstra ce ai verificat la alegerea împuternicitului Avizul EDPB 22/2024.
Dovezi despre backup și recovery: frecvență, RTO/RPO, testele de restore, limitarea și logarea accesului la backup și separarea mediilor, deoarece ENISA recomandă explicit aceste măsuri ENISA & CERT-EU.
Dovezi de segregare și access control: ce medii au fost separate, ce rețele au fost segmentate, cum a fost limitată mișcarea laterală și cum a fost controlat accesul cloud vs. on-prem ENISA & CERT-EU.
Istoricul deciziei de notificare: momentul awareness, analiza de risc, versiunea inițială a notificării, completările și motivele pentru orice întârziere art. 33 GDPR, Orientările EDPB 9/2022.

Fără acest pachet de probe, rămâi prizonierul propriei narațiuni. Cu el, poți demonstra că ai ales vendorul cu un minim rezonabil de diligență, că ai avut procese reale de securitate și că ai reacționat în timp util, chiar dacă incidentul tehnic a fost serios.

Scenarii practice: cine răspunde și ce faci diferit

CRM compromis. Dacă furnizorul CRM găzduiește și procesează datele clienților tăi pentru managementul vânzărilor, el este de regulă împuternicit, iar tu rămâi operator. Dacă sunt exfiltrate nume, telefoane, e-mailuri, note comerciale și identificatori de cont, art. 33 cere analiza de risc și, frecvent, notificarea autorității. Dacă au fost compromise și credențiale sau alte date care permit fraudă ori spear phishing, crește probabilitatea de risc ridicat și de informare a persoanelor, cu recomandări concrete de protecție art. 33 și 34 GDPR, Orientările EDPB 9/2022.

Aplicație HR. Aici riscul juridic urcă rapid, fiindcă pot apărea CNP-uri, salarii, evaluări, date disciplinare sau chiar date privind sănătatea. Într-un astfel de context, discuția despre art. 34 devine mult mai sensibilă, pentru că efectele posibile pentru angajați sunt mai grave, iar pragul de risc ridicat poate fi atins mai ușor. Când vendorul HR este compromis, nu te uiți doar la indisponibilitatea serviciului, ci la posibilitatea de divulgare, discriminare, fraudă și impact reputațional sau profesional asupra persoanelor art. 34 GDPR, Comunicat ANSPDCP 25.03.2026.

Platformă e-commerce. Dacă atacul vizează comenzile, conturile de client și datele de livrare, trebuie să delimitezi imediat ce a fost afectat: simple date de contact, parole, token-uri, istoric comenzi sau date de plată gestionate de alți furnizori. Dacă au fost compromise identificatoare de acces, EDPB recomandă ca persoanele să primească recomandări concrete, precum resetarea parolelor. Contractual, aici contează enorm și cine gestionează subprocesatorii pentru hosting, fraud detection, email transactional și customer support Orientările EDPB 9/2022, Avizul EDPB 22/2024.

Software medical. Când vendorul procesează date privind sănătatea, art. 32 trebuie citit la nivel de risc maxim practic, iar comunicarea către persoane devine adesea mai probabilă dacă există divulgare ori acces neautorizat. Aici backup-ul, segregarea, controlul accesului privilegiat, jurnalizarea și procedura de comunicare trebuie să fie mult mai mature, iar analiza de transferuri și subprocesatori devine esențială art. 32 GDPR, ENISA & CERT-EU.

Platformă de marketing. Dacă incidentul afectează liste de newsletter, profiling, tracking IDs și istoricul interacțiunilor, întrebarea nu este doar dacă vendorul era processor, ci și dacă folosea datele pentru scopuri proprii. Dacă da, rolul lui trebuie reanalizat pentru acea parte de prelucrare. În plus, dacă datele afectate erau criptate sau altfel făcute neinteligibile pentru acces neautorizat, poate exista spațiu pentru a concluziona că nu este necesară informarea persoanelor potrivit art. 34 alin. (3), dar această concluzie trebuie documentată serios art. 28 alin. (10) GDPR, art. 34 alin. (3) GDPR, Orientările EDPB 07/2020.

Checklist practic pentru companiile care folosesc SaaS

Identifică pentru fiecare aplicație cine este operator, cine este împuternicit și dacă există prelucrări în care vendorul poate deveni operator separat Orientările EDPB 07/2020.
Păstrează o evidență actualizată a tuturor subprocesatorilor și a rolului lor în lanțul de prelucrare Avizul EDPB 22/2024.
Verifică dacă DPA-ul acoperă toate elementele din art. 28 alin. (3) și dacă este dublat de anexe tehnice reale art. 28 GDPR.
Impune contractual notificare de incident imediată, cu update-uri în etape și conținut minim obligatoriu art. 33 alin. (2) GDPR, Orientările EDPB 9/2022.
Testează backup-ul și restaurarea, nu doar existența backup-ului ENISA & CERT-EU.
Controlează strict accesul vendorului și al terților la sistemele tale și loghează accesul privilegiat ENISA & CERT-EU.
Asigură MFA, patching și segmentare pentru serviciile critice și pentru mediile cloud ENISA & CERT-EU.
Ține pregătit un model intern de notificare ANSPDCP și un model de comunicare către persoane vizate pagina ANSPDCP Notificare, Orientările EDPB 9/2022.
Stabilește cine decide juridic momentul „awareness”, cine semnează notificarea și cine validează mesajul către persoane EDPB Guidelines 01/2021.
Documentează due diligence-ul vendorului și reevaluează-l periodic, mai ales după schimbări de subprocesatori sau funcționalități Avizul EDPB 22/2024.

Cele mai frecvente greșeli după un incident

Aștepți raportul final de forensic înainte să pornești analiza GDPR. EDPB spune expres că operatorul nu ar trebui să aștepte o examinare criminalistică detaliată înainte de evaluarea notificării EDPB Guidelines 01/2021.
Te ascunzi în spatele vendorului. Faptul că atacul a fost într-o aplicație administrată prin împuternicit nu a împiedicat ANSPDCP să sancționeze operatorul în cazul Renault Comunicat ANSPDCP 25.03.2026.
Confunzi contractul cu realitatea. EDPB arată că rolurile sunt funcționale și nu depind exclusiv de etichetele din contract Orientările EDPB 07/2020.
Nu ai vizibilitate pe subprocesatori. Dacă nu știi cine face parte din lanțul de prelucrare, nu poți demonstra că ai verificat garanțiile suficiente Avizul EDPB 22/2024.
Te bazezi doar pe certificări. Codurile de conduită și certificările pot fi elemente utile, dar nu înlocuiesc analiza proprie a riscului și a măsurilor concrete art. 28 alin. (5) și art. 32 alin. (3) GDPR.
Nu documentezi deciziile intermediare. Art. 33 alin. (5) cere documentarea breșei, a efectelor și a acțiunilor de remediere, nu doar concluzia finală art. 33 alin. (5) GDPR.
Trimiți o comunicare către persoane într-un mesaj de marketing sau pe un canal compromis. EDPB recomandă mesaje dedicate și prudență față de canalele posibil compromise Orientările EDPB 9/2022.
Uiți că processorul poate avea propriile încălcări și propria expunere. Art. 82 și art. 28 alin. (10) arată că și împuternicitul poate răspunde în anumite condiții și poate deveni chiar operator pentru anumite prelucrări art. 82 GDPR, art. 28 alin. (10) GDPR.

Concluzie

Cazul Renault Commercial Roumanie este un semnal foarte clar pentru toate companiile care rulează business-ul pe software extern: o breșă GDPR furnizor SaaS nu este doar un incident al vendorului, ci un test complet al guvernanței tale ca operator. ANSPDCP a arătat că va privi simultan la securitatea efectivă a prelucrării și la standardul după care ai ales și ai controlat împuternicitul Comunicat ANSPDCP 25.03.2026, art. 28 GDPR, art. 32 GDPR.

Răspunsul corect la întrebarea „cine răspunde?” nu este un nume, ci un sistem: operatorul trebuie să știe ce externalizează, cui, cu ce garanții, în ce condiții și cum reacționează dacă sistemul extern cade sau este compromis. Processorul trebuie să poată demonstra măsuri reale, să notifice imediat, să coopereze și să lase urme verificabile. Contractul trebuie să susțină acest sistem, nu să-l mimeze. Iar în primele 24–72 de ore după incident, diferența dintre conformitate și expunere majoră o fac viteza, proba și coordonarea juridico-tehnică.

Cu alte cuvinte, prevenția bună înseamnă due diligence, arhitectură, contract și supraveghere. Reacția bună înseamnă containment, audit trail, evaluare de risc, notificare la timp și comunicare clară. Exact între aceste două axe — guvernanță înainte și reacție rapidă după — se va decide, de regulă, dacă un incident de vendor rămâne o criză gestionabilă sau devine o sancțiune, un litigiu și o problemă reputațională pe termen lung.