Erasure Requests Versus Immutable Tax Archives in a Multi-Tenant HR SaaS
An HR SaaS provider stores records for 2.3 million data subjects across the EU and California. Primary data sits in a multi-tenant relational database encrypted with one KMS key per region, shared by all tenants. Nightly backups are retained 35 days in object storage. Tax and payroll records for a subset of customers are copied into a seven-year immutable archive that cannot be deleted before its retention date. A customer has submitted an erasure request covering 12,000 of its former employees; roughly 900 of those records fall under statutory tax retention. Separately, the company's search cluster and a five-year analytics warehouse hold copies of the same personal data, and application logs contain email addresses. The security team has proposed moving to per-tenant encryption keys as a way to make erasure cheap, but the migration would require re-encrypting the entire database and rewriting every service that reads it.
1. Design a response to the erasure request that satisfies both the erasure obligation and the retention obligation. Address the backups explicitly.
Read the worked answer
Split the population before doing anything. Classify the 12,000 records: roughly 900 fall under a statutory retention obligation, the rest do not. Document the legal basis for retaining the 900 and the exact fields and retention end date; erasure law generally permits retention where a legal obligation requires it, but the exemption covers the minimum necessary, not the whole employee record. Where possible, delete the non-required fields from those 900 and keep only what the tax rule demands.
For the remaining 11,100, delete from the primary store, the search cluster, the warehouse, and any tenant export. Write a suppression or tombstone record keyed by a stable identifier so the subject is not re-created by the next nightly load or by a backup restore.
Backups are the usual stumbling block. Backups do not need to be rewritten; the defensible approach is to let the 35-day backup set expire on its normal schedule, document that policy, and rely on the suppression list so that any restore re-applies the deletions before serving traffic. Critically, prove that the restore path works: rehearse a restore into an isolated environment and demonstrate the suppression list is applied. Without that test, the backup exception is an assertion rather than a control.
Close the request with a written record: what was deleted, what was retained and why, which systems were touched, and the restore test evidence.
2. Evaluate per-tenant encryption keys as an erasure mechanism. Where does it help, where does it not, and what would have to change for it to be reliable?
Read the worked answer
Per-tenant key granularity gives you crypto-shredding at the tenant level: destroy the tenant's key and every ciphertext encrypted under it becomes unrecoverable. That is a strong answer to a whole-tenant offboarding and a weak answer to this request, because the request covers 11,100 individuals inside tenants that remain customers. Destroying the key would erase the customer's live data too.
It helps where the key scope can be made to match the deletion unit. If the design moved to per-tenant keys plus field-level encryption or tokenization for the highest-risk personal fields under a per-subject or per-subject-cohort key, individual erasure becomes cheap. That is a significant engineering change, not a KMS setting.
It does not help where the data has escaped the key boundary. Snapshots and backups written under the old regional key, the search index, the analytics warehouse, log sinks, and tenant exports must all be re-encrypted or reindexed under the new key model, or erasure is incomplete. A per-tenant key migration also requires every reading service, background job, and data pipeline to resolve the right key, which is where most migrations fail.
Conditions for reliability: key scope documented and enforced at write time; key destruction authorized by a controlled, audited workflow with a recovery window; no plaintext copies in caches, indexes, or logs; and a periodic test that destroys a canary key and confirms the data is unreadable everywhere. Without those, per-tenant keys provide an encryption story, not an erasure guarantee.
3. The search cluster, analytics warehouse, and application logs also contain the same personal data. How do you bring these copies under control without a multi-year replatforming project?
Read the worked answer
Treat each secondary store as a separate data-flow with its own minimization decision, rather than trying to unify them.
Search cluster: this is typically the easiest fix. Make deletion the authoritative operation, driven by the same event that deletes from the primary store, and index only the fields search actually needs. Email address is often indexed for convenience; replace it with a token that resolves at render time. Verify with a query that the deleted subjects no longer appear.
Analytics warehouse: five years of personal data is almost always more than the analysis needs. Pseudonymize at ingest, keep a separately controlled mapping table with a shorter retention, and delete the mapping on erasure. Historical aggregates survive; the individual becomes unlinkable. This avoids reprocessing five years of history under a new key.
Logs: stop logging personal data at the source rather than scrubbing after the fact. Add redaction at the logging library for known sensitive fields, and set a short retention for verbose application logs, keeping only security-relevant events longer. For existing log data, apply a redaction pass and let the remainder age out on its normal schedule.
Sequence the work by effort and exposure: logs and search first, because they are usually configuration changes, then warehouse pseudonymization. Track each store in a register that names the owner, the retention period, and the last verified deletion test.