Erasure Requests Against an Immutable Lake and an Open Investigation
Caldera Health is an insurer operating in the EU and two US states. It receives roughly 40 erasure requests and 6 access requests per month, each carrying a 30-day statutory deadline. Member data lives in a 3NF Oracle claims system, a nightly feed into an immutable S3 data lake retained seven years for audit, twelve downstream data marts, and 35-day backups. Data marts hold a tokenised member identifier, but date of birth, postcode and claim category remain in clear because the actuarial models need them. Two requests breached the deadline last quarter: one because a mart had no documented lineage, and one because the requester was also a subject in an open fraud investigation - a fact the privacy office only learned on day 22. The DPO wants a repeatable process; Security has ruled out new tooling this budget year.
1. Set out how an erasure obligation should be fulfilled across the Oracle system, the immutable lake, the twelve marts and the backups. Where a store cannot be deleted from, what must exist instead?
Read the worked answer
Erasure is a documented decision per store, not a delete statement. Build a matrix of store, legal basis, action, evidence.
Oracle claims system Delete or redact the identifying fields. Retain the claim record only where a legal obligation requires it, with direct identifiers removed.
Twelve marts Delete the tokenised row and re-run any aggregate that could make the individual re-identifiable. Small-cell aggregates in actuarial tables are the usual oversight - a postcode plus claim category plus date of birth is likely identifying even without a name, so the justification that marts are 'pseudonymised only' needs a k-anonymity check, not an assertion.
Immutable S3 lake You cannot delete an object from an append-only archive without compromising its integrity. Two workable patterns:
- Crypto-shredding: keep identifying attributes in a separate store encrypted per member; destroy the key. The event payload becomes unreadable while the archive stays intact.
- Tombstone plus periodic compaction: maintain a suppression list applied at read time, and rewrite affected partitions on a defined cycle.
Backups Standard and defensible practice is not to reach into rotating backups. Record that backups are excluded until they rotate out, and that a suppression list is applied on any restore. The exemption must be written down and approved, not assumed.
What must exist where deletion is impossible A recorded decision, the reason, the approver, the compensating control, and the expiry date.
2. The fraud-investigation conflict surfaced on day 22. Diagnose the process failure and describe the intake-to-response workflow you would put in place, using only existing tooling.
Read the worked answer
The failure is sequencing, not law. Erasure is not absolute: an exception exists for the establishment, exercise or defence of legal claims. The organisation had a legitimate ground to refuse in part and discovered it too late to act on.
Diagnosis
- No hold check at intake. The legal-hold register and the privacy queue were never connected, so conflict detection was accidental.
- No internal deadline. A 30-day statutory clock with no earlier internal milestone guarantees that every complication becomes a breach.
Workflow
- Intake ticket created on day 0 with the statutory due date calculated and displayed.
- Automated hold check against the existing legal-hold register and open-investigation list. This is a lookup, not new tooling.
- Fan-out to data owners on day 1 with a 10-day internal deadline - leaving 20 days for review, partial refusal drafting and sign-off.
- Triage decision: full erase, partial erase with documented exception, or refusal with reasons.
- Response issued by day 25.
The partial case Erase everything not needed for the investigation - marketing, app telemetry, non-claim marts. Retain only what the fraud case requires, restrict it to the investigation team, and record the retention review date. Refusing everything is both disproportionate and harder to defend than a scoped retention.
Evidence Keep the conflict assessment with the ticket. The regulator asks why, not only whether.
3. Security has ruled out new tooling. What changes would you make to reduce systemic exposure, and how would you test whether the marts are genuinely de-identified?
Read the worked answer
Work with what exists: keys, retention, lineage and queries.
Crypto-shredding without new platforms Move member identifiers out of the marts into a lookup table encrypted with a per-member key held in the existing KMS or HSM. Destroying one key renders one member's records unreadable across every mart that references the token. This is the highest-leverage change available and uses infrastructure the organisation already runs.
Retention reduction Seven years is set by audit for claims. It almost certainly does not apply to app telemetry, marketing consent records or web analytics. Shortening those retention periods reduces the surface of every future request and costs nothing.
Lineage from existing metadata The day-22 breach was caused by an undocumented mart. Reconstruct lineage from Oracle catalog metadata, ETL job definitions and S3 inventory tags; store it in the repository already in use. Aim to cover the marts that hold member attributes, not all twelve at once.
Testing de-identification Run a k-anonymity query per mart: for each combination of date of birth, postcode and claim category, count distinct members. Any combination with a count of one or two is not de-identified, regardless of the token. Repeat for the actuarial extracts. Publish the cell counts to the DPO.
Expectation The query will likely show small cells in sparsely populated postcodes. That result is the finding; the fix is generalisation or suppression in the extract, not a tool purchase.