intermediate 2 min answer

A regulator asks how long after an erasure request the data is genuinely gone. Production deletes in seconds; backups are daily with 35-day retention; the warehouse is fed by change data capture; the search index rebuilds weekly; three processors hold copies. Roughly what number do you give and what does it rule out?

erasurebackupssuppression-listcdcprocessors
Show the full answer Hide the answer

The assumptions, stated

  • Live database: soft delete immediately, hard delete on the next daily compaction, so under 24 hours.
  • Search index: full rebuild weekly, so up to 7 days unless a targeted delete is issued.
  • Warehouse: CDC lag of minutes plus a tombstone that is only applied at the next table compaction, so up to 24 hours, plus historical snapshots that are kept for 90 days.
  • Backups: daily full, 35-day retention, so the oldest copy containing the record ages out after 35 days.
  • Processors: contractual deletion within 30 days of instruction, and you cannot verify it.

The arithmetic

The horizon is the maximum, not the average, because the regulator's question is about the last copy.

live           < 1 day
search index   ≤ 7 days   (targeted delete drops this to minutes)
warehouse      ≤ 1 day, snapshots ≤ 90 days
backups        ≤ 35 days
processors     ≤ 30 days
------------------------------------
deletion horizon ≈ 90 days, dominated by warehouse snapshots;
                   35 days if snapshots are excluded or targeted

So the honest answer is "removed from every system that serves a user within 24 hours, and from the last backup or snapshot within 90 days", not "immediately".

Which assumption dominates the error

Retention of the oldest derived copy, and it is nearly always a copy nobody thinks of as a database: warehouse time-travel snapshots, a quarterly regulatory extract, a laptop-hosted CSV from an analyst. Halving backup retention halves the headline number and costs you restore range. Deleting inside a backup is not an option: backups are restored as a unit, and a mutated backup is not a backup.

The mechanism that makes the number defensible

A suppression list that survives restore. The erasure request is recorded as a durable instruction, and every restore path replays the suppression list before the restored system takes traffic. Without it, a restore silently resurrects erased people and the first sign is a marketing email to someone who asked to be forgotten two years ago.

Common weak answers

  • "We delete immediately." True of the row, false of the system, and the auditor will ask for the backup schedule next.
  • "We will delete from backups." Selective deletion inside backup media is not a thing at any scale worth having. Say the retention period and the suppression rule instead.
  • Forgetting the processors. Their clock starts when your instruction reaches them, which means the instruction must be automated, not a ticket someone raises on Friday.