What ransomware recovery actually involves
Most business owners imagine ransomware recovery as a transaction: you pay, you get a key, you decrypt your files, you're done. That picture is wrong in almost every way.
Even in scenarios where decryption is possible — and it often isn't, because decryptors provided by attackers are unreliable, incomplete, or simply nonexistent — decryption is the smallest part of recovery. Before you can trust your systems again, you have to answer a set of questions that have nothing to do with decryption: How did the attacker get in? Are they still in? What else did they access or exfiltrate? Were the backups compromised? Are any credentials still in their hands?
Until those questions are answered, restoring from a decryption key or from backups onto a still-compromised network just means getting encrypted again — or handing your rebuilt systems back to an attacker who never left.
Real recovery involves isolating the incident, scoping the damage, rebuilding from clean sources, resetting every credential that may have been exposed, restoring normal operations, and then figuring out what happened and how to prevent it. Done right, it takes days. Done wrong — or without preparation — it takes weeks to months, and some businesses don't make it through.
Why paying is a trap
Paying the ransom is almost never the right answer, and the reasons go beyond the obvious one.
The obvious reason: there's no guarantee. Attackers have no incentive to provide a working decryption key after payment, and many don't. The decryptor may be buggy, may only recover some files, or may not arrive at all. You've paid, and you still need to rebuild.
The less obvious reasons: payment doesn't remove the attacker from your network. In most ransomware incidents, the attacker was present for weeks before the encryption event — moving through systems, stealing data, escalating privileges. Paying to decrypt files doesn't undo any of that. They still have your credentials. They still know your network layout. You're recovering into a compromised environment unless you do the forensic work regardless.
Payment also funds the same criminal operations that attacked you, making future attacks more likely — both against you and against others. And depending on who the attacker is, payment may violate U.S. Treasury OFAC sanctions if the group is designated. That creates legal exposure on top of everything else.
The cases where paying makes sense are genuinely rare — typically where backups are completely unavailable, data loss would be catastrophic and irreversible, and all other options have been exhausted. Even then, payment should only happen after legal consultation, not as the first response under pressure.
The single thing that determines outcome
If there is one factor that separates businesses that recover quickly from those that don't, it is this: tested, isolated backups.
Not backups. Tested, isolated backups.
A backup stored on the same network it backs up — or connected to it — can be encrypted alongside your production systems. That is the most common failure mode in ransomware recovery. The business discovers it had backups; it discovers those backups were also encrypted; it has no path to recovery without paying.
Isolated backups — stored offsite, in a cloud account that isn't connected to your production environment, or on an immutable storage platform where data can't be deleted or modified during a retention window — survive ransomware. So do air-gapped backup copies rotated offsite physically.
And tested means the restore has actually been run. Backup files that have never been tested are not backups — they're untested assumptions. A restore that takes 45 minutes in a drill takes 45 minutes during an incident. A restore that has never been tested may not work at all.
See the backup and restore guide for what a tested backup program looks like in practice.
A realistic recovery sequence
When ransomware hits, the sequence matters. Moving too fast — or skipping steps — creates new problems.
1. Isolate. Disconnect affected systems from the network immediately. The goal is to stop the spread to systems that haven't been encrypted yet. Do not power systems off; forensic evidence lives in memory and logs.
2. Assess scope. Before touching anything, understand what was hit. Which systems are encrypted? When did the attacker first appear in logs? What accounts were used? Which data may have been accessed or exfiltrated? This step is often skipped under pressure and almost always causes problems downstream.
3. Restore from clean backups. Once you know the scope and have identified the intrusion vector, restore from a known-clean backup onto a clean environment — not onto the existing infrastructure until it's been verified. Confirm the restore point predates the attacker's initial access, not just the encryption event.
4. Rebuild identity and credentials. Every account that existed in the compromised environment should be treated as potentially compromised. Reset passwords, rotate service account credentials, revoke active sessions, and review MFA enrollment. If the attacker had access to your identity infrastructure, this step requires careful attention.
5. Post-incident review. After operations are restored, document what happened, how the attacker got in, what was accessed, and what the recovery cost — in time, revenue, and direct expense. Use that to close the gaps that allowed the incident and to inform your incident response plan for next time.
Why prevention is far cheaper than recovery
The total cost of a ransomware incident — lost revenue during downtime, incident response fees, staff time, potential regulatory notification costs, reputational damage, and increased insurance premiums — consistently exceeds the cost of the preventive controls that would have stopped it or dramatically reduced its impact.
The prevention layer isn't exotic: tested and isolated backups, EDR that monitors behavior rather than just scanning for known signatures, MFA on every account that matters, and email security that catches the phishing attempt before it delivers the initial access. That combination doesn't prevent every incident, but it raises the bar high enough to redirect most attackers to softer targets — and it makes recovery fast when an incident does occur.
The disaster recovery guide covers how to build a documented plan before you need it.
Cyber insurance and your incident response plan
Cyber insurance covers many of the costs associated with a ransomware incident — incident response fees, notification costs, business interruption losses, and sometimes ransom payments. But coverage has conditions.
Most cyber insurance policies require specific controls as a precondition of coverage: MFA, tested backups, documented security policies. A policy that looked adequate at renewal can be denied at claim time if those controls weren't actually in place. Review your policy terms carefully, and confirm with your provider that what you have in place satisfies their requirements. The cyber insurance guide covers what to look for.
An incident response plan isn't just a document — it's a decision tree you build before you need it. Who calls whom when an incident is detected? What's the escalation path? Who is authorized to make recovery decisions? Who handles communications to customers, regulators, or partners? Having those answers documented in advance reduces the chaos cost of an incident substantially.
Ransomware is a solvable problem for most small businesses. Not by eliminating risk entirely — that's not achievable — but by building the layer of controls that makes fast, complete recovery possible without paying criminals and without losing months of data.