Right to Erasure

Article 17 of GDPR, with equivalents elsewhere. It is not absolute — legal obligations, contractual necessity and defence of legal claims can override it — but where it applies it must be satisfied within a month, and it applies to every copy.

That last word is where architecture meets the requirement, and the enumeration is longer than people expect: the primary database, read replicas, caches, search indexes, the analytical warehouse, the data lake, event logs, message queues holding unprocessed events, application logs, backups, disaster-recovery copies, third-party processors, and the observability platform where a trace payload or an error message carried the data unnoticed.

The architectural responses. Data minimisation first — the strongest control is not holding it. Tokenisation or a reference model so personal data lives in one store and everything else holds a pointer. Crypto-shredding for immutable stores. A defined backup expiry window, documented as the erasure boundary for backups, which is the usual accepted position. And lineage, so the copies can actually be enumerated rather than guessed.

The engineering conclusion: erasure is a design requirement to be established at the start, because retrofitting it onto an architecture that has copied data freely is one of the most expensive remediations there is.