On 15 July 2026, Sophos published its annual ransomware report: among organisations whose data was encrypted, 66% recovered it from their backups, up from 54% a year earlier. Two victims out of three, then, get out of it through ransomware backup recovery. For a small business, the useful question is not "do I have backups?" but "would my backup survive a ransomware attack, and could I actually restore it?".
Key takeaways
- According to Sophos, 56% of ransomware attacks succeeded in encrypting the victim's data over the twelve months studied.
- When data is encrypted, 66% of organisations recover it from backups and 48% pay the ransom, and both answers can apply to the same victim.
- Paying guarantees nothing: according to Hiscox, only 60% of businesses that paid got all or part of their data back, and 31% were asked for more money.
- A backup only protects you from ransomware if it is out of the attacker's reach and its restore has been tested.
What is happening
The report The State of Ransomware 2026 is based on a survey run from January to March 2026 by the research firm Vanson Bourne on behalf of Sophos, among 2,158 IT and cybersecurity leaders in 17 countries. All of their organisations, from 100 to 5,000 employees, had been hit by ransomware in the previous twelve months. It is a snapshot of victims, not of businesses in general.
Three figures deserve attention. First, 56% of attacks ended with data encrypted, up from 50% in the previous edition: attackers are regaining ground. Second, among organisations whose data was encrypted, 66% recovered it from backups, 12 points more than a year earlier. Third, 48% paid the ransom. The survey allowed several answers: the same company may have restored part of its data and paid for the rest. Only 2% got nothing back at all.
The report also notes that the smallest organisations surveyed, with 100 to 250 employees, stopped the attack before encryption in only 34% of cases, against 46% for the largest, with 3,001 to 5,000 employees. And the average cost of recovery, excluding any ransom, reaches 1.7 million dollars per incident.
Its recommendation on this point is unambiguous: backups that are tested regularly, stored offline or in an immutable form, and built into a documented incident response plan that can be carried out under pressure.
The insurer Hiscox provides the other half of the picture. In its 2025 Cyber Readiness Report, published on 29 September 2025 and covering 5,750 businesses in seven countries, 27% of companies said they had suffered a ransomware attack in the year. Of those, 80% paid. Yet only 60% of those who paid recovered all or part of their data, and 31% received a further demand for money.
What it means for your ransomware backup and recovery
The good news is real: a well-built backup remains the safest way out of a ransomware attack without negotiating with the people who attacked you. But the gap between "having backups" and "recovering thanks to backups" is exactly where the third victim sits. The report does not say how many of them believed they were covered. In practice, I see three main causes.
The backup is within the attacker's reach. An external drive that stays plugged in, a network share reachable from the server, a folder synced to the cloud: if your server can write to the backup, whoever takes control of your server can delete or encrypt it too.
The backup is incomplete or unusable. A database copied file by file while it is running can look like a backup without being restorable. A gap in scope (email, configuration, attachments) only shows on the day it is missing.
Nobody has ever restored it. Then you discover, under pressure, that a password is missing, that the procedure is written nowhere, or that the restore takes three days instead of three hours. A backup that has never been restored is only an assumption.
What I have learned
I apply these rules to my own management system, the one that runs the accounting, websites and appointments of my companies. Every night, the database is exported and then automatically read back: an unreadable export makes the job fail instead of going unnoticed. A copy then goes off-site, to storage where the production server can add backups but cannot delete them. If that server were compromised, the attacker could not destroy the history. I am notified on every run, on success as well as on failure: silence is never good news.
In September 2026, I reviewed the whole chain and found a trap: the copy of the database's raw files, taken while the engine was running, looked like a backup with no guarantee of being restorable. I removed it and kept only the verified export, rather than let someone believe one day that they could rely on it. Then I ran the only test that matters: restoring the night's export into a disposable environment cut off from any network, and comparing the result with production. The restore finished in under two minutes, without errors, and all seven control counts matched. I repeat this test at least once a quarter and after every significant update. Another rule: I take a backup before any intervention that changes data.
I also learned that a safety net nobody has tested can give way. After an automatic system update, my application did not restart: 8 h 30 of downtime on the websites, while I believed that case was covered. I fixed the setting, then deliberately triggered the same failure to check it: the service came back on its own in under half a minute. It is the same logic as for a backup: until you have played the scenario, you do not know.
This is not new in my work. When I designed the IT infrastructure of AtonRa Partners, a financial management firm, backups were part of the foundation, alongside servers, network and access security, with technical documentation handed over to the team. The tools have changed since; the principle has not.
What to do in practice
1. List what has to come back
Databases, shared files, email, accounting documents, server and application configuration. For each: how many days of data can you afford to lose, and how long can you stay down? Those two answers dictate how often you back up and what kind of solution you need.
2. Keep one copy out of reach
At least one copy outside your premises that your servers can neither change nor delete: append-only storage, immutable for a set period, or a disconnected medium. Keep several generations, over several weeks and several months, so you can go back to before a quiet infection started.
3. Have every backup checked automatically
A backup job should check what it produces and notify you on failure as well as on success. If you receive nothing, that is a warning sign, not a break.
4. Test a full restore
In an isolated environment, actually restore your data and compare it with production. Time the operation: that is your real recovery time. Do it again at least once a quarter and after every significant change.
5. Write the procedure before you need it
Who decides, who calls whom, where the credentials needed for the restore are kept, in what order services come back, and what your position is on paying a ransom. A decision made calmly is better than one made in the middle of a crisis.
Frequently asked questions
Is cloud sync enough as a backup against ransomware?
No. Sync faithfully copies the files that the ransomware has encrypted. You need versions kept over time and a copy that your computers and servers cannot change.
How often should a restore be tested?
At least once a quarter, and always after a major update of an application or a database. A test that has never been run tells you nothing about your real recovery time.
Should you pay the ransom if the backups are missing?
That decision is yours, but the Hiscox figures are clear: paying guarantees neither the return of your data nor the end of the demands. The best position is never to have to make that choice.
Going further
I design and run infrastructure for small and mid-sized businesses, backups and restore tests included: see the Systems and infrastructure page. If you want to know whether your backups would hold up against ransomware, let's talk during a 20-minute call.
Sources
- The State of Ransomware 2026, Sophos, report published on 15 July 2026.
- 79% of Ransomware Attacks Now Originate from Compromised Identities, Sophos Report Finds, Sophos, press release, 15 July 2026.
- Cyber-attacks leave SMEs with hefty fines and uncertain futures (Hiscox Cyber Readiness Report 2025), Hiscox Group, 29 September 2025.
Photo: Domaintechnik / Unsplash (unsplash.com/photos/VHmBX7FnXw0).
Tags: ransomware, backup, restore, small business, cybersecurity, business continuity, infrastructure