A GDPR erasure request arrives for a customer. Where does their data actually live, and what makes this expensive to retrofit?

Where the data lives

Longer than people expect, and enumerating it is most of the work:

Primary database · read replicas · caches · search indexes · analytical warehouse · data lake · event logs and streams · message queues holding unprocessed events · application logs · backups · DR copies · third-party processors (payment, email, support, analytics) · the observability platform, where a trace payload, an error message or a request log carried the data without anyone intending it.

The last one is the most commonly missed and the least defensible, because it is usually avoidable.

Why retrofitting is expensive

Copies proliferate silently. Every pipeline, projection, cache and export created another copy, none of them registered anywhere. Without lineage you cannot enumerate them, so the erasure is best-effort and cannot be attested to.

Immutable stores conflict directly. Append-only event logs, immutable backups, versioned object storage and time-travelling tables are all designed not to permit deletion. Solving this after the fact means either rewriting history (which defeats their purpose) or introducing encryption retroactively across data already written in plaintext.

Deletion may break referential integrity in systems that assumed the row would always exist.

The clock is short — one month under Article 17 — which makes a manual process across a dozen systems untenable at any volume.

What makes it cheap when designed in

Data minimisation. The strongest control by a wide margin: data never collected needs no erasure, cannot be breached, and costs nothing to store.

A reference model. Personal data lives in one store; everything else holds a pointer. Erasure becomes a single deletion, and every downstream copy holds an identifier that no longer resolves.

Crypto-shredding for immutable stores: per-subject encryption keys, destroyed on request. The ciphertext persists and is permanently unreadable — the only approach that reaches backups and event logs without rewriting them.

A documented backup expiry window as the stated erasure boundary for backups, which is the generally accepted position.

Lineage, so the copies can be enumerated rather than guessed.

What a strong answer adds

Distinguishing erasure from anonymisation. Properly anonymised data — where re-identification is not reasonably possible even in combination with other data — falls outside GDPR entirely and need not be deleted. That makes anonymisation of analytical datasets a design decision with a large compliance payoff, and it is worth doing deliberately rather than discovering the obligation later.