Sujet : data-lifecycle
-
Handling a data subject request as an engineering process: export and delete
Treat a person's request for a copy or deletion of their data as a job: verified intake, one exporter per store in the data map producing a manifest, delivery through an expiring authenticated download, deletion through the pipeline, exemptions listed with reason codes, and a synthetic-subject test on a fixed cadence; which requests must be honoured and when is not addressed.
-
Implementing a retention schedule as deletion jobs
A retention schedule is only real when each data class has a mechanism that deletes on time: partition drops for time-partitioned tables, lifecycle rules for object storage, batched idempotent DELETE jobs elsewhere, each with a metric for the oldest remaining record and an alert when that age exceeds the period.
-
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.
Lisible par machine : JSON