Your erasure process works. You have tested it. A data subject invokes Article 17, your team runs the procedure, the record is gone from the primary database, the replicas catch up, the search index is reindexed, the caches expire.
Then someone restores last month's backup to debug a production incident, and the person you erased is back.
Backups are the part of Article 17 that most compliance documentation skips, because it is the part with no clean answer. This is what the regulation actually asks for, what the guidance says, and what the options look like when your backup format cannot be edited.
What the regulation says, and what it does not
Article 17 requires erasure without undue delay. It does not mention backups. That silence is where seven years of argument have lived.
The UK ICO's position is that backups are within scope, but that the obligation is shaped by what is technically possible. If you cannot selectively delete an individual record from a backup, you are expected to put the data "beyond use" — and to delete it when the backup is next restored or cycled. The European Data Protection Board has taken a similar line in guidance and in national enforcement.
"Beyond use" is a real standard with conditions attached. In the ICO's formulation it means you cannot and will not use the data to inform any decision about the individual, you give no other organisation access to it, you protect it with appropriate technical and organisational measures, and you commit to permanent deletion when that becomes possible.
The practical reading: you must be able to describe, to a regulator, exactly what happens to that person's data in your backup estate. Not that it is gone. What happens to it.
Why selective deletion from backups usually is not possible
Most production backup strategies produce artefacts that resist editing, deliberately.
Physical and block-level backups capture the database at the storage layer. There is no row to find. Editing one means restoring the whole snapshot, changing the record, and taking a fresh backup — for every snapshot in retention.
Immutable and WORM storage is the current best practice against ransomware. Object lock on S3, retention locks on tape, append-only repositories. The entire point is that nothing can modify or delete the contents until the retention period expires. A control designed to defeat an attacker also defeats you.
Encrypted, deduplicated archives split data into chunks shared across many backup sets. A chunk containing your data subject's email may be referenced by forty snapshots. Removing it corrupts all of them.
Third-party and managed backups live in a vendor's system with a retention policy you configured once and may not control day to day.
If your backups have any of these properties — and a well-run estate has most of them — surgical deletion is not on the table. That is not a failure of your engineering. It is the security design working as intended.
The documented-process answer
The path most organisations end up on is procedural rather than technical: accept that the data remains in backups until they expire, and build a controlled process around it.
That process needs several parts, and a regulator will ask for each.
A register of erasure requests that outlives the request itself, holding the identifier of the erased subject, the date of erasure from live systems, and the date on which the last backup containing them will expire.
A restore-time suppression step, so that any restore from a backup predating an erasure triggers a replay of erasures against the restored data before it returns to service. This is the part teams most often skip and most often get caught on, because it is the difference between "the data will expire eventually" and "the data cannot come back into use."
A retention policy that actually ends, with a defined maximum age. If any part of your estate keeps backups indefinitely, "we will delete it when the backup cycles" is not a commitment, it is a deferral.
An audit trail proving the above ran: who was erased, when, which restores happened, and whether suppression was applied.
The weakness of this answer is that it depends on people and processes running correctly under pressure, months after the original request, often during an incident. It is defensible. It is not robust.
The cryptographic answer
There is a second option, and it changes the shape of the problem rather than managing it.
If the personal data in your database was never stored in plaintext — if what your application wrote was a token, with the underlying value held encrypted under a key you control separately — then your backups contain ciphertext and tokens. They always did. Every snapshot, including the ones already sealed under an object lock, holds values that cannot be read without a key held elsewhere.
Erasure then means destroying the key material for that data, not editing the backup. What remains in the archive is unreadable and stays unreadable, including on restore. There is nothing to suppress at restore time, because the restored rows do not contain personal data either.
This is usually called crypto-shredding, and it is worth being precise about what it does and does not give you.
It does not make the ciphertext disappear. It makes it unreadable with current cryptography, which is the same guarantee your encryption at rest already relies on. Regulators have generally accepted this as putting data beyond use, but the acceptance rests on the strength of the scheme and on the keys genuinely being destroyed rather than archived somewhere else.
It requires key granularity to be planned in advance. One key per tenant does not let you erase one person. If the key you destroy covers a thousand customers, you have not solved erasure, you have created an outage.
It shifts the burden onto key management. The question a regulator asks moves from "where are the copies" to "prove the key is gone, and prove no copy of it exists in a backup of your key store." That is a narrower question, with a clearer answer, but it is not a free one — and a key vault that is itself backed up naively reintroduces exactly the problem you were solving.
Which one applies to you
If your application already holds plaintext personal data in its primary database, the cryptographic route is not something you can adopt retroactively for existing backups. Those snapshots contain what they contain. For them, the documented-process answer is the only honest one, and building it properly is worth doing now rather than during an inquiry.
For data collected from this point forward, the choice is architectural, and it is the difference between managing the backup problem forever and not having it.
Either way, the question to bring to your next architecture review is not whether you can delete a user. It is what a restore of a six-month-old snapshot would put back into production, and whether anything in your system would notice.
Obsydia Core0 takes the tokenisation approach: values are encrypted at field level before they reach your database, so your backups hold tokens rather than personal data. You can read how the separation between data and keys is enforced in the architecture notes.