An incident response plan is a documented, pre-approved playbook defining exactly how an organization will detect, contain, eradicate, recover from, and report a cybersecurity incident. It names roles, sets escalation paths, and covers legal and regulatory notification.
Key takeaways
- An incident response plan is an operational document, not a compliance artifact. If nobody can follow it at 2am, it isn’t finished.
- The core components are roles and an incident commander, a severity scale with concrete triggers, phase-by-phase actions, escalation and communication procedures, notification obligations, and a post-incident review process.
- Keep the plan short and push detail into scenario-specific playbooks. A 60-page plan doesn’t get read during an incident.
- Pre-authorize containment actions. Approval chains are where response time goes to die.
- A plan you haven’t tested is a hypothesis. Tabletop exercises are how you find the gaps.
- Review annually at minimum, and after every real incident, tool migration, or org change.
Most organizations have something they call an incident response plan. Far fewer have one their team could execute under pressure at 3am on a holiday weekend, which is the only test that matters. The gap usually isn’t effort—it’s that the document was written to satisfy an auditor rather than to be used, so it describes the incident response lifecycle in the abstract without ever saying who picks up the phone. A usable plan answers concrete questions fast: who declares an incident, who can isolate a production system without asking permission, and who talks to customers.
What belongs in an incident response plan?
Six components do the actual work. Everything else is supporting material.
- Roles and authority. Name the incident commander and their backups. Name the technical lead, the communications lead, and legal counsel. Specify what each role can decide alone. This is the single highest-value section, because ambiguity about authority is what stalls response.
- A severity classification scale. Define levels with measurable triggers, not adjectives. “Critical” should mean something like “confirmed unauthorized access to production data or systems supporting revenue operations,” not a vague adjective. Each level maps to a response tier and an escalation path.
- Phase-by-phase actions. Walk the lifecycle—preparation, identification, containment, eradication, recovery, and review—with the deliverable at each step. Keep it to what’s common across incidents and push scenario-specific detail into playbooks.
- Escalation and communication procedures. Who gets notified at each severity level, in what timeframe, through what channel. Include an out-of-band channel, because if your identity provider is compromised, so is your chat tool.
- Legal, regulatory, and notification requirements. Which regulations apply, what the clocks are, who decides whether a reportable breach occurred, and where the pre-drafted notification templates live.
- Post-incident review process. Who runs the review, on what timeline, and where the after-action report goes. Without this, the plan never improves.
How do you structure the plan around the response lifecycle?
Each phase in the plan should specify a trigger, an owner, actions, and a deliverable. That four-part structure is what makes a plan followable.
| Phase | Owner | Key deliverable |
|---|---|---|
|
Preparation |
Security lead | Playbooks, contact tree, tested backups, logging coverage |
|
Identification |
On-call analyst | Severity classification and initial scope |
|
Containment |
Technical lead | Affected systems isolated, spread stopped |
|
Eradictation |
Technical lead | Attack foothold and entry point removed |
|
Recovery |
Infrastructure owner | Systems restored, monitoring in place |
|
Review |
Incident commander | After-action report and remediation backlog |
Two notes on structure. First, containment and eradication are different jobs with different urgency—containment is fast and reversible, eradication is deliberate and permanent. Plans that merge them tend to encourage reimaging before anyone has worked out the entry point.
Second, the deliverable column is what prevents phase drift. A team can’t be “in recovery” if nobody removed the attacker’s persistence, and writing the deliverable down makes that visible.
Who does what during an incident?
The plan should include a role table your team can read in 10 seconds:
- Incident commander—Declares the incident, sets severity, makes final calls, owns communication to leadership. One person, with named backups.
- Technical lead—Directs investigation and containment, coordinates analysts and infrastructure owners.
- Infrastructure or application owner—Executes changes on the affected systems.
- Legal counsel—Assesses regulatory exposure and notification obligations, manages privilege.
- Communications lead—Handles internal updates, customer messaging, and press if needed.
- Scribe—Maintains the timeline. Underrated, and the reason your after-action report and regulatory filing are defensible.
Smaller organizations assign these to existing staff rather than hiring. One person can hold two roles, with one exception: the incident commander shouldn’t also be doing hands-on technical work, because the coordination job disappears the moment they’re deep in a log query. More on structure, responsible/accountable/consulted/informed (RACI) mapping, and triage on our incident response team page.
What are the legal and regulatory notification requirements?
Notification is the part of the plan most likely to be wrong when you need it, because the obligations are specific, the clocks are short, and they’re set by regulation rather than by your team.
Your plan should capture what triggers a reportable event, the deadline, who the report goes to, and who internally makes the determination. Many organizations operate under several at once—sector regulators, state and national data protection laws, contractual obligations to enterprise customers, and cyber insurance policy requirements, which often carry the tightest notification window of the group.
Three things worth pre-building:
- A decision owner. “Is this reportable?” is a legal determination. Name who makes it.
- Draft notification templates, reviewed by counsel in advance. Nobody writes good regulatory language during an active incident.
- An evidence and timeline standard, so the record supports the filing. This is what the scribe role produces.
Requirements vary significantly by jurisdiction and sector, so the specifics belong to your counsel, not to a template. What belongs in the plan is the process and the owner.
How do you test an incident response plan?
Through a tabletop exercise—a facilitated walkthrough of a simulated incident where the team talks through their planned actions without executing them live. It’s the cheapest way to discover that your on-call rotation has a gap, that two people think they’re the incident commander, or that nobody knows who can approve taking a revenue system offline.
Run one at least twice a year, and always after a significant change. Then fix what the exercise surfaced.
Three places to go next, depending on what you need:
- For what a tabletop exercise is and what it covers: see the CyberSpeak page on tabletop exercises (linked in the FAQ below)
- For the mechanics of facilitating one: how to run an incident response tabletop exercise
- For a free, ready-to-run kit with scenarios and facilitator materials: Oh Noes!
Incident response plan best practices
- Keep the core plan under 15 pages. Push scenario detail into separate playbooks.
- Pre-authorize containment actions at defined severity levels so analysts don’t wait on approval.
- Store the plan somewhere reachable when your network is down. A printed copy in the on-call bag isn’t paranoid.
- Include an out-of-band communication channel and test that people can actually get into it.
- Write the contact tree with mobile numbers, not just email. Assume email is compromised or unavailable.
- Build your first three playbooks for phishing, ransomware, and business email compromise—that’s most real incidents.
- Assign a scribe in every incident. The timeline is what your after-action report and any regulatory filing rest on.
- Review after every real incident, not just annually. Real incidents surface gaps no exercise will.
Expel’s take
The plans that hold up in real incidents are the ones written around decisions, rather than descriptions. We see a lot of customer plans, and the pattern is consistent: the documents that fail aren’t missing content, they’re missing authority. They describe the lifecycle thoroughly and then leave “who can isolate a production host at 2am without escalating” unanswered. That single gap costs more response time than any tooling deficiency.
The other consistent gap is the seam between an internal team and its managed detection and response (MDR) provider. Expel’s security operations center (SOC) handles detection, triage, and containment on a 24×7 basis, and pre-authorized response actions in Expel Workbench™ are what get us to a 14-minute mean time to remediate (MTTR) on fully automated high- and critical-severity incidents. But there’s a category of decision no provider should make for you—taking a revenue system offline, notifying regulators, what to tell customers. A good plan draws that line explicitly and names your internal owner for each. The plans that assume the provider handles “response” without defining where that ends are the ones that stall in the middle of an incident.
Ruxie, our AI SOC manager, assembles investigative context so analysts start from a working picture rather than a raw alert—human-led, AI-powered, with a named analyst making every call. What it can’t do is decide your business’s risk tolerance. That’s the part your plan exists to settle in advance.
Frequently asked questions
What should be included in an incident response plan?
An incident response plan should include defined roles and an incident commander, a classification and severity scale, phase-by-phase actions across the response lifecycle, escalation and communication procedures, legal and regulatory notification steps, and a post-incident review process.
How often should an incident response plan be updated?
Most frameworks recommend reviewing an incident response plan at least annually and after any significant organizational change, tool migration, or real incident. Testing through tabletop exercises should happen more often—quarterly or semi-annually—to keep the plan current.
What is the difference between an incident response plan and an incident response policy?
A policy states the organization’s high-level commitment and requirements for incident response, including who must be notified and what regulations apply. A plan is the detailed, tactical playbook describing exactly how the team executes each phase.
Do small businesses need a formal incident response plan?
Yes, and arguably more than large ones, since smaller organizations typically lack the staff to improvise a response under pressure. Even a simple plan naming who to call and what to isolate first dramatically reduces response time and cost during a real incident.
What is a tabletop exercise and why does it matter for an incident response plan?
A tabletop exercise is a facilitated walkthrough of a simulated incident scenario where the response team talks through their planned actions without executing them live. It’s the primary way teams find gaps in a plan before a real incident exposes them.