Building an incident response plan you'll actually use

There's a specific document that exists in a lot of businesses: a thick incident response plan, professionally formatted, approved by leadership, filed in a shared drive nobody remembers the name of. It was written to satisfy a compliance requirement or an insurance question, and it did. Then it was never opened again — least of all during the one event it was written for.

The reason binders fail isn't that they're wrong. It's that a crisis is the worst possible time to read. At 1 a.m., with systems locking up and phones ringing, no one scrolls to page 27 for the escalation matrix. They freeze, or they improvise, and both cost time you don't have. A plan you'll actually use has to be built for that moment — short, physical, and rehearsed.

Start with a one-page runbook

The core of a usable plan is a single page anyone on the response team can act from in the first thirty minutes. Not a summary of the big document — a replacement for it, in the moment. It answers four questions fast:

• Who do I call first? The name and mobile number, not a role in an org chart.
• What do I do right now? The first three containment actions, in order.
• What must I not do? Don't power off systems, don't delete anything, don't pay or negotiate on your own.
• Where's everything else? Links to the full plan, contacts, and account details — for when the fire is out.

Print it. Laminate it. Put a copy where the response team will find it even if the network — and the shared drive — is down. A plan that only exists on the systems being encrypted is not a plan.

The call tree: roles, not just names

Everyone in a crisis assumes someone else made the call. A call tree fixes that by assigning both a role and a specific person (plus a backup) to each. At minimum you need an incident lead who runs the response and makes decisions, a technical lead who executes containment, a communications owner for staff, customers, and press, and an external contacts holder who reaches your MSSP, insurer, and legal counsel. Write the names and numbers down. During an incident, the org chart is useless; the phone list is everything.

The six phases every plan follows

Under the one page, your full plan should follow the widely used lifecycle. You don't need to reinvent it — you need to make each phase concrete for your business.

Prepare

Everything you do before the incident: the runbook, the call tree, backups you've tested, logging that's actually on, and knowing who your insurer and counsel are before you need them.

Detect

How you find out something's wrong — SOC alerts, EDR detections, a user report. Define what qualifies as an incident so someone can declare one without waiting for permission.

Contain

Stop the spread. Isolate affected endpoints, disable compromised accounts, cut the attacker's access — fast, decisive, and before you fully understand the whole picture.

Eradicate

Remove the threat completely: the malware, the persistence mechanisms, the backdoors, the stolen credentials. Half-eradication is how organizations get hit twice in a week.

Recover

Restore from clean, verified backups and bring systems back in a controlled order, watching closely for signs the attacker is still present.

Learn

A blameless review within two weeks: what happened, what worked, what didn't, and what changes in the plan. This is the phase everyone skips and the one that pays off.

Rehearse it: the tabletop exercise

A plan is a hypothesis until you test it. A tabletop exercise is a facilitated, no-stress walkthrough of a realistic scenario — "ransomware note appears on three servers at 6 p.m. Friday" — where the team talks through what they'd do, step by step. It's the cheapest way to find the gaps: the phone number that's out of date, the assumption that IT can restore in an hour when a real restore takes twelve, the fact that nobody knows the insurer's notification deadline. Run one at least annually. Carriers increasingly ask whether you have.

The decision checklist

The hardest parts of an incident aren't technical — they're the judgment calls made under pressure. Bake the thresholds into the plan ahead of time so no one has to invent them at midnight:

• When to pull the plug: the criteria for isolating a system or taking the network offline, and who has authority to order it.
• When to notify: the triggers for informing leadership, staff, customers, and — where required by law or contract — regulators, plus the clock on each.
• When to call the insurer and counsel: almost always early. Many policies require prompt notice, and involving legal counsel early can protect the investigation under privilege.
• Who talks to the attacker: the answer is your specialists and counsel — never an untrained employee acting alone.

How Atom helps you build one

We help clients replace the unused binder with a plan that fits on a page and holds up in the room. We draft the runbook and call tree with you, align the full plan to a recognized framework, and facilitate the tabletop that turns it from a document into a reflex. And because our SOC is often the first phone call on that call tree, the detect-and-contain phases aren't theory — they're what we do for you around the clock. The best incident response plan is the one your team can execute half-asleep. That's the only kind worth writing.