Handling Personal Data in Backups Without Undermining Erasure Rights
Backups are designed to be immutable and durable, which is in direct tension with erasure obligations. Here is how to reconcile the two.
The structural conflict nobody resolves by policy alone
Backup systems exist to preserve data reliably against deletion, corruption, and disaster; erasure obligations under Section 8(7) exist to guarantee data is actually gone once the purpose has lapsed or consent is withdrawn. These two goals are in direct tension, and no amount of policy language resolves it — a backup that still contains a supposedly erased record is a real gap regardless of what the retention policy document says should happen.
The honest starting point is acknowledging that immediate, surgical erasure from every backup snapshot is usually not technically feasible in the way it is for a live database. What is feasible, and what a reasonable design should target, is ensuring erased data cannot be restored back into a live, accessible state without also being subject to the same erasure trigger it was already flagged under.
Crypto-shredding as the practical mechanism
Crypto-shredding — encrypting data with a key that is itself deletable, and destroying that key when erasure is required — is the standard technical answer to the backup problem. If personal data in backups is encrypted at the record or tenant level with keys that can be independently destroyed, erasure can be satisfied by deleting the key rather than needing to physically locate and remove the record from every historical snapshot. The backup snapshot itself can remain intact and durable; the data within it becomes permanently unreadable.
This only works if the key granularity matches your actual erasure granularity. A single key shared across your entire backup corpus makes crypto-shredding useless for individual erasure requests, since destroying it destroys everything. Keys need to be scoped per user, per tenant, or per some other unit that aligns with how erasure requests actually arrive, which has real implications for backup architecture decided well before the first erasure request comes in.
Restore-time filtering as a second line of defense
Even with crypto-shredding, restores from older backups can reintroduce data that was erased after that backup was taken, if the restore is a full point-in-time recovery rather than a scoped one. A restore-time filtering step — checking restored records against an erasure log before they go live again in production — catches this gap, re-applying erasure to anything the backup reintroduced that should no longer exist.
This requires maintaining an erasure log independent of the primary data store, recording what was erased and when, so it survives even if the primary system is the one being restored from an older backup. Without that independent log, there is no way to know, post-restore, what needs to be re-erased.
Aligning backup retention with your policy, not against it
Backup retention windows are often set by infrastructure teams for disaster recovery reasons with no reference to the organisation's data retention policy, which means backups can end up retaining personal data far longer than the live system does. Shortening backup retention windows to something defensible, and documenting the disaster-recovery rationale for whatever window remains, closes an otherwise easy gap to spot in a review.
Where a genuinely long backup retention window is operationally necessary, pair it explicitly with the crypto-shredding and restore-time filtering controls above, so the retention period is not, by itself, treated as evidence that erasure obligations are being ignored for backed-up data.
Where to go next
The Retention Planner tool on this site can help you set backup retention windows that are deliberate and documented rather than inherited defaults, and the Evidence Tracker is useful for keeping the erasure log itself in an auditable form.