Key takeaway: Access and deletion rights are engineering problems disguised as legal ones. The binding constraint is knowing where personal data actually lives, and most organisations do not.
Why the First Request Is Painful
A deletion request arrives. Someone deletes the row in the primary database and marks the ticket complete.
The data remains in the analytics warehouse, in application logs, in the email platform, in the support tool, in the payment processor, in six months of database backups, in a CSV a colleague exported last quarter, and in a Kafka topic with seven-day retention.
The response was incomplete, and nobody involved knew it. The failure was not negligence — it was the absence of a map.
Building the Inventory
The inventory is the prerequisite for every other privacy capability, and it does not need to be elaborate to be useful.
| Field | Why it matters |
|---|---|
| System name and owner | Who executes the deletion |
| Categories of personal data | Determines which rights apply |
| Lawful basis | Whether deletion can be refused |
| Retention period | Whether it should already be gone |
| Downstream flows | Which other systems inherit copies |
| Deletion mechanism | Whether it is automated or manual |
The downstream column matters most and is hardest to complete. Data rarely stays where it was written — it is replicated to a warehouse, exported to a vendor, cached in a search index. Each copy is a separate deletion obligation.
Interviews find far more than documentation does. Ask each team what they receive, what they send, and what they export manually. The manual exports are the ones that never appear in an architecture diagram and consistently surprise everyone.
The Genuinely Hard Cases
Backups. Deleting a record from a backup is usually impossible without restoring and rewriting the whole set. Regulators generally accept a documented approach where backups age out on a defined schedule and restores re-apply pending deletions. That requires a durable deletion log that survives the restore.
Immutable and append-only stores. Event logs and ledgers are designed not to change. Crypto-shredding is the practical technique: encrypt personal fields with a per-subject key and destroy the key on deletion, which renders the ciphertext unrecoverable without altering the record.
Aggregates and derived data. A trained model or a computed metric may embed information from a record. Aggregates that cannot identify an individual are generally acceptable; anything re-identifiable is not.
Third parties. A processor holding data on your behalf must delete on instruction. That obligation belongs in the contract, and the mechanism needs testing rather than assuming.
Making It Routine
Manual fulfilment does not scale and is error-prone under time pressure. Build a deletion pipeline that fans out to every system in the inventory and records confirmation from each.
Log the request, the systems contacted, the timestamps and the confirmations. The record demonstrating that you fulfilled the request is as important as the fulfilment, because it is what you present when asked.
Retention automation prevents the problem from growing. Data deleted on schedule is data that cannot appear in a future request, and most over-retention is inertia rather than a decision.
The Bottom Line
Build the data inventory before you receive a request, with special attention to downstream copies and manual exports. Automate fan-out deletion with per-system confirmation, use crypto-shredding for immutable stores, and document your backup approach rather than pretending backups are covered.
