Trebuie să șterg datele personale din copiile de siguranță?
Aflați când se șterg datele din copiile de siguranță, cum se tratează seturile protejate și cum se împiedică reintroducerea după restaurare.

Nu trebuie distrus imediat orice suport de recuperare, dar nici copiile de siguranță nu sunt în afara dreptului la ștergere. Ștergerea datelor din copiile de siguranță începe prin a decide dacă articolul 17 se aplică, a clasifica fiecare copie, a acționa fără întârzieri nejustificate și a împiedica reintroducerea datelor după restaurare 1,3.
Răspuns rapid: Ștergerea datelor din copiile de siguranță este necesară când articolul 17 o cere. Tratați mai întâi copiile active și editabile. Dacă integritatea împiedică modificarea sigură, izolați setul, documentați expirarea și interziceți utilizarea obișnuită. La restaurare, consultați registrul și reaplicați ștergerea înainte ca datele recuperate să fie eliberate 1,3.
Ultima actualizare: 24 septembrie 2026
Funcția copiei este mai importantă decât eticheta
Un backup nu este automat exceptat și nici întotdeauna editabil. Clasificați copia ca replică activă, snapshot editabil în siguranță sau set de recuperare protejat prin integritate. Mai întâi se decide temeiul și excepția juridică; abia apoi mecanica 3.
| Tip de copie | Acțiune | Dovadă |
|---|---|---|
| Sistem activ sau replică obișnuită | Ștergere ori restricționare și verificare | Căutare, acțiune și rezultat verificat |
| Backup editabil în siguranță | Modificare sau reconstruire fără compromiterea recuperării | Identificator, metodă, test și integritate confirmată |
| Set protejat prin integritate | Izolare, expirare demonstrată și control la restaurare | Izolare, eveniment de expirare, instrucțiune și verificare |
| Excepție validă a articolului 17 | Păstrarea numai a domeniului necesar | Excepție, normă, câmpuri, perioadă și responsabil |
Conectați responsabilul cererilor cu responsabilul recuperării. Primul cunoaște persoana, domeniul și răspunsul; al doilea cunoaște seturile, replicile și dependențele. Dacă evidențele lor nu sunt legate, datele pot dispărea din producție și reapărea la următoarea restaurare.
O arhivă căutabilă, un cache sau un export poate fi activ indiferent de nume. Dacă un utilizator ori proces îl consultă în activitatea normală, copia necesită o acțiune directă și nu poate fi lăsată doar rotației viitoare.
Clasificați prin întrebări observabile: cine poate monta sau interoga copia, cât de des, în ce scop și ce date pot ieși din ea? Un snapshot păstrat pentru recuperare devine operațional dacă echipa îl montează regulat pentru cereri curente. În sens invers, o imagine imuabilă, izolată de utilizarea obișnuită și cu expirare controlată, nu devine bază activă numai pentru că păstrează aceiași octeți. Înregistrați starea prezentă și evenimentele care o pot schimba, inclusiv testele de recuperare, migrarea, investigațiile și predarea către un furnizor.
Pentru un backup editabil, verificați recuperabilitatea întregului set, nu doar existența unei comenzi de ștergere. Folosiți o copie controlată, validați indexurile și manifestele, restaurați înregistrări neafectate și confirmați că procesul nu lasă o replică temporară. Dacă reconstruirea este mai sigură, documentați sursa, filtrele, validarea și eliminarea setului înlocuit. Această probă distinge o decizie reală de integritate de preferința comodă de a nu modifica nimic.
Documentați și relația cu furnizorii. Contractul trebuie să arate cine poate edita, cine aprobă restaurarea, ce notificare se trimite și ce dovadă revine operatorului. O declarație comercială despre „backup securizat” nu răspunde la aceste întrebări. Cereți descrierea funcției, izolării, rotației și destinațiilor, apoi includeți rezultatul în inventar, astfel încât cererea să nu se oprească la marginea infrastructurii interne.
Confirmați motivul înainte de inventarul tehnic
Articolul 17 se aplică pe baza unui motiv, nu doar pentru că o persoană cere ștergerea. Verificați identitatea, domeniul și identificatorii, apoi înregistrați motivul corespunzător 3:
- Datele nu mai sunt necesare scopurilor pentru care au fost colectate sau tratate.
- Consimțământul a fost retras și nu există un alt temei pentru continuarea tratamentului.
- Opoziția prevalează ori privește marketingul direct, unde efectul este specific.
- Datele au fost tratate ilegal și nu există o bază pentru continuare.
- Ștergerea este necesară pentru o obligație a Uniunii sau a unui stat membru aplicabilă operatorului.
- Datele au fost colectate pentru servicii ale societății informaționale în condițiile articolului 8 alineatul (1).
Fiecare motiv are nevoie de dovadă proprie. Pentru lipsa necesității, comparați scopul aprobat cu folosirea actuală; pentru retragere, verificați dacă există alt temei; pentru obligația legală, identificați norma concretă 3. Separați cererea persoanei de rezultatele efective ale căutării. Aceeași adresă poate conduce la un cont activ, facturi păstrate în temeiul unei reguli aplicabile, tichete fără scop actual și mai multe seturi de recuperare. Fiecare rezultat primește acțiune și justificare proprie. Cererea nu devine o comandă oarbă de distrugere, dar nici nu poate fi închisă după ștergerea contului vizibil. O concluzie generică nu explică de ce un set a fost șters, altul restricționat și altul păstrat legitim.
Construiți apoi inventarul: producție, arhive căutabile, replici, cache-uri, exporturi, snapshoturi și seturi externe aflate sub control. Notați proprietarul, căutarea posibilă, integritatea, rotația, destinația restaurării și orice beneficiar din aval.
Excepțiile se aplică numai în măsura necesară
Testați cele cinci categorii din articolul 17: libertatea de exprimare și informare; obligație legală ori sarcină publică sau autoritate oficială; sănătate publică; arhivare, cercetare sau statistică potrivit articolului 89 când ștergerea ar împiedica ori prejudicia grav obiectivele; și pretenții juridice 3.
| Excepție | Dovadă necesară | Rezultat limitat |
|---|---|---|
| Exprimare și informare | Activitate, drept și test de necesitate | Păstrarea strictă pentru exercitarea dreptului |
| Obligație legală sau sarcină publică | Norma, datele, perioada și responsabilul | Numai domeniul impus de norma aplicabilă |
| Sănătate publică | Temei și măsuri de protecție | Date și perioadă limitate la necesitate |
| Arhivare, cercetare sau statistică | Condițiile articolului 89 și prejudiciul demonstrat | Garanții și domeniu limitat proiectului |
| Pretenții juridice | Litigiu ori necesitate juridică identificabilă | Setul probator strict necesar |
O excepție nu transformă întreaga bază într-un bloc de „păstrare legală”. Pentru articolul 17 alineatul (3) litera (b), identificați norma reală a Uniunii sau statului membru, datele acoperite și proprietarul. Nu inventați o perioadă europeană comună pentru backupuri.
Dacă numai unele câmpuri sunt necesare, separați-le sau restricționați-le când este posibil. Documentați de ce restul a fost șters. O dificultate tehnică de separare necesită o decizie justificată; nu extinde singură excepția.
Aplicați necesitatea la nivelul cel mai îngust. Obligația de a păstra o factură nu justifică preferințe de marketing, note de suport și copii de identificare legate aceleiași persoane. Un litigiu poate cere anumite mesaje, nu istoricul complet. Înregistrați câmpurile, intervalul, accesul și evenimentul de eliberare. Când o copie amestecă date exceptate și neexceptate, explicați dacă separarea imediată este sigură și ce controale împiedică folosirea datelor păstrate pentru un alt scop.
Revizuiți excepțiile pe durata păstrării. Litigiul se poate încheia, norma poate înceta să ceară documentul, iar proiectul poate ajunge la obiectiv. Legați decizia de o dată sau de un eveniment și desemnați proprietarul. Fără această legătură, o excepție corectă la început devine retenție nedeterminată. Revizuirea poate actualiza registrul care guvernează accesul, expirarea și restaurarea fără a modifica setul protejat înainte ca acest lucru să fie sigur.
Separați și comunicarea către persoană de detaliile tehnice interne. Răspunsul trebuie să explice acțiunea și limita relevantă fără a divulga arhitectura ori măsuri care ar slăbi securitatea. Evidența internă păstrează însă seturile, proprietarii și verificările precise. Această diferență nu este o scuză pentru răspuns vag; este o împărțire controlată între explicația utilă persoanei și dovada completă necesară operatorului.
Copiile active cer o închidere verificată
Producția, arhiva căutabilă, replica obișnuită, cache-ul și exportul de lucru pot fi active, astfel că definiți câmpurile, ștergeți ori restricționați, verificați absența și abordați destinatarii, fără a transforma expresia „fără întârzieri nejustificate” într-un termen tehnic universal inventat 3.
Evidența finalizării include cheia cererii, domeniul, sistemele, metoda de căutare, acțiunile, excepțiile, destinatarii, responsabilul, data și verificarea independentă, iar o căutare eșuată sau o acțiune parțială rămâne deschisă, deoarece trimiterea unui tichet nu dovedește ștergerea.
Verificați efectele laterale, fiindcă indexul poate păstra o valoare eliminată din baza principală, exportul poate alimenta alt sistem, iar furnizorul poate menține o replică; închiderea este justificată numai când aceste trasee au fost examinate și rezultatele sunt legate de cerere.
Un calendar intern ajută la coordonare, dar nu schimbă standardul juridic, așadar explicați dependențele reale, începeți prompt și păstrați persoana informată când este necesar.
Responsabilul cererii compară domeniul decis cu rezultatele fiecărui sistem și separă absența confirmată de o eroare de căutare, astfel încât o verificare nereproductibilă să nu fie raportată drept succes. Dacă o valoare reapare într-un index, într-un export sau la furnizor, redeschideți ruta afectată, păstrați dovezile acțiunilor deja confirmate și repetați verificarea până la capăt.
Integritatea trebuie completată de controlul restaurării
Un set imuabil poate pierde garanția de integritate dacă este modificat. Raportul EDPB recunoaște această preocupare și răspunsul practic de a urmări cererile și a le reaplica după restaurare 1.
| Câmp al registrului | Conținut operațional |
|---|---|
| Cheia cererii | Referință minimă care nu expune date în plus |
| Identificatori de potrivire | Valorile și variantele necesare căutării după restaurare |
| Set de backup | Nume, interval, locație și proprietar al recuperării |
| Decizie de integritate | Motivul pentru care editarea nu este sigură și testul aferent |
| Controlul utilizării | Izolare, acces limitat și interdicția folosirii obișnuite |
| Eveniment de expirare | Dată sau condiție și dovada finalizării ulterioare |
| Acțiune la restaurare | Căutare, reaplicare, excepții și ordinea operațiunilor |
| Verificare | Rezultat și aprobarea responsabililor cererii și recuperării |
Izolarea trebuie să fie reală: fără montări de rutină, analize, exporturi sau recuperări pentru scopuri obișnuite. Minimizați identificatorii și accesul la registru; altfel, procedura creează un nou set de date cu risc propriu.
Expirarea planificată nu este expirare demonstrată. Păstrați dovada că setul și replicile dependente au ieșit din rotație. Când seturile noi le înlocuiesc pe cele vechi, verificați că datele deja șterse nu au fost introduse din nou.
Registrul trebuie să fie disponibil când mediul principal nu este. Păstrați-l într-o locație rezilientă, cu versiune și acces controlat, fără a depinde numai de setul care urmează să fie restaurat. Definiți cine poate autoriza consultarea și cum sunt protejați identificatorii în timpul incidentului. O listă prea bogată devine ea însăși risc; una prea săracă nu găsește datele. Folosiți cheia minimă suficientă și o procedură pentru ambiguități.
Testați trecerea dintre echipe și furnizori. Prestatorul poate restaura infrastructura înainte ca responsabilul cererii să afle, ori poate transmite imaginea către alt serviciu care creează replici. Ghidul și contractul cer notificare, izolare și confirmare înainte de eliberare. Notați proprietarul fiecărei etape, dovada furnizată și răspunsul când verificarea nu poate fi finalizată în fereastra tehnică. Mediul rămâne controlat; nu se presupune că ștergerea anterioară a supraviețuit.
Folosiți un registru de excepții separat logic de registrul ștergerilor, dar legat prin cheia cererii. La restaurare, o potrivire pozitivă poate cere ștergerea unor câmpuri și restricționarea altora. Instrucțiunea trebuie să poarte ambele rezultate fără a transforma excepția într-o restaurare completă. Verificarea finală arată ce a fost eliminat, ce a rămas, în baza cărei decizii și ce eveniment va declanșa o nouă revizuire.
Rotația automată nu este o procedură completă
Acțiunea coordonată a consemnat preocupări în rândul unei jumătăți dintre autoritățile respondente și anumite slăbiciuni, însă aceste constatări descriu răspunsurile din exercițiu, nu prevalența practicilor între toate organizațiile 1,2.
Secvența specifică cererii leagă motivul, excepțiile, copiile active, seturile nominalizate, integritatea, expirarea și instrucțiunea de restaurare, iar rotația poate contribui fără a arăta singură că persoana a fost găsită ori că o restaurare nu va inversa rezultatul.
Intervalele lungi cer o evaluare bazată pe izolarea reală, nevoia de recuperare și posibilitatea reaplicării, deoarece raportul nu oferă un maxim universal, iar o preferință tehnică nu trebuie prezentată drept termen legal.
Separați „programat să expire” de „expirare verificată”, iar dacă suportul nu iese din rotație ori o replică persistă, cererea rămâne deschisă, cu responsabil și o nouă verificare.
Evaluarea leagă fiecare set nominalizat de cerere, compară durata planificată cu posibilitatea folosirii obișnuite și identifică măsura care menține datele indisponibile până la evenimentul de expirare; dacă izolarea eșuează, copia revine în categoria activă și cere o acțiune directă, nu o nouă promisiune de rotație. Dacă reaplicarea după restaurare nu a fost demonstrată, responsabilul menține deschisă dependența și programează un test înainte ca mediul recuperat să poată fi eliberat, iar dovada expirării numește setul, evenimentul observat, replicile dependente și persoana care a verificat rezultatul, astfel încât alt evaluator să poată repeta controlul. O copie succesoare care a moștenit datele redeschide cererea pentru acea rută, fără a șterge deciziile juridice și acțiunile active deja documentate.
Cifrele acțiunii arată exercițiul, nu întreaga piață
Au participat 32 de autorități de supraveghere, dintre care 9 au deschis investigații formale și 23 au desfășurat activități de constatare, fiind contactați 7 943 de operatori și primite 764 de răspunsuri 1; cifrele descriu exercițiul, nu o rată universală de conformitate.
Au reapărut lacune legate de proceduri, calendare și excluderi nejustificate 1,2, deoarece excluderea tuturor backupurilor poate ascunde o replică activă, un calendar fără căutare poate rata persoana, iar o procedură fără restaurare poate inversa o ștergere corectă.
Pentru o organizație mică pot fi suficiente un registru al cererii, un inventar al copiilor și un ghid de restaurare, simplitatea fiind utilă dacă fiecare decizie, responsabil și dovadă rămâne vizibilă și repetabilă.
Testați un caz pozitiv și unul fără potrivire: primul dovedește că mecanismul găsește și tratează datele, iar al doilea că rezultatul negativ provine dintr-o căutare reală, nu din lipsa verificării.
Folosiți aceeași cheie pentru a lega decizia, seturile și rezultatul exercițiului, astfel încât predarea între responsabilul cererii, echipa de recuperare și furnizor să nu rupă traseul probator. Dacă unul dintre ei nu poate reproduce căutarea sau identifica versiunea ghidului, cazul rămâne deschis până când procedura este clarificată și testată din nou.
Exercițiul de restaurare blochează reintroducerea
Mediul restaurat rămâne izolat până când controlul ștergerilor este verificat. Urmați opt pași în ordine:
- Identificați snapshotul, sistemele acoperite și ora exactă a punctului restaurat.
- Restricționați accesul și împiedicați mediul să trimită date sau să alimenteze producția.
- Consultați registrul folosind numai identificatorii autorizați pentru potrivire.
- Reaplicați fiecare potrivire pozitivă înainte de utilizarea obișnuită a mediului.
- Separați datele păstrate prin excepție și mențineți scopul și accesul limitate.
- Verificați replicile din aval, cache-urile, indexurile și exporturile produse la restaurare.
- Înregistrați potrivirile, absențele confirmate, acțiunile, erorile și verificările.
- Eliberați mediul numai după semnătura responsabililor cererii și recuperării.
| Scenariu | Rezultat așteptat | Dovadă |
|---|---|---|
| Înregistrare de test cu potrivire | Cererea este găsită și reaplicată | Interogare, acțiune și verificare documentate |
| Înregistrare fără potrivire | Căutarea se încheie fără afectarea altor date | Parametri și rezultat negativ păstrate |
| Replică sau cache din aval | Nicio copie derivată nu scapă acțiunii | Inventar și rezultate pe destinație |
| Eșec al unei etape | Mediul rămâne izolat, iar etapa se repetă | Incident, proprietar, remediere și test nou |
Folosiți date controlate pentru mecanism și testați și o cale autentică fără potrivire. Dacă o etapă eșuează, nu eliberați mediul pentru a respecta fereastra de recuperare. Atribuiți un responsabil și repetați controlul.
Actualizați ghidul când se schimbă identificatorii, formatele sau destinațiile. O instrucțiune care caută numai e-mailul poate rata un identificator de client ori o adresă modificată.
Includeți o schimbare deliberată de identificator în exercițiu. Folosiți o înregistrare de test în care adresa s-a schimbat, dar cheia internă a rămas, și confirmați că relația este găsită. Apoi testați un nume sau o valoare similară pentru a demonstra că procesul nu șterge datele altei persoane. Regulile de potrivire trebuie să echilibreze acoperirea și precizia, cu revizuire umană pentru rezultate ambigue; căutarea prea îngustă lasă date, iar cea indiscriminată creează un incident nou.
Măsurați durata etapelor fără a o prezenta drept termen juridic. Măsurarea arată dacă fereastra de recuperare permite consultarea registrului, reaplicarea și verificarea replicilor înainte de eliberare. Dacă nu, modificați arhitectura, secvența sau fereastra planificată. Înregistrați dependențele care au întârziat testul și atribuiți îmbunătățiri. Un exercițiu oprit doar fiindcă timpul a expirat demonstrează fragilitatea procesului, nu finalizarea lui.
După test, comparați mediul cu inventarul anterior și verificați că nicio exportare temporară nu a rămas în afara izolării. Ștergeți datele de test conform scopului și păstrați numai dovada necesară. Raportul distinge potriviri pozitive, absențe reale, excepții menținute și eșecuri. Astfel, următoarea echipă poate reproduce procedura fără să depindă de memoria participanților.
Repetați etapele care au eșuat cu aceiași proprietari și cu criteriul de reușită scris înainte de noul test. O remediere tehnică poate muta problema către un cache, o integrare sau o permisiune; de aceea, recitiți secțiunea reparată împreună cu pașii anterior și următor și parcurgeți din nou traseul complet. Abia verificarea de ansamblu justifică eliberarea mediului.
Închiderea unește legea, copiile și recuperarea
Dosarul final reunește motivul, excepțiile, acțiunile active, seturile de backup, deciziile de integritate, expirarea și controalele de restaurare, iar munca fără dovadă și testele eșuate rămân deschise 3.
Înainte de alegerea stării, responsabilul parcurge lanțul în ordinea executării, verifică dacă fiecare referință conduce la o dovadă disponibilă și compară domeniul cercetat cu cererea decisă; absența confirmată este consemnată distinct de lipsa unui rezultat, deoarece numai prima arată că metoda a rulat complet și nu a găsit date. O legătură lipsă menține deschisă partea afectată și împiedică raportarea întregului dosar drept finalizat, fără a invalida acțiunile independente care au fost deja demonstrate.
Folosiți trei stări:
- Închidere: toate acțiunile și verificările aplicabile sunt demonstrate.
- Suspendare: o excepție, dependență sau decizie legitimă este încă analizată și controlată.
- Redeschidere: apare o copie, eșuează o verificare sau restaurarea cere reaplicarea solicitării.
Decizia completă are trei părți: articolul 17 stabilește domeniul juridic, funcția și integritatea copiei stabilesc implementarea, iar registrul și ghidul împiedică restaurarea să inverseze discret rezultatul 3. Asociați fiecare parte cu proprietarul și ultima verificare pozitivă, inclusiv rezultatul reproductibil fără potrivire, apoi confirmați că răspunsul către persoană corespunde stării interne; dacă apare un set nou, expiră o excepție ori eșuează un test, redeschideți punctul concret prin aceeași cheie, conservați dovada anterioară și repetați verificările dependente. Închiderea devine astfel o decizie care poate fi reprodusă și revizuită, nu o etichetă administrativă care ascunde o copie sau o acțiune neterminată.
Întrebări frecvente
Trebuie șterse imediat toate copiile de siguranță?
Copiile de siguranță sunt exceptate automat de la ștergere?
Ce motive pot activa dreptul prevăzut la articolul 17?
O obligație legală de păstrare permite reținerea tuturor datelor?
Este suficientă rotația automată a backupurilor?
Ce se întâmplă când este restaurată o copie?
Surse
Vreți să rulăm asta pe afacerea dumneavoastră?
AI Foundation Audit — o evaluare structurată a amprentei dumneavoastră de IA: riscuri de integrare, lacune de guvernanță, oportunități de ROI. Livrată ca un raport cuprinzător pe care puteți acționa.
Primiți AI Opportunity Report și Implementation Brief — adaptate afacerii dumneavoastră și livrate imediat.