Your ransomware playbook is probably putting the wrong person in charge at 4 a.m.
A growing body of evidence shows that the real damage in ransomware incidents often comes not from the attack itself, but from who gets to decide whether to pull the plug on a business-critical system.
Key points
- Ransomware, malicious software that locks a company's systems until a payment is made, appeared in 48 percent of all data breaches studied in Verizon's 2026 Data Breach Investigations Report, which drew on more than 31,000 incidents across 145 countries.
- The median ransom payment dropped to $139,875 in that same report, meaning the cost of stopping a business to fight the attack often dwarfs the ransom itself.
- Colonial Pipeline's May 2021 shutdown lasted six days and affected 17 states, even though the ransomware never touched the pipeline's operating systems.
- NIST, the US government body that sets security standards, finalised updated incident-response guidance in April 2025 that explicitly moves ownership of these decisions away from security teams and toward named business leaders.
- Most company playbooks do not record who is authorised to take a revenue-generating system offline at 4 a.m. on a Saturday.
Picture this. It is 4:47 on a Saturday morning. A security analyst on overnight duty watches ransomware, the kind of malicious software that scrambles files and demands payment to unlock them, spreading across three servers. The playbook, the step-by-step response guide sitting open on the analyst's second monitor, says isolate those servers: cut them off from everything else to stop the spread.
Sixteen minutes later, the company's chief financial officer is calling. Those three servers were the live payment system.
The malware might have reached a dozen more machines if left alone. The isolation took down revenue for fourteen hours. The Monday question from the board is not "how did the attackers get in?" It is "who in this organisation was allowed to make a decision that big at 4:47 in the morning?"
Why "pull the plug" stopped being the safe answer
Cutting off an infected system is the right move when that system is a developer's laptop. It is a different calculation when the system processes every card payment your business takes.
The old security doctrine, built when offices ran on desktops and a disconnected machine cost one worker a bad afternoon, says: when in doubt, isolate. That reflex is baked into every automated security tool and most written response plans. It made sense for a long time.
The failure mode here is that isolation itself can be the loss event. A payment gateway, a hospital's patient-records system, a factory's production controls: taking any of these offline does damage that starts in minutes and compounds by the hour. The containment becomes the disaster.
Colonial Pipeline is the clearest example. In May 2021, the DarkSide ransomware group broke into Colonial's corporate billing network. The pipeline's actual operating systems were not touched. Colonial shut the pipeline down anyway, because it could not be certain the infection would stay contained to the office side. The result: six days offline, fuel shortages across 17 states and the District of Columbia, and the largest fuel supply crisis the US East Coast had seen in decades. The intrusion hit a back-office network. The response paralysed a region.
Who actually has the authority to make this call?
In most large organisations, the answer is uncomfortable. The security operations centre (SOC), the team of analysts monitoring for threats, has the technical authority to isolate a system. The business leader who owns that system, and who will be held accountable for it being unavailable, usually does not have a formal say.
These are different people in different parts of the organisation, and the gap only becomes visible when a system goes dark.
NIST, the US National Institute of Standards and Technology, updated its main incident-response guidance in April 2025. The revision explicitly frames incident response not as a security-team task but as a company-wide risk decision, one where the business owner is a named participant, not an afterthought.
The practical fix, as outlined in analysis published by CSO Online, involves two tools most security teams could build in an afternoon.
The first is a "no-touch register." Most companies already keep a list of their most critical systems. The no-touch register adds one column: which actions is the security team pre-approved to take on this system, and which ones require a call to a named business owner first? A payment gateway might allow the security team to monitor and restrict suspicious outbound traffic without asking anyone. Taking it fully offline would require a named executive to say yes.
The second is a clear decision chart, sometimes called a RACI (which stands for Responsible, Accountable, Consulted, Informed), that maps out exactly who approves what, and who steps in automatically if that person cannot be reached in time.
| System type | Security team can act alone | Needs business owner approval |
|---|---|---|
| Standard laptop or workstation | Full isolation, reimaging | None |
| Payment gateway | Monitor, restrict outbound traffic | Isolate, take offline |
| Identity system (login provider) | Alert, add extra checks | Revoke all active sessions |
| Factory control systems | Passively monitor, escalate | Any action affecting production |
| Hospital patient-records system | Restrict admin access, log | Block clinician access, take offline |
The value of building that table is not the table itself. It is the meeting you have to build it. Business owners often hear for the first time that the security team is authorised to shut their service down. Security teams often hear for the first time what fourteen hours of downtime actually costs.
One thing the post-mortem will say: "we did not have a documented escalation path." Build one before the Saturday morning call.
If your organisation relies on any always-on digital service, check whether your incident response plan names a specific person, with a phone number, who must be contacted before that service is taken offline. If it does not, that gap is worth a conversation this week.
The operational takeaway: the playbook is not broken because the SOC is incompetent. It is broken because it was written by security people, for security people, and never went through the legal and operations review that would have spotted the problem.
