Most companies think they've implemented GDPR's right to erasure when they add a "Delete Account" button to their settings page. They haven't.
Article 17 of the GDPR requires that personal data be erased "without undue delay." What that means technically is something most engineering teams have never fully mapped. And when a regulator asks for proof — not a promise, but cryptographic proof — that a specific individual's data is gone from every storage layer, most systems fail.
This article explains what Art.17 actually requires technically, where most implementations fall short, and what a compliant architecture looks like.
The legal text is deceptively simple:
"The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay."
The key phrase is "personal data concerning him or her" — not "the record in your main database." Personal data lives in many places simultaneously. Compliant erasure means removing it from all of them, provably, with an audit trail that survives the deletion itself.
Before you can erase data, you need to know where it is. Most engineers think about the main database. Regulators think about everything else.
1. Your primary database
The obvious one. DELETE FROM users WHERE id = $1. Most teams stop here.
2. Write-ahead logs (WAL)
Every major database — PostgreSQL, MySQL, MongoDB — maintains a WAL for crash recovery and replication. When you delete a row, the WAL records that a deletion occurred. But depending on your retention settings, the original data may remain in WAL segments for hours, days, or weeks.
3. Replication streams
If you run read replicas or a hot standby, data is replicated — including the pre-deletion state. A deletion on your primary does not immediately propagate everywhere, and replicas may retain stale data during lag windows.
4. Backup snapshots
Your nightly backups contain the data as it existed at snapshot time. Deleting from the primary does nothing to existing backups. If those backups are retained for 30 days, the person's data lives in 30 snapshots.
5. Application logs
How many of your debug logs contain user_email=john@company.com or Processing payment for card ending 4242? Log aggregators like Datadog, Splunk, and CloudWatch retain log data independently of your application database.
6. Vendor systems
Every SaaS tool you've connected to your application — your CRM, your support platform, your email provider, your analytics tool — may have received and retained copies of that user's data. Each vendor is a separate controller or processor with their own retention policies.
7. CDN and caching layers
If you've served personalised content through a CDN, that content may be cached at edge nodes globally.
8. Search indexes
Elasticsearch, Algolia, and similar systems maintain their own indexes. A deletion from your primary database does not automatically propagate to search.
DELETE Is Not EnoughConsider this sequence:
-- User requests erasure at 09:00
DELETE FROM users WHERE id = 12345;
DELETE FROM orders WHERE user_id = 12345;
DELETE FROM addresses WHERE user_id = 12345;
-- Done. Or is it?
What remains after this operation:
A regulator asking "prove this person's data is gone" after this operation would find multiple active copies. The delete button deleted one copy.
Modern application architectures are designed to replicate data for performance, reliability, and observability. Every mechanism that makes your system fast and resilient — caching, replication, logging, backups — creates additional copies of personal data.
You cannot solve this problem at deletion time. By the time a user requests erasure, their data has already propagated into dozens of systems. Trying to chase it down at that point is operationally complex, error-prone, and impossible to prove completely.
The only architecture that reliably solves Art.17 is one that never stores plaintext personal data in the first place.
The approach that makes Art.17 technically tractable is field-level tokenisation at the point of ingestion.
Instead of storing john@company.com in your database, your application stores tk_91asx3f2b8d... — a cryptographic token that references the original value in an isolated, encrypted vault. Your application logic, your logs, your replicas, your backups — all of them contain only tokens.
Application sends: field: "email", value: "john@company.com"
Vault returns: token: "tk_91asx3f2b8d..."
Application stores: tk_91asx3f2b8d...
When a user requests erasure, you don't need to find and delete copies. You erase the value from the vault and rotate or destroy the encryption key. Every system that holds the token now holds a reference to nothing. The token is meaningless without the vault, and the vault no longer contains the value.
This is not just a technical convenience — it's a fundamentally different relationship between your application and personal data.
A compliant Art.17 implementation produces an audit trail that answers these questions:
The audit record itself must survive the deletion. You need proof that the erasure happened, which means the log of the erasure is not personal data and does not need to be erased.
A well-designed system generates a signed erasure receipt — a cryptographic proof that a specific token's underlying value was purged from all nodes, including write-ahead logs on every replica.
This deserves specific attention because it catches most teams.
PostgreSQL's WAL retention is controlled by wal_keep_size and archiving configuration. In a default setup with streaming replication, WAL segments are retained until all replicas have consumed them. If a replica is lagging or disconnected, WAL segments accumulate — potentially containing the pre-deletion state of your personal data.
When you tokenise at ingestion, this problem disappears. The WAL records that a vault entry was created and later purged. It never contains john@company.com. The WAL of your application database contains only tokens.
Architecture
Erasure process
Auditability
Vendor management
Backup policy
Obsydia Core0 is a self-hosted PII vault designed specifically to close the Art.17 gap.
When your application calls Core0, personal data is encrypted at field level with a per-field, per-tenant key before it leaves your application's trust boundary. Your database receives a token. Your logs see a token. Your backups contain tokens.
When a data subject requests erasure, a single API call to DELETE /v1/pii/{token} triggers a coordinated purge across all Core0 nodes — including WAL entries on every replica. The operation is atomic and produces a signed erasure receipt with node-level confirmation.
curl -X DELETE https://your-core0/v1/pii/tk_91asx3f2b8d... \
--cert cert.pem --key key.pem \
-H "X-Tenant-ID: your-tenant"
# Response:
{
"erased": true,
"token": "tk_91asx3f2b8d...",
"nodes_confirmed": 4,
"wal_purged": true,
"timestamp": "2026-07-22T14:23:11Z",
"receipt": "eyJ..."
}
The receipt is a JWT signed with your tenant key — independent proof that erasure occurred, even if Core0 itself were later decommissioned.
Core0 is self-hosted. Your data never leaves your infrastructure, which means cross-border transfer restrictions don't apply, and you control the encryption keys entirely.
GDPR Article 17 compliance is an architectural problem, not a feature you add to an existing system. The delete button deletes one copy. Personal data lives in dozens of places simultaneously — by design, because modern systems are built to replicate.
The only robust solution is to never store plaintext personal data in the systems that replicate. Tokenise at ingestion. Store tokens everywhere. Keep the values in an isolated, encrypted vault with built-in purge mechanics.
When a regulator asks for proof, you hand them a signed receipt with node-level confirmation, not a screenshot of a SQL query.