Cât timp păstrați datele personale?

Întrebarea „cât timp păstrați datele personale?” nu se rezolvă printr-un număr copiat peste toate sistemele. O firmă are nevoie de o regulă pentru fiecare scop, de obligații legale verificate în statul membru aplicabil, de un eveniment de început observabil și de o acțiune finală testată. Altfel, termenul din registru nu schimbă nimic în aplicații.

Răspuns rapid

Ca să decideți cât timp păstrați datele personale, legați fiecare categorie de un scop activ și de orice obligație legală verificată. Notați evenimentul care pornește perioada, acțiunea finală și excepțiile controlate. GDPR nu oferă un termen universal; programul trebuie justificat, executat în sisteme și retestat pe dovezi.

Ultima actualizare: 28 august 2026

Porniți de la o înregistrare, nu de la o listă de ani

Principiul limitării stocării cere ca datele personale să fie păstrate într-o formă identificabilă numai atât timp cât este necesar scopului ¹. Comisia Europeană și EDPB explică necesitatea unei justificări, a revizuirii și a ștergerii ori anonimizării când datele nu mai sunt necesare ^2,3. Niciuna dintre aceste cerințe nu produce singură o durată identică pentru toate procesele.

Luați un caz real și urmăriți-l de la colectare la ieșire. Pentru o comandă, identificați clientul, documentele contabile, conversațiile de suport, preferința de marketing și jurnalul de securitate; ele pot porni din același formular, dar servesc scopuri diferite, au utilizatori diferiți și nu trebuie să primească aceeași regulă doar fiindcă împart un identificator.

Perioada trebuie să poată fi calculată de persoana care configurează sistemul. „Cât timp este necesar” descrie principiul, nu o instrucțiune executabilă, iar „șase ani” fără eveniment de început poate produce date scadente diferit în două aplicații. Formula operațională combină obiectul, evenimentul, durata ori criteriul, acțiunea și excepția.

Dreptul intern furnizează unele perioade reale

GDPR stabilește principiul, nu un catalog european de durate. Perioadele pentru evidențe fiscale, societare, de muncă, salarizare și pentru activități sectoriale se verifică în dreptul statului membru aplicabil. Un număr preluat din altă jurisdicție poate porni de la alt eveniment, poate privi alt document și poate avea excepții pe care sistemul nu le cunoaște ^1,2.

Responsabilul nu notează doar durata găsită. Fișa păstrează articolul ori regula, data verificării, cui i se aplică, documentul acoperit, evenimentul de început, condițiile de prelungire și acțiunea finală. În acest fel, persoana care configurează ștergerea poate calcula aceeași dată ca persoana care a citit norma.

Nu amestecați categoriile. O obligație pentru factură nu justifică păstrarea istoricului de navigare al clientului, iar o regulă salarială nu păstrează automat mesajele, evaluările și copiile locale din toate departamentele. Fiecare utilizare ulterioară are propriul scop, acces și termen justificat.

În România, Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP) este autoritatea competentă de contact pentru protecția datelor. Duratele fiscale, societare, de muncă, salarizare și sectoriale trebuie totuși rezolvate din dreptul material aplicabil, nu deduse din simpla existență a autorității de supraveghere.

Construiți programul pe scopuri și evenimente

După separarea obligațiilor verificate, celelalte perioade se justifică prin necesitate, nu prin analogie cu numerele fiscale. Echipa descrie rezultatul pentru care persoana trebuie să rămână identificabilă, faptele care arată cât timp acel rezultat este activ și momentul în care o formă agregată ori anonimizată ar satisface nevoia ulterioară cu mai puțin risc.

Pentru fiecare înregistrare, definiți mai întâi categoria și scopul și verificați sursa necesității ². Apoi stabiliți un declanșator calculabil, perioada, excepțiile controlate și acțiunea finală. Aplicați acțiunea tuturor copiilor reale și verificați rezultatul.

Fișa de justificare compară utilizarea observată cu impactul păstrării. Notați cine consultă datele și pentru ce decizie, frecvența reală, consecința dacă înregistrarea nu mai este disponibilă, sensibilitatea, numărul persoanelor, accesul și posibilitatea de a reduce identificatorii; costul redus al stocării ori dorința nedefinită de analiză nu sunt argumente pentru necesitate, în timp ce un proces activ și demonstrabil poate susține o perioadă proporționată.

Testați o alternativă mai puțin intruzivă înainte de concluzie. Dacă tendința comercială poate fi măsurată din totaluri, dacă un litigiu poate folosi numai documentele delimitate ori dacă suportul poate păstra rezultatul fără conversația completă, descrieți de ce alternativa este suficientă sau de ce pierde un fapt necesar; acest pas face durata reanalizabilă când tehnologia ori procesul se schimbă.

Nu inventați totuși o perioadă doar pentru că registrul are nevoie de o celulă. Dacă nu există încă dovezi pentru un număr stabil, folosiți un criteriu de revizuire apropiat, un proprietar și o întrebare precisă, apoi observați ciclul procesului; starea provizorie este mai onestă decât o certitudine falsă, dar trebuie să aibă o dată la care devine decizie și să nu permită acumularea nelimitată între timp.

Separați și copiile. Înregistrarea principală, exportul unui coleg, atașamentul dintr-un tichet și copia furnizorului pot conține aceleași date, însă regula trebuie să ajungă la toate, iar dovada explică decalajul controlat al copiilor de siguranță, imposibilitatea folosirii lor curente și suprascrierea conform traseului documentat.

Testați calculul pe exemple complete

Un program devine credibil când altcineva poate calcula aceeași dată din aceeași sursă. Luați o obligație verificată din statul membru aplicabil și construiți patru cazuri: eveniment obișnuit, înregistrare exact la limită, eveniment înregistrat târziu și excepție activă. Nu publicați durata în sistem până când fiecare ramură poate fi reprodusă.

Lucrați apoi un client pe scopuri. Comanda poate genera o factură acoperită de o obligație legală, un tichet de suport păstrat cât este necesar cazului, o preferință de marketing care execută alegerea persoanei și un jurnal de securitate cu propria justificare. Identificatorul comun nu le acordă termenul maxim; fiecare linie are sursa, declanșatorul, acțiunea și excepția sa.

Pentru regula bazată pe drept intern, verificați ce dată cunoaște sistemul. Dacă norma pornește de la închiderea unei perioade, aplicația nu poate folosi comod data exportului. Dacă o depunere târzie ori un control schimbă durata, ramura trebuie alimentată de evenimentul real și închisă de un proprietar, nu de o presupunere calendaristică.

Pentru regula bazată pe necesitate, testați și concluzia negativă. Dacă suportul s-a închis, nu există obligație ori litigiu, iar rezultatul ulterior poate fi păstrat anonimizat, echipa trebuie să poată executa ieșirea fără să mențină conversația completă. O nevoie nouă se analizează înainte de folosire și nu prelungește retrospectiv regula veche.

Eșantionul trebuie să dezvăluie rotunjirea la sfârșit de lună, fusul orar greșit, evenimentele lipsă și copiile care nu primesc starea. Testul se încheie numai când data și acțiunea observate corespund fișei, iar o eroare produce o constatare cu proprietar și retestare.

Faceți ștergerea observabilă în fiecare sistem

„Șters” poate însemna lucruri diferite: ascuns din interfață, marcat inactiv, mutat într-o arhivă, eliminat din sistemul principal sau suprascris și în copiile controlate. Programul definește rezultatul acceptat pentru fiecare depozit și persoana care îl verifică, astfel încât un buton de dezactivare să nu fie tratat automat ca eliminare.

Inventariați aplicațiile, folderele partajate, e-mailul, dispozitivele, exporturile și furnizorii. O regulă centrală care curăță baza de clienți nu ajunge la foile descărcate de echipa de vânzări, iar un contract care promite ștergerea nu arată dacă administratorul a activat configurația necesară.

Anonimizarea este o ieșire numai dacă reidentificarea nu mai este rezonabil posibilă în context. Eliminarea numelui, păstrând un identificator stabil și o cheie accesibilă, este pseudonimizare și lasă datele personale în domeniu; testul caută combinațiile, copiile, cheile și persoanele care ar putea reconstrui identitatea.

Păstrați o dovadă proporționată a execuției: numărul de înregistrări scadente, regula și versiunea ei, sistemele atinse, erorile, excepțiile și confirmarea rezultatului. Dovada nu trebuie să reproducă tocmai datele pe care procesul trebuia să le elimine.

Copiile de siguranță cer un traseu propriu. Dacă ștergerea individuală nu este fezabilă în copia izolată, documentați ciclul de suprascriere, împiedicați folosirea ei ca arhivă de lucru și asigurați-vă că o restaurare reaplică regulile și stările de ștergere înainte ca datele să redevină accesibile utilizatorilor; altfel, un incident tehnic poate reactiva în masă înregistrări expirate.

Propagați ieșirea către integrări prin identificatori și confirmări controlate. O cerere trimisă furnizorului fără răspuns, o coadă de sincronizare eșuată sau un export păstrat pe dispozitiv rămân constatări deschise, iar proprietarul nu declară finalizarea până când dovada acoperă fiecare destinație ori explică restricția temporară și următorul test.

Folosiți suspendări înguste, nu arhive permanente

Un litigiu, o investigație sau o altă obligație documentată poate cere suspendarea acțiunii normale pentru anumite materiale. Marcați exact persoanele, categoriile, intervalul și sistemele acoperite, autoritatea deciziei, proprietarul și condiția de încetare; formula „păstrați tot până la noi instrucțiuni” extinde riscul și face imposibilă revenirea controlată.

Restrângeți folosirea datelor aflate sub suspendare. Faptul că ele nu pot fi șterse pentru moment nu le transformă într-o resursă pentru analiză, marketing ori alte scopuri, iar accesul trebuie limitat la cei care gestionează motivul suspendării și securitatea materialului.

Revizuiți suspendarea la evenimente și intervale definite. Când motivul se încheie, scoateți marcajul, recalculați regula normală și executați imediat acțiunea dacă data ar fi trecut; nu porniți o perioadă nouă doar fiindcă dosarul a fost eliberat târziu.

Legați regulile de declanșatori de schimbare

Programul nu rămâne corect prin inerție. Un produs nou, un câmp nou, o integrare, o schimbare fiscală, un scop secundar sau un furnizor nou poate modifica categoria, evenimentul ori capacitatea de ștergere, iar proprietarul schimbării trebuie să consulte linia relevantă înainte de lansare.

Folosiți declanșatori pe care echipele îi pot recunoaște: închiderea unui contract, finalizarea unei declarații, schimbarea statutului unui caz, încetarea unei suspendări, dezactivarea unui cont și terminarea unui serviciu furnizat. O dată calendaristică de revizuire rămâne utilă pentru control, dar nu trebuie să fie singura cale prin care programul află că scopul s-a încheiat.

Achizițiile includ capacitatea de export, ștergere și returnare în evaluarea furnizorului. Produsul păstrează evenimentele de început. Finanțele validează regulile pentru evidențele acoperite de obligațiile verificate. Proprietarul confidențialității verifică necesitatea, iar securitatea se asigură că jurnalele și copiile nu devin căi ocolitoare.

Când un scop se schimbă, nu prelungiți în tăcere termenul vechi. Descrieți noul rezultat, verificați compatibilitatea, temeiul, transparența și minimizarea, apoi decideți o regulă proprie; disponibilitatea istorică a datelor nu dovedește că noua folosire este necesară sau permisă.

Conectați fiecare declanșator la un câmp observabil și la o sarcină. Închiderea contractului, depunerea, plecarea, schimbarea statutului sau terminarea suportului trebuie să ajungă din sistemul care cunoaște evenimentul la motorul ori persoana care calculează acțiunea, cu jurnal pentru erori; o regulă precisă pe hârtie nu funcționează dacă data rămâne într-un e-mail sau dacă integrarea nu transmite actualizarea.

Testați evenimentele lipsă și corectate. Un cont poate fi închis și redeschis, o depunere poate fi înregistrată târziu, iar o comandă poate primi o contestație după finalizare, astfel încât procesul definește care fapt schimbă calculul, cum se păstrează istoricul și cine aprobă excepția, fără să reseteze termenul pentru orice editare administrativă.

O suspendare poate fi eliberată parțial când evenimentul se schimbă. Dacă investigația mai privește o singură tranzacție și două persoane, celelalte înregistrări nu rămân blocate din comoditate; proprietarul actualizează domeniul, păstrează motivul pentru materialul rămas și trimite restul către regula normală, cu o dovadă a selecției care evită atât ștergerea probelor, cât și conservarea excesivă.

Conflictele dintre declanșatori se escaladează pe fapte. Echipa care solicită suspendarea precizează întrebarea și materialul necesar, iar proprietarul programului arată ce date ar fi scadente și ce risc suplimentar creează păstrarea, astfel încât decidentul să aleagă domeniul minim și protecțiile; eticheta „legal” nu înlocuiește delimitarea, proprietarul și condiția de încetare.

Coordonați păstrarea cu drepturile persoanei

Un program de ștergere și o solicitare a persoanei pot ajunge la aceeași înregistrare. Sistemul trebuie să poată opri o acțiune automată suficient pentru a răspunde corect unei cereri în curs, fără să transforme oprirea într-o păstrare generală, și să reia regula după închiderea controlată a cazului.

Același client poate apărea în mai multe ramuri fără ca termenul cel mai lung să se extindă asupra tuturor datelor sale. Documentul contabil acoperit de o obligație verificată rămâne separat de conversația de marketing, nota internă și preferințele de interfață, iar cheia comună trebuie să permită păstrarea materialului necesar fără a menține profilul operațional complet; dreptul persoanei este aplicat pe fiecare scop și rezultat.

Când două scopuri legitime acoperă aceeași înregistrare, registrul le arată distinct și definește ce se întâmplă la încetarea primului. Datele nu primesc pur și simplu termenul maxim într-o singură coloană, deoarece o folosire poate trebui oprită înaintea celeilalte; sistemul aplică restricția de scop și acces până când ultima justificare reală se încheie, apoi execută ieșirea convenită.

Dreptul de acces nu cere recrearea datelor șterse legitim înainte de solicitare. În același timp, firma nu trebuie să accelereze sau să ascundă ștergerea ca să evite răspunsul la o cerere cunoscută; cronologia arată când a fost primită solicitarea, ce date existau atunci și ce regulă ori suspendare s-a aplicat.

Rectificarea trebuie să ajungă la copiile care rămân active, iar restricționarea cere o stare pe care aplicațiile o pot respecta. Dacă datele sunt ținute pentru o obligație verificată, explicați persoanei de ce nu sunt șterse imediat și limitați folosirile care nu mai au justificare, fără să promiteți un rezultat pe care sistemul nu îl poate executa.

Evidența deciziei păstrează motivul și rezultatul, nu un duplicat complet al conținutului cererii. Astfel, firma poate demonstra cum a coordonat dreptul cu programul fără să creeze un nou depozit permanent din documentele folosite pentru răspuns.

Revizuiți programul prin eșantion și dovadă

Revizuirea pornește din registru, dar se termină în sisteme. Alegeți linii cu risc și volum diferit, calculați datele scadente din evenimentele reale, cereți dovada acțiunii și urmăriți o excepție până la închidere; diferența dintre regulă și rezultat este o problemă de control, chiar dacă foaia arată complet.

Înregistrați rata erorilor și cauza: eveniment lipsă, regulă nepublicată, acces insuficient, integrare neacoperită sau furnizor care nu poate executa cererea. Remedierea primește proprietar, termen și un nou eșantion, fiindcă închiderea unui tichet fără retestare nu arată că datele următoare vor fi tratate corect.

Raportați conducerii excepțiile deschise, volumele trecute de termen și sistemele fără capacitate de ștergere, nu doar procentul de linii documentate. Aceste informații permit prioritizarea riscului real și împiedică o politică elegantă să mascheze depozite necontrolate.

Revizuirea trebuie să includă și date istorice migrate înaintea regulii curente. Dacă lipsesc evenimentele de început, echipa nu atribuie date convenabile în bloc, ci identifică surse alternative, grupează numai cazurile cu aceeași justificare și tratează necunoscutele după o decizie de risc documentată; proiectul de curățare are etape, proprietari și o măsură a volumului care rămâne nerezolvat.

Comparați rezultatele între cicluri. Scăderea excepțiilor expirate și a erorilor de furnizor poate arăta că remedierea funcționează, în timp ce o rată perfectă obținută prin excluderea sistemelor dificile este un semnal de acoperire slabă; indicatorul păstrează numitorul, regulile selectate și motivele pentru care un depozit nu a putut fi testat.

Fișa finală leagă categoria, scopul, sursa, persoanele, evenimentul de început, regula, acțiunea, sistemele, copiile, furnizorii, excepțiile și proprietarul. Orice durată provenită dintr-o obligație include condițiile și citarea, iar orice durată bazată pe necesitate include faptele și alternativa analizată.

Publicați regula către echipele care creează date și configurațiile care o execută. O perioadă schimbată în registru trebuie să ajungă la automatizare, procedura manuală și contractul relevant, cu o dată efectivă și un plan pentru înregistrările existente; altfel, două generații de date vor urma reguli diferite fără justificare.

Concluzia poate fi mai scurtă decât perioada cerută de un departament. Costul stocării, interesul analitic vag și ideea că informația „ar putea fi utilă” nu demonstrează necesitatea, iar o obligație pentru evidențe contabile nu justifică păstrarea profilului complet al clientului.

Un program bun răspunde fără slogan: ce date, pentru ce scop, până la ce eveniment și criteriu, în ce sisteme, cu ce excepție și cu ce dovadă finală. Logica deciziei este material echivalentă în UE și în Regatul Unit: scopul, necesitatea, declanșatorul, excepția și dovada rămân centrale, dar dreptul intern care furnizează duratele de sprijin se verifică în jurisdicția aplicabilă. Această disciplină transformă întrebarea „cât timp păstrați datele personale?” dintr-o coloană statică într-un control repetabil, aliniat principiului limitării stocării și obligațiilor efectiv verificate.