Prompt and context
An erasure request cannot be completed in one pass when transaction records are under legal hold and personal data remains in rolling backups. Legal holds, live systems, and backups therefore need distinct states, owners, expiry rules, and evidence.
What the interviewer evaluates
- Having an authorized process decide validity and exemptions instead of encoding legal judgment in the pipeline.
- Retaining only fields required for a stated purpose, with owner, basis, and expiry.
- Keeping backup data beyond use and reapplying erasure after a restore.
- Separating live erasure from the remaining backup lifecycle.
Clarifications before answering
Confirm identity, subject key, jurisdiction, held datasets, and expiry. Establish whether backups support record deletion, their overwrite schedule, restore process, and third-party copies. Privacy or legal owners provide the structured decision; engineering executes it.
A 30-second answer framework
Create a versioned eligibility decision. Eligible data enters an idempotent workflow immediately; held data moves to a restricted domain with minimum fields and an expiry review. After live erasure, a protected suppression manifest covers backups. Backups cannot support ordinary processing, and every restore applies the manifest before access. Evidence separately lists erased scope, held scope and basis, latest backup expiry, and restore-drill results.
Step-by-step deep dive
Use explicit states such as eligible, partial_hold, live_erased, backup_pending, and complete. Store categories and deadlines, not copied personal content. Key actions by request ID and an irreversible internal subject reference.
Block re-ingestion before deleting eligible live copies. Move held records to least-privilege storage and enqueue them automatically when the hold expires. Exclude aggregates only after proving they cannot reasonably be linked back to a person.
ICO guidance allows backup overwrite on an established schedule while requiring affected data to be beyond use. A restore starts in isolation, applies the encrypted suppression manifest, verifies zero matches, and only then opens to business traffic. Evidence records system category, time, outcome, and digest—not deleted content.
Strong sample answer
The authorized owner supplies a structured hold scope and expiry. The pipeline erases everything else and isolates the minimal held record. Once live systems finish, the request is backup_pending, not complete.
Backups age out over 35 days and cannot serve ordinary processing. Every restore replays the suppression manifest first. The evidence package contains domain results, hold basis and expiry job, plus a restore drill. Completion occurs only after every boundary closes.
Common mistakes
- Letting data engineers decide legal exemptions.
- Retaining a whole profile because one record is held.
- Claiming completion immediately after live deletion.
- Restoring a backup without replaying the suppression manifest.
- Copying personal data into the audit trail.
Follow-up questions
What if backups cannot delete one record?
Expire them on the established schedule, keep the data beyond use, apply the manifest to every restore, and disclose the latest removal date.
How do you avoid forgetting an expired hold?
Require an expiry, owner, and automated job. Expiry re-enters the same idempotent workflow; failures appear in reconciliation.
How do you prove restore handling works?
Restore representative backups in isolation, apply the manifest, and run a zero-match check using internal subject references. Keep counts and digests only.
How are third-party processors included?
Send each processor a request-ID-based instruction and collect confirmation. Missing acknowledgments keep the overall request incomplete.