The practical answer
- Short answer
- A SOC 2-clean IR plan assumes Slack, MFA, and clear authority all survive the incident. They rarely do. Here is how enterprise IT closes the gap.
- Best fit
- Industry: Enterprise IT. Function: Security Operations
- Operating path
- Compliance & Security → Turnaround & Restructuring → Turnaround & Restructuring Services
- Key metric
- $2.03M Average cost savings for companies with tested IR teams (IBM 2024)
The Document Is Real. The Capability Is Not.
2 AM on a Sunday. Endpoint detection lights up across three subnets, domain controllers are answering oddly, and someone on the SOC bridge says the words no enterprise CIO wants to hear: "We think identity is compromised." Now go pull up your incident response plan. It is a clean PDF with a version table, a color-coded escalation tree, and your CISO's sign-off from a SOC 2 cycle two quarters ago. It tells you to "notify the Core Response Team via Slack." Slack rides on the identity provider you just lost.
That is the gap. The document is real. The capability is not. And nobody finds out which one they have until the worst possible night to find out.
Here is the number that should reframe how you fund this. IBM's 2024 Cost of a Data Breach Report puts the average breach at $4.88 million — and organizations with a tested incident response team and plan came in roughly $2.03 million cheaper per breach than those without. That delta is not buying more tools. It is buying muscle memory: people who have already made the hard containment call once, in a drill, before the night it counts. The plan is the audit artifact. The rehearsal is the asset.
The reason enterprise IR plans fail is almost never a missing playbook section. It is that the plan was written for a tabletop where the VPN is up, the phone tree is current, and everyone agrees who is in charge. A real intrusion attacks the response itself — your comms, your credentials, your chain of command — before you finish reading the runbook. IBM's data shows the cost gap is real; what it cannot show you is that the plan failing in the room next door was probably technically complete and fully compliant.
Every IR plan I have read assumes the network, identity, and the org chart all survive the incident. The incident's first move is to take one of those away.
The Three Assumptions That Break in the First 48 Hours
When we run security and response reviews across larger enterprise environments — and inside portfolio cybersecurity risk assessments — we rarely find a tooling shortage. The SIEM is licensed, EDR is deployed, the runbook is thick. What is missing is operational reality. The same three assumptions break, in the same order, almost every time.
1. The communications channel you wrote the plan in is the one that's down
The plan says coordinate over email and Slack. Both authenticate through the identity layer a serious intrusion targets first. Worse, if the attacker is still resident, your incident channel becomes their best source of intelligence: they read what you've found, what you haven't, and exactly when you're about to pull the plug. Ponemon's resilience research has long shown that immature response capability stretches the time to identify and contain — and in our experience the first 48 hours don't disappear into forensics, they disappear into "how do we even talk to each other safely." The fix: a pre-provisioned out-of-band tenant on a separate identity root, plus a tested phone tree, and you actually call the numbers once a quarter to find out how many have changed. An untested comms path is a guess, not a control.
2. The security controls you're proudest of lock you out
Least privilege and hard MFA are the right posture. They are also why, during a ransomware event or an IdP outage, your own admins can't get into the systems they need to contain it — MFA is down, privileged accounts are quarantined, and break-glass credentials are sitting in a cloud vault behind the very SSO that just failed. Incident response data from JumpCloud reinforces a simple operating truth: every hour you spend fighting your own access controls is an hour the blast radius keeps growing. The fix: break-glass procedures stored offline or in a separate trust domain, with their own MFA path, and a recovery dependency map that tells you exactly which system has to come back before the next one can.
3. Nobody at 2 AM has the authority to do the one thing that stops it
This is the failure that turns a contained incident into a board-level one. Containment often means severing connectivity to a major customer or pausing a revenue-generating system to stop lateral movement. Your roster lists who is on the bridge. It does not say whether the on-call VP of Engineering can unilaterally cut a top-five customer's integration at 2 AM, or whether they have to wake the CEO and wait. While that question hangs, the attacker keeps moving. In security diligence reviews, we repeatedly see manageable incidents metastasize in exactly that decision gap. Write the dollar thresholds and named authorities into the plan, then test that the named human actually exercises them.
What You Can Run Before the Next Quarter Closes
You can't buy your way out of this. Authority, rehearsal, and tested dependencies are not products. Here is what moves a plan from artifact to capability — concretely enough to put on next quarter's calendar.
Run quarterly scenario drills, not the annual discussion
Annual tabletops in a high-risk enterprise are theater. Run a different hard scenario every quarter and force real decisions, not talking points: Q1, ransomware takes the ERP and you have to decide on disclosure timing. Q2, an insider exfiltrates regulated customer data. Q3, a managed service provider's breach becomes your supply-chain incident. Q4, executive extortion with a media deadline. Put legal, communications, finance, and the executive sponsor in the room — because the technical fix is maybe a third of the actual event. Disclosure clocks, customer notification, cyber-insurance triggers, and board updates all run in parallel, and they are where contained incidents become public ones.
Build the offline crisis kit
If your incident response materials live only in the cloud, you don't have them on the night the cloud is the problem. Keep an offline-encrypted kit your core team can reach without the production identity layer: the current IR plan and network topology, direct emergency numbers for vendors, outside counsel, the cyber-insurance hotline, and law enforcement, and the break-glass procedures for backup and identity systems under approved controls. Refresh it on the same quarterly cadence as the drill.
Treat on-call capacity as a control, not a schedule
A burned-out Level 1 responder misses the first alert and fumbles the first escalation — the two moments that set how long containment actually takes, and immature response capability is what stretches that window toward the 304-day average. Sustainable rotations are a security control, not an HR nicety; we've written separately on preventing engineering on-call burnout for exactly this reason.
Your job as the enterprise technology leader is not to tune the firewall. It is to guarantee that on a Sunday at 2 AM, your people can communicate off-band, get into locked systems through a tested break-glass path, and make the disruptive call without waiting for a chain of approvals that doesn't exist yet. Stop polishing the PDF as the deliverable and start stress-testing the operating system behind it. It is far cheaper to find the gap in a conference room on a Tuesday than during a live incident on a Sunday.
