The backup problem nobody wants to open
By Dylan Wolpe
The short version
- Backups are the most commonly excluded system in erasure programmes, and the exclusion is usually undocumented, which is worse than excluding them deliberately and writing down why.
- Restoring, deleting and re-taking a backup is impractical at any real scale and defeats the point of an immutable backup in the first place.
- Per-subject key destruction reaches backups only if the backup contains ciphertext and the keys live outside it. If your backup captured the key vault too, you have backed up the thing you were going to destroy.
- The design decision that determines whether erasure is possible is where the keys sit relative to the backup boundary, and it is made long before anyone submits a request.
Ask a data protection team how they handle erasure requests and you will get a clear account of the production database, the warehouse, probably the CRM. Ask what happens to the nightly backups and the answer arrives more slowly, and often begins with the word “well”.
Why it gets skipped
Not negligence, mostly. The mechanics are genuinely awful. A conventional backup is a sealed artefact, frequently on immutable storage precisely so it cannot be tampered with, and deleting one person from it means restoring it, modifying it, and re-sealing it.
At scale that is absurd: hundreds of backup sets, each requiring a restore to remove a few kilobytes, with the modified backup no longer being the backup that was taken. You have broken the property that made it a backup in order to satisfy a requirement about a property it never had.
So the pragmatic answer becomes “we delete from production and let backups age out”. Which is often a defensible position, and stops being defensible the moment nobody writes it down.
The problem is rarely the exclusion. It is that the exclusion is undocumented, so it looks like an oversight rather than a decision.
What regulators have broadly accepted
Supervisory authorities have generally been practical about this. The recurring shape of an acceptable position is:
- Backups are within scope, you cannot pretend they are not data you hold.
- Immediate deletion from backups may be impractical, and saying so is acceptable.
- The data must not be restored into production without re-applying outstanding erasure requests.
- Backups must age out on a defined, actually-enforced schedule.
- All of the above is written down before anyone asks.
The failure mode is not usually a firm that reasoned through this and reached a defensible conclusion. It is a firm that never considered backups, restores one during an incident, and silently reintroduces personal data it certified as deleted eighteen months earlier.
Where key-based erasure does and does not reach
Cryptographic erasure changes the picture, but only if one design decision went the right way. The question is where the keys sit relative to the backup boundary.
| Backup contains | Destroy the key and… | Verdict |
|---|---|---|
| Ciphertext only; keys held elsewhere | Every backup copy becomes undecryptable at once | Erasure reaches the backups |
| Ciphertext and the key vault | You restore the key with the backup | Erasure does not reach them |
| Plaintext personal data | Nothing, there was no key | No mechanism available |
The first row is the case worth designing for, and it is genuinely powerful: one key destruction renders that subject unrecoverable across every copy that exists anywhere, without touching any of them. No restores, no re-sealing, no enumeration of where the copies went.
The second row is the trap, and it is easy to fall into because backing up the key vault is exactly what a careful operations team would do. Disaster recovery reasoning and erasure reasoning point in opposite directions here, and whichever team asks last usually loses.
What to actually do
Find out which backups contain personal data. A surprising number of organisations cannot answer this, which makes every downstream statement about erasure unverifiable.
Check where your keys are backed up to. If your key management system replicates to a DR region that is itself snapshotted, your key destruction is not destruction. This is the same failure discussed in key custody, and backups are where it most often hides.
Write the position down. Which backups, why deletion is impractical, what happens on restore, when each set ages out. An inspection asks to see your reasoning far more often than it asks to see a deleted record.
Make restore a re-processing step. If a restore does not re-apply outstanding erasure requests, then every restore quietly undoes part of your compliance record, and nobody notices, because the whole point of a restore is that things come back.
Questions people ask about this
Do I have to delete personal data from backups under GDPR?
The obligation applies to personal data you hold, and backups are data you hold. Regulators have generally accepted that immediate deletion from backups is often impractical, and have expected a documented approach, typically that the data will not be restored into production and will age out on a defined schedule. What they have not accepted is silently ignoring backups.
Can you delete one person from a backup without restoring it?
Only if the backup holds encrypted per-subject data and the keys are stored outside the backup. Destroy the key and the ciphertext in every backup copy becomes permanently undecryptable, with no restore required. If the backup also captured the keys, you have preserved exactly what you intended to destroy.
What should we do about existing backups that were not designed this way?
Document the position honestly: which backups contain personal data, why deletion from them is impractical, that restored data will be re-processed against outstanding erasure requests, and when each backup ages out. A documented, defensible position is far better than an undocumented exclusion, and it is what an inspection will actually ask about.