An erasure request arrives and the person's data is in backups, an event stream, a warehouse copy and a training set. What can you honestly delete?

First, the request is narrower than it sounds

Before designing anything, establish what you are obliged to do. The right to erasure is conditional, not absolute: it applies to data you no longer have a lawful reason to hold, and it yields where processing remains necessary for a legal obligation, for the defence of legal claims, or for a small set of public-interest grounds. So the first output is a recorded decision about which categories of the subject's data are in scope and which are retained with a stated reason. Starting with DELETE statements skips the part a data protection officer cares about most.

The second is that erasure is a request about a person while your systems are organised around records. You cannot service it without knowing every place a person's data comes to rest, so the real prerequisite is an inventory: systems, tables, topics, buckets, extracts, third-party processors, and for each one the field that identifies the subject. Organisations that struggle with erasure almost never struggle with the delete; they struggle because nobody can enumerate the copies.

The operational store is the easy part

In the primary transactional database the delete is mechanically straightforward and the interesting decisions are about referential integrity. Hard-deleting a customer row cascades into orders, payments and messages that other obligations require you to keep, so what you usually want is field-level erasure: overwrite the identifying and contact attributes, keep the transactional shell that tax or financial regulation requires, and record that the shell now belongs to an erased subject. Soft-delete flags are not erasure — a row with deleted_at set is still fully readable by anyone with database access and still present in every backup.

The event stream

An append-only log is the first place the naive answer breaks, because you cannot reach into the middle of a log segment and rewrite one record. Two mechanisms are available, and both need to have been chosen before the request arrived.

If the log is keyed by the subject identifier and the topic is compacted, publishing a tombstone for that key makes compaction remove the prior records for it, eventually. That "eventually" matters: compaction is asynchronous, so you own the lag and must be able to state it. If the topic is time-retained instead, the honest position is that the data ages out at the retention horizon, and the defensible answer is to keep that horizon short and to say what it is.

The deeper problem is that a stream exists to be consumed, so it is not one copy but the distribution mechanism for many: every consumer has already materialised the payload somewhere else. The design that works is to make erasure itself an event. Publish a SubjectErased record that every consumer must handle, and treat handling it as a condition of subscribing at all. That turns an unbounded manual hunt into a fan-out you can monitor.

The warehouse copy

Analytical stores were built on the assumption that history is immutable, which is why row-level deletion in a warehouse or lakehouse is a feature rather than a given. Modern table formats support deletes, but the delete is not the end of the job: the previous snapshot still exists for time travel, and older files persist until compaction and snapshot expiry have run. Erasure here is a delete plus a snapshot-expiry policy short enough that the residual window is defensible.

Then there are the copies the warehouse spawned, which are the ones that get missed: extracts sent to a BI tool, a cached dashboard result, a notebook in someone's personal workspace, a CSV mailed to a stakeholder, and a downstream aggregate that is safe to keep only if it is genuinely aggregate. The structural fix is not diligence but preventing the copies: no row-level personal data in the analytical layer unless a use case requires it, and surrogate keys instead of natural identifiers so most tables never hold identifying attributes at all.

Backups

Backups are where candidates either overclaim or panic. Rewinding a backup set to surgically remove one subject is usually infeasible and often actively harmful, because a backup that has been rewritten is no longer a faithful restore point. The position generally accepted by supervisory authorities is a deferral, not an exemption: you need not rewrite the archives, provided the backup is not used for any live processing, is retained on a defined and finite schedule, and — the part people forget to promise — the erasure is re-applied if a restore ever happens. That last clause is an engineering commitment: your restore runbook contains a replay step against the erasure register, and that register outlives the records it describes. It also means bounded backup retention is a privacy control and not merely a storage-cost one, because indefinite retention turns the deferral into a permanent copy and the argument stops working.

The training set, and what crypto-shredding buys you

A training set you treat like any other derived dataset: exclude the subject and record the exclusion. A trained model is different, because the data is no longer held as records — it is diffused into weights, and may nonetheless be extractable, particularly for outlier individuals memorised precisely because they were unusual. Machine unlearning research exists but is not a capability to promise. The credible answer is that you remove the subject from the corpus, exclude them at the next retrain, keep provenance linking each model version to the snapshot that produced it so you can say which models are affected, and treat retraining as a cost you have priced. Claiming you can delete a person from an existing model is the fastest way to lose the room.

Crypto-shredding is the mechanism that makes the immutable copies tractable, and its entire value depends on being designed in first. You encrypt each subject's personal fields under a per-subject data encryption key, store only ciphertext in the log, the warehouse, the object store and the backups, and hold the keys in a small mutable keystore. Erasure then becomes destroying one key, which renders every copy of that ciphertext — including the copies inside sealed backups you cannot rewrite — unrecoverable in one operation. The caveats are worth volunteering: it covers only the fields you encrypted, so anything that leaked into a free-text note or a log line is untouched; the key must be per subject, since a shared key means shredding one person destroys everyone; the keystore becomes a single point of catastrophic failure and needs a backup story that cannot resurrect shredded keys; and you can no longer join or filter on the encrypted fields, which is why teams quietly leave an identifier in the clear and undo the whole scheme.

Pseudonymisation does something different and is routinely misdescribed. Replacing a name with a stable surrogate means the data cannot be attributed to a person without the mapping table, which reduces breach impact and narrows how many systems hold identifying data. But under GDPR pseudonymised data is still personal data, because re-identification remains possible using additional information you hold. It does not take the data out of scope and it is not, by itself, erasure. What can take data out of scope is anonymisation — destroying the mapping and ensuring the residue cannot single out an individual by combination, a much harder bar than it sounds for fine-grained event data. Pseudonymisation limits where identity lives, which is what makes crypto-shredding and selective deletion feasible; it is a lever on the problem rather than a solution to it.

Where the strong answer separates itself

The difference between an adequate answer and a strong one is refusing the word "everywhere". An adequate candidate deletes the data everywhere it exists. A strong one produces a per-copy statement with a mechanism and a time bound: deleted synchronously here, tombstoned with a stated compaction lag here, key-destroyed here, aged out at a named horizon here, excluded at the next retrain here, retained deliberately here for this legal reason. That table is the deliverable and it is what a regulator asks for, because the obligation is not perfect deletion — it is knowing where the data is and justifying what you did about each copy. Which makes erasure an architectural property you build before you need it: every decision that scatters personal data, from copying payloads into events to letting teams self-serve extracts, is a decision to make erasure harder, and the time to say so is when it is taken.

Erasure is not a delete statement, it is an inventory plus a defensible mechanism per copy; and the two techniques that make the immutable copies tractable, crypto-shredding and pseudonymisation, only work if you chose them long before the request landed.