There is a button in your admin panel. It says "Delete User." Your engineers built it eighteen months ago. Your legal team signed off on it. Your privacy policy references it.
When a user invokes their right to erasure under GDPR Article 17, someone clicks that button.
The record disappears from the UI. The support ticket is closed. The user is told their data has been deleted.
It has not been deleted.
In most application databases, deleting a record means marking it as deleted. The data remains on disk until that space is overwritten — which may never happen, or may happen years later.
But the soft-delete problem is almost trivial compared to what happens everywhere else.
Write-ahead logs. Every major database — PostgreSQL, MySQL, MongoDB — maintains a write-ahead log for crash recovery. Every write operation, including the original INSERT of your user's personal data, is recorded there. Deleting the row does not delete the WAL entry. The data sits in the log, intact, until the log is rotated — which your DBA may have set to 30 days, 90 days, or never.
Replication streams. If you run a read replica — and most production databases do — the replication stream contains a complete record of every transaction. Your user's data exists on the primary, on the replica, and in the binary log used to keep them in sync.
Backups. You run nightly backups. Excellent. Each of those backups contains a snapshot of your database at a point in time. Deleting a record today does nothing to the backup from last Tuesday, or last month, or last year. How long do you retain backups? Do you know?
Application caches. Redis, Memcached, your CDN's edge cache. Did the user's data end up cached? When does that cache expire?
Search indexes. Elasticsearch, Algolia, your full-text search layer. Was the user's name or email indexed for search? Is it still there?
Analytics pipelines. Did you pipe events to your data warehouse? Segment, Mixpanel, BigQuery? Is the user's personal data in your event stream?
Audit logs. Every time someone in your system accessed this user's record — support tickets, admin lookups, API calls — there is a log entry. Those log entries reference the user by name, email, or identifier.
The regulation is precise. Erasure must be without undue delay. It applies to all copies of the data, in all storage layers, including backups where technically feasible.
The phrase "technically feasible" has done a lot of work in compliance conversations over the past seven years. Teams interpret it charitably. Regulators are beginning to interpret it less so.
The ICO's guidance is clear: where a controller cannot selectively delete from backups, they must have a documented process for ensuring the data is not restored from backup, and must delete it when the backup is eventually processed.
This is harder than it sounds. It means you need to know, for every user who invokes Article 17:
Most engineering teams cannot answer these questions. Not because they are incompetent — because the systems were not designed with this question in mind.
Here is how this typically surfaces.
A user complains to their national supervisory authority. The authority contacts you with a formal inquiry. They want to know what steps you took to ensure complete erasure of the data subject's personal information, across all processing systems.
You ask your engineering team. They point to the delete function in the admin panel.
The authority asks: what about your write-ahead logs? Your replication stream? Your nightly backups? Your analytics pipeline?
Your engineering team goes quiet.
This is not a hypothetical. It is the pattern in enforcement actions across the EU. The fine is rarely for the original processing. It is for the inadequate response to the erasure request — the inability to demonstrate that erasure actually occurred.
The root cause is not negligence. It is architecture.
Most applications are designed around a single question: how do we store and retrieve data efficiently? The question of how do we completely and demonstrably remove data from every layer of the system is an afterthought, added later as a compliance checkbox.
When personal data is stored directly in your application database, removing it completely requires touching every system that has ever seen that data. That is a long list. It grows every time you add an integration, a backup policy, a caching layer, or a new analytics tool.
There is a different approach.
If personal data never enters your application database in plaintext — if it is tokenised at the point of collection, with the raw data stored separately in an isolated system — then erasure becomes a different problem.
You are not hunting across twelve systems for copies of a person's email address. You are deleting one encryption key. The data that remains across your application database, your WAL, your backups, your caches, your search indexes — is ciphertext. Without the key, it is noise. It cannot be reconstructed. It cannot be read. For practical purposes, it does not exist.
This is what cryptographic erasure means. You do not delete the data. You delete the ability to read it.
A regulator asking for evidence of erasure wants one thing: a record they can follow.
The request came in. The data was identified. These specific actions were taken, at these timestamps, across these systems. The cryptographic key was deleted at this exact moment. Here is the signed audit receipt.
That is a story you can tell. "We clicked delete in the admin panel" is not.
The difference between these two answers is not technical complexity. It is architectural foresight — and whether the system was designed from the beginning to answer this question.
Before your next Article 17 request arrives — and it will arrive — ask your engineering team three questions.
Where does our users' personal data actually live, across every system that has ever touched it?
If we deleted a user today, what would remain, and where?
Could we prove to a regulator, with a timestamped audit trail, that erasure was complete?
If the answers are uncertain, you have time to fix that. If the answers are wrong, you are one complaint away from finding out exactly how wrong.
Next: What your cyber insurer's definition of "reasonable security measures" actually means — and whether your architecture qualifies.