.svg){kind=logo}
Your monitoring tool fires an alert at 11:40 PM: unusual database access from an unfamiliar IP. Three people see it. None of them knows if they're supposed to act, who to call, or what "act" even means. That gap, not the alert itself, is what actually costs you the incident.
An incident response plan template is a fill-in-the-blank operational document that defines who does what, in what order, and how fast, when a security incident happens. It covers detection, roles and communication, containment, eradication, recovery, and a post-incident review. It's a different document from an incident response policy, which governs why the program exists and who owns it, not the step-by-step response itself.
Quick answer
An incident response plan template covers roles and backups, a severity classification, a communication tree, phase-by-phase response steps aligned to NIST's model, documentation requirements, and a post-incident review process. It's the runbook a responder actually opens mid-incident, not the governance document explaining why the program exists.
By the end of this guide, you'll have a complete incident response plan template you can adapt in an afternoon, plus a clear answer to a question that trips up most teams: whether what you actually need is this plan, or the separate incident management policy.
Here's what I'll cover:
- What an incident response plan actually is, and how it's different from an incident management policy
- Why a written, rehearsed plan matters more than a capable team's good instincts
- The real phases of incident response, and where most plans skip a step
- Everything a complete plan template needs to include: roles, severity, communication, documentation
- How SOC 2, ISO 27001, HIPAA, and GDPR treat incident response requirements
- A free, downloadable template with real sample clauses
- How to test the plan so it works when you actually need it
- The mistakes that turn a written plan into a document nobody follows
What Is an Incident Response Plan? (Incident Response Plan vs Policy)
An incident response plan is the operational runbook a team actually follows during a live incident: who gets notified, who decides what, what gets done first, and in what order. It's not a statement of intent. It's the document someone opens at 11:40 PM and starts working through.
That's a different thing from incident response best practices, which is the reasoning behind what goes into the plan. A template is the artifact you fill in, adapt to your own systems and team, and actually run from mid-incident, not the theory behind it.
Quick take
An incident response plan is the document a responder follows during an incident. Incident response best practices are the reasoning behind it. Only the plan is what an auditor asks to see as evidence.
Incident Response Plan Template vs. Incident Management Policy: What's Actually Different
We already publish an incident management policy guide, and it's worth being direct about how this article is different, because the overlap is real. That page is the governance document: why the incident response program exists, who owns it, its organization-wide scope, the review cadence, and how severity tiers get defined at a policy level.
This article is the plan itself, the operational runbook a responder actually opens and works through during an incident: named roles, a communication tree, and a phase-by-phase timeline written as fill-in-the-blank template language. It also ships as a real downloadable PDF, which the policy page doesn't currently offer.
Note
These two pages work together, not in competition. Start with the incident management policy if you need the governance document: ownership, scope, and review cadence. Come here for the actual document a responder follows during an incident, plus a downloadable template.
Why Every Company Needs a Cyber Incident Response Plan
Incidents get worse in the confusion window before anyone knows who's actually in charge. A cyber incident response plan removes that ambiguity before it costs real response time, not after.
"The team is technically capable" and "the team has a plan they've actually run through" are not the same claim, and only the second one is what an auditor, a customer security reviewer, or a cyber-insurance underwriter asks to see. A written plan also protects a company from itself: the version of the team that's calm on a Tuesday afternoon is not the version that's making decisions twenty minutes into a live incident.
Watch out
"We'd figure it out" is the same gap that trips up every unwritten control, not just incident response. If a reviewer can't point to a document and a rehearsal record, it doesn't count, no matter how capable the team actually is.
Incident Response Plan Steps: The NIST Incident Response Plan Phases
A complete incident response plan template is built around a consistent set of phases, the same structure NIST's incident response guidance is organized around: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Review.
- Preparation. Before anything happens: named roles, tooling, logging coverage, and a plan that's actually been read by the people expected to use it.
- Detection and Analysis. Someone notices something, and the plan tells them how to confirm it's real and how severe it is, not just who to panic-message.
- Containment. Stop the incident from getting worse, short-term, without destroying the evidence needed for the next two phases.
- Eradication. Remove the actual cause, not just the symptom, whether that's a compromised credential, a vulnerable service, or a misconfigured permission.
- Recovery. Bring systems back safely, with monitoring in place to confirm the threat is actually gone, not just quiet.
- Post-Incident Review. Document what happened, what worked, what didn't, and update the plan accordingly.
Post-Incident Review is the phase most plans skip once the fire is out, and the one auditors specifically probe on. "We fixed it" is not the same answer as "here's the documented review, and here's what changed in the plan afterward."
Quick take
A plan that stops at Recovery is an incomplete plan. Post-Incident Review is what turns one bad night into a stronger plan for the next one, and it's the phase an auditor is most likely to ask for direct evidence of.
What to Include in an Incident Response Plan Template
A complete incident response plan template has eight core components. Here's what each one covers and why it actually matters once an incident is live, not hypothetical.
| Section | What It Covers | Why It Matters When an Incident Is Actually Happening |
|---|---|---|
| Roles and RACI | Named incident commander, technical lead, communications lead, and their backups | A plan with one name per role is a single point of failure |
| Severity classification | Concrete tiers (Critical/High/Medium/Low) tied to real triggers | Vague severity language means the team argues about the tier instead of responding |
| Detection and reporting channel | How an incident gets reported and by whom, the moment it's suspected | A plan nobody knows how to trigger doesn't get triggered |
| Communication tree | Who notifies whom, in what order, within what timeframe | Prevents both silence and chaos during the first critical minutes |
| Phase-by-phase response steps | Preparation through Post-Incident Review, in fill-in-the-blank language | This is the actual runbook content a responder follows |
| Evidence and documentation requirements | What gets logged, by whom, as the incident unfolds | This record is what an auditor asks to see afterward |
| External notification triggers | When customers, regulators, or auditors must be told, and by when | Varies by framework; missing this is a compliance failure, not just a process gap |
| Post-incident review and plan update | How the plan itself gets revised after a real incident or exercise | A plan that never changes goes stale the same way an unreviewed policy does |
Incident Response Team Roles and the Incident Response Communication Plan
- Incident commander: owns the decision-making during the incident, coordinates the response, and has a named backup for when they're unreachable
- Technical lead: drives containment, eradication, and recovery on the systems side
- Communications lead: owns internal updates and any external notification, so technical responders aren't also drafting customer emails mid-incident
- Severity classification: a simple tiering, Critical, High, Medium, Low, tied to concrete triggers like customer data exposure, a service outage, or an internal-only anomaly, not a "use your judgment" scale
- Communication tree: who gets notified, by whom, within what timeframe, for each severity tier, internal escalation first, then customers, regulators, and auditors as required
A plan with only one named person per role isn't really a plan, it's a bet that the right person is always awake, reachable, and not the one who's out.
Computer Security Incident Response Plan Template: Documentation Requirements
What gets logged during an incident (the timeline, the actions taken, the decisions made, and who made them) is what an auditor actually asks to see afterward, not a verbal recap reconstructed from memory weeks later.
External notification triggers vary meaningfully by framework, covered in the framework section below rather than repeated here. But the documentation habit itself doesn't: log as you go, not after.
Action step
Build a simple incident log template into the plan itself, timestamp, action, owner, so documentation happens as a byproduct of responding, not a separate task nobody gets to.
Incident Response Plan for SOC 2, ISO 27001, HIPAA, and GDPR
An incident response plan for SOC 2 or ISO 27001 needs to hold up against whichever framework a company is actually pursuing. Here's what each one actually expects, not a generic "compliance requires this" line.
| Framework | Where It Lives | What It Actually Requires |
|---|---|---|
| SOC 2 | Trust Services Criteria CC7.3 and CC7.4 | Expects a documented process for identifying, responding to, and communicating about security incidents, and evidence the process is actually followed, not just a written intent |
| ISO 27001 | Annex A controls 5.24-5.28 (Information security incident management) | Covers incident planning and preparation, assessment of events, response itself, learning from incidents, and evidence collection, as five distinct, auditable controls |
| HIPAA | Security Rule, 45 CFR §164.308(a)(6), Security Incident Procedures | Requires policies and procedures to address security incidents, including a response and reporting process; the regulation itself doesn't prescribe specific plan content |
| GDPR | Article 33 (notification to the supervisory authority) and Article 34 (notification to affected individuals) | Requires notifying the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, and notifying affected individuals directly when the risk to them is high |
Companies keep treating incident response as a checkbox for whichever audit is coming up next. In practice, it's one plan, mapped once against each framework's actual language, then rehearsed the same way regardless of which auditor is asking. -- Upendra Varma, CTO at ComplyJet
Incident Response Plan Template: A Free Example You Can Download
Here's a real incident response plan example: two sample clauses from a current template, written out in full rather than just described.
Incident Response Plan Example: Sample Clauses
Sample clause: Severity Classification
Incidents are classified as Critical (confirmed unauthorized access to customer data, or a full production outage), High (suspected unauthorized access, or a partial service degradation), Medium (an internal-only anomaly with no confirmed customer or data impact), or Low (a policy violation with no active security risk). The incident commander assigns the initial severity within 15 minutes of a report and may revise it as more information becomes available.
Sample clause: Communication Tree (Critical Incident)
On confirmation of a Critical incident, the reporting party notifies the incident commander immediately. The incident commander notifies the technical lead and communications lead within 15 minutes. The communications lead notifies company leadership within 30 minutes and prepares any required customer or regulatory notification per the applicable framework's timeline. All notifications and timestamps are logged in the incident record as they happen.
Free Template
Download the Free Incident Response Plan Template (PDF)
All eight sections above, pre-filled with sample roles, severity tiers, and a communication tree, plus framework-specific notes for SOC 2, ISO 27001, HIPAA, and GDPR readers to adapt.
Testing Your Incident Response Plan Template: Tabletop Exercises and Review Cadence
Writing the plan is the easy half. An incident response plan only works if the team has actually run through it before they need it for real.
- Schedule a tabletop exercise, a walkthrough of a simulated incident using the written plan, without touching live systems, on a fixed cadence, at minimum annually and after any major system or team change.
- Assign someone to run it, using a realistic scenario, and someone else to take notes on exactly where the plan broke down or where people hesitated.
- Update the plan based on what the exercise surfaced, not just what worked, since the gaps are the point of running the exercise at all.
- Log the exercise and its findings as evidence, the same way a real incident's post-incident review gets logged.
That sequence is the real distinction from the "what to include" section above: testing is about proving the plan works before it's needed, not just that it's written down.
Note
A tabletop exercise is rehearsed; a real incident post-mortem is live. Both should feed the same review loop and the same version of the plan, so lessons from one don't get lost from the other.
Common Incident Response Plan Template Mistakes
- No named backup for key roles. The plan collapses the moment the incident commander is on a flight, on vacation, or simply doesn't pick up.
- Severity levels defined too vaguely. The team spends the first 20 minutes of a real incident arguing about which tier it is instead of responding.
- A communication tree that only covers internal escalation. Nobody's named as responsible for customer or regulator notification, which is exactly the part a framework actually requires.
- Treating the plan as a one-time deliverable for an audit. Never rehearsed, never updated after the team or systems change.
- No documentation requirement built into the plan itself. Post-incident evidence gets reconstructed from memory weeks later, if at all.
- Confusing the plan with the policy. The document that should read like an operational runbook ends up reading like a mission statement instead.
- No clear escalation trigger to legal or leadership. Left to in-the-moment judgment calls during the worst possible time to be improvising.
How ComplyJet Supports Your Incident Response Plan Template
A written plan is the starting point. Turning it into an evidence-backed, audit-ready control is the part most companies underestimate, especially once an auditor starts asking for a rehearsal record, not just the document.
We help teams do exactly that as part of a broader SOC 2, ISO 27001, HIPAA, or GDPR program: AI-assisted policy and plan drafting to get the document itself right, plus a place to log tabletop exercises and real incidents as evidence, instead of reconstructing a timeline from memory every audit cycle.
Compliance Automation
Turn your incident response plan into an audit-ready control
ComplyJet pairs AI-assisted policy and plan drafting with a place to log tabletop exercises and real incidents as evidence, across SOC 2, ISO 27001, HIPAA, and GDPR.
FAQs
What Is an Incident Response Plan?
The operational document a team follows during a security incident, covering detection, roles, communication, containment, eradication, recovery, and post-incident review. It's the runbook a responder actually opens mid-incident.
What Are the Phases of Incident Response?
Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Review. The full breakdown of what each phase involves is in the "Phases" section above.
How Do You Create an Incident Response Plan?
Start from a template covering roles, severity tiers, a communication tree, and phase-by-phase steps, then adapt it to the company's actual systems, team, and reporting lines. See the "What to Include" section above for each component.
Is an Incident Response Plan Required for SOC 2?
SOC 2's Trust Services Criteria, CC7.3 and CC7.4, expect a documented incident identification, response, and communication process. An auditor will ask to see the plan itself and evidence it's been used, not just a verbal description.
Is There a Free Incident Response Plan Template PDF?
Yes. This article includes a downloadable incident response plan template PDF, pre-filled with sample roles, severity tiers, and a communication tree, plus framework-specific notes for SOC 2, ISO 27001, HIPAA, and GDPR.
How Often Should an Incident Response Plan Be Tested?
Through a scheduled tabletop exercise, at minimum annually and after any major system or team change, not only after a real incident happens. See the "Testing" section above for the full review loop.
Who Should Be on an Incident Response Team?
At minimum, a named incident commander, technical lead, and communications lead, each with a named backup so the plan doesn't collapse if one person is unreachable. See the "Roles" section above.
What Is a Tabletop Exercise?
A rehearsed walkthrough of a simulated incident using the written plan, without touching live systems, meant to surface gaps in the plan before a real incident does.
Related Reading
- Incident Management Policy, the governance-level policy this plan sits under: ownership, scope, and review cadence.
- Business Continuity and Disaster Recovery Plan, for broader operational continuity beyond a single security incident.
- Risk Management Policy, the risk-assessment methodology that feeds into incident severity classification.
- Logging and Monitoring Policy, the detection layer that triggers this plan's response steps.
- Vulnerability Management Policy, for readers whose "incident" is really an unpatched vulnerability finding, not a live breach.
Sources: AICPA Trust Services Criteria (2017, with 2022 revisions), CC7.3 and CC7.4; ISO/IEC 27001:2022, Annex A controls 5.24-5.28; 45 CFR §164.308, HIPAA Security Rule Administrative Safeguards; GDPR Articles 33 and 34, Personal Data Breach Notification; NIST Special Publication 800-61, Computer Security Incident Handling Guide.
