GDPR-compliant backups: what your retention policy actually needs to say

Your app has backups, which feels like the responsible thing. Then a customer asks you to delete their data, or an auditor asks how long you keep it, and you realize you have no written answer. How long do the backups live? Do they include the data you just promised to erase? Nobody wrote it down, so nobody knows.

A backup retention policy is the short document that answers those questions before someone asks. This post covers what it needs to say to line up with GDPR, and how to handle the awkward overlap between keeping backups and deleting data on request.

The rule that shapes everything: storage limitation

GDPR has a principle called storage limitation (Article 5(1)(e)). In plain terms: don’t keep personal data longer than you actually need it for the purpose you collected it. Backups are personal data. So “we keep every backup forever, just in case” is not a neutral safety choice. It’s a policy decision you have to be able to justify.

That pulls against a real operational need. You want enough backup history to recover from a problem you didn’t notice immediately, like a bad migration that corrupted records three weeks ago. The answer isn’t “keep nothing” or “keep everything.” It’s to pick a retention window on purpose, write down why, and delete on schedule.

Two more GDPR ideas matter here:

Right to erasure (Article 17). People can ask you to delete their data. Backups make this messy, because you can’t easily reach into a snapshot from last Tuesday and surgically remove one person.
Integrity and confidentiality (Article 5(1)(f)). Backups have to be secured and, sensibly, encrypted. A backup file sitting unencrypted in someone’s cloud drive is a breach waiting to happen.

What your retention policy needs to say

A good policy is one page. It should cover these points, with real numbers, not “as appropriate.”

What’s backed up. Which databases and systems, and what kinds of personal data they hold.
How often backups run. Daily, hourly, continuous. Point-in-time recovery, which lets you restore to any moment, is stronger than a nightly snapshot, but either way, name it.
How long each backup is kept. State the window in days. A common, defensible pattern for a small app is something like: daily backups kept 30 days, then deleted. Pick what fits your recovery needs and justify it in one sentence.
When and how old backups are deleted. Automatic deletion on a schedule beats “someone remembers to clean up.” Say it’s automatic and say the interval.
Where backups live and in which country. If they sit outside the UK/EU, the same data-transfer rules that apply to your live data apply to the backups. A backup quietly stored in a US region is still a transfer.
How backups are secured. Encryption at rest and in transit, and who can access or restore them.
How erasure requests interact with backups. This is the part most policies skip. See below.
Who owns the policy and when it’s reviewed. A named person and a review date, yearly at least.

Squaring backups with the right to erasure

Here’s the honest position most regulators accept. When someone asks you to erase their data, you delete it from your live systems right away. You are not expected to crack open every historical backup and surgically remove that one person immediately. That would often be technically impossible and would risk corrupting the backup.

What you do instead:

Delete the data from live systems promptly.
Make sure the person’s data won’t be silently restored. If you ever restore an old backup that still contains their record, you re-apply the erasure right after.
Write this approach into your policy so it’s a documented, consistent process, not an improvisation.
Keep the backup retention window short enough that the deleted data ages out of backups on its own within a defined, reasonable period.

The short retention window is what makes this defensible. If backups are deleted after 30 days, then within 30 days the erased data is gone from backups too, without any manual surgery. If you keep backups for seven years, that argument falls apart, and you’ve also breached storage limitation. Short windows solve two problems at once.

Document the restore-then-re-erase step. An auditor is far more comfortable with “we have a written process for this” than with a team improvising under pressure.

A quick self-check

Run through these. A “no” is a gap to fix.

Is there a written retention window, in days, for each backup type?
Are old backups deleted automatically on a schedule?
Are backups encrypted and access-controlled?
Do you know which country your backups sit in?
Has a restore actually been tested, so you know the backups work?
Does the policy say what happens to backups when someone requests erasure?

That fifth point deserves its own emphasis. A backup you’ve never restored is a guess, not a safety net. Untested backups fail silently, and you only find out during the incident you needed them for. If you want a walk-through of testing a restore end to end, see our backup and restore tutorial.

Or, we do it for you

Writing the policy is the easy half. The hard half is backups that actually run, sit in the EU, are encrypted, and have a tested restore path. That’s our default setup for the apps we host: point-in-time recovery, EU storage, and restores we’ve proven work. See our for-SME page.

FAQ

How long should we keep backups?

There’s no single legal number. Pick the shortest window that still lets you recover from problems you might not notice for a while, then write down the reason. For many small apps, 30 days of daily backups is a reasonable, defensible default. The key is that it’s chosen on purpose and deleted on schedule, not open-ended.

Do we really have to delete a person from old backups when they ask?

Not immediately from every historical backup. You delete from live systems promptly, and you make sure their data isn’t quietly reintroduced if you restore an old backup later. A short retention window means the data ages out of backups on its own within a defined period. Document this so it’s a consistent process.

Does it matter where our backups are stored?

Yes. Backups are personal data, so the same data-residency and transfer rules that apply to your live database apply to the backups. A backup stored outside the UK/EU is a data transfer and needs the same legal basis. Know the country your backups sit in.

What counts as a “tested” backup?

One where you’ve actually restored it into a working system and confirmed the data came back intact, not just that the backup file exists. A restore you’ve never run is an assumption. Test it on a schedule, and record the date you last did.