Suppression List

A subject's data is deleted from every store. A batch pipeline that started before the deletion completes an hour later and writes the record back. A replay of an event stream reconstructs it. A partner feed re-imports it next week.

Deletion is a point-in-time operation; ingestion is continuous. Without something that persists the decision, erasure is undone by systems doing exactly what they were built to do.

Why it is required rather than defensive

The obligation is that the data does not exist, not that a delete statement was executed. A record recreated after erasure is a live compliance failure, and it is invisible — nothing errors, and the pipeline reports success.

This is the failure mode that makes erasure programmes fail their first audit even when the deletion mechanism itself works correctly.

Implementation patterns

• A minimal suppression record holding only what is needed to match — ideally a hash of the identifier rather than the identifier itself, since the list must survive the erasure it enforces.
• Checked at ingestion, before the record enters any store, so the suppression is applied once at the boundary rather than by every consumer.
• Applied to replays and backfills, which is where it matters most and where it is most often forgotten.
• Combined with [[deletion-propagation]] acknowledgements, so the organisation can demonstrate both that every store deleted and that nothing re-created.
• Retained as long as the source of re-ingestion could plausibly deliver the record, which for partner feeds and backups can be a long time.
• Governed itself. The list is personal data of a kind — a register of people who requested erasure — so it needs access control and a justification for its own retention.

Industry example

Organisations implementing erasure at scale find the same sequence: the deletion works, the acknowledgements come back, and weeks later a reconciliation finds the subject present again. The cause is almost always a scheduled import, a replay after an incident, or a restored backup — all legitimate operations with no awareness of the erasure.

The associated lesson is that a legal hold must be evaluated as a blocking pre-check before deletion, and a suppression entry must not be created for a record that should have been preserved. The two mechanisms operate on the same pipeline stage and must be ordered deliberately.

Failure scenarios

• No suppression, so continuous ingestion silently reverses erasure.
• Suppression not applied to replays, the most common gap.
• The full identifier stored, so the mechanism retains what it was meant to remove.
• Per-consumer suppression rather than at the boundary, guaranteeing an inconsistent gap somewhere.
• Suppression retained forever with no justification, becoming its own compliance problem.
• Restored backups bypassing the check entirely, which needs an explicit post-restore reconciliation step.

Trade-offs

The list is an operational burden and a small privacy liability in its own right, and hashing limits it to exact matching — a subject re-entering under a slightly different identifier is not caught, which is a real limitation with no clean answer short of retaining more than you want to.

The proportionate design is a hashed list at the ingestion boundary with a defined retention, plus periodic reconciliation to detect recreation that the list missed. Reconciliation is what turns the control from an assumption into evidence.

Interview question

"You erase a subject's data across twelve systems successfully. Three weeks later they appear again in your warehouse. Name three ways that could have happened and what you would have built to prevent each."