Incident Response Plan Template: The 6 Phases (and What Most Templates Miss)

Seventy-seven percent of organizations that suffer a breach had no tested incident response plan in place. They had a document. Usually a long one. But it had never been walked through end-to-end, the notification deadlines were vague or wrong, and nobody could find the contact list when the Slack channel went dark.

An incident response plan is not a document you write to satisfy an auditor. It’s the procedure you’re going to execute at 2am with adrenaline running and half your team in different time zones. It needs to be right when it’s hardest to use.

TL;DR

• NIST SP 800-61 Rev. 3 (finalized April 2025) maps incident response to CSF 2.0’s 6 functions — Govern, Identify, Protect, Detect, Respond, Recover — replacing the Rev. 2 four-phase model
• CIRCIA requires critical infrastructure entities to notify CISA within 72 hours of “reasonably believing” a covered incident occurred; ransomware payments within 24 hours; final rule expected May 2026
• The most common IRP failures: no regulatory notification decision tree, no pre-identified outside counsel, no evidence preservation protocol, and no documentation standard for what needs to survive a regulatory examination
• A plan that has never been tested in a tabletop exercise is not an incident response plan — it’s a hypothesis

What Most Templates Actually Look Like

The standard-issue incident response template you’ll find on the internet has:

• A list of NIST phases
• Generic role descriptions (“Security Team,” “IT”)
• A blank table for contact information
• A section on “containment” that says “isolate affected systems”
• A reminder to “notify regulators as required”

That last one — “notify regulators as required” — is doing a lot of work that the plan hasn’t actually done. Which regulators? Which incidents trigger notification? What’s the timeline? What information has to be in the notice? Who drafts it? Who approves it?

When you’re four hours into a ransomware event and your counsel is asking those questions for the first time, the plan has already failed.

How NIST SP 800-61 Rev. 3 Changed the Framework

NIST published SP 800-61 Revision 3 in April 2025 and simultaneously withdrew Revision 2. The structural change matters for how incident response programs are designed.

Rev. 2 (2012–2025) established a four-phase lifecycle: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity. This was the dominant framework for over a decade.

Rev. 3 (2025–present) eliminates the standalone lifecycle model and instead maps incident response activities to the six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, and Recover.

The implication: incident response is now positioned as a component of the overall cybersecurity program, not a separate process activated only when something goes wrong. Your IRP should map to how your organization implements CSF 2.0.

For practitioners, the practical 6-phase structure below maps cleanly to CSF 2.0 and gives you the operational specificity that the NIST framework intentionally leaves abstract.

The 6 Phases of an Effective Incident Response Plan

Phase 1: Preparation

Preparation is everything that happens before the incident — and everything that determines how well you respond when it does happen.

Team structure. Name the Incident Commander, technical leads, legal counsel (internal and pre-identified external IR counsel), communications lead, and executive escalation path. Include backup contacts. Store this information somewhere accessible when your primary systems are down — a printed copy or an out-of-band system.

Playbooks. Pre-built response procedures for the incident types you’re most likely to face: ransomware, business email compromise, data exfiltration, DDoS, insider threat. Playbooks don’t replace judgment — they compress the time between “incident confirmed” and “first right actions.”

Tools and access. Logging infrastructure, endpoint detection, forensic tools, out-of-band communication channels (if Slack is down, how does the team communicate?). These need to exist and be tested before an incident.

Notification decision tree. Pre-map which incident categories trigger which regulator, what the applicable deadline is, and who makes the determination. This is the single most important document most organizations don’t have.

Legal counsel engagement. Decide in advance when outside counsel is engaged and document that protocol. Counsel preference for managing IR-related communications under attorney-client privilege must be established before the incident — not negotiated while you’re managing the response.

Phase 2: Detection and Identification

An incident you don’t detect is an incident you can’t contain. Detection begins with monitoring infrastructure — SIEM, EDR, network monitoring, log aggregation — and the analyst capacity to review what those systems produce.

When a potential incident is flagged:

Confirm it’s real. Rule out false positives before activating the full IRP. Document the evidence of the incident, not just that it was reported.

Scope it. What systems are affected? What data was potentially accessed? What’s the blast radius? This drives containment strategy and — critically — notification decisions.

Classify severity. Pre-defined severity tiers (typically Sev-1 through Sev-4) drive escalation paths, notification timelines, and resource activation. Sev-1 gets the Incident Commander on the phone at 2am. Sev-4 goes through normal change management.

Start the clock. Document the time you “reasonably believed” an incident occurred. Under CIRCIA, your 72-hour reporting clock starts here — not when the investigation concludes.

Phase 3: Containment

Containment stops the spread without destroying evidence. This is harder than it sounds because the instinct is to remediate immediately — but removing systems before forensic capture destroys the evidence you’ll need for regulatory reporting, insurance claims, and potential litigation.

Short-term containment. Isolate affected systems from the network while keeping them running (memory and disk state preserved for forensics). Block attacker command-and-control communications.

Evidence preservation. Capture memory, disk images, and logs before any remediation steps. Document the chain of custody. Many organizations skip this and then can’t produce evidence when regulators ask for it.

Long-term containment. If remediation will take days or weeks, implement temporary workarounds that allow business operations to continue while the affected systems are isolated.

The containment decision — specifically, whether to take customer-facing systems offline — is a business decision, not purely a security one. It requires executive involvement and should be pre-authorized in the IRP for defined scenarios.

Phase 4: Eradication

Eradication removes the root cause: malware, backdoors, compromised credentials, unauthorized access paths. It happens after containment and forensic capture.

Common eradication steps:

• Remove malware and attacker artifacts from all affected systems
• Revoke compromised credentials and rotate at-risk credentials system-wide
• Patch the vulnerability that enabled initial access
• Verify no persistence mechanisms remain (scheduled tasks, modified startup entries, rogue admin accounts)

Eradication is not complete when the malware is removed. It’s complete when you can demonstrate the attacker no longer has access and the vulnerability that enabled the incident has been addressed.

Phase 5: Recovery

Recovery restores systems to verified-clean operation and returns the organization to normal business functioning.

Restoration sequencing. Don’t restore everything at once. Start with the most critical systems (as defined in your BIA), verify clean operation, monitor closely, then proceed to lower-priority systems.

Enhanced monitoring. Run elevated detection sensitivity for 30+ days post-recovery. Attackers often maintain persistence through the recovery phase.

Stakeholder communication. Customers, partners, vendors, and regulators may need status updates during recovery. These communications should be coordinated through legal counsel and your communications lead, using pre-approved templates where possible.

Phase 6: Post-Incident Activity

Post-incident is where most organizations spend the least time and derive the most operational value. It’s also where regulatory exposure compounds if documentation is inadequate.

Root cause analysis. Not “a phishing email got through” — the actual chain of events: initial access, lateral movement, persistence mechanism, detection gap. What would have stopped this earlier?

Regulatory reporting and documentation. All notifications sent, to whom, at what time, and with what content need to be documented. Examiners will ask for contemporaneous records — not reconstructed timelines.

Evidence records. Under CIRCIA, organizations must preserve incident-related records (logs, forensic artifacts, records related to any ransom payment) for two years from when the report was submitted or required.

Lessons learned. What failed? What worked? What needs to change in the plan, the tooling, or the team structure? A post-incident review that doesn’t produce concrete plan updates is not a lessons-learned process — it’s a retrospective.

Regulatory Notification: The Section That Requires Its Own Document

Notification requirements are complex enough that they should exist as a separate annex to the IRP, not embedded in Phase 6 as an afterthought. The key frameworks:

CIRCIA update: CISA has delayed finalization of the CIRCIA implementing rules to May 2026, citing public comment volume and the need to harmonize with other federal reporting frameworks. Further delays are possible. But covered critical infrastructure entities — financial services, healthcare, energy, transportation — should design their IRPs to comply with CIRCIA requirements now. The rule delay doesn’t reduce your operational exposure if you’re breached and have no reporting process.

The notification annex should pre-answer: which incident types trigger which obligations, what information must be included in each notice, who approves the notification, who sends it, and who maintains the record.

What Tests a Plan More Than Anything: The Tabletop Exercise

Seventy-seven percent of organizations that suffer a breach had no tested plan. Testing is not optional — it’s the difference between a plan that works and a document that hasn’t been proven yet.

A tabletop exercise is a structured walkthrough of an incident scenario with the actual response team. It typically runs 2–3 hours and systematically reveals the things your plan assumed were in place that actually aren’t.

Common discoveries from tabletops:

• The notification decision tree has a gap no one noticed until the scenario forced the question
• Outside counsel isn’t pre-retained and doesn’t know the organization or its systems
• The out-of-band communication channel isn’t actually set up
• Two people think they’re the Incident Commander
• Nobody knows where the forensic tools are licensed to and whether they’re activated

Run at least one tabletop per year. More frequently for teams that have seen significant personnel or system changes.

See AI Incident Response Plan: Building a Playbook for Model Failures and AI Gone Wrong for how to extend your IRP to cover AI-specific incident types — hallucination events, model drift, and agentic AI failures require dedicated playbooks that standard IRPs don’t cover.

So What?

The gap between having an incident response plan and having one that works is almost entirely a testing and specificity problem. Generic phase descriptions don’t fail you — the missing notification decision tree does. “Notify regulators as required” isn’t an instruction. It’s a placeholder for work that hasn’t been done.

Audit your current IRP against this checklist:

• Named Incident Commander with named backup and out-of-band contact
• Pre-identified outside IR counsel
• Severity classification criteria with defined escalation for each tier
• Notification decision tree with deadlines for each applicable regulatory framework
• Forensic preservation procedure before any remediation steps
• Post-incident documentation standard specifying what records to preserve and for how long
• Tabletop exercise completed within the last 12 months

If more than two items aren’t done, you don’t have a functional incident response plan — you have a draft.

The Incident Response & Breach Notification Kit includes a complete IRP template built against the NIST SP 800-61 Rev. 3 framework, a notification decision tree pre-mapped to OCC, CIRCIA, SEC, and state breach law requirements, severity classification criteria, playbooks for ransomware and BEC, and a tabletop exercise facilitation guide.

For the fintech-specific incident response requirements — including the 36-hour OCC notification and state-chartered bank obligations — see Incident Response Plan Template: What Every Fintech Needs.

Sources: NIST SP 800-61 Rev. 3 (April 2025) · CISA CIRCIA Overview · CISA Delays CIRCIA Rules to May 2026 — Davis Wright Tremaine · NIST SP 800-61 Rev. 3 Announcement · CISA Incident Response Plan Basics