Ransomware readiness — the plan that holds up in the first hour

Ransomware is no longer a malware problem; it is a business-continuity problem with a malware trigger. The groups running it are organized, patient, and they have read the assumptions in your incident response plan better than you have.

If you run IT or security: this is the gap analysis for your current plan. If you are an exec: this is why "we have backups" is not the answer you think it is. If you have never been through one: this is the compressed version of lessons that usually cost a company its worst week.

The mental image — a user clicks a link, files encrypt, a ransom note appears — is a decade out of date. Modern ransomware is a multi-week operation.

It starts with access: a phished credential, an exposed remote service, an unpatched edge device, or access bought from a broker who got in weeks ago. Then comes the quiet part: the attacker moves laterally, escalates privilege, learns your environment, and finds your backups. Then they steal data — because the real leverage now is the threat to publish it. Only at the end do they encrypt, usually on a Friday night or before a holiday, and usually after they have already deleted or encrypted the backups you were counting on.

By the time you see the ransom note, the attacker has been in your network for days or weeks. The note is the last step, not the first.

The single most important shift: attackers steal your data before they encrypt it. This is "double extortion," and it breaks the old playbook.

In the old model, good backups meant you could refuse to pay — restore and move on. In the double-extortion model, restoring your systems does nothing about the copy of your data sitting on the attacker's server. They will threaten to publish it, sell it, or notify your customers and regulators. Many will extort a second time even after you pay.

The implication is uncomfortable but clear: backups protect your availability, not your confidentiality. A plan that assumes "we can always restore, so we never have to pay" no longer matches how these attacks work. You have to prevent the data theft, not just survive the encryption.

When it hits, the first hour decides a lot. The instinct is to start restoring immediately. That is usually the wrong first move, because if you do not understand how they got in, you restore straight back into a compromised environment.

The right sequence. Contain before you clean: isolate affected segments, disable the compromised accounts, cut the paths the attacker is using — without wiping the evidence you will need. Preserve, do not destroy: snapshot systems before reimaging; you will need forensics to find the entry point and to answer regulators. Assemble the right people: this is not just IT — it is legal, communications, leadership, and often outside IR and counsel. Decide who can authorize what before you are in the room.

The single biggest first-hour mistake is rushing to restore. The second is going silent — internally and with the people who need to know.

Attackers know that backups are what stand between you and paying. So backups are now a primary target, and they are usually attacked first.

The backups that survive a ransomware event share three properties. They are immutable — once written, they cannot be altered or deleted for a fixed window, even by an administrator. They are isolated — the backup environment is not reachable with normal production credentials, so a domain compromise does not reach it. And they are tested — someone has actually restored from them recently and knows how long it takes.

The classic failure is backups that are online, reachable with the same admin credentials as everything else, and never test-restored. Those are not a safety net. They are just more files for the attacker to encrypt.

The question every leadership team asks in the first hour, and the worst time to think about it for the first time.

The honest reality: paying is not illegal in most jurisdictions, but it is fraught. It may be sanctioned if the group is on a government list — paying certain actors can itself be a violation. Paying funds the next attack and marks you as someone who pays. And the decryption tools you get are often slow, buggy, or incomplete; paying does not guarantee a clean recovery.

The right answer is to make the decision in advance, in calm conditions, with legal and leadership: under what circumstances would we consider paying, who is authorized to approve it, and what is our position on data-theft extortion specifically? A company that decides this during the crisis decides it badly.

Because modern ransomware spends days in your network before it encrypts, the encryption is the failure, not the attack. Every hour before that is a chance to catch it.

The signals are detectable if anyone is watching. Sudden privilege escalation. A spike in failed logins followed by a success. Reconnaissance commands enumerating the network. Backup systems accessed by unusual accounts. Large volumes of data moving to an external destination — the exfiltration before the encryption. Security tools being disabled.

This is the case for a SOC that actually monitors, not just collects logs. The organizations that catch ransomware before encryption are the ones watching for the quiet middle of the attack. The ones that find out from the ransom note were collecting the same logs — nobody was reading them.

Even with good backups, recovery is harder than teams expect, because they have rehearsed restoring one server, not rebuilding an enterprise.

The questions that surface during a real recovery: In what order do systems come back? (Identity and DNS before the apps that depend on them.) How do you rebuild without re-importing the compromise? How long does a full restore actually take at scale — and is that within what the business can survive? Who is doing the work, for how many consecutive days, and what happens when they burn out in week two?

The answer is a tested recovery runbook and at least one realistic exercise. Not a tabletop where everyone agrees the plan is good — an actual restore of a representative system, timed, with the gaps written down.

Eight things that separate a fast recovery from a catastrophic one.

1. Immutable, isolated, recently-tested backups. The single highest-value control.

2. Phishing-resistant MFA on every external entry point — VPN, email, remote access. Most intrusions start with a credential.

3. Patched and monitored edge devices. The internet-facing VPN, firewall, and gateway are the most common entry points.

4. Network segmentation that limits lateral movement, so one compromised host is not the whole estate.

5. A SOC or monitoring capability watching for the pre-encryption signals, not just storing logs.

6. An incident response plan with named roles, decision authority, and outside IR and legal on retainer.

7. A pre-decided position on payment and data-theft extortion, made with legal before the crisis.

8. At least one realistic recovery exercise per year, timed, with gaps remediated.

If more than two of these are missing, the plan is a hope, not a plan.