Date reale într-un mediu de test? Ce verifici înainte de copiere

În comunicatul din 16 octombrie 2026, ANSPDCP descrie un atac asupra unui server de test. Lipsurile de securitate au permis accesul neautorizat la date personale, inclusiv nume, date de contact și identificatori din acte de identitate. Autoritatea a constatat încălcarea art. 32 alin. (1) lit. (b) și alin. (2) GDPR și a cerut operatorului respectiv o procedură de folosire exclusivă a datelor fictive în dezvoltare și testare.

Este o măsură corectivă dispusă într-un caz individual, prezentată într-un comunicat al autorității. Nu este o lege nouă și nu transformă automat orice utilizare a datelor reale pentru testare într-o încălcare. Arată însă de ce mediile de test trebuie incluse în analiza protecției datelor.

Sursă: ANSPDCP — comunicat din 16 octombrie 2026; constatări și măsură individuală.

Da, atunci când informațiile privesc persoane identificate sau identificabile. Copierea, stocarea, consultarea și modificarea lor sunt operațiuni de prelucrare. Denumirea serverului — „test”, „dezvoltare” sau „staging” — nu schimbă natura datelor.

Operatorul trebuie să poată explica scopul și temeiul prelucrării, să limiteze datele la ce este necesar și să stabilească păstrarea și măsurile de securitate. Aceste cerințe se aplică și copiilor. Protecția datelor trebuie avută în vedere când este conceput fluxul de testare, nu doar după apariția unei probleme.

Sursă: Regulamentul (UE) 2016/679 — art. 4 pct. 1–2, art. 5 alin. (1)–(2), art. 6, art. 25 și art. 32.

Dacă schimbi doar numele, dar lași adresa de e-mail, telefonul ori alte detalii care identifică persoana, nu ai obținut un set anonim. Nici eticheta „date sintetice” nu este suficientă: verifică modul în care au fost generate și ce informații despre persoane reale pot fi recuperate. Anonimizarea unui set real este ea însăși o operațiune care trebuie făcută legal și în siguranță.

Sursă: GDPR — art. 4 pct. 1 și 5; considerentul 26, pentru interpretarea identificabilității.

Sursă: CNIL — explicații despre anonimizare și pseudonimizare; material de orientare.

• Scopul concret. Ce comportament trebuie verificat: formatul unui câmp, calculul unui total, permisiunile, timpul de răspuns sau o eroare anume? „Testăm aplicația” este prea general pentru a justifica un export complet.
• Setul minim. Ce câmpuri și câte înregistrări sunt necesare? Construiește întâi date fictive pentru cazurile obișnuite, valorile-limită și erorile. Verifică și atașamentele ori câmpurile de text liber.
• Accesul. Cine poate vedea datele, din ce cont și pentru cât timp? Include dezvoltatorii, testerii, furnizorii și persoanele cu acces administrativ. Verifică efectiv restricțiile.
• Ieșirile din mediu. Un test poate trimite e-mailuri, SMS-uri sau cereri către alte aplicații. Folosește destinații controlate și verifică faptul că nu ajung mesaje ori date la destinatarii din producție.
• Furnizorii. Unde sunt găzduite datele și cine le poate accesa? Pentru prelucrări în numele companiei, verifică instrucțiunile și relația contractuală. Dacă există transferuri internaționale, acestea cer o analiză separată.
• Toate copiile. Inventariază exporturile, jurnalele, capturile de ecran, atașamentele din tichete și copiile de siguranță. Stabilește perioade justificate, cine șterge și cum verifică rezultatul, inclusiv regulile aplicabile copiilor de siguranță.
• Decizia și închiderea. Consemnează ce s-a verificat, ce rămâne neclar și cine decide continuarea. La final, păstrează dovada testului și a măsurilor luate, fără să reproduci inutil datele personale.

Aceasta este o listă practică de lucru, nu un formular impus de GDPR. Măsurile se aleg în funcție de context și risc. CNIL recomandă, în ghidul pentru dezvoltatori, evitarea reutilizării datelor reale din producție și construirea unor seturi fictive pentru dezvoltare și testare.

Sursă: GDPR — art. 5 alin. (1) lit. (b), (c), (e), (f) și alin. (2); art. 25; art. 28; art. 32; art. 44.

Sursă: CNIL — „Tester vos applications”; recomandări pentru dezvoltatori.

Scenariu fictiv: echipa verifică dacă noul import respinge înregistrările fără un câmp obligatoriu și semnalează identificatorii repetați. Pentru aceste teste nu este nevoie să afle cine sunt clienții reali.

• Construiește câteva înregistrări fictive: una completă, una fără câmpul obligatoriu, două cu același identificator și una cu un text lung, cu diacritice.
• Folosește identificatori creați pentru test și destinații de e-mail controlate. Dezactivează notificările către clienți sau direcționează-le către o căsuță de test, apoi verifică setarea printr-o probă.
• Notează rezultatul așteptat și cel observat. Un test reușit trebuie să arate ce comportament a fost verificat.
• Închide testul: șterge setul temporar conform regulii stabilite și păstrează rezultatele necesare pentru remediere și reverificare.

Exemplul este suficient pentru comportamentele descrise, nu pentru toate testele unui CRM. Un test de performanță, o migrare sau investigarea unei erori poate avea alte cerințe. Acestea se analizează separat; exemplul nu justifică importarea întregii baze de date.

Cere explicația exactă: ce eroare nu poate fi reprodusă și ce alternative au fost încercate? Apoi analizează scopul, necesitatea, temeiul juridic și protecțiile pentru operațiunea propusă. Dacă este un scop diferit de cel inițial, se verifică regulile privind prelucrarea ulterioară și informarea persoanelor, inclusiv excepțiile aplicabile. Faptul că datele există deja în companie nu rezolvă singur aceste întrebări.

Sursă: GDPR — art. 5 alin. (1) lit. (b); art. 6, inclusiv alin. (4); art. 13 alin. (3)–(4) și art. 14 alin. (4)–(5).

Datele privind sănătatea și celelalte categorii speciale necesită verificarea condițiilor suplimentare din art. 9. Dacă prelucrarea este susceptibilă să genereze un risc ridicat, se analizează obligația unei evaluări de impact înainte de prelucrare, potrivit art. 35 și regulilor aplicabile situației. O astfel de evaluare nu este obligatorie automat pentru orice test și nici nu este înlocuită de fișa de mai sus.

Sursă: GDPR — art. 9 și art. 35.

Dacă nu este clar de ce sunt necesare date personale sau cine le poate accesa, propunerea nu este încă pregătită pentru implementare. Clarifică punctele deschise cu persoanele responsabile de dezvoltare, securitate și protecția datelor. Aprobarea internă nu înlocuiește temeiul juridic și măsurile efective.

Completează câte o fișă pentru un scenariu și un mediu. Folosește descrieri ale câmpurilor și trimiteri către dovezi cu acces controlat; nu lipi în fișă baze de date, parole, acte de identitate sau exporturi cu clienți. În foaia „Exemplu completat” găsești un caz fictiv, pe care îl poți adapta.

Pentru fiecare răspuns important, notează cine l-a verificat și pe ce se bazează. La închiderea testului, consemnează rezultatul, problemele rămase și situația copiilor. Documentul ajută echipa să urmărească lucrul; nu dovedește, prin simpla completare, că măsurile funcționează.