Dati personali che hanno dimenticato di avere una fine.
Il limite di conservazione, Art. 5(1)(e), stabilisce che i dati personali devono essere conservati in una forma che permetta l'identificazione delle persone solo per il tempo necessario allo scopo per cui sono stati raccolti. È uno dei doveri più facili da violare senza volerlo, perché aggiungere un luogo in cui memorizzare qualcosa è un'operazione di routine, mentre aggiungere la parte che li elimina in seguito è la parte che tutti dimenticano.
The shapes the same control failure takes.
Il cambiamento è quasi mai 'conserva questo per sempre di proposito'. È una metà mancante di una modifica altrimenti ragionevole. Queste sono le forme che si ripetono.
Un nuovo archivio viene aggiunto senza una scadenza
Una migrazione o un modello aggiunge una tabella, una cache o un indice che contiene dati personali, e nulla imposta un limite di conservazione o una scadenza, quindi i dati si accumulano semplicemente.
Un lavoro di conservazione viene rimosso o disabilitato
Un'eliminazione pianificata, un TTL su una cache o un'attività di pulizia viene rimossa durante un refactoring o commentata per risolvere un problema non correlato, e i dati che prima venivano eliminati automaticamente ora rimangono.
Un periodo di conservazione si allunga silenziosamente
Un periodo di conservazione viene aumentato (90 giorni diventa illimitato o un valore predefinito di configurazione cambia) senza uno scopo o una ragione documentata per conservare i dati più a lungo.
Un'eliminazione soft mantiene tutto
Un'eliminazione viene modificata in un flag (una colonna deleted_at) in modo che la riga, e i dati personali al suo interno, rimangano comunque indefinitamente, il che è conservazione, non eliminazione.
La cancellazione non raggiunge la nuova copia
Un nuovo luogo in cui i dati personali vengono memorizzati (un'esportazione, un sink di analisi, un secondo database) non è collegato al percorso di eliminazione del mio account, quindi una copia sopravvive alla cancellazione. Questo è anche un problema dell'Art. 17.
Un'eliminazione pianificata rimossa che mantiene gli utenti inattivi per sempre.
Un lavoro pianificato che eliminava i dati personali degli utenti inattivi da lungo tempo viene rimosso, forse perché era rumoroso, forse perché sembrava sicuro mantenere i dati. L'effetto è che i dati personali ora non hanno una scadenza definita.
schedules: reconcile: { cron: "0 2 * * *" }- purge_inactive: { cron: "0 3 * * *", delete: users, older_than: P2Y }Questo rimuove l'unica cosa che eliminava i dati personali degli utenti inattivi, quindi ora vengono conservati senza una data di scadenza. L'Art. 5(1)(e) (limite di conservazione) prevede che i dati personali siano conservati solo per il tempo necessario allo scopo. Se il lavoro era troppo aggressivo o rumoroso, correggete il suo programma o ambito, ma mantenete un percorso di conservazione piuttosto che rimuoverlo del tutto.
La conservazione è anche un problema di cancellazione.
Il limite di conservazione viene valutato in base ai registri delle attività di trattamento e al programma di conservazione: i dati trovati che sopravvivono oltre lo scopo dichiarato sono il vuoto che una revisione cerca. È collegato al diritto alla cancellazione, Art. 17, perché ogni luogo in cui i dati personali sono conservati è un luogo che una richiesta di eliminazione deve raggiungere. Un nuovo archivio senza conservazione è solitamente anche un archivio che il percorso di eliminazione del mio account non conosce, quindi i due doveri tendono a essere violati insieme, nella stessa pull request.
Una revisione, non un parere legale.
heygrc segnalerà le modifiche che interessano il limite di conservazione e citerà l'articolo in modo che la correzione avvenga nella pull request. Non imposta i periodi di conservazione, non emette un giudizio legale né mantiene i registri delle attività di trattamento. Rileva la modifica in anticipo in modo che una domanda sulla conservazione venga risolta durante la revisione piuttosto che dopo un incidente.