Devo cancellare i dati personali anche dai backup?

Alla domanda se sia necessario cancellare i dati personali dai backup, due risposte assolute sono entrambe sbagliate: non occorre distruggere immediatamente ogni supporto di recupero, ma le copie di sicurezza non sono esenti per definizione. Prima si stabilisce se l'articolo 17 richiede la cancellazione; poi si classificano tutte le copie, si agisce senza ingiustificato ritardo dove è possibile e si impedisce che un ripristino reintroduca i dati ^1,3.

Risposta rapida — Per cancellare i dati personali dai backup, verificate il motivo dell'articolo 17 e le eccezioni. Eliminate le copie attive e quelle modificabili in sicurezza; isolate i set protetti per integrità fino alla scadenza documentata. Ogni ripristino deve consultare il registro, riapplicare la cancellazione e bloccare le repliche a valle prima del rilascio ^1,3.

Ultimo aggiornamento: 24 settembre 2026

La funzione della copia viene prima del suo nome

Un file chiamato “backup” può essere una replica disponibile ogni giorno, un'istantanea modificabile oppure un set di recupero protetto contro alterazioni. La base giuridica e l'eventuale eccezione vengono prima della meccanica della copia ³. Solo dopo questa decisione è possibile scegliere un intervento che rispetti sia la cancellazione sia l'integrità necessaria al recupero.

La classificazione va provata, non dedotta dal nome del prodotto. Un archivio ricercabile dal personale per recuperare vecchie email è una copia attiva. Un set immutabile, scollegato dall'uso ordinario e accessibile soltanto durante un evento di recupero, può seguire il ramo protetto. Tra questi estremi esistono copie esportate, cache, repliche geografiche e snapshot: ognuna deve avere proprietario, funzione e regola di uscita.

Collegate il responsabile delle richieste al responsabile del recupero. Il primo conosce identità, ambito e motivo; il secondo conosce set, replica e sequenza di ripristino. Se lavorano su registri separati, la cancellazione può risultare completa nel sistema corrente e scomparire durante il primo incidente. Un identificatore comune, minimo e non direttamente descrittivo, permette di coordinare le due funzioni senza diffondere più dati del necessario.

La classificazione va riesaminata dal punto di vista dell'uso, non soltanto dell'architettura: una copia nata per il recupero può diventare un archivio consultato dal supporto, e una replica formalmente attiva può essere stata isolata durante una migrazione; registrate quindi chi può accedere, con quale interfaccia, per quale scopo, quali scritture sono possibili e quale evento riporta la copia nel servizio, perché questi fatti determinano l'azione più del nome assegnato dal fornitore.

Il motivo dell'articolo 17 delimita la ricerca

Non tutte le richieste che usano la parola “cancellazione” hanno lo stesso fondamento. Verificate identità, relazione, sistemi e intervallo temporale, quindi registrate il motivo pertinente. L'articolo 17 comprende esattamente questi sei percorsi ³:

• I dati non sono più necessari rispetto alle finalità per cui erano stati raccolti o trattati.
• La persona revoca il consenso e non esiste un'altra base giuridica.
• L'opposizione è accolta oppure riguarda il marketing diretto.
• I dati sono stati trattati illecitamente.
• La cancellazione è necessaria per un obbligo del diritto dell'Unione o dello Stato membro.
• I dati riguardano l'offerta di servizi della società dell'informazione nelle condizioni dell'articolo 8, paragrafo 1.

Il motivo guida l'evidenza. Se i dati non sono più necessari, occorre mostrare la finalità originaria e perché è terminata. Se il consenso è revocato, bisogna controllare se un altro fondamento copre davvero lo stesso uso. Per il marketing diretto l'opposizione segue il suo percorso specifico; non può essere trasformata in una valutazione generica di interessi contrapposti.

La decisione deve inoltre separare i dati e gli usi coperti: la revoca del consenso per una newsletter può eliminare indirizzo, preferenze e liste di invio senza incidere su una fattura conservata con un altro fondamento, mentre la cessazione di una finalità può lasciare soltanto una traccia minima necessaria a dimostrare l'azione; costruite quindi una matrice tra scopo, base, campi, sistemi e risultato, così il team tecnico non riceve un comando indistinto che rischia tanto la cancellazione eccessiva quanto la conservazione ingiustificata.

Prima di avviare le azioni, fate convalidare l'ambito da chi conosce la relazione con la persona e da chi conosce le dipendenze dei sistemi, registrando ogni conflitto e la sua soluzione: un identificatore condiviso da più profili, per esempio, richiede una regola che distingua le corrispondenze e una verifica manuale, perché l'automazione non deve cancellare dati di un omonimo né usare l'incertezza come motivo per non intervenire sul record corretto.

La ricerca deve produrre un inventario di copie. Partite dagli identificatori confermati, cercate varianti e collegamenti pertinenti, annotate sistemi attivi, esportazioni, cache, repliche e set di recupero. Una ricerca per sola email può perdere un record indicizzato con ID cliente; una ricerca troppo ampia può coinvolgere omonimi. Registrate quindi query, criteri, risultati e controlli manuali ³.

L'inventario deve includere anche il periodo coperto: un set creato prima dell'iscrizione della persona non può contenere il record, mentre uno generato dopo la cancellazione potrebbe contenere soltanto la traccia minima necessaria a evitare la reintroduzione; collegare ogni copia alla propria finestra temporale riduce ricerche inutili, rende spiegabile un risultato negativo e permette al team di scegliere campioni che provino davvero il percorso positivo e quello senza corrispondenza.

Le eccezioni si applicano per necessità, non per database

Prima di cancellare, valutate le cinque categorie dell'articolo 17, paragrafo 3: libertà di espressione e informazione; obbligo legale o compito di interesse pubblico o esercizio di pubblici poteri; sanità pubblica; archiviazione, ricerca o statistica dell'articolo 89 quando la cancellazione comprometterebbe seriamente gli obiettivi; accertamento, esercizio o difesa di diritti in sede giudiziaria ³.

Ogni ramo richiede una decisione circoscritta. Non si marca l'intero profilo come “da conservare” se soltanto tre fatture sono necessarie. I dati trattenuti non restano disponibili per marketing, analisi o assistenza ordinaria. Separazione logica, controllo degli accessi e data di riesame trasformano l'eccezione da etichetta a misura verificabile.

Per un obbligo giuridico, registrate la disposizione reale dell'Unione o dello Stato membro, il titolare della decisione e il periodo applicabile ³. Non esiste una durata europea universale per tutti i backup. Se la norma riguarda soltanto certi documenti, gli altri dati possono dover essere cancellati. Inventare un periodo “prudenziale” comune sposta il problema invece di risolverlo.

Separate inoltre l'oggetto necessario dalle copie che lo contengono: conservare una fattura per un obbligo applicabile non giustifica mantenere, nello stesso profilo, note commerciali, preferenze o cronologia di assistenza, e l'impossibilità tecnica di separare subito i campi richiede un piano di estrazione, restrizione e verifica con scadenza, non l'estensione automatica dell'eccezione all'intero archivio.

Le copie attive vanno trattate e verificate

Produzione, archivio ricercabile, replica ordinaria, cache ed esportazione di lavoro possono essere attivi qualunque sia la loro etichetta. Definite i campi e gli identificatori, eseguite la cancellazione o la limitazione pertinente, poi verificate l'assenza nei punti in cui il dato era utilizzabile. Affrontate anche i destinatari quando l'articolo 17 lo richiede.

“Senza ingiustificato ritardo” non equivale a una scadenza tecnica universale inventata ³. La sequenza deve essere tempestiva rispetto a complessità, rischio e dipendenze reali. Un sistema difficile non autorizza l'inazione: richiede proprietario, priorità, stato aperto e controllo temporaneo che impedisca ulteriori usi mentre la correzione procede.

Il record di completamento può essere compatto: chiave della richiesta, motivo, sistemi cercati, query o metodo, dati trovati, azioni, eccezioni, destinatari, verificatore, data ed errori aperti. Una risposta “zero risultati” merita la stessa prova di una corrispondenza positiva. Senza query e perimetro, non distingue una vera assenza da una ricerca mal costruita.

Gli errori non vengono chiusi con una nota. Se una cache non può essere interrogata o un'esportazione resta fuori controllo, la richiesta rimane aperta e il rischio viene contenuto. La chiusura arriva solo quando l'azione e la verifica coprono ogni copia attiva nota, oppure una decisione documentata spiega il perimetro trattenuto.

La verifica dovrebbe osservare sia l'archivio sia le funzioni che lo espongono, poiché un indice di ricerca, una coda di messaggi o un rapporto già generato può continuare a restituire il dato dopo la rimozione dalla tabella primaria; definite quindi un insieme di interrogazioni dal punto di vista dell'utente, ripetetele dopo l'azione, fate controllare almeno un risultato da una seconda persona e conservate le differenze, così la prova dimostra un cambiamento effettivo e non soltanto l'esecuzione di un comando.

L'integrità del backup richiede un controllo sul ripristino

Il rapporto EDPB riconosce le preoccupazioni per l'integrità e descrive come risposta pratica il tracciamento delle richieste e la loro riapplicazione dopo un ripristino ¹. Un set protetto non deve essere modificato in modo improvvisato; deve però essere isolato dall'uso ordinario, collegato a una scadenza provata e accompagnato da un'istruzione che impedisca la riattivazione dei dati.

Minimizzate gli identificatori nel registro e limitate l'accesso ai ruoli che devono eseguire la ricerca. Il registro non deve diventare una nuova copia completa dei dati cancellati. Una chiave pseudonima può rinviare a identificatori protetti, disponibili soltanto durante la verifica. Registrate ogni consultazione, soprattutto durante un incidente.

Il vero isolamento significa che il set non alimenta analisi, assistenza, test o consultazioni ordinarie. La scadenza deve essere dimostrata da eventi del sistema o da una verifica, non soltanto prevista da una politica. Quando cambia la tecnologia di backup, rivalutate se i nuovi set ereditano richieste aperte e se i vecchi restano raggiungibili ¹.

Durante la transizione, costruite una matrice tra vecchi set, nuovi set e intervalli recuperabili, perché una migrazione può creare una copia temporanea non registrata, prolungare la vita di un supporto destinato alla distruzione o trasferire dati in un formato che la query abituale non riconosce; il responsabile privacy verifica che ogni richiesta aperta sia applicabile a entrambe le tecnologie, mentre il responsabile del recupero prova che nessun percorso di rilascio aggiri il controllo.

Formalizzate il passaggio con un criterio di accettazione: il responsabile privacy consegna chiave, identificatori e perimetro; il responsabile del recupero conferma set, query, sequenza e condizioni di rilascio. Entrambi registrano le discrepanze prima della prova. Se un identificatore non produce lo stesso risultato nei due registri, il ripristino resta isolato finché la mappatura non è corretta e verificata da una seconda persona.

Provate anche il passaggio di responsabilità. Durante un incidente simulato, il tecnico che avvia il recupero deve trovare la chiave della richiesta senza conoscere la storia del caso, capire quali identificatori usare e sapere chi autorizza un'eccezione. Se deve telefonare all'autore del registro per interpretarlo, il controllo dipende da memoria personale e non è ancora un runbook. Registrate l'ambiguità come errore operativo e riscrivete l'istruzione prima della prova successiva.

La scadenza automatica non sostituisce la procedura

Il rapporto riferisce una preoccupazione rilevata tra la metà delle autorità rispondenti e descrive debolezze nei processi, ma questi dati non dimostrano una prevalenza universale tra tutti i titolari ^1,2. Servono a individuare punti di controllo: ricezione, valutazione, calendario, copie, eccezioni, comunicazione e verifica.

Una sequenza completa collega la richiesta al motivo, controlla le eccezioni, tratta le copie attive, nomina i set di backup, registra decisione d'integrità e scadenza, quindi crea l'azione di ripristino. La sola rotazione automatica vede il supporto, non la persona né la base giuridica. Può eliminare una copia senza provare che tutte le altre siano state incluse.

Intervalli lunghi richiedono una valutazione basata su necessità di recupero, rischio, isolamento e capacità di riapplicare le richieste. Il rapporto non stabilisce un massimo universale. Un'organizzazione deve poter spiegare perché il ciclo scelto è necessario e come impedisce l'uso durante l'attesa, senza trasformare un limite tecnico in una regola giuridica.

“Scadenza prevista” e “scadenza completata e verificata” sono stati diversi. Il registro conserva entrambi, registra ritardi ed errori e mantiene la richiesta aperta finché l'evento effettivo non è provato. Questa distinzione evita che una pianificazione corretta venga riportata come risultato già ottenuto.

Per ogni set, l'evento conclusivo dovrebbe provenire da una fonte osservabile, come il catalogo del sistema, un verbale di distruzione o una verifica di irrecuperabilità, ed essere riconciliato con eventuali duplicati e copie fuori linea; se il ciclo fallisce o viene prorogato, una nuova data accompagnata dal motivo mantiene trasparente il ritardo, mentre modificare la scadenza originaria cancellerebbe proprio l'evidenza necessaria a capire se il processo ha funzionato.

I dati dell'azione coordinata indicano dove guardare

L'esercizio ha coinvolto 32 autorità di controllo: 9 hanno avviato indagini formali e 23 attività di accertamento. Sono stati contattati 7.943 titolari e sono pervenute 764 risposte ¹. Queste cifre descrivono l'esercizio e il suo campione; non sono percentuali applicabili automaticamente a tutte le organizzazioni.

I risultati richiamano lacune ricorrenti nelle procedure, nei calendari e nelle esclusioni non giustificate ^1,2. Il valore pratico sta nelle domande da riportare al proprio processo: chi prende in carico la richiesta, quale data controlla il lavoro, come vengono individuati i sistemi, chi approva un'eccezione e come si prova che il dato non tornerà dopo un recupero?

Una piccola organizzazione non ha bisogno di una piattaforma complessa. Un record per richiesta, un registro delle copie e un runbook di ripristino possono bastare se condividono identificatori, proprietari e stati. La semplicità aiuta solo quando il record è completo e viene usato nelle prove; tre fogli isolati ricreano il medesimo divario che dovrebbero chiudere.

Il controllo minimo può essere messo alla prova scegliendo una richiesta chiusa, chiedendo a una persona diversa di individuare tutte le copie pertinenti e simulando il ripristino di un intervallo che certamente conteneva il dato; se il tester non riesce a trovare l'istruzione, non sa distinguere un'eccezione o non può provare l'assenza nelle repliche, la lacuna appartiene alla procedura e resta aperta anche se la cancellazione originale era corretta.

Una prova di ripristino verifica l'ultima barriera

L'ambiente recuperato resta isolato fino al completamento del controllo di cancellazione. Usate record di test controllati insieme a percorsi autentici autorizzati, includendo sia una corrispondenza positiva sia un vero caso senza corrispondenze. La prova segue otto passaggi, nell'ordine:

1. Identificare istantanea, sistemi inclusi e momento cui il ripristino riporta i dati.
2. Limitare accessi e connessioni affinché l'ambiente non alimenti sistemi ordinari.
3. Consultare il registro delle richieste valido per l'intervallo recuperato.
4. Riapplicare cancellazione o limitazione a tutte le corrispondenze positive.
5. Separare i dati trattenuti da eccezioni ancora valide e documentarne il perimetro.
6. Controllare repliche, cache, esportazioni e destinazioni a valle del sistema recuperato.
7. Registrare corrispondenze, assenze, azioni, errori e ripetizioni necessarie.
8. Rilasciare l'ambiente soltanto dopo l'approvazione dei responsabili richiesta e ripristino.

Un esito negativo non è automaticamente un successo: deve essere plausibile rispetto all'intervallo, agli identificatori e al set recuperato. Fate verificare query e perimetro da una persona diversa da chi li ha preparati. Se uno stadio fallisce, mantenete l'isolamento, assegnate un proprietario e ripetete dal punto che può aver contaminato i passaggi successivi.

Il verbale del simulacro deve distinguere il record controllato, la corrispondenza autentica autorizzata e l'assenza genuina, riportando per ciascuno quali identificatori sono stati cercati, quali sistemi a valle erano collegati e chi ha verificato l'esito; questa separazione impedisce che un unico risultato positivo mascheri una query troppo stretta e trasforma la prova in materiale riutilizzabile quando cambiano il software, la sequenza o i responsabili.

La chiusura deve poter sopravvivere al prossimo ripristino

Il fascicolo finale riunisce motivo, eccezioni, azioni sulle copie attive, set di backup, decisioni d'integrità, scadenze e controlli di ripristino. Una fase non provata o fallita resta aperta. La risposta alla persona non deve anticipare una chiusura che il registro tecnico non sostiene.

• Chiudere: motivo deciso, copie attive trattate, eccezioni circoscritte e controllo di ripristino verificato.
• Sospendere: una conservazione necessaria o un set protetto impedisce la chiusura, con perimetro e prossimo evento indicati.
• Riaprire: una nuova copia, un errore, un ripristino o un cambiamento tecnico rimette in discussione l'esito precedente.

La decisione completa ha tre parti. L'articolo 17 definisce l'ambito giuridico; funzione e integrità della copia definiscono l'implementazione; registro e runbook impediscono una restituzione silenziosa dei dati. Se il processo riesce a dimostrare tutte e tre dopo un ripristino reale, la cancellazione non dipende più dalla memoria delle persone o dal nome attribuito a una cartella.

Conservate la chiusura insieme al prossimo evento che potrebbe riaprirla, come una migrazione, una modifica della rotazione o l'attivazione di una nuova replica, perché un controllo affidabile non promette che il dato non esista mai più in astratto: dimostra quali copie sono state trattate, quali restano protette per una ragione limitata, quale barriera opera al recupero e chi deve reagire quando cambiano le condizioni su cui poggiava la decisione.