Incident Response Plan Template: Free Download & Guide

Posted: March 6, 2026 to Cybersecurity.

Incident Response Plan Template: Build Your Cybersecurity Playbook

When a security breach occurs, the difference between a contained incident and a catastrophic data loss often comes down to one thing: whether your organization had a tested incident response plan in place before the attack began. After 23 years of responding to breaches, ransomware attacks, and data theft incidents for organizations of all sizes, I can tell you with certainty that organizations without a documented IR plan consistently suffer worse outcomes, longer recovery times, and higher costs.

This guide walks you through every section of an effective incident response plan, explains what each section must contain, and provides the structure you need to build your own. Whether you are starting from scratch or updating an existing plan, this template covers all six phases of incident response as defined by NIST SP 800-61 Revision 2.

Why Every Organization Needs an Incident Response Plan

A written incident response plan is not just a best practice. It is a regulatory requirement under multiple frameworks. HIPAA requires covered entities to have security incident procedures under 45 CFR 164.308(a)(6). CMMC requires incident response capabilities under the IR domain controls 3.6.1 through 3.6.3. PCI DSS Requirement 12.10 mandates an incident response plan for any organization that processes payment cards. NIST Cybersecurity Framework core function RS (Respond) cannot be satisfied without one.

Beyond compliance, the business case is clear. According to IBM's Cost of a Data Breach Report, organizations with a tested incident response plan and dedicated IR team reduce the average cost of a breach by $2.66 million compared to organizations without one. That is not a theoretical number. It represents real savings from faster containment, reduced downtime, and avoided regulatory penalties.

The Six Phases of Incident Response

The NIST SP 800-61 framework defines six phases of incident response. Your plan must address every phase with specific, actionable procedures.

Phase 1: Preparation

Preparation is the foundation of your entire incident response capability. This phase covers everything you do before an incident occurs to ensure your organization is ready to detect, contain, and recover from security events.

IR Team Structure and Roles

Define your Incident Response Team (IRT) with specific roles and responsibilities. At minimum, your team should include an Incident Commander who has authority to make decisions during an active incident, a Technical Lead who coordinates the hands-on investigation and containment activities, a Communications Lead who manages internal and external messaging, and a Legal and Compliance Advisor who guides decisions related to regulatory obligations and legal exposure.

For each role, document the primary assignee, at least one backup, and contact information including personal cell phones, home email addresses, and any out-of-band communication methods. During a ransomware attack, your corporate email and phone systems may be unavailable.

Communication Plan

Establish out-of-band communication channels that do not depend on your primary IT infrastructure. This might include personal cell phones, a dedicated Signal or WhatsApp group, satellite phones for critical infrastructure organizations, or a pre-configured war room with independent internet access. Define escalation thresholds that determine when to notify executive leadership, legal counsel, law enforcement, regulators, and affected individuals.

Tools and Resources

Maintain an IR toolkit that includes forensic imaging tools, network packet capture capabilities, malware analysis sandboxes, and a secure evidence storage location. Keep offline copies of critical documentation including network diagrams, asset inventories, vendor contact lists, and insurance policy details. These resources must be accessible even if your primary systems are compromised.

Phase 2: Detection and Analysis

Detection is where most organizations struggle. The faster you detect an intrusion, the lower the cost and impact of the incident.

Detection Sources

Document every detection source in your environment and the type of alerts each one generates. Common sources include SIEM platforms, endpoint detection and response (EDR) tools, intrusion detection and prevention systems (IDS/IPS), firewall logs, email security gateways, user reports, and external notifications from law enforcement or threat intelligence sharing organizations.

Incident Classification

Establish a severity classification system with clear criteria for each level. A common four-tier model works as follows. Severity 1 (Critical): confirmed breach of sensitive data, active ransomware encryption, or complete system compromise. Severity 2 (High): confirmed unauthorized access without data exfiltration, malware infection on multiple systems, or denial of service affecting business operations. Severity 3 (Medium): isolated malware infection, suspicious but unconfirmed unauthorized access, or policy violation with potential security implications. Severity 4 (Low): failed attack attempts, minor policy violations, or informational security events.

Analysis Procedures

For each incident type, define the initial analysis steps. What logs should be examined first? What artifacts should be preserved? What questions need to be answered to determine scope and severity? Document these procedures for your most common incident types including phishing compromises, malware infections, unauthorized access, data exfiltration, ransomware, and insider threats.

Phase 3: Containment

Containment limits the damage of an incident and prevents further compromise. Your plan must define both short-term and long-term containment strategies.

Short-Term Containment

Short-term containment is about stopping the bleeding immediately. Actions may include isolating affected systems from the network, blocking malicious IP addresses and domains at the firewall, disabling compromised user accounts, and redirecting DNS to prevent command-and-control communication. These actions should be executable within minutes to hours of detection.

Long-Term Containment

Long-term containment involves more durable measures while you prepare for eradication. This may include rebuilding compromised systems on clean media, implementing additional network segmentation, deploying enhanced monitoring on affected network segments, and rotating all credentials that may have been exposed. Document decision criteria for when to move from short-term to long-term containment.

Evidence Preservation

Before any containment action that modifies or destroys evidence, create forensic images of affected systems. Maintain a chain of custody log for all evidence. This is critical if the incident may result in legal proceedings, insurance claims, or regulatory investigations. Your containment procedures must include specific steps for evidence preservation and the order of operations.

Phase 4: Eradication

Eradication removes the threat from your environment completely. This phase requires thoroughness because any remnant of the attacker's presence can lead to reinfection.

Common eradication activities include removing malware from all affected systems, closing the vulnerability or attack vector that was exploited, rebuilding compromised systems from trusted images, patching all systems against the exploited vulnerability, and scanning the entire environment for indicators of compromise (IOCs) related to the incident.

Do not rush eradication. Verify that every affected system has been identified and cleaned. Threat actors frequently maintain multiple persistence mechanisms, and missing even one backdoor means the attacker can return.

Phase 5: Recovery

Recovery returns affected systems to normal operations. This phase must be carefully managed to avoid reintroducing the threat.

Restore systems from known-good backups after verifying the backups are not contaminated. Return systems to production in a controlled, phased manner with enhanced monitoring. Validate that all systems are functioning correctly and that security controls are in place. Continue elevated monitoring for an extended period, typically 30 to 90 days, to detect any signs of the attacker's return.

Phase 6: Lessons Learned

The lessons learned phase is where good organizations become great at incident response. Within two weeks of incident closure, conduct a formal post-incident review with all stakeholders.

Document what happened, when it happened, how it was detected, how long it took to contain and eradicate, what worked well, what did not work, and what changes are needed to prevent a recurrence. Update your incident response plan, detection rules, and security controls based on the findings. This review must be documented and retained.

Regulatory Notification Requirements

Your incident response plan must include a notification matrix that maps incident types to specific notification obligations.

HIPAA Breach Notification

Breaches of unsecured PHI affecting 500 or more individuals must be reported to HHS OCR within 60 calendar days of discovery. Affected individuals must also be notified within 60 days. Breaches affecting fewer than 500 individuals must be logged and reported to HHS annually. State attorneys general must be notified for breaches affecting residents of their states.

CMMC and DFARS Incident Reporting

Defense contractors must report cyber incidents to the DoD within 72 hours of discovery per DFARS 252.204-7012. You must preserve images of all known affected systems and relevant monitoring data for at least 90 days. The incident report must be submitted through the DIBNet portal.

State Breach Notification Laws

North Carolina requires notification to affected residents without unreasonable delay under N.C.G.S. 75-65. If more than 1,000 NC residents are affected, you must also notify the NC Attorney General and all consumer reporting agencies. Other states have varying requirements and timelines that may apply if you have customers or patients in multiple states.

Testing Your Incident Response Plan

A plan that has never been tested is almost as useless as no plan at all. You should conduct the following exercises at least annually.

Tabletop Exercises

Gather your IR team and walk through a realistic scenario discussion-style. Present a fictional but plausible incident and have each team member describe their actions at each phase. Tabletop exercises are low-cost, low-risk, and highly effective at identifying gaps in your plan and coordination issues between team members.

Functional Exercises

Go beyond discussion and actually execute portions of your plan in a simulated environment. Test your ability to isolate a network segment, restore from backups, communicate through out-of-band channels, and coordinate with external parties. Functional exercises are more resource-intensive but reveal operational gaps that tabletop exercises miss.

Purple Team Exercises

Engage a penetration testing team to simulate a real attack while your IR team practices detection and response in real time. This is the most realistic test of your incident response capability and provides invaluable feedback on your detection speed, containment effectiveness, and communication processes.

Getting Started

If your organization does not have an incident response plan, start building one today. If you have a plan that has not been updated or tested in more than a year, treat that as a critical gap. At Petronella Technology Group, our ComplianceArmor platform includes incident response plan templates customized for HIPAA, CMMC, and general cybersecurity frameworks. We also conduct tabletop exercises and full IR plan development for organizations that need expert guidance.

Contact our incident response team to discuss your IR planning needs or to engage our team for a rapid response to an active incident.