Incident Response
8 min read

Your Incident Response Plan Will Fail on a Saturday Morning

A healthcare client got hit with ransomware on a Saturday morning and nobody owned the response for three hours. The IR plan listed titles instead of decision frameworks, and the entire escalation chain assumed someone else was handling it.

GuardsArm Team

Security Experts

February 27, 2026

The CISO-on-a-plane scenario is real. I'm not talking about a thought exercise from a conference panel. I'm talking about something that happened to one of our healthcare clients.

Saturday morning. Ransomware hit at 6:47 AM. The first alert fired at 6:48. And then... nothing. For three hours, nobody owned the response.

The escalation chain assumed someone else was handling it. The on-call engineer saw the alert, figured the security team was on it. The security analyst thought the MSP was responding. The MSP was waiting for authorization from the CISO. The CISO was on a flight to Denver and had no idea anything was happening.

Three hours. In ransomware time, that's an eternity. By the time someone actually picked up the phone and started coordinating, the encryption had spread across two clinical systems and a file server containing patient records.

All because the incident response plan listed titles, not decision frameworks.

The plan on paper vs. the plan in practice

Every healthcare organization I've worked with has an incident response plan. It's usually a forty-page document sitting in a SharePoint folder somewhere. It was written to satisfy a compliance requirement, reviewed once a year by someone who didn't write it, and has never been tested under anything resembling real conditions.

These plans all look the same. There's an escalation matrix with names and phone numbers. There's a section about severity levels. There's a communication plan that assumes everyone will calmly follow the flowchart while their systems are being encrypted.

The problem isn't that these plans exist. The problem is that they fall apart the second something actually happens.

Why Saturday morning breaks everything

Attackers know your schedule better than you do. They know that Friday night through Sunday morning is when your defenses are weakest. Skeleton crew on the help desk. Security team off the clock. Decision-makers unreachable.

A well-designed IR plan accounts for this. A bad one assumes Monday-through-Friday, 9-to-5 conditions where everyone is at their desk, reachable by phone, and available to make decisions within fifteen minutes.

I've reviewed IR plans that list the CISO as the primary incident commander with no defined backup. What happens when the CISO is on vacation? Sick? In a meeting with the board? On a plane with no Wi-Fi? The plan doesn't say, because nobody thought about it.

And it's not just the CISO. What about the network engineer who's the only person with the credentials to isolate the affected VLAN? What about the compliance officer who needs to make the HHS notification decision? What about the communications director who's supposed to handle the media if patient data is involved?

If any of those people are unreachable, your plan has a single point of failure. And single points of failure are exactly what attackers exploit.

Decision frameworks beat escalation charts

The fix isn't adding more phone numbers to the escalation matrix. The fix is building decision frameworks that work regardless of who's available.

Instead of saying "the CISO decides whether to isolate the network," your plan should define the conditions under which network isolation happens automatically. If ransomware is detected on more than three endpoints, isolation happens. Period. You don't need to call anyone. You don't need to wake anyone up. The decision is already made.

Instead of saying "the compliance officer determines reporting obligations," your plan should have a clear decision tree. PHI potentially involved? Start the 72-hour clock. Document what you know. Notify legal. You can refine the assessment later, but the clock starts now regardless of whether someone picks up the phone.

This is what I mean by decision frameworks over titles. The plan should encode the decisions so that anyone in the chain can execute them. Not just the specific person whose name is in the box.

Tabletop exercises expose the truth

You know how you find out your IR plan will fail on a Saturday morning? You test it on a Saturday morning.

Not a Tuesday at 2 PM in the conference room with pizza and everyone's calendars blocked. An actual Saturday morning, with no advance warning, where you call the on-call number and say "we have a confirmed ransomware incident" and see what happens.

I've run these exercises for healthcare clients. The results are always revealing. Calls go to voicemail. People don't know who to call next. Nobody knows where the IR plan document is. Someone suggests checking the wiki, which is hosted on the server that's theoretically been encrypted.

One exercise I ran, the designated incident commander's phone number in the plan had been disconnected for eight months. They'd changed carriers and nobody updated the document.

These aren't edge cases. This is normal. And you won't find out until you test it.

What a real IR plan looks like

A plan that works on Saturday morning at 6:47 AM has a few things the compliance-checkbox version doesn't:

Automated initial response. Detection triggers automatic containment actions. Isolate the affected segments. Block the known IOCs. Spin up the war room channel in Slack or Teams. You can do all of this without a human making a phone call.

Role-based, not person-based escalation. Three people can fill each critical role. The plan defines the role's authority, not the person's. Whoever picks up first has full authority to act.

Pre-authorized decisions. The board and leadership have already agreed on the big calls. Isolate systems even if it means EHR downtime? Pre-authorized. Engage external IR firm? Pre-authorized up to a defined spend. Notify law enforcement? Decision tree is already documented.

Regular, unannounced testing. Not the annual tabletop that everyone prepares for. Real surprise drills that test the actual response chain under realistic conditions.

Stop admiring the plan

Your incident response plan is a living document or it's a compliance artifact. There's no middle ground.

If you can't confidently say that your organization would respond effectively to a ransomware attack at 6:47 on a Saturday morning, then you don't have an incident response plan. You have a document.

At GuardsArm, we help healthcare organizations build IR plans that actually work -- and then we test them until they break, fix what's broken, and test again. We also provide 24/7 SOC coverage so that when Saturday morning comes, someone is already watching. If your IR plan hasn't been tested under real conditions, reach out. Let's find the gaps before an attacker does.

Topics

#Incident Response
#Healthcare Security
#Business Continuity
#CISO
#Tabletop Exercises

Written by GuardsArm Team

Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.

Related Articles

MFA Won't Save You: Why Token Theft Is Healthcare's Next Crisis
Emerging Threats

MFA Won't Save You: Why Token Theft Is Healthcare's Next Crisis

The $4.5 Million Email: How Phishing Still Owns Healthcare
Emerging Threats

The $4.5 Million Email: How Phishing Still Owns Healthcare

Your IT Director Is Not a CISO (Stop Pretending)
Industry Specific

Your IT Director Is Not a CISO (Stop Pretending)