Restoring is not recovering: two in three recover from backup and nearly half still pay

There is a figure in Sophos's annual ransomware report that in any other year we would have celebrated without caveats: 66% of organisations whose data was encrypted recovered from their backups, twelve points more than last year. It is a sharp rebound: in 2025 it was 54%, the lowest level in six years according to the report itself. Right next to it sits another one: 48% paid the ransom. And a third that overshadows both: the average cost of recovering rose 11% to $1.7 million, ransom excluded.

The easy reading is that the three numbers contradict each other. They tell the same story from three angles, and it is a story close to home for us: the backup, as a technical component, has clawed back most of the ground it lost last year. Around it there is the same old mess. Restoring a volume and recovering a company are two different jobs, and only one of them shows up in last night's backup status report.

Where the numbers come from

It pays to know what you are reading before arguing about it. The study is commissioned by Sophos and run by Vanson Bourne in the first quarter of 2026: 2,158 IT and security leaders at organisations of 100 to 5,000 employees, across 17 countries (Spain among them), in fifteen sectors, all of them ransomware victims in the previous twelve months. It is a survey of victims, not a picture of the market: the percentages describe who it happened to, not how likely it is to happen to you. With that caveat in place, these are the figures that matter:

Who restored and paid at the same time

The headline going round these days is that "backups are winning". If only. Both percentages are calculated on the same base, the victims whose data was encrypted, so 66 plus 48 does not fit into 100: at least fourteen in every hundred both restored and paid. The report does not say why, so what follows is our own reading. There are mechanical explanations —decryption looked faster than restoring, or the backup covered some systems and not others— and there is one we see more often: the ransom is not always paid to get the data back, but to keep it from being published.

We wrote about this a few days ago over a campaign that does not even bother encrypting: your backup gives you the service back, not confidentiality. No backup undoes a leak. The report puts a number on that boundary —16% of victims were both encrypted and robbed— and that 16% is the most visible part of the problem restoring does nothing for, because thefts without encryption do not even enter that count.

A note on method, because it is easy to misread: the median demand was $698,000 and the median payment was $769,000. It looks like people paid more than they were asked for, and that is not it: these are two different populations —all victims versus only those who paid— and whoever ends up paying tends to be whoever got the biggest demand. With the same report saying 51% of payers negotiated below the initial demand, the honest conclusion is the opposite: people negotiate downwards, but those who pay start from higher numbers.

The ransom drops and the bill goes up

This is, for us, the most important line in the report: the median ransom demand has dropped 65% over two years while the average recovery cost has risen 11% to $1.7 million per incident. The two curves run in opposite directions. What is getting cheaper is the part that makes headlines; what is getting more expensive is the part you pay even if you never negotiate with anyone.

And inside that $1.7 million there is no cryptocurrency at all. There are hours of your own people and other people's, hardware bought in a hurry, emergency licences, forensics so you can say with certainty what was taken, weeks of manual work re-entering whatever was lost between the last good backup and the encryption, lawyers, communications, and customers calling to ask why their order is not moving. A fast restore prevents none of that. Deciding beforehand in what order each thing comes back reduces all of it, a lot.

"One week" sounds fast until you put it in your own calendar

55% recovered within a week or less and only 16% in under a day. Put the other way round, which is how it should be put: 45% took more than a week, and 84% took more than a day. Now take your own calendar and cross out five consecutive working days. No invoicing, no production, no ERP, email half-working, and the whole workforce doing what it can on paper or in spreadsheets. That is the real unit of measurement for a continuity plan, and it does not fit in any SLA from your backup provider.

We said it ten days ago about an AWS outage and it holds here: recovery time is not a property of the backup, it is a property of the whole system. It depends on how many machines have to come up and in what order, on whether directory and DNS return before the applications that depend on them, on how many megabytes per second your backup storage really delivers when you restore ten servers at once instead of one, and on whether anyone can state without crossing their fingers that the machine you just put back on the network is clean.

97% had MFA

The other half of the report explains why this keeps happening, and there is a reversal in it: for the first time in four years exploited vulnerabilities are no longer the main way in —down to 18%, fourteen points less than the previous year— and 79% of attacks start at an identity. Malicious email (26%) and phishing (24%) on their own account for half of all incidents. Attackers have stopped forcing the window because they have the key to the door.

The figure that should keep you up at night is one line below: in 97% of incidents whose root cause was compromised credentials, the organisation had MFA deployed in some capacity. That "in some capacity" is the report's own wording, and it is where all the comfortable exceptions live: the inherited service account, the legacy protocol nobody dares switch off, the portal left outside the policy, the SMS second factor an attacker intercepts or simply asks for over the phone. We wrote about that last one when Microsoft announced it was retiring SMS as a second factor. MFA with exceptions is not MFA: it is an inventory of exceptions.

This has a direct consequence for how backups are designed, and it is why we are putting it in a post about recovery: if the attacker gets in with legitimate credentials, they get in with permissions. A backup reachable with the same admin credentials as the rest of the environment is not a backup, it is one more system inside the blast radius. We saw it spelled out in the wiping of Romania's land registry: the attacker broke nothing, they authenticated.

Five things worth timing before the bad day

We run backups with Proxmox Backup Server and with Veeam, with the usual discipline —three copies, two media, one offsite; at least one immutable— and we have spent years watching the same scene: the backup is green and nobody knows how long the way back takes. That is why a restore drill worth running is not about opening one file and calling it a day. These are the five things worth timing, and all five spring surprises the first time round:

All five are solved by giving them an afternoon each quarter, with a stopwatch running and someone writing the times down in a document you can later show to people. That document is, literally, your continuity plan; the rest is a folder full of backups.

What we take away from this report

This year's report brings good news about backups and bad news about everything else, and that combination is exactly the one we saw coming: the industry has gone back to solving the problem of having the data reasonably well and still has not solved the problem of getting back to business. That is why the ransom drops and the bill goes up. If next year you want to be in the 16% that recovers in under a day instead of the 45% that takes more than a week, the difference will not come from the backup software you buy this autumn: it will come from how many times you timed the way back before you needed it.

Sources (verified): all figures come from Sophos's The State of Ransomware 2026, the seventh edition of the study, conducted by Vanson Bourne in the first quarter of 2026 with 2,158 IT and security leaders at organisations of 100 to 5,000 employees across 17 countries (Spain included) and fifteen sectors, all of them ransomware victims in the previous twelve months. Specific data —79% of attacks originating in compromised identities, 26% malicious email and 24% phishing, 18% exploited vulnerabilities, 97% of credential-caused incidents with MFA deployed, 56% encryption with 16% encryption plus theft, 48% payment among encrypted victims, 51% negotiating below the initial demand, median demand $698,000 and median payment $769,000, a 65% drop in median demands over two years, average recovery cost of $1.7M per incident (+11%), 55% recovered within a week and 16% in under a day— published in the official Sophos press release and in the report summary (the 66% backup recovery figure, twelve points above 2025, and the 11% rise in recovery cost come from the latter). The 54% of 2025 and its status as the lowest level in six years are in the previous edition of the same report: that is why we call it a rebound and not a record. These are our reading and not the report's: the warning about the two medians (demand and payment are computed over different populations and do not support the conclusion that anyone paid above what was asked), the minimum fourteen-point overlap between those who restored and those who paid —along with the reasons we attribute to it, which the report does not explain—, the inverted reading of the recovery figure (45% above one week, 84% above one day) and the five things worth timing in a restore drill.