The attack is over. The threat is contained, the insurer is engaged, the notification letters are drafted. And your business still can’t take an order.

That gap has a number attached to it. In the most recent Sophos survey of 3,400 organizations hit by ransomware, 53% were fully recovered within a week. But 18% took more than a month. Same threat, same year, wildly different outcomes.

The difference wasn’t luck. Sophos attributes the faster recoveries to organizations investing in incident preparation and recovery readiness before the attack. In other words, the companies back in business within a week made their recovery decisions in a calm conference room, months earlier. The companies down for over a month made those same decisions at 2 in the morning, with the clock running.

This is the last piece of the incident response story, and it’s the one most plans skip.

Two plans that have never met

Through this series I’ve walked you through the bad day itself. Ransomware in Part 1. Wire fraud in Part 2. The data breach and its legal clock in Part 3. An incident response plan is what carries you through those hours: detect, contain, communicate, engage the right people in the right order.

But an incident response plan gets you to “contained.” It does not get you to “operating.”

That second job belongs to your disaster recovery plan. Which systems come back first. Where the backups live and how fast they restore. Who declares the business recovered. In most small and midsize companies, if both plans exist at all, they were written by different people, at different times, and have never been tested in the same room.

Here’s the problem with treating them as separate documents. The old model assumed a clean handoff: response ends, recovery begins. Current federal guidance has abandoned that idea. The newest revision of NIST’s incident response framework, the standard your insurer and your auditors work from, now treats response and recovery as one continuous motion, because in real incidents they overlap from the first hour. Recovery decisions get made while the response is still running. If the 2 plans don’t know each other, that overlap is where your business stalls.

When the backup becomes the ransom

The clearest evidence of what a broken handoff costs shows up in the ransom negotiations themselves.

Backups were used to restore encrypted data in just 54% of ransomware incidents last year. That’s the lowest rate Sophos has recorded in 6 years of running this survey. Nearly half of victims either had no usable backup or couldn’t reach it when it mattered.

And among the organizations that ended up paying more than the attacker’s original demand, 38% said the reason was that their backups failed or were malfunctioning.

Read that again. A failed backup doesn’t just slow your recovery. It hands the attacker leverage in the middle of a negotiation, and the price goes up. Your disaster recovery plan, or the absence of one, is being read across the table by the person extorting you.

The average cost to recover from a ransomware attack, excluding any ransom paid, now runs $1.53 million. The single biggest variable in that number is how fast you get back to operating. Which means the biggest variable is work you either did or didn’t do before the attack.

The decisions that belong in the calm room

A disaster recovery plan that shakes hands with your incident response plan answers 4 questions, and every one of them is a business decision, not a technical one.

First, how long can you be down before the damage becomes permanent? Not “how long until IT fixes it.” How many days without invoicing, shipping, or answering the phone before customers leave and payroll is at risk? That number sets the budget and urgency for everything else.

Second, how much data can you afford to lose? If your last good backup is from Sunday night and the attack hits Thursday, you’ve lost 4 days of orders, timesheets, and records. Is that survivable? The answer determines how often backups run and where they live.

Third, what comes back first? When everything is down, everything feels urgent. A plan sets the order in advance: usually payment processing and customer communication before the file server, the file server before the marketing site. Without a decided order, your team restores whatever is loudest.

Fourth, who declares the business recovered? Someone has to own the call that systems are trusted again, that it’s safe to reconnect, that the incident is genuinely over. If that isn’t assigned, it defaults to whoever is most exhausted.

And underneath all 4: the backups get tested. Actually restored, on a schedule, with the results documented. An untested backup is a hope, not a plan, and the 38% figure above is what hope costs.

Two companies, same attack

Picture 2 companies, 60 employees each, hit by the same ransomware on the same Thursday.

The first one has the 2 plans stitched together. Response contains the attack by Friday. Because restoration order was decided in advance, payment systems and email are back Monday from tested backups. The owner spends the weekend on customers and insurance, not triage. They’re in the 53% that recovers within a week.

The second one has an IR document from an old compliance checklist and backups nobody has restored since they were configured. Containment goes fine. Then the restore fails. Now they’re negotiating with attackers who know it, deciding restoration order by argument, and discovering their recovery time question for the first time while the answer is being written for them. They’re in the 18%, and every week of that month costs them customers they won’t get back.

Same attack. The outcome was decided before it started.

Where this series lands

Four parts, one argument: an incident response plan is not an IT document. It’s the difference between a bad week and a threat to the business, and every piece of it, from the first phone call to the last restored system, is built or not built long before you need it.

If you’ve never seen your incident response plan and your disaster recovery plan in the same room, that’s the review to schedule. I help business owners run exactly that conversation.

Sources:

• Sophos, The State of Ransomware 2025 (survey of 3,400 IT/cybersecurity leaders in organizations of 100 to 5,000 employees)
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025)
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems