Incident Response Plan: Steps, Framework & Template 2026

An incident response plan is the documented, tested set of procedures your organization follows the moment a security incident is suspected, so the response is fast, coordinated, and defensible instead of improvised under pressure. A good plan names who does what, defines how incidents are classified and escalated, and specifies the legal and regulatory notifications you owe within hours, not days. This guide walks through the frameworks that shape modern plans, including the 2025 change to the NIST guidance most articles have not caught up with, the six phases, the reporting deadlines that carry real penalties, and a template you can adapt.

Updated: August 2026. Reflects NIST SP 800-61 Revision 3 (April 2025), which withdrew Revision 2 and re-framed incident response as a NIST CSF 2.0 Community Profile, alongside the SANS PICERL model still used across the industry.

What is an incident response plan?

An incident response plan (IRP) is a formal document that tells your people exactly how to detect, respond to, contain, and recover from a cybersecurity incident. It turns a chaotic event, a ransomware detonation, a data breach, a compromised account, into a sequence of known steps with clear owners, decision points, and communication paths.

It helps to separate three terms that get used interchangeably:

• Incident response is the overall discipline of handling security incidents.
• Incident response plan is the written playbook that governs that handling.
• Disaster recovery and business continuity are broader plans for restoring operations after any disruption, of which a cyber incident is one type.

The plan matters because the expensive part of a breach is rarely the initial intrusion; it is the time between compromise and containment. Faster detection and response directly lower cost, which is why the metrics that track them, mean time to detect and mean time to respond, sit at the center of any mature program.

Why your organization needs one

Three forces make an incident response plan non-negotiable in 2026.

• Cost. The longer an incident runs unmanaged, the more it costs. A rehearsed plan compresses the timeline and limits the blast radius, which is where most of the savings in data breach cost come from.
• Regulation. Disclosure deadlines are now measured in hours. The US SEC requires public companies to report material incidents within four business days; the EU GDPR requires notifying authorities within 72 hours. Missing these carries fines and legal exposure on top of the incident itself.
• Insurance. Cyber insurers may ask about incident-response planning, tabletop exercises, and response capabilities during underwriting or claims review, with requirements varying by insurer and policy.

Without a plan, teams waste the most valuable hours of an incident deciding who is in charge and what to do. With one, they execute.

Incident response frameworks: SANS, NIST, and the 2025 shift

Two reference models dominate. They agree on the substance and differ mostly in how they group the work.

The SANS PICERL model breaks incident response into six steps: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It is the framework most practitioners learn first and the one this guide uses for its step-by-step walkthrough.

The NIST guidance, published as Special Publication 800-61, is the other anchor. For years its Revision 2 used a four-phase lifecycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. In practice, SANS and NIST Rev 2 describe the same journey.

The important 2026 update is that NIST changed course. In April 2025, NIST withdrew SP 800-61 Revision 2 and published Revision 3, which drops the rigid lifecycle diagram entirely and instead frames incident response as a Community Profile of the NIST Cybersecurity Framework (CSF) 2.0. Rather than marching through fixed phases, Revision 3 maps response activities onto CSF 2.0's six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The message is that incident response is not a separate silo bolted onto security; it is woven through your entire risk-management program, with governance and preparation (Govern, Identify, Protect) treated as continuous work rather than a one-time first step.

The practical takeaway: use the six operational steps below to run an incident, and use the CSF 2.0 framing to make sure preparation and governance are ongoing, not an afterthought.

The six phases of incident response

1. Preparation

Preparation is the phase that determines whether every later phase succeeds. It covers everything you do before an incident: writing and approving the plan, building the response team, deploying detection tooling, defining severity levels, creating playbooks for common scenarios, and rehearsing. It also includes the unglamorous logistics, an up-to-date contact list, out-of-band communication channels in case email is compromised, retainers with external forensics or legal counsel, and access to the logs you will need.

A plan that lives in a shared drive nobody has opened in a year is not preparation. Preparation is the plan plus the muscle memory to execute it.

2. Identification (detection and analysis)

Identification is confirming that an event is actually a security incident and understanding its scope. Alerts flow in from many sources, endpoint detection, SIEM correlation, user reports, threat intelligence, and most are noise. This phase triages them: is this a real incident, how severe is it, what systems and data are involved, and is it still active?

Two decisions anchor this phase. First, classification: assign a severity so the response matches the threat. Second, declaration: formally declaring an incident triggers the plan, notifies the team, and starts the clock on regulatory timelines. Document the timeline from the first indicator, because you will need it for both the investigation and any legal notification.

3. Containment

Containment stops the bleeding. The goal is to prevent the incident from spreading while preserving evidence for later analysis. It usually happens in two stages: short-term containment to immediately limit damage, such as isolating an affected host from the network, and long-term containment, applying temporary fixes that let clean systems keep operating while you prepare to eradicate.

Resist the urge to wipe everything immediately. Pulling the plug can destroy the forensic evidence you need to understand how the attacker got in and whether they are still present. Isolate, capture memory and disk images where relevant, and then move to eradication deliberately.

4. Eradication

Eradication removes the threat from the environment: deleting malware, disabling breached accounts, closing the exploited vulnerability, and eliminating any persistence the attacker established. This is where thoroughness matters most, because attackers routinely plant backdoors, additional credentials, and scheduled tasks so they can return after the obvious infection is cleaned.

Eradication depends on the root-cause understanding you built during identification and containment. If you do not know how the attacker got in, you cannot be confident you have removed them, which is why rushing this phase so often leads to reinfection.

5. Recovery

Recovery restores affected systems to normal operation and confirms they are clean and hardened before returning them to production. That means rebuilding from known-good backups or images, applying patches and configuration fixes, monitoring closely for signs the attacker returns, and validating that business functions work as expected.

Recovery is a judgment call about timing. Restore too early and you risk bringing a still-compromised system back online; wait too long and the business impact grows. Clear criteria, defined in advance, for what "clean and ready" means make this decision defensible.

6. Lessons learned

As soon as practical after closing the incident, often within days or a few weeks, the team holds a post-incident review: what happened, how the response went, what worked, and what to fix. The output is concrete, updated playbooks, new detection rules, patched gaps, and training, so the same incident cannot succeed twice.

This phase is the one teams most often skip, and skipping it is how organizations get breached the same way repeatedly. In the CSF 2.0 framing, lessons learned feed straight back into Govern and Identify, closing the loop so that every incident makes the next response faster.

What to include in your incident response plan

The frameworks describe the flow; the plan itself needs specific, written components. A complete IRP includes:

• Roles and responsibilities. Define the incident response team (often a CSIRT) and use a RACI model so every task has a clear owner. Name an incident commander who runs the response and a communications lead who handles internal and external messaging.
• Severity classification. A defined scale (for example, low to critical) with criteria, so responders escalate consistently rather than by gut feel.
• Playbooks. Step-by-step procedures for your most likely scenarios, ransomware, business email compromise, data breach, insider threat, tailored to your environment.
• Communication plan. Who is notified, when, and how, including executives, legal, affected customers, regulators, and law enforcement, plus out-of-band channels if primary systems are down.
• Escalation paths. Clear triggers for when an incident moves up in severity or brings in outside help.
• Evidence and forensics handling. How to preserve logs, images, and chain of custody so evidence stands up later.
• Tools and access. The systems responders need and how they get emergency access.
• Regulatory and notification requirements. The specific deadlines and authorities that apply to your industry and jurisdiction.

Types of security incidents your plan should cover

A plan is only as good as the scenarios it anticipates. Build playbooks for the incident types most likely to hit your environment:

• Ransomware and destructive malware. Encryption or wiping of systems, often with extortion; typically the highest-severity scenario for the disruption it causes.
• Phishing and business email compromise. The most common entry point, where a user is tricked into handing over credentials or authorizing fraudulent payments.
• Data breach. Unauthorized access to or exfiltration of sensitive data, the scenario that most often triggers regulatory notification.
• Account and credential compromise. Stolen or guessed credentials used to access systems, frequently the pivot point for a larger intrusion.
• Insider threat. Malicious or negligent action by an employee or contractor, which standard perimeter controls rarely catch.
• Denial of service. Attacks that overwhelm systems to disrupt availability.
• Supply chain and third-party compromise. An incident that reaches you through a vendor, software update, or integration you do not fully control.
• Cloud misconfiguration. Exposed storage, over-permissive access, or leaked keys that lead to unauthorized access.

You do not need a bespoke playbook for every variation, but the plan should map cleanly to each of these categories and name who leads the response for each.

Regulatory reporting deadlines you cannot miss

Notification timelines are short and enforced. Map the ones that apply to you into the plan so declaring an incident automatically starts the right clocks.

These are baselines, not legal advice; confirm the exact requirements for your industry and every jurisdiction you operate in, and build the tightest applicable deadline into your plan.

Incident severity and response ownership examples

Use these examples as a starting point and adapt them to your risk profile, business impact, and regulatory obligations.

Example incident severity matrix

Example incident-response RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed.

One-page incident checklist

1. Declare and classify the incident.
2. Start the incident timeline and preserve evidence.
3. Activate legal and regulatory reporting clocks.
4. Contain the affected systems without destroying useful evidence.
5. Investigate scope, root cause, attacker persistence, and affected data.
6. Eradicate malware, compromised credentials, and persistence.
7. Recover from known-good states and monitor for recurrence.
8. Notify regulators, customers, partners, insurers, or law enforcement where required.
9. Validate that critical systems and controls are operating normally.
10. Run the post-incident review and update playbooks, detections, and training.

Test the plan before you need it

An untested plan is a hypothesis. Validate it the way you would any critical control.

• Tabletop exercises. Walk the team through a realistic scenario in a room, testing decisions, communication, and gaps without touching production. Run them at least annually and more frequently for high-risk or rapidly changing environments.
• Red team and purple team engagements. A red team versus blue team exercise tests whether your detection and response actually work against a realistic adversary, not just whether the document reads well.
• Metrics. Track mean time to detect and mean time to respond over time. If rehearsals are working, those numbers should fall.

Testing is also where penetration testing feeds the plan. A penetration test shows you the attack paths an adversary would use, which tells you which playbooks and detections you actually need. Our guide to penetration testing methodology covers how those engagements are scoped and run.

Incident response plan template (core sections)

Use this as a skeleton and fill each section with details specific to your environment:

1. Purpose and scope — what the plan covers and who it applies to.
2. Roles and contacts — the response team, RACI, and a current contact list with out-of-band details.
3. Incident classification — severity levels and declaration criteria.
4. Response procedures — the six phases, with playbooks for your top scenarios.
5. Communication plan — internal, executive, customer, regulator, and law-enforcement messaging.
6. Regulatory obligations — the notification deadlines and authorities that apply to you.
7. Evidence handling — preservation and chain-of-custody procedures.
8. Recovery criteria — what "clean and ready to restore" means.
9. Post-incident review — how lessons learned are captured and fed back.
10. Testing schedule — tabletop and technical exercise cadence, and the metrics you track.

Common incident response mistakes to avoid

Most failed responses fail for the same handful of reasons. Design your plan to prevent them:

• Having a plan but never testing it. An untested plan collapses under real pressure. Rehearsal is what turns a document into a capability.
• Destroying evidence in a rush to clean up. Wiping or rebuilding before capturing forensic images loses the information you need to find the root cause and prove the scope for regulators.
• No clear chain of command. If nobody knows who has authority to isolate a system or approve downtime, the response stalls exactly when speed matters most.
• Undefined severity levels. Without agreed criteria, teams over-react to noise and under-react to real threats, and escalation becomes inconsistent.
• Poor communication. Failing to keep executives, legal, customers, and regulators informed turns a technical incident into a reputational and legal one.
• Relying only on primary channels. If the attacker is in your email or chat, you need pre-arranged out-of-band communication, or responders end up coordinating on compromised systems.
• Skipping lessons learned. Closing the ticket without a post-incident review guarantees the same weakness gets exploited again.

Every item above is cheap to fix in advance and expensive to discover mid-incident.

The bottom line

An incident response plan earns its value in the first hours of a real incident, when a rehearsed team executes known steps instead of arguing about who is in charge. Build it on the six operational phases, keep the SANS and NIST frameworks in mind, and adopt the CSF 2.0 mindset from NIST's 2025 revision: preparation and governance are continuous, not a box you check once. Then test it, measure detection and response, and update it every time reality teaches you something new. The organizations that weather incidents well are rarely the ones that never get hit; they are the ones that practiced the response until it became routine.

Frequently asked questions

What is the difference between an incident response plan and a disaster recovery plan?

An incident response plan governs how you handle a security incident, detecting, containing, eradicating, and recovering from an attack. A disaster recovery plan is broader, focused on restoring IT operations and data after any disruption, including non-security events like hardware failure or natural disaster. A cyber incident often triggers both.

What is the difference between the SANS and NIST incident response frameworks?

They describe the same work with different groupings. SANS uses six steps (PICERL). NIST SP 800-61 Rev 2 used four phases. In April 2025, NIST Rev 3 replaced that lifecycle with a NIST CSF 2.0 profile organized around six functions (Govern, Identify, Protect, Detect, Respond, Recover). Use the six operational steps to run incidents and the CSF 2.0 framing to integrate response into overall risk management.

How often should we test our incident response plan?

Run tabletop exercises at least annually and more frequently for high-risk or rapidly changing environments. Supplement them with technical exercises such as red or purple team engagements that test whether detection and response actually work. Track mean time to detect and mean time to respond so you can see improvement over time.

Who should be on the incident response team?

At minimum, an incident commander, technical responders (security and IT), a communications lead, and legal or compliance representation, with executive sponsorship. Many organizations formalize this as a CSIRT and use a RACI model. Define external contacts too, forensics, outside counsel, and law enforcement, before you need them.

How quickly must we report a breach?

It depends on the regulation. US public companies file an SEC 8-K within four business days of determining materiality; EU GDPR requires notifying authorities within 72 hours; US HIPAA allows no later than 60 days. Sector rules can be tighter. Map every deadline that applies to you into the plan so declaring an incident starts the right clocks automatically.

What is a CSIRT?

A CSIRT, or Computer Security Incident Response Team, is the cross-functional group responsible for executing the incident response plan. It typically combines security, IT, legal, communications, and management, and it is exactly the team your plan's roles and RACI define. Some organizations use the terms CIRT or CERT for the same function; the label matters less than having named, trained people ready to act.