A customer exercises their right to erasure. List every place their data plausibly exists in a mature architecture and how each is handled.
Show the full answer Hide the answer
What is being tested
Whether you can enumerate a real system's data copies. Most designs handle the primary row and miss six other locations.
The inventory
| Location | Handling |
|---|---|
| Primary database row | Hard delete or anonymise in place |
| Read replicas | Follows automatically via replication |
| Search index | Explicit delete; verify, since index deletes are often asynchronous |
| Caches | Invalidate by key, or accept the TTL window if short |
| Data warehouse and lake | Row-level delete (needs a table format supporting it) or partition rewrite |
| Event log / message queue | Crypto-shredding, or expiry if retention is short enough |
| Backups | Usually a documented exception with a defined rolling window |
| Logs | Retention policy; ideally personal data was never logged |
| Analytics and product tooling | Deletion request via each vendor's API |
| Third-party processors (CRM, email, support, payments) | Contractual deletion requests |
| Machine learning training data and models | Remove from datasets; retraining is the honest answer for the model |
| Object storage (uploads, avatars, documents) | Delete objects and any derived thumbnails or transcodes |
The hard cases and their standard answers
Backups. You cannot practically delete one record from a backup without invalidating it. The accepted position is a documented retention window — backups roll off within N days — plus a guarantee that if a restore occurs, deletions are re-applied from a persisted suppression list. That suppression list is the mechanism people forget, and without it a restore silently resurrects deleted people.
Immutable event logs. Crypto-shredding: personal data encrypted per subject, key destroyed. This must be designed in from the start, since data already written in plaintext cannot be shredded.
Retention floors that conflict with erasure. Tax and financial regulation may require retaining transaction records for years. Erasure and retention both apply to the same customer, and the resolution is field-level: delete or anonymise identity attributes while retaining the financial record with a pseudonymous reference. Record-level thinking makes this look like an unresolvable conflict; field-level thinking resolves it.
Derived data. Aggregates that include the person are usually fine if genuinely anonymised and non-reidentifiable. A model trained on their data is the genuinely contested case.
What makes this tractable
- A data inventory and classification that is maintained. If you cannot list where personal data lives, you cannot delete it, and this list is the artefact that makes the difference between a one-day response and a two-week archaeology exercise.
- A propagating deletion mechanism — a deletion event that every store subscribes to, with acknowledgement — rather than a runbook of manual steps.
- A suppression list consulted after any restore.
- Verification. Something that checks afterwards, in each store, that the data is actually gone.
The strategic point
The cheapest data to delete is data you never collected. Sampling telemetry, aggregating rather than retaining raw events, and declining to log request bodies remove both cost and legal exposure permanently rather than managing them. In a breach, the data you did not need is the part that hurts most — and at storage-heavy scale, as products like Dropbox demonstrate, lifecycle economics are not a hygiene matter but the shape of the business.