Acasă/Metode

E-commerce · Confidențialitate

Cum gestionezi cererile GDPR de ștergere în magazin, helpdesk și platforma de email

O cerere GDPR de ștergere înseamnă că un client îi cere magazinului online să-i șteargă datele personale. Oprim marketingul către acea persoană în aceeași oră, cartografiem fiecare sistem care ține o copie, ștergem doar după chei exacte și instalăm un registru de ștergeri înainte să ștergem ceva, fiindcă sincronizările de noapte refac ce ai șters. Unele înregistrări, ca facturile, se păstrează prin lege, așa că răspunsul nu spune niciodată „am șters tot”. E metoda noastră de lucru, nu consultanță juridică.

Actualizat 2026-10-11

Ce faci când un client îți cere să-i ștergi datele

O cerere GDPR de ștergere înseamnă că un client își exercită dreptul la ștergere din articolul 17 GDPR: îi cere unei firme să șteargă datele personale pe care le are despre el. Ordinea care funcționează pentru un magazin online este: oprești întâi orice marketing către acea persoană, în aceeași oră; confirmi identitatea fără să strângi date în plus; cartografiezi fiecare sistem care ține o copie; treci ștergerea într-un registru care o reaplică după fiecare sincronizare; ștergi doar după chei exacte; păstrezi ce cere legea; și îi spui clientului precis ce s-a șters, ce s-a păstrat și până când.

Articolul descrie cum tratăm cererile de ștergere pentru magazine online și a fost scris după un caz real în care fiecare capcană de mai jos a fost lovită efectiv. Nu e consultanță juridică. Trimiterile legale sunt cele pe care le consemnează procedura noastră pentru magazine din România, iar procedura însăși avertizează să nu citezi termene de păstrare din memorie: verifică legea în vigoare.

Pasul 1: oprește marketingul înaintea oricărui alt lucru

Oprirea marketingului e prima acțiune, înaintea triajului și a inventarului. Articolul 21 alineatul (3) din GDPR cere încetarea prelucrării în scop de marketing direct când persoana se opune, iar asta nu beneficiază de termenul de o lună din articolul 12 alineatul (3).

În cazul real, clienta a primit un email promoțional la 2 ore și 37 de minute după ce ceruse ștergerea, și l-a deschis. Nimeni nu fusese neglijent. Pur și simplu nu exista nicio legătură între tichetul din helpdesk și platforma de email. Suprimă persoana la ambele capete: în platforma de email și în consimțământul de marketing din magazin, fiindcă înregistrarea de consimțământ din platforma de email fusese creată de webhook-ul de clienți al magazinului, iar o resincronizare putea s-o reaboneze.

Verifică fiecare unealtă care trimite mesaje după propriul calendar. Aplicația noastră de recenzii n-avea API pentru suprimarea unei persoane; am încercat nouă nume plauzibile de endpoint și toate au întors 404, deci a trebuit blocată de mână, din panoul ei. Cererile de recenzie pleacă de obicei la 15-30 de zile după livrare, așa că altfel o cerere de recenzie putea ajunge exact după confirmarea scrisă că trimiterile au încetat.

Pasul 2: confirmă identitatea fără să strângi date în plus

Când cererea de ștergere vine de pe aceeași adresă de email ca și comanda, iar numele sau telefonul coincid, asta e o verificare rezonabilă a identității în sensul articolului 12 alineatul (6). Să ceri copie după actul de identitate înseamnă să strângi mai multe date decât cere situația, ceea ce contrazice principiul minimizării din articolul 5 alineatul (1) litera c), și întârzie răspunsul.

Termenul de răspuns este de o lună de la primire, potrivit articolului 12 alineatul (3). Notează ora exactă la care a sosit cererea; incidentul de marketing de mai sus se măsoară de la ea.

Pasul 3: fă harta locurilor în care stau datele clientului

Datele personale ale unui client sunt împrăștiate, într-o firmă mică de e-commerce, în mult mai multe sisteme decât magazinul. Harta noastră pentru un singur client a cuprins: platforma magazinului (fișa clientului, comenzile, mai multe copii ale fiecărei adrese, adresa IP și scorurile de risc de fraudă); platforma de email (profil, evenimente, scoruri predictive); helpdesk-ul (profil, conversații, note interne și un link de status al comenzii care poartă o cheie secretă); depozitul de date (comenzi cu o copie JSON completă a fiecărei comenzi, plus agregate pe client, ca scorurile de refuz); baza de date de expediere; sistemul de gestiune a comenzilor; bazele de profitabilitate, cu circa 28 de tabele de backup în baza vie; bazele-oglindă locale; înregistrările apelurilor din sistemul de telefonie; urmele din monitorizarea erorilor, care conțineau date de comandă; foile de calcul și spațiul de stocare comun.

Trei categorii scapă ușor: coloanele JSON brute care țin o copie completă a comenzii, tabelele de arhivă din baza vie, pe care nicio procedură de redactare nu le atinge, și înregistrările apelurilor. Indecșii orbi, adică hash-urile telefonului sau emailului folosite la căutare, sunt și ei date personale: cu ei oricine poate testa o ipoteză, deci trebuie goliți.

Pasul 4: instalează registrul de ștergeri înainte să ștergi

O ștergere dintr-o copie din aval e suprascrisă de următoarea sincronizare, dacă sincronizarea nu știe de ea. La noi, magazinul alimentează depozitul de date, din care se refac de mai multe ori pe zi cache-uri derivate, iar sincronizarea de la curier reumple datele de expediere pe o fereastră de 90 de zile. Fără registru, o ștergere se anula în 24 de ore.

Deci ordinea e: treci întâi cererea în registrul de ștergeri, abia apoi ștergi. Câteva joburi mici reaplică registrul în fiecare oră, în fiecare bază, potrivind doar chei exacte din registru, niciodată nume. Joburile nu afișează nimic când n-au ce reaplica, deci orice linie în jurnalul lor înseamnă o resurecție reală, iar joburile servesc și ca monitorizare. Le acceptăm doar după trei rulări consecutive tăcute.

Platforma magazinului a refuzat ea însăși redactarea comenzilor din ultimele 6 luni, deci sursa rămâne vie luni întregi. Am depus totuși cererea oficială de ștergere a platformei, care pornește ceasul. Dovada ștergerii nu e comanda de ștergere, ci verificarea de a doua zi că rândurile nu au reapărut.

Pasul 5: păstrează ce cere legea și spune asta

O cerere de ștergere nu anulează obligațiile legale de păstrare, iar răspunsul trebuie să spună ce rămâne și de ce. Pentru magazine din România, procedura noastră consemnează: facturile se păstrează 5 ani, potrivit Legii 82/1991, articolul 25, modificat prin Legea 36/2023 (termenul vechi era de 10 ani, iar modelele lingvistice îl citează încă); o copie a fiecărei facturi stă în sistemul național de facturare electronică al autorității fiscale, unde magazinul nu are drept de ștergere; dovada livrării, ca document justificativ; nucleul contractual, 3 ani; garanția legală de conformitate, 2 ani de la livrare; și perioada de retragere de 14 zile.

Perioada de retragere merită o frază în răspuns. Dacă cererea vine în cele 14 zile, ștergerea totală lasă magazinul fără posibilitatea de a procesa un retur al aceleiași persoane, ceea ce e împotriva interesului clientului. Se păstrează și intrarea din lista de excludere de la marketing, izolată, fiindcă ea oprește trimiterile viitoare. Verifică fiecare termen în legea în vigoare; lista de aici nu e consultanță juridică.

Capcanele pe care le-am lovit și cum le prindem acum

Omonimii. Pentru un nume de familie frecvent, o singură căutare a întors 16 persoane diferite într-o bază și 11 în alta. Ștergerea după nume distruge datele altcuiva și transformă o cerere rezolvată în două încălcări. Scriem lista cheilor admise înainte de prima interogare și nu ieșim din ea; niciodată LIKE '%nume%'.

Zero fără control pozitiv. Un rezultat gol poate veni dintr-un filtru greșit, dintr-o coloană criptată, din lipsă de acces sau dintr-un perimetru care nu acoperă cazul. Un folder comun cu 18 fișiere nu conținea deloc comenzi, deci zero-ul lui venea din acoperire, nu din absență. O foaie de calcul cu 75.000 de comenzi nu o conținea pe clientă fiindcă se oprea cu 6 luni înainte. Prima verificare pe un server a raportat „niciun tabel” pentru că utilitarul de linie de comandă al bazei nu era instalat; citit altfel, fișierul avea datele în 3 tabele. Dovedește întâi că metoda găsește pe altcineva.

Coloanele criptate. Câmpurile criptate cu IV aleator nu se potrivesc niciodată într-o clauză WHERE și eșuează tăcut, ca zero rânduri. Ia rândurile după identificatorul comenzii și filtrează după decriptare.

Nicio operație de ștergere. API-ul sistemului nostru de gestiune a comenzilor nu avea operație de ștergere în niciuna dintre cele 151 de căi, iar singura scriere de adresă ar fi împins modificări în magazin și în toate aplicațiile conectate. Am curățat direct în baza lui de date.

Unde am greșit și ce nu trebuie să scrie răspunsul

Prima variantă de răspuns a căzut din cauza a trei fapte pe care nu le văzusem din cod: cererea nu ajunsese niciodată la marketing, două bucle de sincronizare ar fi refăcut rândurile șterse, iar ștergerea totală era imposibilă legal. Metoda am învățat-o din cazul acela.

Regulile pentru răspuns: nu scrie niciodată „am șters tot”, fiindcă absența nu se poate dovedi, ci doar ce ai șters. Nu afirma că ai notificat destinatarii dacă nu i-ai notificat. Dacă a plecat un email după cerere, spune-o; jurnalele platformei îi sunt la fel de accesibile unui anchetator ca și ție. Desparte ce ai verificat de ce ți-a declarat cineva. Spune-i clientului că poate depune plângere la autoritatea națională de protecție a datelor.

Auditul însuși creează copii: cache-uri de răspunsuri API, transcripte, exporturi. La final se purjează dumpurile brute, dosarul de lucru se păstrează ca dovadă a unui proces corect, iar datele reale ale clienților nu intră niciodată în documentație, fiindcă pe acolo scapă.

Limite și listă de verificare

Unele lucruri un magazin nu le poate închide singur. Spațiul de stocare comun și foile de calcul pot fi declarate curate doar pentru fișierele efectiv enumerate, fiindcă un token de acces vede adesea doar fișierele create de propria aplicație. Linkurile publice semnate către facturi sau etichete pot fi invalidate doar de furnizorul care le-a emis; dacă furnizorul nu poate, documentează limitarea în loc s-o ascunzi.

1. Suprimă marketingul peste tot, la ambele capete, în aceeași oră. 2. Verifică identitatea din emailul comenzii; nu cere act. 3. Cartografiază fiecare sistem, inclusiv JSON-ul brut, tabelele de arhivă, înregistrările și indecșii orbi. 4. Întâi registrul, apoi ștergerea, doar pe chei exacte. 5. Verifică a doua zi că nu a reapărut nimic. 6. Enumeră ce se păstrează, în baza cărei legi, până când. 7. Nu scrie niciodată „am șters tot”.

Întrebări și răspunsuri

Ce trebuie să facă întâi un magazin online când un client cere ștergerea datelor?

Primul pas e oprirea oricărui marketing către acea persoană, în aceeași oră, înaintea oricărui triaj. Articolul 21 alineatul (3) din GDPR cere încetarea marketingului direct și nu beneficiază de termenul de o lună care se aplică restului cererii. Suprimă persoana în platforma de email și în consimțământul de marketing al magazinului și blochează orice unealtă de recenzii sau SMS care trimite după propriul calendar. Nu e consultanță juridică.

Poate un magazin să șteargă toate datele unui client conform GDPR?

De obicei un magazin nu poate șterge tot, fiindcă obligațiile legale de păstrare au prioritate pentru unele înregistrări. Pentru magazine din România, procedura noastră consemnează facturile păstrate 5 ani potrivit Legii 82/1991 modificate prin Legea 36/2023, o copie în sistemul național de facturare electronică pe care magazinul nu o poate șterge și garanția de conformitate, 2 ani de la livrare. Răspunsul enumeră ce se păstrează, de ce și până când. Verifică legea în vigoare.

De ce reapar datele clientului după o ștergere GDPR?

Datele șterse reapar fiindcă bazele din aval se refac din sursă prin sincronizări programate. Dacă magazinul încă ține comanda, următoarea sincronizare în depozitul de date sau în baza de expediere readuce rândurile șterse, la noi în 24 de ore. Treci cererea întâi într-un registru de ștergeri, rulează joburi care îl reaplică după fiecare sincronizare și verifică a doua zi că rândurile nu au revenit.

Trebuie să cer buletinul ca să verific o cerere GDPR de ștergere?

De obicei buletinul nu e necesar. Când cererea vine de pe aceeași adresă de email ca și comanda, iar numele sau telefonul coincid, asta e o verificare rezonabilă a identității în sensul articolului 12 alineatul (6). Copia actului de identitate strânge mai multe date decât e nevoie, ceea ce contrazice minimizarea din articolul 5 alineatul (1) litera c), și întârzie răspunsul. E practica noastră, nu consultanță juridică.

Cum evit să șterg datele altei persoane la o cerere GDPR?

Eviți ștergerea datelor altcuiva dacă scrii cheile admise, adică numerele de comandă, identificatorul clientului, emailul și telefonul, înainte de prima interogare și nu potrivești niciodată după nume. La noi, un nume de familie frecvent a întors 16 persoane diferite într-o bază și 11 în alta. Dovedește și că fiecare căutare găsește pe altcineva înainte să crezi un rezultat zero.

Toate metodele