Building an Incident Response Plan: A Template and Tabletop Guide

Start with the lifecycle, not a document

Most incident response plans fail the same way: they are a binder written to satisfy an auditor, read once, and never rehearsed. When a real event hits at 2 a.m., nobody can find the binder, the on-call contact left the company, and the team improvises under pressure — which is exactly when people make expensive mistakes.

A useful plan is built on a repeatable lifecycle. We use the NIST SP 800-61 model because it is vendor-neutral, well understood, and maps cleanly to how attacks actually unfold. It has four broad phases, which we break into five practical stages:

1. Preparation
2. Detection and analysis
3. Containment and eradication
4. Recovery
5. Post-incident activity

The goal is not a longer document. It is a plan short enough to execute and specific enough that a tired analyst can follow it without guessing.

Phase 1: Preparation

Preparation is the only phase you control on your own schedule, so it carries the most leverage. Before an incident, you need:

• An asset and identity inventory. You cannot contain what you cannot see. Know which systems are crown jewels and who has privileged access.
• Logging and detection coverage. Endpoint, identity, network, and cloud telemetry should flow to a central place. A managed detection and response capability shortens the gap between compromise and discovery, which is where most of the damage cost accumulates.
• Defined severity levels. A three- or four-tier scale (SEV-1 through SEV-4) with concrete criteria removes the argument about how urgent something is at the worst possible moment.
• Contact trees and escalation paths. Names, phone numbers, and backups — stored somewhere you can reach if your primary systems are down.

Phase 2: Detection and analysis

This phase answers two questions: is this a real incident, and how bad is it? The plan should specify how alerts are triaged, who validates them, and what evidence gets collected before anything is changed. Key practices:

• Assign every alert an initial severity within a defined window (for example, less than 15 minutes for SEV-1 candidates).
• Preserve evidence before you act — capture memory, logs, and disk images where feasible, because containment often destroys the forensic trail.
• Establish scope: which accounts, hosts, and data are involved, and whether the activity is still ongoing.

Detection is where mean-time-to-identify lives, and industry breach studies consistently show that the longer an intrusion goes unnoticed, the more it costs. Directionally, breaches that are identified and contained faster are meaningfully cheaper than those that drag on for months.

Phase 3: Containment and eradication

Containment buys time; eradication removes the threat. Separate them deliberately.

• Short-term containment stops the bleeding: isolate a host, disable a compromised account, block a malicious domain. It should be fast and reversible.
• Long-term containment applies temporary fixes that let the business keep running while you prepare a clean rebuild.
• Eradication removes malware, closes the entry vector, resets exposed credentials, and patches the exploited weakness. If you eradicate without finding the root cause, you will be back in this phase within days.

A frequent mistake is eradicating too early — pulling systems offline before you understand the full scope, which tips off the attacker and leaves footholds you never found.

Phase 4: Recovery

Recovery returns systems to production with confidence that they are clean. The plan should define validation gates before anything is trusted again: confirm the vector is closed, monitor restored systems for reinfection, and restore from backups you have verified are uncompromised. This is where incident response meets business continuity and disaster recovery — tested recovery time and recovery point objectives (RTO/RPO) turn "we think we can restore" into a number you can stand behind.

Phase 5: Post-incident activity

Within one to two weeks of closing an incident, hold a blameless review. Answer plainly: What happened? What did we detect, and what did we miss? What would have contained it faster? Every lesson should produce a tracked action item — a new detection rule, a hardened configuration, an updated runbook — with an owner and a due date. An incident you do not learn from is an incident you will repeat.

Define roles before the incident

Ambiguity about who is in charge is the single biggest amplifier of a bad incident. Assign named roles, each with a designated backup:

• Incident Commander — owns decisions and coordination; not necessarily the most technical person.
• Technical Lead — directs investigation and containment.
• Communications Lead — manages internal and external messaging.
• Legal and Compliance — advises on regulatory obligations and breach notification timelines.
• Scribe — maintains a timestamped log of decisions and actions.

For organizations without a full-time security leader, a virtual CISO can hold the Incident Commander role and keep the plan current between events.

Build a communications plan

Technical response and communications must run in parallel, because a mishandled disclosure can cost more than the breach itself. Define in advance:

• Internal notification — who gets told, in what order, through which channel. Assume email may be compromised and have an out-of-band option.
• Customer and partner messaging — pre-approved holding statements so you are not drafting legal-sensitive language under pressure.
• Regulatory notification — know your obligations and clocks. Many frameworks require notification within days of determining a reportable breach.
• A single source of truth — one channel where the current status lives, so leadership is not pulling the team away for updates.

What belongs in a runbook

The plan sets strategy; runbooks handle specific, likely scenarios — ransomware, business email compromise, a lost laptop, a public-facing web app exploit. A good runbook is a checklist, not an essay. Each one should contain:

• Trigger conditions and severity mapping
• Step-by-step containment actions in order
• The exact commands, consoles, and access needed to perform them
• Decision points with clear criteria (for example, when to isolate versus monitor)
• Contacts and escalation thresholds

Store runbooks where they are reachable during an outage, and keep them tied into your security operations workflow so they are actually used, not archived.

Run a tabletop before you run a real one

A plan you have never exercised is a hypothesis. A tabletop is a facilitated, discussion-based walkthrough of a realistic scenario — no production systems touched. To run one:

1. Pick a plausible scenario, such as ransomware detected on a file server on a holiday weekend.
2. Gather the response roles, including a business stakeholder and a legal representative.
3. Inject the scenario in stages ("the backups are also encrypted") and have each role state what they would actually do and with what.
4. Track every point where the team stalls, guesses, or cannot find information.
5. Convert each gap into a fix with an owner.

Run one at least annually, and after any major change to your environment. Ninety minutes of structured practice routinely surfaces broken contact lists, missing access, and untested assumptions — cheaply, and before an attacker finds them for you.

Line up a retainer before you need it

The worst time to negotiate for expert help is mid-incident, when leverage and clock are both against you. An incident response retainer secures guaranteed response times and a team that already knows your environment, so the meter isn't running while you search for someone to call.

If you want a plan that is tested rather than theoretical — the lifecycle, the runbooks, the tabletop, and a retainer standing by — intSignal's incident response team builds and rehearses it with you. Talk to us before the 2 a.m. call, not during it.