When the incident takes out your incident response

Most organisations that have done any security work at all have an incident response plan. It's usually a reasonable document. Someone thought about roles, escalation paths, who calls the insurer, when you notify a regulator.

And it almost always lives on the corporate network.

That's the flaw, and it only reveals itself at the worst possible moment. A plan you can't open is not a plan. A contact list inside a system you've just disconnected is not a contact list. This is what "out-of-band" means, and why it's the first design decision in serious incident response — not a nice-to-have you add later.

The failure mode, step by step

It plays out with grim consistency:

1. Something serious is detected — ransomware, a compromised admin account, an intrusion of unknown scope.
2. The correct early move is to isolate: pull systems off the network, disable accounts, cut access.
3. Isolation takes out the wiki with the plan, the file share with the contact list, and the identity provider everyone signs in through.
4. The team falls back to personal WhatsApp and memory — which now becomes your evidence trail and your command channel.
5. Nobody is confident whether the attacker can read the channel they're coordinating in, because nobody is yet sure what was compromised.

That last point is the one people underestimate. During an active intrusion, your internal comms are not a safe place to plan your response. If an attacker has a foothold in email or chat, discussing containment there is telling them exactly what you're about to do — and giving them time to move first.

What "out-of-band" actually means

Out-of-band means your response capability does not depend on the infrastructure it exists to rescue. Different hosting, different identity, different network path. If your entire environment goes dark, this stays up — and stays trustworthy, because it was never in the blast radius.

Concretely, these are the things that need to survive the incident:

• The playbook — what to do, in what order, with decisions pre-made while everyone was calm.
• The contact tree — internal escalation, your insurer, external counsel, forensics, and the regulator, with numbers that work when email doesn't.
• A coordination channel — somewhere to run the response that you can reasonably trust isn't compromised.
• The evidence record — what was found, when, who did what, and what was decided.

Why the evidence record matters more than people expect

In the moment, documentation feels like overhead. It isn't. The record is what determines how the weeks after the incident go.

Your insurer will want to know what happened and when you knew it. If personal information was involved, notification obligations turn on specific facts and timing. Anyone doing forensics afterwards needs a reliable timeline. And if the incident ends up anywhere near a dispute, "we think it was around the Tuesday" is not a position you want to be in.

Which is why an append-only record is worth insisting on. Notes that can be quietly edited after the fact are worth much less — not because anyone intends to rewrite history, but because a record that could have been changed is harder to rely on. Write-once, timestamped, in order.

Playbooks: pre-made decisions, not documents

The point of a playbook isn't the paperwork. It's that decisions get made when people are calm rather than at 02:00 with the business down.

Established frameworks — ISO/IEC 27035 for incident management, NIST's incident handling guidance — are useful precisely because they force you to think in phases: prepare, detect and analyse, contain, eradicate and recover, then review. The value isn't compliance. It's that each phase has questions you really don't want to be answering for the first time under pressure:

• Who has authority to take production offline? (If the answer is "the CTO", what happens when the CTO is on a flight?)
• At what point do we notify the insurer — and does calling them first affect cover?
• What's our threshold for engaging external forensics?
• Who talks to customers, and what do they say before the facts are established?

Every one of those is a five-minute conversation in advance and a very expensive argument during.

The review afterwards is the part everyone skips

Once systems are back and the adrenaline drops, the review gets postponed and then quietly dropped. That's understandable and it's a mistake — it's the only step that makes the next incident cheaper.

It doesn't need to be lengthy. What was the actual initial access? What detection should have caught it sooner? Which step in the playbook turned out to be wrong or missing? Who couldn't be reached? Fix those four things and you've measurably improved your position, which is more than most organisations manage between incidents.

---

Incident response is one of those capabilities you buy long before you need it, and value entirely on the day you do. The test is simple, and worth actually running: pick a weekday, assume the network is gone, and see how far your team gets.