Special operations units have a saying: slow is smooth, smooth is fast. It sounds like a paradox until you’ve watched what happens without it. Rush a task you haven’t drilled and you fumble it: a dropped magazine, a missed step, a door breached wrong. Now you’re slower than if you’d taken the extra half-second to do it right. Slow down, do it the way you practiced, and the motion looks unhurried but the outcome arrives faster, because you didn’t have to pay for a mistake.
Incident response runs on the same physics. The teams that look calm during a ransomware event aren’t calm because the stakes are low. They’re calm because the decisions that matter were already made, tested, and rehearsed before the pager went off. The teams that scramble aren’t slower because they’re less capable. They’re slower because they’re improvising decisions live, under pressure, for the first time, with the clock and the attacker both running.
The case: a restore that couldn’t wait
A few years ago I worked a ransomware case where the client’s Exchange server had been encrypted along with most of the rest of their environment. They had backups, and they had a backup appliance that supported instant recovery: spin up a virtual copy of the server and run production off of it while the real restore happened in the background. On paper, that’s exactly the kind of resilience you want.
The problem was capacity. Both the original Exchange server and the backup appliance running the instant-recovery copy were underpowered for the mail load they’d be asked to carry, a fact everyone on the response could see once we started looking at the specs. We told the client that running live email through that setup, mid-restore, was likely to overload it and crash. They heard the warning and decided the business cost of email being down outweighed the risk. It was, in fairness, a real tradeoff: email had been down for days already, and the pressure to bring it back was intense.
They turned it on. It crashed.
The crash didn’t just cost them the email downtime they were trying to avoid. It corrupted the in-progress restore and set the real recovery back by several more days. Backups that should have gotten them out of paying the ransom no longer would, on the timeline the business could tolerate. They ended up paying the ransomware actor for a decryption key, specifically because the restore had been delayed past the point their leadership was willing to wait. A recoverable incident became an extortion payment because of one decision made in the middle of the fire.
Where the decision actually should have been made
Nothing about that outcome required bad luck. The underpowered hardware wasn’t new information created by the incident. It had been true the whole time, sitting undiscovered in a DR plan nobody had stress-tested against a real production load. The tradeoff between “email down for X more days” and “risk overloading the recovery path” is a legitimate business decision. It’s just a much better decision when it’s made on a Tuesday afternoon in a tabletop, with time to check the appliance’s actual throughput numbers, than when it’s made at 2 a.m. on day four of a ransomware event with the CEO asking why email still isn’t back.
That’s the whole point of slow is smooth. The speed doesn’t come from moving fast when the incident hits. It comes from having already done the slow, unglamorous work beforehand: knowing your actual restore times under real load, knowing what your backup infrastructure can and can’t carry simultaneously, and knowing in advance which risks your organization is and isn’t willing to take. When that thinking has already happened, the in-incident decision is fast because it’s not really a decision anymore. It’s executing a plan.
What this means for your IR and DR program
A few concrete things follow from this:
- Test recovery capacity under realistic load, not just “does the backup work.” A restore that succeeds in a quiet test environment can still fail when it’s carrying live production traffic on hardware sized for backup duty, not primary duty.
- Run tabletop exercises that include the ugly tradeoffs, not just the clean technical steps. “Do we run degraded service through a system we’re not sure can handle it” is exactly the kind of question a tabletop should surface and debate before it’s asked for real.
- Write down risk tolerance in advance. If leadership decides in a calm planning session that a multi-day outage is preferable to risking the restore path, that’s a defensible, informed call. Making the same call for the first time mid-incident, without the numbers in front of you, is a gamble.
- Treat DR exercises as a capacity check, not a checkbox. The value isn’t in confirming a backup exists. It’s in finding out, somewhere other than a live incident, that your restore infrastructure can’t carry the load you’re about to ask of it.
None of this prevents ransomware from happening. What it prevents is the second incident, the one caused by an untested assumption made under pressure, from stacking on top of the first. Slow, deliberate preparation is what makes the actual response smooth, and smooth is what makes it fast when it counts.
If your incident response and disaster recovery plans haven’t been pressure-tested with a real tabletop, that’s where to start, before you’re the one deciding, live, whether an underpowered server can carry the weight you’re about to put on it.