Most UK businesses now back up their data. Far fewer could tell you, with confidence, what happens in the hour after a ransomware attack hits.
That gap is worth sitting with. According to the DSIT Cyber Security Breaches Survey 2025, 71% of UK businesses back up data securely via cloud services, and a further 47% use other secure backup methods. But formal incident response plans sit at just 53% for medium businesses and 75% for large ones, dropping off sharply further down the size scale. Backup adoption is high. Readiness to respond to an attack is not. That mismatch is the entire argument for why “backup” and “cyber resilience” aren’t interchangeable terms, even though people use them that way constantly.
If you’re building a security strategy or trying to explain to a board why backup alone isn’t the finish line, it’s worth being precise about the difference.
What Backup Does Best
Backup has one job: make sure a copy of your data exists somewhere it can be recovered from. Modern platforms like Veeam have extended that job considerably; immutable snapshots, air-gapped and cloud repositories, malware scanning on backup data and role-based access. Backup itself has become a cybersecurity layer, not just an availability safety net.
That’s a genuine shift, and it matters. A well-configured, immutable backup is one of the few things standing between a ransomware attack and a six-figure ransom decision. Most people think backup solves every problem after an attack. In reality, it answers a much narrower question: can we get our data back? It doesn’t address everything else needed to recover, such as maintaining operations, meeting legal obligations, or getting back to business quickly.
What Cyber Resilience Looks Like
Cyber resilience is the wider discipline. It’s the ability to anticipate, withstand, respond to, and recover from a cyber incident while continuing to deliver the business outcomes that matter. The NCSC’s Cyber Assessment Framework and NIST’s cyber resiliency guidance both describe it the same way: not a product, but a set of capabilities spanning identification, protection, detection, response, and recovery.
Backup sits inside “recovery.” It’s one box on a five-box diagram. The other four are where most of the actual damage control happens:
Detection – knowing an attacker is in your environment before they’ve had three weeks to map it, escalate privileges, and find your backup repositories.
Containment and response – isolating affected systems, preserving evidence, and following a defined process rather than improvising while everyone’s phone is ringing.
Recovery orchestration – restoring systems in the right order, into a clean environment, without re-introducing the malware that caused the incident in the first place.
Governance and communication – who makes the call to pay or not pay a ransom, who tells customers and regulators, who talks to the cyber insurer, and within what deadline.
A business can be excellent at backup and still fail badly at all four of these, which is exactly what tends to happen when “we have backups” gets mistaken for “we have a plan.”
Where Backup Reaches Its Limits
A few scenarios where solid backup on its own hasn’t been enough:
Attackers increasingly target backup infrastructure specifically, knowing it’s the recovery lifeline, which is why immutability and isolation matter more than the backup schedule itself. Even with clean backups, restoring straight back into a compromised network just hands the attacker a second run at you; recovery has to happen into an isolated, verified-clean environment. And a technically successful restore can still miss the recovery time the business needs, recovering the file server in six hours is a win, unless the business needed it back in one and nobody had tested how long the process actually took.
None of these are backup failures. They’re resilience failures that a backup strategy was never designed to solve alone.
Backup Is the Foundation, Not the Whole Building
None of this is an argument against investing in backup, quite the opposite. Immutable, air-gapped, tested backup is non-negotiable, and it’s the layer everything else depends on. If your backups aren’t clean, isolated, and verified restorable, no amount of incident response planning saves you. The point is that backup is necessary but not sufficient and treating it as the whole strategy is where organisations get caught out.
Practically, closing the gap between the two tends to come down to a short list:
- Immutable and air-gapped backups as the non-negotiable baseline, with recovery-point objectives that match what the business can tolerate losing.
- An isolated recovery environment so systems can be brought back clean, scanned, and verified before they touch the production network again.
- A written, tested incident response plan that names who does what, including who has authority to make the call on containment, disclosure, and (where relevant) ransom decisions, rather than one that exists only as a policy document nobody’s opened.
- Detection and monitoring that gives you a chance of catching an attacker during the weeks they’re usually inside the network before triggering encryption, not just after.
- Regular recovery testing, including tabletop exercises, so the first time your team executes the incident response plan isn’t during a live incident.
Where This Leaves You
If you already have solid, well-configured backup, that’s the hard part done. The next question isn’t “do we need better backup,” it’s “if this triggered at 2am tonight, does everyone in this business know exactly what happens in the first hour, and have we actually tested it?”
For most organisations, that’s a gap analysis worth doing before an incident forces the conversation. If you want a second pair of eyes on where your backup strategy ends and your resilience plan needs to pick up, get in touch with the Nexstor team.
