Errori comuni di conservazione e cancellazione che i team SaaS fanno ancora
Risposta diretta
L'obiettivo pratico della conservazione e cancellazione non e solo interpretare un requisito. E trasformarlo in un workflow ripetibile con owner, decisioni documentate e prove solide.
Chi riguarda: Compliance lead, security team, audit owner, founder e responsabili operations che preparano customer review o assessment formali
Cosa fare ora
- Elencate sistemi e workflow in cui le decisioni di conservazione e cancellazione sono ancora informali.
- Definite owner, trigger, percorso di eccezione e prova minima per ogni categoria di dati ad alto rischio.
- Testate un workflow di cancellazione end to end prima della prossima review cliente, audit o release.
Errori comuni di conservazione e cancellazione che i team SaaS fanno ancora
Gli errori di conservazione e cancellazione nascono quando il tema resta una policy e non diventa un processo operativo. Nel GDPR, i dati personali non dovrebbero essere conservati oltre il tempo necessario, servono limiti per cancellazione o revisione, e il diritto alla cancellazione puo richiedere un'azione concreta. La parte difficile e provarlo nei sistemi, nei ticket, nei vendor workflow, nei backup e nell'evidenza.
I problemi piu frequenti sono trigger poco chiari, regole non mappate sui sistemi, eccezioni informali, promesse di cancellazione irrealistiche sui backup e prove deboli.
Perche succede anche in team maturi
Una policy puo sembrare ordinata: customer data per un certo periodo, ticket di supporto per un altro, dati candidati dopo il processo di selezione, backup a rotazione. Ma gli stessi dati possono vivere in app, warehouse, CRM, helpdesk, log, analytics, billing, export, drive condivisi e ambienti di fornitori. Se questa mappa manca, la cancellazione e parziale.
Errore 1: policy senza mappa dei sistemi
Una retention schedule deve dire dove sono i dati, chi possiede il sistema, quale azione e possibile e quale prova rimane. Iniziate da chiusura account, richieste di cancellazione, ticket support, dati employee, vendor offboarding, analytics e log.
Errore 2: durata senza trigger
"Conservare per tre anni" non spiega quando parte il conteggio. Churn, fattura finale, disattivazione account, chiusura ticket o fine obblighi contrattuali possono produrre date diverse. Il trigger deve essere un evento operativo verificabile.
Errore 3: trattarlo come solo engineering
Engineering spesso esegue, ma legal, privacy, security, support, finance, product e procurement decidono o controllano parti del flusso. Serve chiarezza su chi definisce la regola, rileva il trigger, approva eccezioni, esegue e conserva evidenza.
Errore 4: minimizzazione troppo tardi
La cancellazione e piu difficile quando sono stati raccolti troppi dati. Form, analytics, allegati support, integrazioni e campi liberi diffondono dati personali. Ogni nuova feature dovrebbe chiedere se il dato e necessario, se basta una forma anonima o aggregata, dove viene copiato e quale regola di retention vale dal lancio.
Errore 5: dimenticare backup e archivi
I sistemi live possono essere cancellati subito, mentre backup e archivi seguono cicli separati. Alcuni backup sono immutabili o non modificabili per singolo record. Distinguete cancellazione live, anonimizzazione, expiry dei backup, restore controls e legal holds. Nel 2026 l'EDPB ha indicato backup e retention periods come sfide pratiche per i controller.
Errore 6: trattare tutte le richieste allo stesso modo
Il diritto alla cancellazione non e assoluto. Obblighi legali, interesse pubblico o difesa di diritti possono giustificare una conservazione limitata. Usate un decision tree: identita e scope, sistemi e vendors, base della cancellazione, eccezioni, azione e documentazione.
Errore 7: perdere l'evidenza
Un job eseguito, una mail del vendor e un ticket chiuso non bastano se non collegano regola, trigger, decisione, owner, azione e data. L'evidenza puo essere leggera, ma deve essere coerente.
Errore 8: non aggiornare dopo cambi prodotto
Nuove integrazioni, tabelle analytics, log AI, screenshot support o migrazioni billing cambiano il perimetro. Le release ad alto rischio dovrebbero includere il controllo: quali dati personali, quali copie, quale owner, quale cancellazione, quale prova.
Checklist pratica
- Ogni regola e collegata a sistemi e fornitori.
- Il trigger e un evento chiaro.
- Owner di decisione, esecuzione ed evidenza sono definiti.
- Backup, archivi ed export sono separati.
- Eccezioni e legal holds sono documentati.
- Le promesse ai clienti corrispondono alla realta tecnica.
Partite da un workflow concreto, come chiusura account o richiesta di cancellazione. Un processo piccolo ma eseguibile batte una policy ampia ma fragile.
Termini chiave in questo articolo
Fonti primarie
- For how long can data be kept and is it necessary to update it?European Commission · Consultato 6 mag 2026
- Do we always have to delete personal data if a person asks?European Commission · Consultato 6 mag 2026
- What data can we process and under which conditions?European Commission · Consultato 6 mag 2026
- EDPB identifies challenges hindering the full implementation of the right to erasureEuropean Data Protection Board · Consultato 6 mag 2026
Esplora hub correlati
Articoli correlati
Termini del glossario correlati
Pronto a garantire la tua compliance?
Non aspettare che le violazioni blocchino la tua attività. Ottieni in pochi minuti il tuo report completo di compliance.
Scansiona ora il tuo sito gratis