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.