Most discussions about ransomware begin with the same set of questions. Are the right security tools in place? Are users being trained? Are patches being applied quickly enough? Has the organisation invested enough in detection and response? These are fair questions. They also leave out a more awkward one: what happens if the attack works?

That is not a defeatist way to look at cyber risk. It is a practical one. IBM’s 2026 X-Force Threat Intelligence Index reported a 49% increase in active ransomware groups compared with the previous year, underlining the scale and persistence of the threat facing organisations. For all the progress made in prevention, no business can realistically assume every attack will be stopped. At some point, the conversation has to move beyond keeping attackers out and towards limiting the damage when they get in.

Recovery plans often look robust until they’re examined through that lens. Backups may exist. Recovery objectives may be documented. There may even be a disaster recovery plan sitting somewhere on the corporate network. The harder question is whether the organisation could restore clean systems, in the right order and within a timeframe that avoids serious disruption to customers, employees and operations, as Wayne Kiphart, CEO, CloudFirst, explains.

The problem with treating backups as reassurance

There was a time when saying “we have backups” carried real comfort. If files were encrypted, the organisation had a route back. It might be painful and disruptive, but at least there was a copy of the data to return to in the event of a breach.

Modern ransomware has made that answer much less reassuring. Attackers understand exactly what organisations rely on to get back on their feet and increasingly target those assets directly. Backup servers, repositories, management consoles and shared administrator credentials can all become part of the attack path because interfering with restoration efforts increases pressure on the victim.

The challenge is that backup systems are often treated as though they sit outside the attack surface when, in reality, they may be exposed to many of the same risks as production environments. If recovery infrastructure shares credentials, management tools or network access with the systems it is designed to protect, the separation organisations believe exists may be far weaker than expected.

Immutable copies, separated credentials and isolated recovery environments are not simply technical considerations. They help determine whether an organisation still has viable options when the rest of the environment is compromised. Organisations understandably focus on whether backup jobs completed successfully, but that alone says little about how those backups would fare during a live ransomware incident.

The difference between restoring data and restoring a business

Many businesses assume that the most recent backup is automatically the best one. In a ransomware incident, that can be a dangerous mistake.

Attackers often spend time inside an environment before the business realises anything is wrong. During that period, accounts may be compromised, configurations changed and malicious code introduced. By the time encryption begins, several generations of backups may already contain elements of the problem. The focus then shifts to trust. Which copy is clean? Which systems can safely be brought back online? Which applications need additional checks before they return to production?

Anyone who has been through a significant outage knows that bringing systems back online is only part of the job. The harder challenge is getting the business working again. Applications need to function properly, data needs to be reliable and key processes need to resume without creating new issues. In more complex environments, the relationships between systems, data and configuration are often just as important as the files themselves.

This is where testing earns its value. Discovering in the middle of a ransomware incident that a restored environment is incomplete, inconsistent or unusable is an expensive way to learn where the gaps are.

The plans that only fail once

Most organisations have Recovery Time Objectives and Recovery Point Objectives. The difficulty is that many of these targets are treated as planning assumptions rather than tested facts.

A four-hour recovery target may look sensible in a business continuity document. It may even satisfy an audit or insurance questionnaire. But if the last full restore took a day and a half, or depended on people who have since left the organisation, that target provides a misleading picture of recovery capability.

Testing can be uncomfortable because it exposes weaknesses that would otherwise remain hidden. Instructions turn out to be outdated. Dependencies emerge that nobody anticipated. Decisions take longer than expected. Yet that discomfort is precisely what makes testing valuable. A failed exercise is far less damaging than a failed recovery during a live incident.

There is also the wider ransomware reality to consider. Many attacks now involve data theft as well as encryption. Even a well-executed restore will not undo the exposure of sensitive information. Legal, regulatory and communications decisions therefore need to sit alongside the technical recovery plan rather than being improvised once the pressure is already on.

Conclusion

Few organisations need convincing that ransomware is a serious threat. The harder task is understanding whether the plans designed to minimise disruption would actually work when needed.

Security controls will always play a critical role, but ransomware has become a test of how well an organisation functions when things go wrong. The question for leadership teams is simple: are those assumptions backed by evidence, or have they yet to be proven?