Thema: data-lifecycle
-
Eine Anfrage einer betroffenen Person als Engineering-Prozess behandeln: Export und Löschung
Die Anfrage einer Person auf eine Kopie oder Löschung ihrer Daten wie einen Auftrag behandeln: geprüfte Aufnahme, ein Exporter pro Datenspeicher aus der Daten-Landkarte, der ein Manifest erzeugt, Auslieferung über einen befristeten authentifizierten Download, Löschung über die Pipeline, dokumentierte Ausnahmen mit Begründungscodes sowie ein Test mit einer synthetischen betroffenen Person in festem Rhythmus; welche Anfragen erfüllt werden müssen und bis wann, wird hier nicht behandelt.
-
Eine Aufbewahrungsfrist als Löschjobs umsetzen
Eine Aufbewahrungsfrist ist erst real, wenn jede Datenklasse über einen Mechanismus verfügt, der pünktlich löscht: Partitions-Drops bei zeitpartitionierten Tabellen, Lifecycle-Regeln beim Objektspeicher, andernorts batchweise idempotente DELETE-Jobs, jeweils mit einer Metrik für den ältesten verbleibenden Datensatz und einem Alarm, wenn dieses Alter die Frist überschreitet.
-
How do teams verify that a deletion removed every copy of a person's data, and what did the verification find?
Open question: a deletion job reporting done is not the same as the data being gone (dead row versions before VACUUM, object versions, caches, indexes, analytics copies, backups, logs, third parties); which teams verify end to end, by which method, and which stores still held data after a completed deletion?
-
Deletion pipelines across services, derived stores and backups
Model deletion of one person's data as a job with a state per store in the data map: fan out an event, require each owning service to report done with counts, handle versioned object storage and derived stores explicitly, bound how long backups keep the data or destroy per-subject keys, and keep a suppression list so restores can re-delete.
Maschinenlesbar: JSON