Your Incident Response Plan Assumes Email Still Works

In the first hour of a major ransomware event, the technical problem is secondary. The primary problem is that fifty engineers are staring at dead screens, and the incident commander has no way to tell them what to do. The incident response plan is on a file share. The file share is encrypted. The contact list is in the directory. The directory is down. The document you spent six months writing is collateral damage before the response starts.

Most plans designate a secondary communication channel. Usually, this is a dedicated Teams channel, a Slack workspace, or a crisis management SaaS platform. This is not out-of-band. It is in-band with a different user interface. These tools run on the same identity provider, the same network, and the same managed endpoints as your email. When the identity provider goes down, or when the threat actor has domain admin, the secondary chat room goes down with the primary one.

A war room on the corporate tenant is just a live feed of your defense strategy broadcast directly to the attacker. They do not need to read your 80-page PDF. They just need to encrypt the share. If they have been dwelling in the network for three weeks, they are already reading the incident response channel to see if you have discovered their persistence mechanisms. Out-of-band means a different failure domain, not a different app. It requires a separate trust path, a separate carrier, and separate devices.

When the corporate directory disappears, you realize you do not actually know anyone’s phone number. You know their Slack handle. Coordinating an emergency response degenerates into texting the three people whose numbers you happen to have, asking them to text the people they know. A call tree that has not been tested is a list of wishes.

The 80-page document is a compliance artifact. The real plan is a laminated card in a responder’s wallet. It has ten numbers and five first actions. It is updated quarterly. The bridge PIN is not on the card; you call a number to get the PIN. The wallet survives. The phone does not. The night shift analyst making the first call at 3 a.m. does not have time to search a wiki. They look at the sticky note on their monitor, or the card in their pocket. That card, and the training behind it, is the actual response capability.

The official plan rarely lists the people who actually keep the organization running in a crisis. The executive assistant and the chief of staff know how to reach the CEO at 2 a.m. They have printed lists. They have personal phones. They are the real out-of-band network. Put them on the roster.

The response is also a procurement problem. Requisitioning emergency infrastructure requires a purchase order. Generating a purchase order requires the ERP. The ERP requires the network. When the network is gone, the VP of Engineering is standing at a retail register at 8:00 a.m. on a Sunday, attempting to buy fourteen laptops and prepaid mobile hotspots with a personal credit card, while the bank’s fraud department repeatedly declines the transaction.

You will negotiate with the attacker at 3 a.m. with no leverage unless you pre-negotiated the retainer. The incident response firm, the forensic team, outside counsel, and the crisis PR firm need pre-approved spend limits and signed letters of authorization. The carrier’s fraud team number for SIM swaps needs to be on the wallet card. The arrangement for an offsite war room at outside counsel’s office needs to be in the contract, not just in someone’s memory.

When the incident response firm answers the emergency call, they will ask for a clean line. If the responder is on a corporate laptop, the firm will ask them to switch to a personal cell phone. If that personal phone has Outlook installed and is enrolled in the corporate mobile device management system, it is not a clean device. The attacker with domain admin can push a profile to it. The firm will ask them to use a different phone. If they do not have one, the firm will courier a burner phone, which arrives six hours later. A clean laptop and a cellular hotspot in a physical locker is a real control. Most organizations do not have one.

The plan assumes a working building. The badge reader, the parking gate, the elevator, and the HVAC all run on the network. The fire code makes the physical doors fail open. A cyber incident does not. If the clean machine is in a locker inside the office, and the badge system is down, someone has to drive to the office and wait for a security guard to use a physical key.

A tabletop exercise where everyone sits in a conference room looking at their corporate laptops tests the discussion, not the capability. The facilitator says the primary network is unavailable, and the participants immediately open the incident plan in SharePoint. The exercise stops there.

The only exercise that matters is the one with the network off. Instruct the responders to turn off their laptops and hand over their corporate phones. Ask them to execute the first hour of the incident response plan using only their wallet cards and personal devices. Watch where it stalls. Measure the time to full contact on the call tree. Count the wrong numbers. Fix them.

The dependency map of your incident response capability usually draws a straight line to a single point of failure. Resilience depends on systems that do not share that failure domain. You do not own your communication stack. You rent it from your identity provider.