Your Backups Are Not a Recovery Plan
Backups are one of those things every business knows it should have, and they’re probably sitting… somewhere in the background, quietly reassuring everyone that if the worst happens, the data is safe, the systems can be restored, and business will continue with only a modest amount of disruption.
And while it makes for a comforting thought, unfortunately, it’s not always true.
A backup is only useful if it can be restored, a recovery plan is only useful if people know how to use it, and in the middle of something like a ransomware attack, cloud outage, accidental deletion, failed migration, or hardware failure, sitting saying “we think the backups are working” isn’t a particularly strong position to be in.
That’s why backup testing deserves more attention than it usually gets. It’s not exciting, and nobody is rushing to put “tested restore process” on a keynote slide.
But when something goes wrong, it may be the difference between a short interruption and a full operational mess.
What Is Backup Testing?
Backup testing is the process of checking that your backed-up data, systems, or applications can actually be restored when needed.
That might mean restoring a single file, rebuilding a user mailbox, recovering a server, testing a cloud workload, or simulating how the business would bring critical systems back online after a major incident.
In simple terms, backup testing answers three questions:
Is the data actually being backed up?
Can we restore it?
Can we restore it quickly enough for the business to cope?
That last question is the one many organisations miss - or skip entirely.
A backup can technically work and still fail the business if restoration takes too long, misses key data, depends on a single person being available, or restores infected files after a ransomware incident.
In short, the backup may very well exist. The recovery does not.
Why Backups Get Overestimated
Most backup problems don’t come from reckless neglect. More often, they come from assumptions that are along the lines of…
Someone assumed the backup job was completed successfully.
Someone assumes the cloud platform is covered.
Someone assumes Microsoft 365, Google Workspace, a CRM, finance system, or line-of-business application is automatically recoverable in the way the business expects.
Someone assumes the old restore process still applies, even though the environment has changed three times since it was written.
And because nothing has gone wrong recently, those assumptions remain untested, inviting risk into the process.
Modern IT environments have long moved past being a neat set of servers in a cupboard. These days, they include cloud platforms, AI and SaaS tools, endpoints, mobile devices, remote workers, identity systems, integrations, and third-party suppliers. The data that matters to your business may be spread across more locations than anyone has properly mapped… If they’ve indeed ever mapped it at all.
If you don’t know where the critical data lives, it becomes difficult to know whether it is protected, and in the same vein, if you don’t test recovery, it’s difficult to know whether protection is more than a nice idea.
Why This Matters More in 2026
The National Cyber Security Centre has been increasingly clear that resilience matters just as much as prevention. Its severe cyber threat guidance says organisations need to be ready to continue operating through disruption and recover under pressure, not simply hope every threat can be stopped in advance, which, in itself, is an important shift.
For years, cyber security conversations focused heavily on keeping attackers out with things like firewalls, endpoint protection, MFA, patching, email security, and awareness training. All essential, of course. But even the strongest controls don’t eliminate 100% of the risk.
Systems fail. Users make mistakes. Suppliers have outages. Attackers find gaps. Credentials get compromised. Files get deleted. Ransomware groups specifically target backup systems because they know recovery gives businesses options.
The NCSC’s ransomware guidance advises organisations to verify backups are clean before restoring and to be confident that both the backup and the recovery device are safe. It also describes ransomware-resistant backups as needing protection from destructive actions, the ability to restore from earlier versions, and alerts for significant changes or privileged activity.
In other words, backup isn’t just storage; it should be seen as a security and a continuity control. And it needs to be managed accordingly.
The Difference Between Backup and Recovery
This area is where many conversations get muddled.
A backup is a copy of data.
Recovery is the ability to return systems, data, and business processes to a usable state after disruption.
Whilst they’re related, it’s important to note that they aren’t the same thing.
You might have a backup of your accounting data, but can the finance team access the system by the payroll deadline?
You might have a backup of your file server, but do you know which version is clean?
You might have Microsoft 365 retention policies, but can you restore what users actually need after accidental deletion or compromise?
You might have cloud snapshots, but does anyone know the order in which systems must come back online?
Recovery is where technical planning meets business reality… And business reality has a habit of being awkward.
What Should Businesses Test?
Most organisations simply don’t need to run a full disaster recovery exercise every week. That would be excessive, disruptive, and, quite honestly, a quick way to make everyone avoid eye contact with IT.
But your backup testing should be regular, documented, and realistic. For a sensible starting point, your approach should include:
Restoring individual files to confirm everyday recovery works
Testing key user data, such as mailboxes, SharePoint libraries, or Teams data
Checking critical servers or workloads can be restored
Confirming backup access if core systems or admin accounts are unavailable
Testing whether backups are protected from deletion or encryption
Reviewing restore times against business expectations
Documenting who makes decisions during recovery
Checking whether restored data is clean before it returns to production
The NCSC’s data security guidance also recommends testing backups regularly and making sure you know how to restore files before you have to do it for real.
That last phrase is doing a lot of heavy lifting, admittedly, because the middle of an incident is a terrible time to discover that the process depends on a former employee, an expired licence, a missing encryption key, or a backup repository that has been quietly failing for months.
The Business Questions IT Needs Answered
Backup testing isn’t - and shouldn’t ever be viewed as an IT-only exercise. It needs input from the whole business.
Why?
Well, that’s because IT can restore systems, but the business has to decide what matters most, for example:
Which systems must return first?
How long can each department work without them?
How much data loss is acceptable?
Which processes can continue manually?
Who approves a restore if there is uncertainty?
Who communicates with customers, suppliers, insurers, or regulators?
What happens if the cleanest backup is older than expected?
These questions can absolutely feel uncomfortable, but they’re far easier to answer in a planning session than in the midst of a live incident where panic is factored in.
It’s also where recovery time objective and recovery point objective become useful, rather than just disaster recovery jargon.
Recovery time objective asks: how quickly do we need this back?
Recovery point objective asks: how much data can we afford to lose?
For some systems, the answer may be hours. For others, minutes. In a select few, perhaps a day is acceptable.
The point isn’t to make everything instant. That can become expensive very quickly - if not downright unrealistic. The point is to make conscious decisions based on business impact.
Common Backup Gaps We See
In our experience, the gaps we encounter are rarely baked into something dramatic - the exact opposite, if anything. They’re usually ordinary and something along the lines of:
Backups exist, but nobody has tested a restore recently.
Cloud data is assumed to be covered, but the organisation is relying on platform retention rather than a proper backup strategy.
Senior staff have critical files stored locally.
Old systems are backed up, but the application installer, licence key, or configuration details are missing.
Backups are technically successful, but recovery would take longer than the business expects.
The backup platform is accessible with the same credentials that an attacker would try to compromise first.
We don’t have proactive monitoring, and our logs only go back 30 days, so we don’t know whether we’re restoring a compromised backup.
None of these in isolation - or, even in combinations - means that the organisation in question has done a bad job. It just means their environment has changed, often gradually, and the recovery plan has not kept pace, which is very common.
It’s also fixable.
A Practical Backup Testing Checklist
If you are not sure where to start, begin with a simple review.
List your critical systems:
Identify the platforms, files, applications, and data stores the business depends on.Confirm what is backed up:
Do not assume. Check the backup policy, scope, frequency, and retention.Test a small restore:
Recover a sample file, mailbox, folder, or application record and check it works.Test a meaningful restore:
Choose something business-critical and prove it can be recovered to a usable state.Check protection against ransomware:
Review whether backups are immutable, offline, logically separated, or otherwise protected from destructive actions.Review access:
Make sure recovery does not depend on a single admin account, supplier, or individual.Document the result:
Record what was tested, when, who did it, what worked, what failed, and what needs fixing.Repeat it:
A restore test from two years ago is a nice historical artefact. It is not current assurance.
Final Thought
Backups aren’t boring because they are unimportant.
They’re boring because, when they work properly, nothing dramatic happens. And that’s exactly the point.
A tested backup strategy gives a business options. It reduces panic. It gives leadership more confidence. It turns recovery from guesswork into a process.
For many UK SMEs and mid-market organisations, the goal should not be to build an impossibly complex disaster recovery programme overnight. It should be to move from assumed recoverability to proven recoverability.
Because when something breaks, the question will not be whether a backup job once said “successful,” but how long it takes a business to get back to work.
And that answer should never be left to hope.