One Erasure Request, Fourteen Systems, Two Immutable Logs
A 350-tenant HR SaaS platform processes payroll and benefits data. An employee with an open grievance against their manager submits an erasure request. Their data exists in: the primary Postgres cluster across three regions; nightly S3 snapshots with a 35-day lifecycle; an immutable audit log under S3 Object Lock retained two years; an Elasticsearch index; a warehouse with 400 dbt models; a vector store of resume and performance-review embeddings; a recommendation model trained on 18 months of review text; eight sub-processors including a background-check vendor; and a legacy on-prem ticketing system due for decommission next year. The deletion runbook is four lines long and says "delete from primary DB."
1. Decompose the problem. Which locations are genuinely hard to delete from, and why?
Read the worked answer
Sort by why deletion is hard - the reason determines the remedy.
- Immutable audit log (Object Lock). Hard by design: the integrity guarantee is the product. Deleting a record defeats the control's purpose, so the answer is usually minimization at write time and expiry, not deletion.
- Backups. Hard by economics: rewriting 35 daily snapshots per request is disproportionate. The realistic answer is lifecycle expiry plus a documented suppression step applied at restore.
- Derived warehouse models. Hard by inattention: 400 dbt models are copies. Delete the source row and the address history is still sitting in
dim_employee_address_v2. Deletion must propagate through lineage or the downstream tables must be rebuilt. - Vector store. Hard by design: embeddings have no delete-by-subject primitive, and no one can say what a vector "contains."
- Trained model. Hardest: weights encode the training data and there is no reliable delete function. Retraining is expensive; there is no proof of removal either way.
- Sub-processors and legacy systems. Hard organizationally: eight parties and one decommissioning system you cannot query in real time.
- Easy: the primary database with cascading deletes, caches, queues, and search indices you control.
Naming the category of difficulty is what lets you write a defensible plan and an honest response, instead of a runbook that deletes 1 of 14 copies and declares success.
2. Design the deletion path for each class.
Read the worked answer
Target: make the data unreachable in one action wherever possible; propagate everywhere else.
- Primary, warehouse, search, vector store - crypto-shredding. Encrypt each subject's sensitive records under a per-subject key held in a KMS; erasure destroys the key. One operation renders the copies unreadable at once, including copies you forgot you had, and it addresses the embedding problem without needing vector semantics.
- If crypto-shredding is not feasible: cascade delete with a tombstone, rebuild affected dbt models, reindex search, and maintain a suppression list so no re-ingestion from any source resurrects the record.
- Audit log. Redesign entries so they carry no content - subject IDs replaced by a salted reference, actions recorded rather than values. Then the log is not personal data and the two-year retention stands. If existing entries do contain content, restrict access and document the security basis for keeping them.
- Backups. Document that they expire within 35 days and that a deletion journal is applied on any restore. That is a known, bounded, defensible window.
- Sub-processors. Propagate the request with per-party confirmation and track non-responses; the background-check vendor may hold its own copy under its own retention rule, which you must identify.
- Model. Exclude the subject from future training and record the exclusion; if the data volume is material, schedule a rebuild. Do not claim the model has forgotten.
- Legacy system. Add to the decommission checklist with an owner and a date, and delete now rather than hoping.
The plan's value is that every system has a named remedy, an owner, and a completion date you can verify.
3. What do you commit to in writing to the requestor, and what do you not commit to?
Read the worked answer
Commit to specifics you can verify; never to absolutes you cannot.
Commit to: what was deleted, from which systems, on what date; what was retained and under which basis (the audit log's security retention, the claim or grievance defense file) and for how long; the backup expiry date; the outcome of sub-processor propagation; and the fact that the retained data is firewalled from analytics and training. Give a date, not "shortly."
Do not commit to:
- "Deleted from all systems." You cannot guarantee it across immutable storage, backups, and a trained model, and an untrue deletion statement is a factual misrepresentation that will be read back to you.
- "The model has forgotten your data." There is no such guarantee.
- A timeframe you have not engineered for.
Two situational notes. The open grievance means this request may become adversarial: the legal-claims basis likely covers the grievance file, but only what is genuinely needed, and the decision to retain should be made by a named person and documented before, not after, a challenge. Second, the four-line runbook is the real finding - one request has exposed that deletion was never engineered. Treat the gaps you discover as a remediation backlog with owners, because the next request will arrive in a month, not a year.