Backup retention policy: how to set one, with examples
Key takeaways
- The NCSC says backup owners should set in advance how long backups are kept, and that this may differ for different types of data
- The NCSC recommends retention based on time rather than a fixed number of backups, which the NCSC says will prevent an attacker overwriting the backup store with a series of corrupted backups in quick succession
- Its own example is daily backups kept for a month and monthly backups kept for a year
- The UK GDPR sets no fixed retention periods for personal data, so you set them and must be able to justify them
- GOV.UK says company accounting records must be kept for 6 years from the end of the last company financial year they relate to, and PAYE records for 3 years from the end of the tax year
Part of our Backup and recovery guide. See all guides.
A backup retention policy answers one question: how long do you keep each backup before it is deleted? Keep too little and you cannot go back far enough after a quiet ransomware attack or a mistake nobody noticed. Keep too much and you pay for storage you do not need, and may hold personal data longer than the law allows. This guide sets out what UK guidance says, how tiered retention works, and gives examples you can adapt.
What is a backup retention policy?
It is a set of rules that says how long each backup is kept, and often how many backups are kept at each level, daily, weekly, monthly or yearly. The NCSC puts it simply: backup data cannot be stored forever, so system owners should be able to set policies in advance that specify how long a backup should be kept.
The NCSC adds two points that shape the whole policy. Retention should align with the backup schedule, and it may be different for different types of data. A finance database and a shared drive of marketing files do not need the same rules.
Retention is separate from how often you back up. Frequency decides how much data you could lose, which is your recovery point objective. Our guide to RPO, RTO and MTD covers that side. Retention decides how far back you can go.
Why base retention on time, not a number of copies
The NCSC's principles for ransomware-resistant cloud backups recommend retention based on time rather than a fixed number of backups. The reason is an attack it describes directly: if an attacker can flood the backup store with corrupted backup data, they do not need to delete anything. With a count-based rule, such as "keep the last few backups", a quick series of corrupted backups pushes every good copy out.
With a time-based rule, such as "keep every daily backup for a month", the good copies stay until their time is up, however many new backups arrive. The NCSC also says the backup service should let you store backups for a retention period that aligns with your risk appetite, and that you should monitor and test the state of your backups regularly so you notice if they are being corrupted.
The same principles cover deletion. The NCSC describes soft delete, where deleted backup data stays recoverable for a period in a separate area that customer accounts, and so attackers, cannot delete from or overwrite. It says this only works if someone monitors the backup system and gets an alert, because an attacker who soft-deletes everything unnoticed until the review period ends can subvert it. Our guide to immutable vs air-gapped backups goes further into protecting copies.
How tiered retention works: daily, weekly, monthly, yearly
Most retention policies use tiers. Recent backups are kept at a fine grain, and older ones are thinned out to one a week, one a month or one a year. The arrangement is often called grandfather, father, son, or GFS.
The NCSC gives a two-tier illustration: a system owner might decide to keep daily backups for a month, and monthly backups for a year.
Microsoft's documentation for long-term retention in Azure SQL Database shows the four common tiers as settings: weekly retention (W), monthly retention (M), yearly retention (Y) and the week of the year whose backup is kept as the yearly copy. Its published examples are a useful way to read any GFS policy:
| Policy | What is kept |
|---|---|
| W=12 | Each weekly full backup, for 12 weeks |
| M=3 | The first full backup of each month, for three months |
| Y=5, week 3 | The third full backup of each year, for five years |
| W=6, M=12, Y=10, week 20 | Weekly backups for six weeks, the first backup of each month for 12 months, and the week 20 backup for 10 years |
Microsoft also notes that changes to a retention policy apply only to future backups. Existing backups keep the retention they were created with. That matters if you shorten retention to save money: the saving arrives gradually, not on the day you change the setting.
In AWS Backup the same idea appears as a lifecycle on each backup rule. The total retention period is the number of days a backup is stored, counting warm storage plus cold storage. AWS says cold storage needs a total retention period of 90 days or more, and recommends not moving a backup to cold storage until after at least 8 days. Its sample backup plan takes a daily backup and deletes each one after a year.
What the law says about how long to keep backups
There is no single UK law that sets a retention period for backups. Two sets of rules pull in different directions, and your policy has to satisfy both.
Personal data. The UK GDPR's storage limitation principle, Article 5(1)(e), says personal data must be kept in a form which permits identification of people for no longer than is necessary. The ICO says the UK GDPR does not set specific time limits for different types of data. That is up to you, and depends on how long you need the data. The ICO expects you to know what personal data you hold and why, to be able to justify how long you keep it, and to have a policy with standard retention periods where possible. It also says personal data held for too long will, by definition, be unnecessary. Backups are copies of personal data, so they need a period you can defend. Our guide to UK GDPR, backups and the right to erasure covers erasure requests that reach backups.
Business and tax records. GOV.UK says a limited company must keep its accounting records for 6 years from the end of the last company financial year they relate to, or longer in some cases. You can be fined £3,000 by HMRC or disqualified as a company director if you do not keep accounting records. Employers must keep PAYE records for 3 years from the end of the tax year they relate to.
Those are duties to keep records, not backups. In our view, the safest approach is to keep the records themselves in a proper archive or in the system of record, and set backup retention for recovery, not as the only place an old record survives.
Backup retention policy examples
These are illustrations to adapt, not rules. Each one starts from what the data is for and what could go wrong.
Example 1: a small office shared drive. Follow the NCSC illustration: daily backups kept for a month, and monthly backups kept for a year. A month of dailies covers a deleted folder nobody misses for a few weeks. A year of monthlies covers a slow problem, such as a file that was corrupted months ago. Keep at least one copy offline, in line with the NCSC's advice, in its blog on cloud backups, that at least one backup should be offline at any given time.
Example 2: a line-of-business database. Use four tiers, in the shape of Microsoft's W=6, M=12, Y=10 example but with periods set from your own needs: daily or point-in-time backups for a few weeks, weekly for a couple of months, monthly for a year, and a yearly copy only if a real requirement, such as a contract or regulator, asks for one. In our view, yearly copies kept for years should be the exception, because every year added is another year of personal data you must justify.
Example 3: a finance system. Back it up for recovery as in Example 2, and separately archive the year-end accounting records so they are kept for at least the 6 years GOV.UK requires. Then the backup policy can stay short, while the records duty is met by the archive.
Example 4: laptops and user devices. If work files sync to a company drive that is itself backed up, device backups can be short, and the drive's policy does the long-term work. Check that the sync tool keeps deleted and earlier versions for a period, since the NCSC suggests checking that cloud storage can restore older versions and recover deleted data for a limited time.
How to write your backup retention policy
- List your data types. For each system, note what it holds, who owns it, and whether it holds personal data. The ICO's first expectation is that you know what personal data you hold and why.
- Set the recovery need. Decide how far back you might need to go for each type: days for accidental deletion, weeks or months for ransomware or corruption found late.
- Set the legal limits. Note any period you must keep records for, such as company accounts, and any point after which personal data is no longer needed.
- Choose tiers and periods by time. Write the rule as "keep each daily backup for a month", not "keep the last few backups", as the NCSC recommends.
- Protect the copies. Keep at least one copy offline or immutable, with soft delete and alerts on mass deletion, in line with the NCSC principles.
- Test restores at every tier. Microsoft suggests considering periodic recovery drills to check long-term backups can be restored and give the expected result. Our guide to how often to test disaster recovery plans has a schedule.
- Review it. The ICO expects retention periods to be reviewed at appropriate intervals. Review the backup policy at the same time.
Retention and the 3-2-1 rule
Retention says how long, and the 3-2-1 rule says where. The NCSC describes 3-2-1 as at least 3 copies, on 2 devices, and 1 offsite, and notes that it does not require any copy to be offline, which is why it adds an offline rule of its own. A good policy sets retention for each copy: the offsite or offline copy often keeps the longest history, because it is the one most likely to survive an attack. Our 3-2-1 backup rule guide explains how to set up the copies.
FAQ
What is a backup retention policy?
It is a rule that says how long each backup is kept before it is deleted. The NCSC says system owners should be able to set these policies in advance, aligned with the backup schedule, and that they may differ for different types of data.
What is a good backup retention policy example?
The NCSC gives an illustration: keep daily backups for a month and monthly backups for a year. Many backup tools add weekly and yearly tiers on top, as Microsoft's Azure SQL long-term retention settings show.
Should retention be based on time or on the number of backups?
The NCSC recommends time. If you keep a fixed number of backups, an attacker can overwrite the store with a series of corrupted backups in quick succession and push the good ones out.
How long should a UK company keep backups of its accounts?
GOV.UK says company accounting records must be kept for 6 years from the end of the last company financial year they relate to, or longer in some cases. In our view, keep the records themselves in a proper archive rather than relying on old backups to meet that duty.
Can I keep backups forever to be safe?
Not if they hold personal data you no longer need. The ICO says personal data held for too long will, by definition, be unnecessary, so backups containing it need a retention period you can justify.
