Skip to content
Backups Are Not the Same as Recovery
Most mid-sized businesses have moved past the basic mistake of having no backups at all.
The jobs run, the storage is offsite or in the cloud, and the report lands in someone’s inbox every morning saying everything completed successfully.
That’s the point where a lot of organisations stop asking questions, and it’s also the point where the real risk sits.
Checklist
Key Focus Areas
Backup vs. Recovery
A backup confirms that data exists somewhere. Recovery is a different exercise entirely: pulling that data back into working systems, in the right sequence, within a window the business can actually absorb. A green tick on a backup job tells you the copy succeeded. It tells you nothing about whether that copy can be restored under pressure, how long the restore will take, or whether the version you’re restoring predates the compromise.
Ransomware targets backups directly
Modern attacks increasingly target backup repositories directly, because attackers know that’s the fastest way to force a ransom decision. Immutable or air-gapped copies, ones that cannot be altered or deleted even by an administrator account that’s been compromised, have gone from a nice-to-have to a baseline expectation in any serious recovery strategy.
The 3-2-1 baseline
Three copies of data, on two different types of media, with one held offsite or air-gapped, still holds as the architecture baseline. Where it falls down in practice isn’t the architecture. It’s the testing cadence.
The testing gap
A restore test run once at implementation and never repeated tells you nothing about whether that process still works after six months of infrastructure changes, staff turnover, and undocumented tweaks.
Dependency mapping
Restoring a database is only useful if the application server it feeds is also back, and that server might depend on an identity provider, a licensing service, or a third-party API nobody thought to include in the runbook. A plan that only covers systems IT directly controls will stall the moment it hits something outside that boundary.
What’s in a Number?
IBM’s Cost of a Data Breach Report 2024 put the average recovery disruption after a ransomware incident at 24 days. That figure covers organisations of every size and maturity level, but it’s a useful reality check against however long your own plan currently assumes. Three weeks of reduced capacity, or worse, is a very different conversation with the board than the four-hour email restore most plans quietly assume without testing it.
Worked Example
Take email as a working example. If the stated target is restoration within four hours, that number only means something once it has been tested end to end, including authentication, mail flow rules, and any third-party filtering service sitting in front of it. Run that test twice a year and the four-hour figure becomes a commitment rather than a guess.
Skip the test and it’s a hope, not a guarantee.
Cyber insurers are increasingly asking the same questions your customers eventually will: when was this last tested, and can you show us.
Policies are starting to require evidence of tested backup and recovery procedures as a condition of cover, not just a checkbox on the application form. A plan that exists only on paper is now a gap that shows up in premium negotiations as well as during an actual incident.