Backup Retention Policy: A UK Business Guide to How Long You Should Actually Keep Your Data in 2026

A backup retention policy is the answer to a question most UK businesses have never actually been asked: how far back do you need to be able to go? In the overwhelming majority of organisations the answer was supplied by a software installer. Fourteen restore points, or thirty days, or whatever the wizard offered when somebody clicked through it during a busy week three years ago. Nobody chose that number against a risk, a regulation or a cost, and yet it now defines the outer limit of what the business can recover.

This guide treats retention as a business decision rather than a configuration setting. It starts with the distinction that resolves most confusion on the subject — backups exist to recover from failure, archives exist to satisfy obligations, and using one as the other is expensive in both directions. It then works through how ransomware dwell time should drive the short end of your recovery point retention, what UK GDPR storage limitation actually requires of backup data as opposed to live data, the statutory minimums that apply to specific record types regardless of what your backup software defaults to, and how to build a tiered schedule that keeps recoverability where it is needed without paying to store 2019 twice over. It covers indicative 2026 UK storage costs by tier, the immutability requirement that has quietly become the most important part of any retention design, and the specific failures that make a policy look compliant on paper and useless in an incident.

Retention is a business decision, not a technical one

Ask an IT team what the retention policy is and you will get a number of days. Ask the finance director, the HR manager and the operations lead how far back they might need something, and you will get three quite different answers, none of which anybody has ever reconciled with the number of days. That gap is where retention policies fail, and it is not a technical failure.

The reason is that retention answers two separate questions that happen to be served by the same storage. The first is a recovery question: if something goes wrong — hardware failure, accidental deletion, corruption, ransomware — how far back do we need a clean copy to restore from? That is driven by how quickly problems are detected, which is a measurable property of the organisation. The second is a records question: what are we obliged to be able to produce, to whom, and for how long? That is driven by statute, regulation, contract and the limitation period for legal claims, none of which have anything to do with IT.

Those two questions have wildly different answers. The recovery question usually resolves to somewhere between thirty and ninety days for most data. The records question can run to six years for accounting records, or forty years for certain health surveillance records. If the same mechanism is asked to satisfy both, one of two things happens: either retention is set to the recovery answer and the organisation quietly fails its records obligations, or it is set to the records answer and the business pays to keep daily restore points from four years ago that nobody will ever use and which, under data protection law, it arguably should not still be holding.

The way out is to separate them deliberately. Backups are operational: frequent, short-to-medium retention, optimised for fast restore, covering everything. Archives are selective: specific records, retained to a defined schedule for a defined reason, optimised for cost and durability rather than speed, and indexed so that something can actually be found. Once the two are separated, both become cheaper and both become defensible. Held together, neither is.

Default retention against derived retention

Most retention policies fall into one of two categories: the number the software suggested, or a number worked out from the organisation’s own risk and obligations. The comparison below sets out what each actually delivers, and it is worth noting that the derived approach is frequently cheaper as well as more defensible, because deriving the number usually reveals that some data is being kept far longer than anything requires.

The line worth dwelling on is ransomware coverage, because it is the one where a default setting is not merely suboptimal but actively dangerous. A uniform fourteen-day retention means that if an intrusion is detected on day sixteen, every restore point available contains the compromise. The organisation has a backup system that has been running perfectly, reporting success every night, and no clean copy to restore from. This is not a rare edge case; it is the single most common way that organisations with functioning backups still end up paying a ransom or rebuilding from nothing.

The cost line frequently surprises people in the other direction. Moving to a tiered schedule with proper archive tiering for the long tail usually reduces total storage cost even while extending the maximum recoverable age, because the expensive part of retention is keeping everything in fast storage rather than keeping it at all. Daily restore points from eighteen months ago sitting on performance storage are the definition of paying a premium for something nobody will use.

Ransomware dwell time and the short end of retention

The short end of a retention schedule — how many consecutive recent restore points you keep — should be derived from one number: how long a compromise might sit in the environment before anybody notices. Restore points from after that moment are contaminated. Only restore points from before it are useful.

Industry incident-response reporting over recent years has put median attacker dwell time in the region of one to two weeks, with ransomware cases typically at the shorter end because encryption is a noisy final act, and with a long tail of intrusions that persisted for months. The median is the wrong figure to design against. Designing to the median means being unable to recover from any incident worse than average, which is a strange position to adopt for a control whose entire purpose is handling the worse-than-average case.

A more useful framing is to ask what proportion of incidents a given retention depth would cover. Fourteen days of restore points covers a meaningful share of ransomware cases and none of the quieter intrusions. Thirty days covers most. Ninety days covers the substantial majority including slower data-theft-then-encrypt operations. Beyond ninety days the curve flattens considerably, which is why ninety days of some form of recoverable point is a reasonable target for the short-to-medium tier in most organisations, delivered through a mix of daily, weekly and monthly points rather than ninety daily copies.

The second consideration matters at least as much as depth. Attackers routinely target backup infrastructure before encrypting production, because a business that can restore does not pay. Deleting backups, encrypting the backup repository, or simply changing the retention setting to one day and waiting are all standard techniques, and they are effective against any backup system that the compromised domain administrator account can reach. Retention depth provides no protection whatsoever if the restore points can be deleted by the same credentials that were stolen.

This is why immutability has become the load-bearing part of a modern retention design rather than an optional extra. A restore point that cannot be altered or deleted until its retention period expires — enforced by the storage platform rather than by the backup software’s own permissions — is the difference between a retention policy and a retention aspiration. We cover the mechanisms in detail in our guide to ransomware recovery and immutable backup, and the wider copy strategy in our guide to the 3-2-1 backup rule.

Where retention policies typically fall down

The grid below groups the recurring weaknesses we find when reviewing an existing backup estate. The badges combine how often the issue appears with how badly it undermines recovery when it matters — a high-risk item is one that is both common and capable of turning a functioning backup system into an unusable one.

The Microsoft 365 item deserves particular emphasis because the misconception is so widespread and the consequences are so specific. Microsoft operates a shared responsibility model: it is responsible for the availability of the service, and the customer is responsible for their data within it. The native controls — deleted items retention, recycle bins, retention policies, litigation hold — are real and useful, but they are governed by settings an administrator can change and windows that expire, and they are not designed to recover a tenant from a malicious administrator or a ransomware event that propagates through synchronised files. Organisations discovering this during an incident is common enough that it is worth checking explicitly rather than assuming.

The second card is where scope creep works against you silently. A backup policy written three years ago covered the systems that existed three years ago. The CRM that moved to a SaaS platform last year, the finance system that migrated, the shared mailbox somebody created for a new department — none of these appear in a backup report as missing, because a job that does not exist cannot fail. Reconciling a list of live systems against a list of backup jobs quarterly is a fifteen-minute task that catches this, and almost nobody does it.

Backup retention in UK businesses — the numbers

The figures below reflect what we typically find when reviewing backup arrangements for UK organisations in the 20 to 400 seat range. They describe estates where backup was implemented competently and then left to run, which is the normal situation rather than a neglected one.

Placing the first two figures next to each other makes the core problem visible. A thirty-day maximum against a six-year statutory obligation is not a marginal shortfall, it is a two-order-of-magnitude gap, and it is almost never noticed because the statutory records usually do exist somewhere — in the accounting system, in a filing cabinet, in an export somebody made. The backup system is not the mechanism satisfying the obligation, but nobody has written down what is, which means nobody can demonstrate it if asked.

The immutability figure is the one that has moved most over the last three years, and it is still lower than it should be given how routinely backup infrastructure is targeted. The encouraging part is that it has become considerably easier to achieve: object lock on cloud object storage, hardened repositories, and immutable vault options in the major backup platforms have brought it within reach of organisations that could not previously have justified tape rotation or a dedicated air-gapped appliance.

How far back UK businesses can actually restore

There is a difference between the retention setting in the backup console and what can genuinely be restored. The chart below shows the proportion of organisations, across reviews of UK estates in the SME and mid-market band, able to produce a working restore of a named business file at a given age. It measures demonstrated capability rather than configured intent, which is why the figures fall away faster than most people expect.

The fall between seven days and ninety days is the retention setting doing what it was configured to do. The fall beyond that is something else: organisations that believe they have long-term copies and discover, when asked to produce one, that the media is unreadable, the backup software that wrote it has been replaced by a version that cannot import the old format, the encryption key was held by someone who left, or the archive was migrated during a platform change and quietly did not come across.

That last category is the reason long-term retention deserves a different design rather than simply a longer number in the same system. A restore point that depends on a specific software version, a specific licence, a specific key holder and a specific storage platform all still existing seven years from now is a chain of assumptions, and each link has a meaningful annual probability of breaking. Long-term archives survive best when they are stored in an open, documented format on a platform whose durability is contractual, with the keys escrowed somewhere the organisation controls.

The practical implication for the six per cent figure at seven years: if your retention schedule promises seven years, the only way to know whether it delivers is to restore something from six years ago and see. That test costs an afternoon and is the only evidence that distinguishes a retention policy from a retention belief. We set out how to run it properly in our guide to backup restore testing.

UK GDPR, storage limitation and backups

The storage limitation principle in UK GDPR requires that personal data is kept in a form permitting identification no longer than is necessary for the purposes it is processed for. Applied naively to backups, this appears to demand that personal data be surgically removed from every historic restore point whenever it is no longer needed, which is technically impossible for most backup formats and would defeat the integrity of the backup if it were attempted.

The regulator’s position is more practical than that, and understanding it removes a great deal of unnecessary anxiety. The Information Commissioner’s Office recognises that backups are a distinct case, and its guidance on the right to erasure indicates that where personal data is held in a backup, an organisation is not required to tear open the backup to extract individual records. What it must do is put the data beyond use: ensure it is not used for any other purpose, and confirm that the data will be erased when the backup is overwritten or cycled out in the normal course. Where an erasure request has been made, the individual should be told that their data remains in backup and when it will be removed.

What this means in practice

Three obligations follow, and none of them require exotic technology. First, have a defined retention period so that “when the backup is cycled” is a knowable date rather than an indefinite one — an infinite retention setting is precisely what makes the beyond-use argument fail, because the data will never be overwritten. Second, have a documented process ensuring that if a restore is performed from a backup containing data subject to an erasure request, that data is re-deleted from the live environment afterwards. Restoring deleted personal data back into active use is the failure mode the regulator actually cares about. Third, write the rationale down: the retention period for each data class and why it is that length.

Retention periods are justified, not prescribed

UK GDPR does not specify retention periods. It requires that the period be no longer than necessary and that the organisation be able to justify it. This is frequently misread as an instruction to keep as little as possible, which produces the opposite error — organisations deleting records they are statutorily required to retain in the belief that data protection demands it. Where another law requires retention, that is itself the lawful basis and justification. The two obligations are complementary rather than in conflict, and the retention schedule is the document that reconciles them, data class by data class.

A related point worth being explicit about: a legal hold overrides a retention schedule. Where litigation is reasonably in prospect or a regulatory investigation is under way, relevant data must be preserved beyond its scheduled deletion date, and the backup platform needs a mechanism for doing that which can be evidenced. A schedule with no hold mechanism is a schedule that will be breached the first time a dispute arises. The broader compliance picture, including how this intersects with Cyber Essentials, is covered in our guide to cloud backup compliance for UK businesses.

Benchmarks — retention practice against what we find

Adoption rates below come from reviews of UK backup estates in the 20 to 400 seat band. As with any adoption measure these readings are generous: an organisation counts as having tested restores if any restore test happened in the period, regardless of whether it covered an old restore point or only last night.

The first three rows tell a complete story on their own. Eighty-nine per cent have backups reporting success; forty-six per cent have proven a restore in a year; thirteen per cent have proven a restore from beyond ninety days. The gap between the first and the third is the gap between a system that runs and a retention policy that works, and it is almost entirely invisible from the backup console, which reports green throughout.

The bottom two rows are the ones that become urgent without warning. An erasure request or a litigation hold arrives on a timetable set by somebody else, typically with a statutory deadline attached, and the process for handling it either exists already or is invented under pressure. Both are inexpensive to define in advance and genuinely difficult to improvise.

Building a retention schedule — the sequence that works

A retention schedule is a document before it is a configuration. The sequence below produces one in about six weeks for a typical UK SME, and the ordering matters: the obligations are established before any technical setting is touched, because otherwise the schedule ends up reverse-engineered from what the current software happens to do.

The two items in week five are the ones organisations are most tempted to defer, and they are the ones that determine whether the schedule survives contact with reality. A retention period that a compromised administrator account can shorten is not a retention period. A schedule with no hold mechanism will be breached by the first dispute. Neither takes long to implement; both are difficult to retrofit while an incident is in progress.

UK statutory retention minimums by record type

These are the periods that most commonly drive long-term retention for UK businesses. They are indicative and not exhaustive, sector-specific regulation frequently imposes longer periods, and the figures should be confirmed against current guidance and professional advice for your own circumstances before a schedule is finalised. The point of the table is to show the shape of the problem: the required periods are measured in years, and they vary by record type rather than applying uniformly.

The contracts row is the one most often overlooked and the one with the widest practical reach. The limitation period for a breach of contract claim in England and Wales is six years from the breach, which can be well after the contract ended. That means the documents, correspondence and delivery evidence supporting a contract may need to be available considerably longer than the contract term suggests, and for a deed the period is twelve years. A retention schedule that keeps contracts for the life of the agreement plus one year is a schedule that will discard the evidence for a claim while the claim is still live.

The health surveillance row illustrates why uniform retention cannot work. Any organisation with a COSHH obligation has a class of records that must survive four decades, which is longer than the working life of every storage technology and backup product currently available. Data of that kind does not belong in a backup system at all; it belongs in an archive with a documented migration plan, because it will need to be moved between platforms several times before its retention period expires.

Retention readiness — where most UK estates sit

Combining the assessment areas into a single figure gives an indication of how well an organisation’s retention arrangements would hold up under either an incident or a request. The gauge reflects a first review of a UK business in the 20 to 400 seat band with functioning backups and no written retention schedule, which is the most common starting position.

A score in the mid-thirties has a consistent composition. Backup execution scores well — jobs run, they report success, and the recent restore points genuinely work. Retention depth scores moderately, because thirty days covers a good deal of ordinary operational need. Immutability and governance score badly, and proven long-term recoverability scores worst of all, because it is the one property that nobody ever tests until they need it.

What makes a low score here different from most benchmarks is that the cheapest remedies are also the most valuable. Writing the schedule costs a few days of meetings. Testing an old restore costs an afternoon. Enabling object lock on an existing cloud repository is a configuration change. The expensive item — building a separate archive tier with a migration plan for multi-decade records — only applies to organisations that actually have multi-decade obligations, and most do not.

The caveat that applies to every benchmark applies here too. A ten-person consultancy with no regulated records, thirty days of immutable cloud backup and a tested restore is in a perfectly defensible position and would score in the forties. The score measures readiness against a general set of risks, and an organisation that has genuinely assessed its own obligations and concluded that a simple arrangement is sufficient has done the work this guide is asking for, regardless of the number.

What retention costs — indicative UK storage tiers

Retention cost is driven by which tier the data sits in far more than by how long it is kept. The table below gives indicative 2026 figures for cloud object storage tiers in a UK region, per terabyte per month, excluding VAT. Actual pricing varies by provider, region and commitment, and backup products add their own licensing on top, so these are for comparing the shape of the tiers rather than for quoting a total.

The spread between hot and archive is roughly fifteen to one, which is why tiering rather than deletion is usually the right answer to a retention cost problem. Keeping seven years of annual restore points in the archive tier costs less than keeping ninety days of daily points in hot storage, for most data volumes. An organisation told that extending retention is unaffordable has usually been quoted for extending it in the tier the data currently sits in.

Two details in that table cause unwelcome invoices. The first is the minimum retention period attached to the colder tiers: data deleted from an archive tier before its minimum period is typically charged as though it had been kept for the full period, so cycling data through archive storage on a short rotation costs more than leaving it in a warmer tier. The second is rehydration. Retrieving a large archive restore is both slow and separately charged, which is fine for a once-in-seven-years statutory request and wholly unsuitable for operational recovery. Putting the ninety-day operational tier in archive storage to save money produces a backup nobody can use in an incident.

Growth needs to be in the model as well. Data volumes in most organisations grow at a rate that compounds noticeably over a retention period measured in years, so a seven-year archive is not seven times one year’s data. Budget from a projection rather than from the current footprint, and note that cloud storage is a standing monthly charge of exactly the kind that drifts unnoticed — a pattern we cover in our guides to cloud backup pricing and preventing cloud bill shock.

The number that decides whether retention will save you

Of all the measurements in a backup review, one predicts the outcome of a ransomware incident better than any other: whether a restore point exists that is both older than the intrusion and impossible for the attacker to have altered. Retention depth alone does not establish this. Immutability alone does not either. It is the combination that matters.

Twenty-five per cent means three quarters of organisations have a backup estate whose retention period is, in practice, whatever an attacker decides it should be. The credentials that administer the domain typically administer the backup server, the backup server controls the repository, and the repository can be emptied. Every restore point in the schedule is present until the moment it becomes relevant.

This is why targeting backups is standard practice rather than an unusual sophistication. It is the highest-value action available to an attacker, it is straightforward once domain administrative access is held, and it converts a recoverable incident into a negotiation. Organisations that recover without paying almost always have one thing in common, and it is not a longer retention setting — it is a copy that could not be reached.

Raising the figure is more accessible than it used to be. Object lock on cloud object storage enforces retention at the storage layer, so a delete request is refused regardless of the credentials presented. Hardened repository configurations in the major backup platforms remove the operating-system-level access that makes a repository deletable. A genuinely offline copy — tape, or removable media rotated out of the building — remains the strongest form and is still appropriate for the long-term archive tier. What matters is that at least one copy is governed by something other than the permissions of the account that was stolen.

Immutability, separation and the extended copy rule

The familiar 3-2-1 rule — three copies, on two types of media, one off site — predates ransomware as a mainstream risk, and it has been extended in response to it. The version worth designing against adds two conditions: one copy immutable or offline, and zero errors verified by testing rather than assumed.

Immutability modes are not equivalent

Where object lock is available it usually offers more than one mode. A governance-style mode allows a sufficiently privileged account to shorten or remove the lock, which makes it useful for preventing accident but not for resisting a determined attacker who has obtained that privilege. A compliance-style mode cannot be overridden by anybody, including the account that set it, until the period expires. The stronger mode is the one that provides the protection people assume they are buying, and it comes with an important operational consequence: a mistake in the retention period cannot be corrected, and the storage will be paid for until it expires. That trade is worth accepting deliberately rather than discovering later.

Separate the credentials, not just the copies

An off-site copy reachable with the same credentials as the on-site copy provides protection against fire and flood but not against compromise. The separation that matters is administrative: a distinct identity, ideally in a distinct directory, with multi-factor authentication, used only for backup administration and not for anything else. This is frequently the single most effective change available in an existing estate, and it costs nothing but the effort of setting it up.

Verify rather than assume

The zero-errors condition is the one most often treated as rhetorical. It means running restores, not checking that a verification job reported success. Backup products verify that the data they wrote can be read back, which is necessary and not sufficient — it does not establish that the application can use the restored data, that the restore fits inside the recovery time the business assumes, or that anybody currently employed knows the procedure. An annual test that restores a real system and has somebody use it is the control that turns the whole arrangement from documentation into capability.

One further consideration for retention specifically: immutability and retention interact with the erasure obligations discussed earlier. Data locked in compliance mode for seven years cannot be deleted in response to an erasure request, which is acceptable under the beyond-use reasoning provided the retention period is defined, justified and documented, and provided restores do not reintroduce erased data into live use. It is not acceptable if the lock period was chosen arbitrarily or set to an indefinite value. Choosing lock periods that match a justified retention schedule is what keeps the two obligations compatible.

The 12-point backup retention checklist

Items one to four establish what the retention periods should be. Items five to nine implement them. Items ten to twelve are what keeps the arrangement honest over time.

1. Reconcile every live system against the list of backup jobs. Include SaaS platforms, endpoints, identity and configuration, not just file and database servers. A missing job never appears as a failure.
2. Classify data into four to eight classes. By what the data is rather than where it sits: financial, HR and payroll, customer personal data, contracts, operational files, configuration.
3. Record the obligation and its source for each class. Statutory minimum, regulatory requirement, contractual commitment, limitation period. Write down which law or contract each period comes from.
4. Set the operational tier from realistic detection time, not convention. Thirty to ninety days of recoverable points for most organisations, delivered as a mix of daily, weekly and monthly rather than all daily.
5. Separate the archive from the backup. Long-term statutory records belong in an indexed archive with a documented format and a migration plan, not in restore points from a backup product.
6. Tier the storage to match the role. Hot for recent, cool or cold for medium-term, archive for long-term. Check the minimum retention period and rehydration cost of each colder tier before committing.
7. Make at least one copy immutable or offline. Object lock in the stronger mode, a hardened repository, or genuinely offline media. Verify that a delete request is actually refused.
8. Separate backup administration credentials. A distinct identity with multi-factor authentication, not used for production administration and ideally not in the same directory.
9. Write the legal hold procedure. How scheduled deletion is suspended for specific data, who authorises it, and how it is evidenced afterwards.
10. Write the erasure procedure for backup data. Including the step that re-deletes erased personal data from the live environment after any restore, which is the part that matters most.
11. Restore from the oldest tier you claim to hold. An actual file, opened in the application that created it. Repeat annually. This is the only evidence that the schedule is real.
12. Review the schedule annually against obligations and volume. Named owner, fixed date. Obligations change, data grows, and systems get added by people who never saw the schedule.

What this looks like in practice

A 140-person engineering consultancy with offices in Leeds and Reading had a backup arrangement that any auditor would have signed off at a glance. Nightly backups of all file servers and the finance database to a local appliance, replicated each morning to a cloud repository, with a dashboard that had reported green for eleven consecutive months. Retention was set to thirty restore points, which had been the default when the system was installed in 2022 and had never been discussed since.

The incident that tested it was not ransomware. A structural calculation file was found to have been corrupted, and the corruption was traced back through successive versions to a change made roughly four months earlier. The project it belonged to had been delivered, signed off and invoiced. A client query had prompted somebody to reopen the file, and the last known good version was outside the thirty-day window by a margin of three months.

There was a second problem behind the first. The firm had assumed that because the project documentation existed in the finance and document management systems, the calculation files were covered by something. They were not; they lived on a file share whose only retention was the backup system. And the contract for the project in question carried a twelve-year liability period, meaning the firm had a professional obligation to be able to evidence its calculations for more than a decade and a technical capability of thirty days.

The review that followed separated the two requirements that had been conflated. Operational backup retention was restructured to a tiered schedule — thirty daily points, twelve weekly, twelve monthly — which increased the maximum operational recovery age from thirty days to just over a year for a modest increase in cost, because the weekly and monthly points went to a cool tier rather than the hot repository. Separately, a project archive was established: on completion, each project’s full record set is written once to archive-tier storage with a twelve-year object lock, indexed by project number in a register that finance maintains. Backup administration was moved to a separate identity with multi-factor authentication, and the cloud repository was placed under object lock in the stronger mode with a thirty-day period matching the operational tier.

The total storage cost rose by under fifteen per cent, which was less than the firm had assumed extending retention would cost, because the extension went to colder tiers while the hot tier stayed the same size. The corrupted file was not recovered; that project was reconstructed at a cost in chargeable hours that comfortably exceeded a decade of the additional storage.

What caught us out was that the backup system had never failed. It did exactly what it had been configured to do, every night, for three years, and the configuration was simply a different question from the one we needed answered. Nobody had ever asked how long we needed to keep things. They had asked whether the backups were working, and the answer to that was always yes.

The generalisable point is that this organisation was not negligent and the failure was not technical. A competent implementation answered a question nobody had framed properly, and the gap only became visible when a specific retrieval was required. That is the ordinary shape of retention failure, and it is why the exercise in this guide is a conversation with the business rather than a change to a configuration file.

Common retention policy mistakes

The failures below recur across reviews. Most are not errors at the moment they are made — they are reasonable defaults that were never revisited as the organisation, its obligations and its data all changed around them.

• Accepting the software default as a policy. Fourteen or thirty restore points is a vendor starting point, not a decision. If nobody can say what risk or obligation the number came from, it is not a retention policy.
• Using backups as the records archive. Backups are optimised for fast recovery of everything; archives are optimised for cheap, durable, findable retention of specific records. Asking one system to do both produces a solution that is expensive and still fails an audit.
• Setting retention shorter than realistic detection time. If the oldest restore point is newer than the intrusion, every available copy is compromised. This is the most common reason organisations with working backups still cannot recover.
• Treating immutability as optional. A retention period that the compromised administrator account can change is not a retention period. Attacking backups is standard practice, not an exotic scenario.
• Assuming Microsoft 365 is backed up by Microsoft. Native retention, recycle bins and holds are useful and are governed by settings an administrator can alter. They are not a substitute for an independent copy under your own control.
• Setting retention to indefinite to be safe. This is the option that actively undermines the data protection position, because the beyond-use argument for personal data in backups depends on the data eventually being overwritten on a knowable date.
• Deleting records because data protection appears to require it. Where another law requires retention, that law is the justification. Storage limitation asks for a defensible period, not the shortest possible one.
• Never restoring from the oldest tier. Long-term retention fails through unreadable media, retired software versions, lost keys and platform migrations. None of these are visible from the backup console, and all are found by one test restore.

At a glance — backup retention summary

How Cloudswitched approaches retention

Cloudswitched designs and manages cloud backup for UK organisations, and retention is where we start rather than where we finish. In practice that means the coverage reconciliation, the data classification, and the conversation with finance, HR and whoever holds legal responsibility that establishes what each class of data is actually obliged to survive. From there we design the tiered schedule and price it, implement immutability with separated administrative credentials, write the hold and erasure procedures, and prove the oldest tier with a real restore. Where an internal team runs the estate, we produce the schedule and the evidence and hand it over.

Frequently Asked Questions

What is a backup retention policy and what should it contain?

A backup retention policy defines how long each class of data remains recoverable, why that period was chosen, and where the data sits during it. A complete policy contains a data classification with four to eight classes, a retention period for each class, the source of each period — the statute, regulation, contract or risk assessment it derives from — the storage tier each period uses, the immutability arrangements, the procedures for legal hold and for erasure requests, and a named owner with an annual review date. A number of days in a backup console is a configuration, not a policy, because it records the decision without recording the reasoning, which means nobody can evaluate or defend it later.

How long should a UK business keep its backups?

There is no single answer, and any figure offered without reference to your data is a guess. The defensible approach splits it: operational backups covering everything for thirty to ninety days of recoverable points, sized to realistic detection time for corruption and compromise; and a separate archive holding specific record types for the periods their obligations require, commonly six years for financial and payroll records, six years after expiry for contracts, twelve years for deeds, and up to forty years for certain health surveillance records. A common tiered operational schedule is thirty daily, twelve weekly, twelve monthly and seven yearly points, but the yearly tier should exist because something requires it rather than because the software offers it.

What is the difference between backup and archive retention?

Purpose, and therefore design. Backups exist to recover from failure: they capture everything frequently, are optimised for speed of restore, and are kept for a period driven by how long problems take to detect. Archives exist to satisfy obligations: they capture specific records once, are optimised for cost and durability rather than speed, are indexed so a named record can be found, and are kept for a period driven by law or contract. Using a backup system as an archive means paying for frequent copies of everything over many years while still being unable to locate a specific record efficiently. Using an archive as a backup means discovering that recovery takes hours of rehydration. The separation makes both cheaper.

How does UK GDPR affect backup retention?

The storage limitation principle requires that personal data is kept no longer than necessary and that the period can be justified. It does not prescribe periods. For backups specifically, the Information Commissioner’s Office recognises them as a distinct case: you are not expected to extract individual records from historic restore points in response to an erasure request. You are expected to put the data beyond use, meaning it is not used for any other purpose and will be erased when the backup cycles, to tell the individual that it remains in backup and when it will go, and critically to ensure that if a restore is performed, erased personal data is re-deleted from the live environment afterwards.

Do we have to delete someone from our backups if they ask?

Not by opening the backup and removing the record, which for most backup formats is not technically possible without compromising the backup. What is required is that the data is put beyond use and that it is erased when the retention period expires and the backup is overwritten. The individual should be informed that their data remains in the backup and when it will be removed. The obligation that genuinely bites is the restore path: if you restore from a backup containing data you were asked to erase, that data has re-entered active use and must be deleted again. Having that step written into the restore procedure, rather than relying on somebody remembering, is what makes the position defensible.

Why is indefinite retention a bad idea?

Three reasons. It undermines the data protection position, because the accepted reasoning for leaving personal data in backups depends on it being overwritten on a knowable date — data that will never cycle is data being retained indefinitely without justification. It costs money permanently and at a rate that compounds as volumes grow. And it creates a larger body of data to be searched, preserved and disclosed if litigation or a regulatory request arrives, which is work nobody budgets for. Keeping everything forever feels like the cautious option and is usually the least defensible one.

How long should retention be to survive a ransomware attack?

Longer than the time it plausibly takes you to notice an intrusion, which for most organisations means thirty days as a minimum and ninety days as a more comfortable position. Designing to the industry median dwell time means being unable to recover from anything worse than average, which is a poor basis for a control that exists for the worse-than-average case. But depth alone is not the answer: attackers routinely target backup infrastructure before encrypting production, so the more important question is whether at least one copy is immutable or offline and therefore beyond reach of stolen administrative credentials. Ninety days of deletable restore points is worth less than thirty days of immutable ones.

Does Microsoft 365 back itself up?

Not in the sense most organisations assume. Microsoft operates a shared responsibility model: it is responsible for the availability of the service, you are responsible for your data within it. The native controls are real and useful — deleted item retention, recycle bins, retention policies, litigation hold — but they are governed by windows that expire and by settings an administrator can change, and they are not designed to recover a tenant from a malicious administrator or from ransomware propagating through synchronised files. If your retention policy depends on Microsoft 365 data being recoverable beyond the native windows, that requires an independent backup under your own control.

What is immutable backup and do we need it?

An immutable backup cannot be altered or deleted until its retention period expires, with the restriction enforced by the storage platform rather than by the backup application’s own permissions. In practice that means object lock on cloud object storage, a hardened repository configuration, or genuinely offline media. Yes, it is needed, because attacking backups is a standard technique rather than an unusual one, and a retention period that a compromised administrator account can change is not really a retention period. Note that lock modes differ: a governance-style mode can be overridden by a privileged account, while a compliance-style mode cannot be overridden by anyone until expiry, which is the stronger protection and the less forgiving of a mistake in the period.

How much does longer retention cost?

Far less than most organisations expect, provided the extension goes to a colder storage tier rather than staying in the tier the recent data occupies. The spread between hot object storage and archive tier is roughly fifteen to one per terabyte, so seven years of annual restore points in archive storage typically costs less than ninety days of daily points in hot storage. The caveats are the minimum retention periods attached to colder tiers, which make short rotations through archive storage more expensive than leaving data warmer, and rehydration time and cost, which make archive tiers unsuitable for operational recovery. Model growth rather than current volume, because a seven-year archive is not seven times one year of data.

How do we prove our retention policy actually works?

Restore something from the oldest tier you claim to hold, annually, and open it in the application that created it. This is the only evidence that distinguishes a policy from a belief. Long-term retention fails in ways that are completely invisible from the backup console: unreadable media, a backup product version that can no longer import the old format, an encryption key held by somebody who left, or an archive that quietly did not survive a platform migration. In reviews, a large majority of organisations can restore from last week and a small minority can demonstrate a restore from beyond ninety days. The test costs an afternoon and is the whole difference between the two groups.

Who should own the retention policy?

Ownership sits with the business rather than with IT, because the periods derive from obligations IT does not hold. In a typical UK SME the practical arrangement is a named owner who is accountable for the schedule — often a finance director, operations director or whoever holds data protection responsibility — with IT responsible for implementing and evidencing it. The reason this matters is that a schedule owned solely by IT gets set from what the software can do, while a schedule owned solely by the business gets set without regard to cost or feasibility. The annual review is where both perspectives meet, and it needs somebody whose job it is to convene it.

Related reading

More guidance on protecting, recovering and governing UK business data:

• Cyber Essentials Plus: what the technical audit involves
• Azure cost management: preventing cloud bill shock
• Multi-site network design: connecting branch offices to the cloud
• Google Workspace to Microsoft 365 migration: a UK guide
• Data warehouse versus reporting database: choosing the right approach