Ransomware Recovery Plan Basics for SMBs
A ransomware recovery plan is more than backups. RTO/RPO, immutable copies, tested restores and exfiltration response, explained for SMB leaders.
Most small businesses that get hit by ransomware thought they were fine beforehand. Aggregated third-party reporting puts that number at 69% of businesses believing they were well-prepared before they were attacked, with victims citing an average of 2.7 contributing factors afterward. That figure comes from a statistics roundup rather than primary research, so treat it as directional — but the pattern is familiar to anyone who has sat in a post-incident debrief.
A ransomware recovery plan is not the same thing as a backup product. Backups are one input. The plan is the part that says how long you can be down, how much data you can afford to lose, who declares an incident, and how you prove any of it works before you need it.
This post walks through the questions that make up that plan. It is education-stage on purpose: no product specs, no compliance promises, just the conversation we have with SMB leadership teams before we touch anything technical.
Why isn’t having backups the same as having a recovery plan?
Because having a copy of the data and being able to return the business to work are two different problems.
Sophos’s retail-sector research found that 62% of retailers hit by ransomware restored their data using backups — which Sophos describes as the lowest rate in four years. Plenty of those organizations had backups. Restoring from them is where it broke down.
The gap usually comes from things that are boring to fix and expensive to discover mid-incident: backup jobs that have been silently failing, a restore that has never been tested on a live system, no known-clean rebuild image for endpoints, no one designated to make the call to stop paying attention to root cause and start restoring.
A recovery plan makes those decisions in advance, in writing, while everyone is calm.
How fast do organizations actually recover from ransomware?
Reporting on Sophos’s 2025 State of Ransomware research states that 53% of organizations fully recovered within a week. The other half took longer — sometimes much longer.
That spread is the whole argument. The difference between one week and three months is rarely the malware. It is whether the organization had a tested restore path, a documented sequence for which systems come back first, pre-agreed escalation, and someone with authority available on a weekend.
If you want one metric to organize your planning around, use that one: could we be substantially back inside a week, and can we show why we believe that?
What does ransomware recovery actually cost?
Sophos reported that the mean cost to recover from a ransomware attack, excluding any ransom payment, fell 44% year over year to $1.53 million, down from $2.73 million in 2024.
Read that number carefully. It is a cross-industry survey figure weighted toward mid-market and larger organizations. It is not what an attack costs a 40-person business, and anyone who quotes it to you as an SMB figure is selling something.
What it is useful for is scale. Even a small fraction of that number — remediation labor, forensics, legal review, replaced hardware, weeks of degraded output — lands hard on a company with no slack in its cash flow.
On the ransom side, aggregated reporting attributed to the Verizon 2025 Data Breach Investigations Report puts the median ransom payment at $115,000, down from $150,000. Other datasets report much higher medians, but those samples skew toward large enterprises. The lower figure is the one closer to the SMB reality — and it is still a number most owners would rather not find out about firsthand.
Why do attackers go after backups first?
Because your recovery capability is the thing standing between them and leverage.
Aggregated 2026 reporting claims backup repositories are targeted in 96% of ransomware attacks, are successfully compromised 76% of the time, and that organizations with compromised backups face recovery costs roughly eight times higher than those with intact backups. Those figures come from an aggregator page rather than the underlying study, so we would want them traced to primary research before anyone builds a budget case on them. Even discounted, the direction is consistent with what incident responders describe.
The design response is the same regardless of the exact percentages:
- Immutable copies. At least one copy that cannot be altered or deleted within its retention window, including by an administrator.
- Offsite or air-gapped separation. A copy that does not depend on the same network, hypervisor, or storage as production.
- Separated backup credentials. Backup administration should not use domain credentials. If one compromised account can encrypt production and delete backups, you have one system, not two.
- Alerting on the backup system itself. Deletion attempts and retention changes are incident signals.
Speed matters here too. Aggregated reporting states that in 54% of incidents, ransomware is deployed within seven days of initial access — a short window in which to notice something is wrong.
What are RTO and RPO in plain English?
RTO is how long a system can be down before the damage is unacceptable. RPO is how much data you can afford to lose, measured in time.
You do not need a framework to set them. Take your five most important workloads — email, file shares, the line-of-business application, finance, and whatever your industry runs on — and answer two questions for each: if this is unavailable for four hours, what happens? If we lose the last hour of work in it, what happens?
The answers will differ per system, and that is the point. A file share that can tolerate a day of downtime and a scheduling system that cannot tolerate an hour should not have identical protection. Once those numbers exist, backup frequency, retention, and recovery order stop being technical opinions and become business decisions.
Does paying the ransom get your data back?
Not reliably. Aggregated third-party reporting states that among small and mid-sized enterprises that paid, only 60% successfully recovered their data, 31% received further demands for more money, and 69% of businesses that paid were attacked again within the following year. These are aggregate figures from statistics roundups rather than primary studies, so hold them loosely — but no source we reviewed suggests paying is dependable.
Refusal is now the majority behavior: aggregated reporting puts it at 63% of victims declining to pay in 2025, up from 59% in 2024. That shift is generally attributed to improved recovery capability, which is the only part of this equation you actually control.
Anything touching payment legality, sanctions exposure, or whether your policy responds is a conversation for your counsel and your carrier, not a blog post.
What if they steal the data instead of encrypting it?
Then restoring files solves nothing, and a plan built only around restores has a hole in it.
Sophos’s enterprise research reported that data encryption fell to its lowest rate in five years, with 49% of attacks resulting in encrypted data, down from 66% in 2024, while the share of attacks stopped before encryption more than doubled from 22% in 2023 to 47% in 2025. In Sophos’s retail dataset, extortion-only attacks tripled, from 2% of incidents in 2023 to 6% in 2025.
So your plan needs a second branch: how you establish what was accessed, who you engage for forensics, which counsel reviews notification obligations, and who communicates with staff, customers, and partners. Write down the phone numbers now.
What actually goes into the plan?
Keep the first version short enough that people read it.
- Prioritized system list with an RTO and RPO for each.
- Who can declare an incident, and their backup — by name and role.
- The restore runbook, including known-clean rebuild images and the order systems return.
- Proof of the last successful test restore of a live system, with a date.
- The data-exfiltration branch: forensics, counsel, notification, communications.
- Out-of-band contact method for when email and chat are unavailable.
- Patch and vulnerability ownership. Sophos found that for the third consecutive year, victims identified exploited vulnerabilities as the most common root cause, used in 32% of attacks overall. Patching and recovery planning are the same conversation.
If you carry K-12, government contracting, healthcare, or grant-funded obligations, backup and incident-response expectations show up in frameworks you already answer to. We are deliberately not mapping controls in an education-stage post — that deserves a direct conversation against the current published requirements rather than a summary.
Where Acronis fits
palmiq is an Acronis Platinum partner, in the top 1% globally, and Acronis is one of the platforms we deploy and manage for SMB backup and recovery. We also run a 24/7 SOC with a 15-minute response SLA on critical issues, so the detection side and the recovery side are not two separate phone calls.
We will not restate platform specifications here. When we scope a recovery design, capability claims get verified against Acronis’s current documentation and matched to the RTO and RPO targets you set — not the other way around.
If you want a second opinion on whether your current setup would survive a bad Tuesday, book a discovery call: https://palmiq.com/discovery-call.