Backup Retention Policies: How Long to Keep Your Data

Every UK business that takes backup seriously eventually confronts the same question: how long should we keep our backups? The answer is rarely simple. Keep data too long and you accumulate vast storage costs, GDPR complications, and an ever-growing attack surface. Delete data too soon and you may find yourself unable to recover from a slow-burning ransomware infection, respond to a legal discovery request, or meet regulatory retention requirements.

A backup retention policy defines how long different types of backup data are stored before being deleted or overwritten. It is not a one-size-fits-all setting — different data types, regulatory requirements, and business needs demand different retention periods. A well-designed retention policy balances legal obligations, business requirements, storage costs, and data protection principles to keep the right data for the right amount of time.

This guide explains how to build a backup retention policy for a UK business, covering the regulatory landscape, common retention schemes, cost implications, and the practical steps to implement and maintain your policy.

Why Retention Policies Matter

Without a clear retention policy, businesses tend to adopt one of two equally problematic approaches. Some keep everything forever, accumulating enormous volumes of backup data that drives up storage costs, creates GDPR compliance issues (since UK GDPR requires that personal data is not kept longer than necessary), and increases the potential impact of a data breach. Others keep too little, overwriting old backups after just a few days, leaving them unable to recover from incidents that are only discovered weeks or months later.

A retention policy addresses both extremes by defining clear, documented rules for how long different types of data are kept. It provides certainty for IT teams managing backup storage, compliance evidence for regulators and auditors, protection against legal discovery obligations, defence against slow-burn threats like ransomware and insider attacks, and cost predictability for storage budgets.

The Business Case for Documented Retention Policies

Beyond regulatory compliance, a documented retention policy delivers tangible business benefits that are frequently overlooked. From an audit perspective, having a clear, written policy demonstrates to external auditors, regulators, and business partners that your organisation takes data governance seriously. When HMRC conducts a compliance check, or when a prospective client includes data protection requirements in their supplier due diligence questionnaire, a documented retention policy provides ready-made evidence of your approach — saving considerable time and reducing the risk of unfavourable findings.

Insurance considerations also play an increasingly important role. Many cyber insurance policies now include conditions around data backup and retention practices. Insurers may require evidence that your organisation maintains backup copies of critical data for specified minimum periods, and that these backups are tested regularly. Failure to meet these conditions could invalidate a claim at precisely the moment you need coverage most. A documented retention policy that aligns with your insurer's requirements provides the evidence base needed to support a claim should the worst happen.

For organisations with boards of directors or trustees, retention policy governance is increasingly recognised as a board-level responsibility. The UK Corporate Governance Code and the Charity Governance Code both emphasise the importance of effective risk management, and data loss due to inadequate backup retention represents a material operational risk. Presenting a clear retention policy to the board — along with regular reports on compliance and testing — demonstrates that management is actively addressing this risk rather than leaving it to chance or informal IT department decisions.

Cost predictability is a further practical benefit that resonates with finance teams. Without a defined retention policy, storage costs tend to grow unpredictably as backup data accumulates without any structured expiry process. By setting clear retention periods and automating the deletion of expired backups, you establish a predictable storage profile that can be budgeted for with confidence. This is particularly important for cloud-based backup solutions where storage is metered and billed on a monthly consumption basis.

UK Regulatory Retention Requirements

Several UK regulations specify minimum retention periods for certain types of data. Your backup retention policy must, at minimum, meet these requirements.

Data Type	Regulation	Minimum Retention Period
Financial records (accounts, invoices, receipts)	Companies Act 2006 / HMRC	6-7 years
VAT records	HMRC VAT regulations	6 years
Payroll records	HMRC PAYE regulations	3 years after the end of the tax year
Employee records	Employment law / HMRC	6 years after employment ends
Health and safety records	Various H&S regulations	3-40 years (depends on type)
Client contracts	Limitation Act 1980	6 years after contract ends
Medical records (healthcare sector)	NHS retention schedule	Up to 30 years
Anti-money laundering records	Money Laundering Regulations 2017	5 years after business relationship ends

Navigating Conflicting Retention Requirements

One of the most challenging aspects of designing a backup retention policy is navigating situations where different regulations impose different — and sometimes apparently conflicting — retention requirements on the same data. For example, UK GDPR's storage limitation principle requires that personal data is not kept longer than necessary, whilst HMRC regulations require financial records containing personal data to be retained for at least six years. These obligations are not truly contradictory, but reconciling them requires careful analysis and thorough documentation of your reasoning.

The standard approach is to apply the longest applicable retention period where multiple regulations govern the same data, provided that you can document a legitimate basis for the longer retention. If HMRC requires you to keep invoices for seven years and UK GDPR requires you to minimise data retention, the HMRC obligation provides a lawful basis for retaining invoice data — including any personal data it contains — for the full seven years. The key is to document this reasoning explicitly in your retention policy so that you can demonstrate compliance with both frameworks if challenged by either the ICO or HMRC.

Where data is genuinely subject to conflicting obligations — for example, where a data subject requests erasure under UK GDPR but the data is also subject to a litigation hold or regulatory retention requirement — the legal retention obligation typically takes precedence. However, you must inform the data subject that their erasure request cannot be fulfilled immediately and explain the legal basis for continued retention. Your retention policy should include procedures for handling these conflicts, ensuring that frontline staff know how to escalate such requests to the appropriate decision-maker within the organisation rather than attempting to resolve them independently.

It is also important to recognise that retention requirements may vary by data type within a single backup set. A single email mailbox backup might contain financial correspondence subject to HMRC retention requirements, personal employee data governed by employment law retention periods, and general business correspondence with no specific regulatory retention obligation. Whilst it is often impractical to apply different retention periods to individual items within a backup, your policy should document the rationale for the retention period chosen for each backup type and explain how it satisfies the various applicable requirements for the different data categories contained within it.

Common Backup Retention Schemes

The most widely used backup retention scheme is the Grandfather-Father-Son (GFS) method, which creates a hierarchy of daily, weekly, monthly, and annual backup points with different retention periods for each tier.

The GFS Retention Model

In a typical GFS scheme, daily backups (the "sons") are retained for a short period — typically 7 to 30 days. Weekly backups (the "fathers") are retained for 4 to 12 weeks. Monthly backups (the "grandfathers") are retained for 12 to 24 months. Annual backups may be retained for 7 to 10 years, depending on regulatory requirements.

This approach provides granular recovery options for recent events (you can restore to any day within the last week or month) while also providing long-term recovery points at lower granularity (monthly snapshots going back a year or more) for compliance and historical purposes.

Implementing GFS in Practice

Translating the GFS retention model from theory into practice requires careful configuration of your backup software and clear documentation of the schedule. The first decision is selecting which backups are promoted to each tier. Typically, the backup taken on a Sunday is designated as the weekly backup, the backup taken on the last day of each calendar month becomes the monthly backup, and the backup taken on the last day of the financial year is preserved as the annual backup. These promoted backups are then retained for their respective tier's duration whilst daily backups from the intervening periods are expired and deleted according to the shorter daily retention schedule.

Most enterprise backup solutions — including Veeam, Acronis, and Commvault — support GFS retention schemes natively, allowing you to configure the promotion schedule and retention periods through a straightforward policy interface. When setting up GFS retention, pay particular attention to time zone settings, as a misconfigured time zone can cause the wrong backup to be promoted to the weekly or monthly tier. Verify the schedule by checking which specific backups have been flagged for promotion after the first few cycles of operation and confirming they align with your intended schedule.

Testing is a critical yet frequently neglected component of any GFS implementation. It is not sufficient to verify that backups are being created and retained according to schedule — you must also periodically confirm that data can actually be restored from each retention tier. A monthly backup from six months ago is entirely worthless if the backup file is corrupted, the restore software cannot read it, or the encryption keys have been lost or rotated. Schedule quarterly test restores from different retention tiers, rotating through daily, weekly, monthly, and annual backups to verify the integrity and recoverability of each tier over time.

Documentation should accompany your GFS implementation, recording the specific schedule, the retention periods for each tier, the storage locations used at each level, and the testing schedule and results. This documentation serves both as an operational reference for your IT team and as compliance evidence for regulators and auditors who may ask to see your data protection arrangements. Keep the documentation updated whenever changes are made to the backup configuration, and review it at least annually as part of your broader retention policy review cycle.

Ransomware Considerations

The rise of ransomware has forced many businesses to reconsider their retention periods. Modern ransomware variants often operate silently for weeks or months, encrypting files gradually or remaining dormant until a critical mass of backups has been infected. If your daily backups only go back 14 days and the ransomware has been present for 30 days, every single backup in your rotation is compromised.

For this reason, we now recommend that businesses maintain at least 90 days of daily backup retention — ideally longer — along with monthly backups going back at least 12 months. This provides a reasonable probability of having a clean recovery point even if a ransomware infection goes undetected for an extended period.

Immutability and Air-Gapped Backups

The single most important advancement in backup technology in recent years is the concept of immutable backups. An immutable backup is one that cannot be modified, encrypted, or deleted — even by an administrator with full access to the backup infrastructure. This property is critical because modern ransomware variants increasingly target backup systems themselves, encrypting or deleting backup files to eliminate recovery options before launching the primary attack on production data and systems.

Cloud storage platforms support immutability through features such as Azure Blob Immutable Storage and AWS S3 Object Lock. When a backup is written to immutable storage, a retention lock is applied that prevents any modification or deletion of the data until the specified lock period expires. Even if an attacker compromises an administrator account with full privileges over the backup environment, they cannot alter or destroy immutable backup copies. This provides a guaranteed recovery point that is immune to even the most sophisticated ransomware attacks and malicious insider threats.

Air-gapped backups take the protection concept a step further by physically or logically isolating backup copies from the production network entirely. A traditional air gap involves writing backups to offline media — such as tape cartridges or removable drives — that are physically disconnected from any network when not in use. Modern cloud-based air gaps achieve a similar effect by storing backup copies in a completely separate cloud subscription or account with independent credentials, ensuring that an attacker who compromises the production environment cannot reach the isolated copies through any network path or shared authentication mechanism.

For UK businesses, the combination of immutable storage and logical air gaps represents the current gold standard for backup protection. The National Cyber Security Centre recommends that organisations maintain at least one backup copy that is offline or otherwise protected from ransomware as part of its published guidance on mitigating malware and ransomware attacks. Implementing these protections adds a modest cost premium to your backup solution but provides a level of resilience that can mean the difference between a manageable incident and a catastrophic, potentially business-ending data loss event.

Storage Cost Management

Longer retention periods mean more storage, and storage costs money. The key to managing costs is using tiered storage — keeping recent backups on fast, accessible storage and migrating older backups to cheaper, slower storage tiers.

Cloud storage platforms like Microsoft Azure and Amazon Web Services offer multiple storage tiers designed for exactly this purpose. Azure, for example, offers Hot storage for frequently accessed data, Cool storage for data accessed less than once a month, Cold storage for data accessed less than once a quarter, and Archive storage for data rarely accessed and tolerant of retrieval delays of hours.

The cost difference between tiers is dramatic. Azure Hot storage costs approximately £0.02 per GB per month, while Archive storage costs around £0.001 per GB per month — a twentyfold reduction. By automatically moving older backups to cooler tiers as they age, you can maintain long retention periods at a fraction of the cost of keeping everything on hot storage.

Calculating Your Total Storage Costs

Accurate cost modelling is essential for securing budget approval and avoiding unpleasant surprises as your backup storage grows over time. The total cost of your backup retention strategy depends on four primary variables: the volume of source data being protected, the daily rate of data change, the retention periods configured for each tier, and the per-gigabyte storage costs at each tier level. Understanding how these variables interact allows you to model your storage requirements and forecast costs with reasonable precision over a multi-year horizon.

Start by measuring your current data volumes across all protected workloads — email mailboxes, file storage in OneDrive and SharePoint, databases, and application data. Then estimate the daily change rate, which represents the percentage of data that changes each day and therefore needs to be captured in incremental backups. For a typical UK office environment, daily change rates range from 1% to 5% of total data volume. Email tends to exhibit higher change rates due to the constant flow of incoming and outgoing messages, whilst file storage change rates depend heavily on the nature of the business and how actively staff create and modify documents.

Deduplication and compression significantly reduce the actual storage consumed by your backups, often by a factor of two to five times compared to the raw source data volume. Modern backup solutions apply deduplication at the block level, identifying and eliminating duplicate data blocks across all backup copies in the repository. This means that even with long retention periods, the incremental storage cost of keeping an additional monthly backup point is relatively modest, as the majority of the data blocks are shared with existing backup copies through deduplication references rather than being stored redundantly.

Armed with these variables, you can model your projected storage growth over one, three, and five years, applying the appropriate storage tier costs to each retention level. For a typical UK SME with 50 users, 500GB of email data, and 1TB of file data, a well-designed GFS retention policy with tiered cloud storage typically costs between two hundred and five hundred pounds per month — a fraction of the potential cost of even a single data loss incident. Present this cost comparison to business stakeholders when seeking budget approval, as the return on investment is almost always compelling when set against the financial and operational risks of inadequate backup retention.

Building Your Retention Policy

A practical backup retention policy should follow these steps. First, classify your data by type and identify any regulatory retention requirements that apply. Second, determine your business-specific retention needs — how far back might you realistically need to recover data, and for what reasons? Third, balance these requirements against storage costs to determine feasible retention periods. Fourth, document the policy, including the rationale for each retention period. Fifth, implement the policy in your backup software, configuring automated expiry and tiering rules. Sixth, review the policy at least annually, or whenever regulations change or a significant incident occurs.

Your policy should be approved by business stakeholders, not just IT. Data retention is a business decision with legal, financial, and operational implications. IT implements the policy; the business defines it.

Annual Review and Continuous Improvement

A backup retention policy is not a set-and-forget document. It requires regular review and updating to remain effective and compliant as your business evolves, regulations change, and the threat landscape shifts. Schedule a formal policy review at least annually, ideally timed to coincide with your organisation's broader information governance or risk management review cycle so that backup retention is considered alongside other data protection activities.

During each annual review, assess whether any new regulatory requirements have come into effect that affect your retention obligations. The UK regulatory landscape is not static — new legislation, updated guidance from the ICO, changes to sector-specific regulations, and evolving case law can all affect the retention periods you need to apply to different data types. Additionally, review whether any business changes — such as entering new markets, acquiring or merging with other companies, or taking on clients in regulated sectors — have introduced new retention requirements that your current policy does not adequately address.

Incident-driven reviews are equally important and should be triggered automatically by relevant events. After any data loss event, attempted ransomware attack, regulatory inquiry, or legal discovery request, conduct a focused review of your retention policy to identify whether the incident exposed any gaps or weaknesses. If your backup was unable to fulfil a discovery request because the relevant data had already been expired under your retention schedule, that is a clear signal that the retention period for that data type needs to be extended. Conversely, if an incident reveals that you are retaining large volumes of data that serve no business or regulatory purpose, this may present an opportunity to reduce retention periods and the associated storage costs.

Finally, ensure that your annual review includes a practical test of your retention tiers to verify that the policy works in practice as well as on paper. Restore a sample item from each retention level — a recent daily backup, an older weekly backup, a monthly backup from several months ago, and an annual backup from the previous year. Verify that each restore completes successfully, that the restored data is intact and fully usable, and that the restore time meets your documented Recovery Time Objectives. Report the results to your stakeholders alongside the policy review findings, providing assurance that your retention strategy remains both compliant and operationally effective year after year.