Il GDPR non contiene un capitolo «backup». È proprio questo a rendere il tema scomodo: gli obblighi si applicano, ma bisogna tradurli da sé in decisioni tecniche.
Ecco i cinque punti sui quali le domande tornano sistematicamente — e quello che si può ragionevolmente rispondere.
Questo articolo descrive principi generali e non costituisce una consulenza legale. Per un trattamento sensibile o un contesto regolamentato, faccia validare la sua analisi da un giurista o dal suo responsabile della protezione dei dati.
1. Il diritto alla cancellazione si ferma ai backup?
È la domanda più frequente, e la risposta ha due tempi.
Una persona esercita il suo diritto alla cancellazione (articolo 17). Lei elimina i suoi dati dalla produzione. Ma restano presenti nei backup delle settimane precedenti — e ripristinare un backup per estrarne chirurgicamente un record è tecnicamente assurdo e pericoloso.
La posizione adottata dalle autorità di controllo, tra cui la francese CNIL, è pragmatica: i backup costituiscono un trattamento distinto, la cui finalità è la sicurezza e la continuità. Non si esige lo svuotamento immediato degli archivi. In compenso, ci si aspettano due impegni:
- I dati cancellati in produzione non devono riapparire: se avviene un ripristino, la cancellazione va rieseguita dopo.
- I backup interessati devono scomparire nel normale corso della rotazione, entro un termine controllato e documentato.
Concretamente: informi la persona che i suoi dati resteranno nei backup fino alla scadenza della conservazione, indicando quel termine. E tenga traccia delle richieste di cancellazione da rieseguire in caso di ripristino.
2. La durata di conservazione dei backup
Una conservazione «illimitata perché è più prudente» è un problema di conformità, non una precauzione.
Il principio di limitazione della conservazione (articolo 5) impone una durata giustificata dalla finalità. Per i backup la finalità è la capacità di ripristinare — non l'archiviazione storica.
In pratica si giustifica una conservazione legandola a un rischio: il tempo di rilevamento di una corruzione silenziosa o di un ransomware a propagazione lenta. È un ragionamento difendibile, e porta generalmente a conservazioni da alcune settimane ad alcuni mesi secondo la criticità.
Quel che conta è che la durata sia decisa, scritta e applicata, non subita per difetto.
3. Il suo cliente è titolare, lei è responsabile del trattamento
Quando esegue il backup dei dati del suo cliente, lui resta titolare del trattamento e lei diventa responsabile del trattamento ai sensi dell'articolo 28. Questo impone un contratto scritto che precisi almeno:
- l'oggetto, la durata, la natura e la finalità del trattamento;
- le categorie di dati e di persone interessate;
- i suoi obblighi di sicurezza e di riservatezza;
- la sorte dei dati alla fine del contratto;
- le condizioni per ricorrere a un sub-responsabile — il suo fornitore di hosting ne fa parte.
Quest'ultimo punto merita attenzione: se ospita i backup presso un terzo, quel terzo è un sub-responsabile e il suo cliente deve esserne informato. Ospitare lei stesso accorcia sensibilmente la catena contrattuale.
4. La localizzazione dei dati
Portare dati fuori dall'Unione europea non è vietato, ma è disciplinato (capo V): un meccanismo di trasferimento valido, una valutazione d'impatto, garanzie supplementari. Significa lavoro amministrativo, monitoraggio giuridico ed esposizione a evoluzioni normative che lei non controlla.
La questione, del resto, non è solo giuridica: è anche commerciale. Un cliente al quale può dire «i suoi backup sono su un server che amministro io, situato a questo indirizzo» è un cliente rassicurato.
Una soluzione di cui scegliere lei l'hosting — presso di lei, presso il cliente, o su un server dedicato in Francia — elimina puramente e semplicemente il tema del trasferimento internazionale.
5. La cifratura, e che cosa cambia davvero
L'articolo 32 cita esplicitamente la cifratura tra le misure adeguate. Ma non tutte le cifrature valgono allo stesso modo rispetto al rischio reale.
Cifratura a riposo sul lato server: i dati sono cifrati sul disco del server di backup. Protegge dal furto fisico del disco. Non protegge se l'aggressore ottiene un accesso al server, poiché questo detiene la chiave.
Cifratura alla fonte: i dati sono cifrati sulla macchina di cui si fa il backup, prima di partire in rete, con una chiave che non lascia mai quella macchina. Il server di backup memorizza soltanto blocchi incomprensibili. Né il fornitore di hosting, né il produttore del software, né un aggressore che abbia compromesso il server possono leggere il contenuto.
La differenza è decisiva per la notifica di violazione (articolo 33). Se dati cifrati alla fonte fuoriescono e la chiave non è fuoriuscita, il rischio per le persone interessate è notevolmente ridotto — cosa che incide direttamente sull'obbligo di informarle.
Il rovescio della medaglia è serio: chi perde la chiave perde i dati. La conservazione sicura e tracciata della chiave di ripristino diventa un obbligo operativo di primo ordine. È tipicamente ciò di cui si fa carico un fornitore di servizi.
Una lista di controllo per i fascicoli dei clienti
| Punto | Che cosa deve poter mostrare |
|---|---|
| Registro dei trattamenti | Il backup vi figura come trattamento, con la sua finalità |
| Durata di conservazione | Una conservazione scritta e giustificata, non «illimitata» |
| Contratto di trattamento | Firmato, aggiornato, con l'elenco dei sub-responsabili |
| Localizzazione | La collocazione fisica dei server di backup |
| Cifratura | Il livello applicato e la procedura di custodia delle chiavi |
| Diritto alla cancellazione | Una procedura di riesecuzione dopo un ripristino |
| Test di ripristino | Verbali datati |
Quest'ultima riga è quella che si dimentica più spesso. L'articolo 32 chiede una procedura volta a testare e valutare regolarmente l'efficacia delle misure di sicurezza. Un backup mai ripristinato non soddisfa tale requisito — e, per inciso, non protegge nessuno.
Ha bisogno di chiarire la catena di subfornitura e la localizzazione per i suoi clienti? Parliamone.