Ransomware playbooks keep failing at the same step: recovery
Backups are finally working: Sophos puts backup-based recovery at 66% of encryption cases, up 12 points in a year, while the median ransom demand has fallen 65% in two. Recovery cost still rose 11%, to $1.7m. The bill did not go away when the ransom did: it moved to the restore.
By Editorial Desk · · 6 min read
The good news first, because it is real
The story told about ransomware for a decade (that backups never work when you need them) has stopped being true, and the data saying so is not from a backup vendor.
Sophos surveyed 2,158 IT and security leaders across 17 countries whose organisations were hit in the past year. Two thirds of those who had data encrypted got it back from backups.
The State of Ransomware 2026, headline figures
| Measure | 2026 figure | Direction | Statistic |
|---|---|---|---|
| Attacks that reached encryption | 56% | Not stated | Share of respondents |
| Recovered encrypted data from backups | 66% | Up 12 points on 2025 | Share of encryption cases |
| Victims who paid | 48% | Not stated | Share of encryption cases |
| Ransom demand | $698,000 | Down 65% over two years | Median |
| Ransom actually paid | $769,000 | Not stated | Median, payers only |
| Recovery cost, ransom excluded | $1.7m | Up 11% year on year | Mean per incident |
| Attacks starting from identity | 79% | Not stated | Share of all attacks |
Read the last two rows together, because that is the whole briefing. Demands are collapsing. Backups are working. The cost of recovering went up anyway.
Where the money actually goes now
Recovery cost is not a rounding error against the ransom, at $1.7m mean against a $698,000 median demand, it is the larger number, and it is the one still rising.
Genuinely improved
- Backup-based recovery, 66% of encryption cases, up 12 points in a single year.
- Ransom leverage: median demands down 65% over two years.
- Negotiation: 51% of paying organisations settled below the demand.
Did not improve, or got worse
- Mean recovery cost, up 11% year on year to $1.7m, ransom excluded.
- Identity as the way in: 79% of attacks, with compromised credentials the single root cause in 23%.
- Small organisations: only 34% of those with 100 to 250 staff stopped an attack before encryption, against 46% at 3,001 to 5,000.
The improvement is in getting the data back. The cost is in everything that happens while you are getting it back, and that is not a backup problem. It is a business continuity problem wearing a backup problem as a costume.
Where recovery time actually goes
The tail is what will actually hurt you
Averages hide the case that ends up in Parliament. Jaguar Land Rover was attacked on 31 August 2025.
Jaguar Land Rover: from incident to full production
31 Aug 2025
Attack begins
IT environment shut down; global manufacturing halted.
Sep 2025
Production stays down
Solihull, Halewood and Wolverhampton idle. Roughly 5,000 vehicles a week not built.
Early Oct 2025
Production restart announced
Around five weeks after the incident began.
22 Oct 2025
Cyber Monitoring Centre publishes its assessment
Category 3 systemic event. £1.9bn modelled impact, over 5,000 UK organisations affected.
Early Jan 2026
Full production projected
Roughly four months from incident to full output.
The vast majority of that £1.9bn was lost manufacturing output, at JLR and at the near-1,000 tier-one suppliers behind it. The ransom, whatever it was, is not the story. Five weeks of not building cars is the story, and no backup strategy shortens it, because the constraint was never the data.
That is the number missing from most board reporting: not the cost of the incident, but the cost per week of not operating.
The assumption underneath all of them
Every failure in this pattern rests on one unexamined belief: that recovery is a technical operation which begins once somebody decides to start it.
It is not. It begins with a question nobody has rehearsed answering, which is what is safe to bring back. A restored system that is reinfected within the hour has not been recovered, so the first real task is establishing which backups predate the intrusion. That requires knowing when the intrusion started, which is an investigation rather than a restore, and it is the part no runbook budgets time for.
The organisations that come back quickly are not the ones with faster storage. They are the ones that already knew, before the day, which systems must return first and what evidence would show a backup was clean. Both of those are decisions, and both are free to make in advance.
That distinction has a practical edge. Ask what your recovery time objective covers, and most answers describe the restore. Ask what it would take to be confident a restored system is clean, and the same people usually have no number at all, because it was never part of the objective.
The other half is identity. A domain compromised badly enough to warrant a full restore usually needs its credentials and trust relationships rebuilt before anything else is safe to bring back, and that work sits on the critical path in front of every application. Organisations that discover this during an incident lose days to it. Organisations that rehearsed it lose hours.
What to check this week
Take this with you
Recovery assumptions worth testing
- Work out the cost of one week of not operating, per critical service. JLR is the reference point: roughly £50m a week of lost production. If nobody can state yours, the recovery time objective in the plan was never grounded in anything.
- Test restore at scale, not one system on a quiet Tuesday. Restoring 400 servers in dependency order is a different exercise from restoring one, and only one of them is on the plan.
- Run the test with the identity platform assumed compromised. With 79% of attacks starting from identity, recovery tooling that authenticates against the directory is inside the blast radius.
- Write down the restoration order as a maintained artefact. On day three it lives in the heads of people who have not slept, which is not a control.
- Extend the exercise past your own perimeter. Over 5,000 UK organisations were affected by JLR: most of them were suppliers or customers who never saw the attacker.
- Decide in advance who accepts data loss and who signs off rebuilding rather than restoring. Deciding it during the incident costs days.
If you are building the evidence rather than the plan, the ransomware tabletop tutorial and the incident response tabletop pack are the practical next step.
