Treceți la conținut

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.

Un carusel izometric de copii de siguranță transportă un marcaj de ștergere către o poartă de verificare a restaurării, înainte ca datele recuperate să ajungă la replicile din aval
De AI Priority Map Editorial

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 copieAcțiuneDovadă
Sistem activ sau replică obișnuităȘtergere ori restricționare și verificareCăutare, acțiune și rezultat verificat
Backup editabil în siguranțăModificare sau reconstruire fără compromiterea recuperăriiIdentificator, metodă, test și integritate confirmată
Set protejat prin integritateIzolare, expirare demonstrată și control la restaurareIzolare, eveniment de expirare, instrucțiune și verificare
Excepție validă a articolului 17Păstrarea numai a domeniului necesarExcepț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țieDovadă necesarăRezultat limitat
Exprimare și informareActivitate, drept și test de necesitatePăstrarea strictă pentru exercitarea dreptului
Obligație legală sau sarcină publicăNorma, datele, perioada și responsabilulNumai domeniul impus de norma aplicabilă
Sănătate publicăTemei și măsuri de protecțieDate și perioadă limitate la necesitate
Arhivare, cercetare sau statisticăCondițiile articolului 89 și prejudiciul demonstratGaranții și domeniu limitat proiectului
Pretenții juridiceLitigiu 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 registruluiConținut operațional
Cheia cereriiReferință minimă care nu expune date în plus
Identificatori de potrivireValorile și variantele necesare căutării după restaurare
Set de backupNume, interval, locație și proprietar al recuperării
Decizie de integritateMotivul pentru care editarea nu este sigură și testul aferent
Controlul utilizăriiIzolare, acces limitat și interdicția folosirii obișnuite
Eveniment de expirareDată sau condiție și dovada finalizării ulterioare
Acțiune la restaurareCăutare, reaplicare, excepții și ordinea operațiunilor
VerificareRezultat ș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:

  1. Identificați snapshotul, sistemele acoperite și ora exactă a punctului restaurat.
  2. Restricționați accesul și împiedicați mediul să trimită date sau să alimenteze producția.
  3. Consultați registrul folosind numai identificatorii autorizați pentru potrivire.
  4. Reaplicați fiecare potrivire pozitivă înainte de utilizarea obișnuită a mediului.
  5. Separați datele păstrate prin excepție și mențineți scopul și accesul limitate.
  6. Verificați replicile din aval, cache-urile, indexurile și exporturile produse la restaurare.
  7. Înregistrați potrivirile, absențele confirmate, acțiunile, erorile și verificările.
  8. Eliberați mediul numai după semnătura responsabililor cererii și recuperării.
ScenariuRezultat așteptatDovadă
Înregistrare de test cu potrivireCererea este găsită și reaplicatăInterogare, acțiune și verificare documentate
Înregistrare fără potrivireCăutarea se încheie fără afectarea altor dateParametri și rezultat negativ păstrate
Replică sau cache din avalNicio copie derivată nu scapă acțiuniiInventar și rezultate pe destinație
Eșec al unei etapeMediul 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ță?
Nu în orice situație. Confirmați mai întâi dacă articolul 17 impune ștergerea și dacă există o excepție. Apoi clasificați fiecare copie. Replicile active și backupurile editabile se tratează fără întârzieri nejustificate; un set a cărui integritate împiedică editarea sigură poate necesita izolare, expirare demonstrată și o instrucțiune obligatorie de reaplicare după restaurare.
Copiile de siguranță sunt exceptate automat de la ștergere?
Nu. Denumirea de backup nu creează o excepție. O copie căutabilă, o replică obișnuită sau un export de lucru poate fi activ. Chiar și un set protejat prin integritate are nevoie de controale care opresc folosirea obișnuită și reintroducerea ulterioară. Decizia depinde de temei, excepții, funcția copiei și dovada disponibilă.
Ce motive pot activa dreptul prevăzut la articolul 17?
Motivele includ lipsa necesității, retragerea consimțământului fără alt temei, o opoziție admisă, tratamentul ilegal, o obligație legală de ștergere și anumite date colectate pentru servicii ale societății informaționale oferite copiilor. Operatorul verifică identitatea și domeniul, înregistrează motivul exact și caută sistematic toate copiile în care pot exista datele.
O obligație legală de păstrare permite reținerea tuturor datelor?
Nu. Excepția acoperă numai datele și perioada necesare unei norme concrete a Uniunii sau a unui stat membru ori altei excepții aplicabile. Evidența identifică norma, câmpurile, perioada și responsabilul. Nu există o perioadă europeană universală pentru păstrarea backupurilor, iar eticheta păstrare legală nu înlocuiește analiza pe scop și categorie.
Este suficientă rotația automată a backupurilor?
Numai dacă face parte dintr-o procedură verificabilă. Cererea trebuie legată de seturile relevante, iar organizația demonstrează izolarea, evenimentul de expirare și finalizarea efectivă. Intervalele lungi necesită o evaluare argumentată. O dată planificată nu dovedește expirarea, iar rotația nu înlocuiește instrucțiunea de reaplicare dacă are loc o restaurare.
Ce se întâmplă când este restaurată o copie?
Mediul restaurat rămâne izolat cât timp este consultat registrul cererilor. Echipa reaplică potrivirile pozitive, separă datele păstrate prin excepție, verifică replicile, cache-urile și exporturile și documentează rezultatul. Mediul revine în utilizare numai după ce responsabilii cererii și recuperării confirmă că toate controalele aplicabile au fost executate și verificate.

Surse

  1. 1.2025 Coordinated Enforcement Action — implementation of the right to erasure by controllersEDPB
  2. 2.EDPB identifies challenges hindering the full implementation of the right to erasureEDPB
  3. 3.Regulation (EU) 2016/679 (General Data Protection Regulation)EUR-Lex

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.

Începeți auditul

Primiți AI Opportunity Report și Implementation Brief — adaptate afacerii dumneavoastră și livrate imediat.