Restore Is Not Recovery: What Ransomware Actually Costs to Undo

There is a comfortable version of ransomware recovery in which the backup appliance does the work: restore the virtual machines, watch the progress bars, brief the board. It survives because it is the only part of the incident that resembles ordinary IT. The uncomfortable version is that restoring files returns an organisation to a state the attacker already knows how to enter, and that the parts of the estate most worth rebuilding are the ones nobody kept a clean copy of.

The Market Says Paying Does Not Work

The numbers have been pointing this way for several years. Blockchain payments to ransomware operators fell from a revised 892 million dollars in 2024 to about 820 million in 2025, and the share of victims who paid dropped to a record low of 28% that year, with Coveware's 2026 caseload running closer to 23%. Verizon's 2026 reporting puts refusal at 69%, and the two figures are close enough to describe the same behaviour from different samples. Median payments are frequently quoted as a single number and should not be: Chainalysis measured 59,556 dollars on-chain in 2025, while Sophos puts the 2026 median at 769,000 dollars for the organisations it surveys. Those are different populations, one weighted to small extortion events and the other to insured mid-market victims. Quoting either as the median cost of ransomware is how bad budget cases get made.

None of this means the pressure has eased. Q3 2026 was the highest-volume quarter on record, with 2,627 claimed attacks, up 29% on the previous quarter and 61% year on year, and an average demand of 602,400 dollars. Qilin and The Gentlemen accounted for much of the volume. More attacks, lower payment rate, and a recovery problem that lands on the defender regardless of whether anyone pays.

What a Restore Actually Restores

A restored server carries its old configuration, including the local accounts, scheduled tasks and service credentials that existed at the time of the backup. If those were compromised before the snapshot, the restore reinstates the foothold. That is why clean recovery depends on establishing a boundary: which backups predate the intrusion, which systems can be re-imaged from vendor media, and which have to be rebuilt by hand. A backup taken six weeks before detection is only useful if you can show the attacker was not already present six weeks before detection, which is a forensic question, not a storage one.

Restore order matters as much as restore completeness. Identity comes first, because everything else authenticates against it, and a domain controller restored from a backup taken after a domain compromise is a liability. Then core network services, then the applications that hold the data, then the integrations that depend on both. Most recovery plans are written as a list of systems rather than a dependency graph, which is why they fail at the join points.

The Identity Rebuild Is the Part People Skip

If the attacker held domain administrator rights, restoring infrastructure without rebuilding the directory leaves them a way back in. The minimum credible rebuild includes a double reset of the KRBTGT account, rotation of every service account and scheduled task credential, revocation of refresh tokens and application consents, replacement of certificates issued by an internal authority that may have been compromised, and a review of every account created or elevated during the exposure window. Each of those steps has an operational cost, and each of them is routinely deferred because the business wants its file shares back.

Test the Restore, Not the Backup

Backup dashboards report success, which is a statement about copying, not about recovering. The number worth putting in front of an executive team is the measured time to restore a tier-one application from cold storage into a clean environment, with its dependencies and its identity, followed by a verification step that proves the data is intact. Organisations that have never run that exercise tend to discover two things: the immutability they paid for covers less than they thought, and the person who knows the restore procedure left.

Practical drills look like this: pick one business-critical service, restore it to an isolated network, bring it up with rebuilt credentials, validate it against a known-good checksum or reconciliation report, and time the whole thing. Then do it again next quarter with a different service, and let the result change the recovery time objective rather than the other way round.

Refusal Is a Decision to Rehearse

Choosing not to pay is the right default, and it is also a decision with legal, insurance and disclosure consequences that has to be made before the incident, by people who will not be in the room at three in the morning. The recovery plan should say who can authorise engagement, what sanctions exposure means for any intermediary, what the notification clock requires, and how the organisation will operate if the data is published anyway. Because that is the other half of the modern loss model: if the attacker took a copy, a perfect restore leaves the extortion entirely untouched.