I am assuming you have backups for your critical data (if you don't, please stop reading and go make backups!). The question I have is: when was the last time you tested your backups? From start to finish, onto a clean machine, opening the files to check they were actually there? For most small companies the honest answer is: "never". The gap between an untested backup and a tested one is what decides whether the next ransomware note means a bad week or the last week of the business. Here's what to test and what to prepare if you want to survive an attack.
Everyone has a "backup". Few have a "recovery".
A backup you have never restored is a guess about the future, and you find out whether it was a good guess at the worst possible moment.
Last year, in companies whose data was encrypted by ransomware, 97% eventually got it back — but only 54% recovered from their own backups, the lowest rate in six years, and 49% paid the ransom anyway.
Sophos, The State of Ransomware 2025: backups were used in just over half of recoveries, while nearly half of victims paid.
Most of the companies that paid had backups. The backups just weren't there when it counted — stale, sitting on a drive the attacker also encrypted, or never once tested.
The cheapest thing on your security list
Cloud storage and an external drive are cheap. The expensive part is the thinking.
YOU are the one responsible for your Disaster Recovery Plan. If you're a CTO yourself, or you've hired one, let them make the call — but the conversation between the CEO and CTO still needs to happen. It will save you countless hours of pain in the future.
Sit down and get it over with in an afternoon, this is not the type of project that takes months to complete.
Write the plan: what, where, who, how long
Keep it to one page.
- What comes back first. List the handful of systems the business genuinely can't run without, in order. You restore those before anything else.
- Where the safe copy lives. At least one copy offline or immutable — a version the same attack can't reach or overwrite.
- Who runs it. A named person, with the access and the steps written down, so recovery doesn't depend on one busy founder being reachable.
- How long you can survive without it. How old a copy you can accept, and how many hours down you can absorb before it hurts. Plain numbers, no jargon. This will determine how frequently you need to back up your data.
Test the restore
Once a quarter, restore your critical systems onto a spare machine, time how long it takes, and open the files.
The first test always finds something — an incomplete backup, a missing password, a step only one person knew. If the first test works, I would question the quality of the test. A failing test is doing its job. You want to find issues on a quiet Tuesday, while nothing is on fire.
Do this before you buy a single tool
Antivirus, EDR, firewalls — every one of them assumes you survive the day it fails to stop something. A tested recovery plan is what makes that assumption true, and it comes before any of them.
When did you last actually restore from a backup and watch the files open? If you're not sure, that's the first thing to fix this week.
If you'd rather not find out your backups don't work during a real incident, we are here to help. We help small teams pressure-test their recovery plan — pankeit.com.
References
- Sophos, The State of Ransomware 2025: https://www.sophos.com/en-us/blog/the-state-of-ransomware-2025
Instagram