How to Write an Incident Response Plan (With Template)

TL;DR

An incident response plan is a documented, tested playbook that tells your organization exactly who does what when a cybersecurity incident occurs. This guide walks through all six phases of the NIST SP 800-61 framework, provides a ready-to-use template for each phase, defines roles and responsibilities for the IR team, and includes tabletop exercise scenarios to validate the plan before a real crisis hits. Organizations with a tested IR plan reduce the average cost of a data breach by $2.66 million.

It was 2:17 AM on a Tuesday when Reyes, the IT director at a 400 person logistics company, received a call from the night shift warehouse supervisor. Every screen in the distribution center displayed the same message: "Your files are encrypted. Pay 4.2 BTC within 72 hours or your data will be published." Reyes grabbed his laptop and drove to the office. When he arrived, he discovered the ransomware had spread across 340 endpoints and encrypted three file servers, including the one running their shipment tracking database.

He called his CEO. His CEO called the company lawyer. The lawyer asked who their incident response lead was. Silence. Nobody had that title because nobody had written that plan. Over the next 96 hours, the company lost $1.8 million in delayed shipments, paid $40,000 to a forensics firm that quoted emergency rates, and discovered the attackers had been inside their network for 47 days before deploying ransomware. They had no preserved forensic evidence, no communication templates for customers, and no documented recovery procedure. They rebuilt everything from scratch.

This story repeats itself across industries every week. According to IBM's 2025 Cost of a Data Breach Report, organizations with a tested incident response plan reduce the average cost of a breach by $2.66 million compared to those without one. The plan is not a luxury. It is the single highest ROI investment in your security program.

What an Incident Response Plan Actually Contains

An incident response plan is not a binder that sits on a shelf collecting dust. It is a living operational document that answers five questions before anyone needs to ask them: What constitutes an incident? Who responds? What do they do first? Who do they call? And how does the organization recover?

The NIST SP 800-61 Rev 2 framework organizes the entire incident lifecycle into six phases. Each phase has specific objectives, required inputs, and defined outputs. The template sections below give your team a starting point for each one.

Phase 1: Preparation

Preparation is everything that happens before an incident occurs. This is where most organizations fail, not because they skip it entirely, but because they do it once and never revisit it. A plan written two years ago with phone numbers for employees who no longer work at the company is worse than no plan at all because it creates false confidence.

Template section for your IR plan:

• Asset inventory: List all critical systems ranked by business impact. Include the system owner, recovery time objective (RTO), and recovery point objective (RPO) for each.
• Tool readiness: Confirm your SIEM is ingesting logs from all critical sources. Verify forensic imaging tools are licensed, installed, and tested. Ensure your team has offline access to the IR plan itself (printed copies or an air gapped device).
• Communication tree: Build a contact list with primary and backup contacts for every IR role. Include personal phone numbers, not just work email. Test the tree quarterly.
• Legal and regulatory checklist: Document which regulations apply to your organization (GDPR, HIPAA, PCI DSS, state breach notification laws). List notification deadlines and the exact regulatory contacts.

The preparation phase also includes training. Every member of the IR team should understand their role without needing to read the plan for the first time during an active incident. The SANS Institute recommends quarterly reviews of the plan and at least two tabletop exercises per year.

Phase 2: Detection and Analysis

Detection is the moment you realize something is wrong. Analysis is the process of confirming whether it is a genuine incident or a false positive, and determining its scope, severity, and type.

Most organizations detect incidents through one of four channels: automated alerts from their SIEM or endpoint detection and response platform, reports from employees who notice unusual behavior, notifications from external parties such as law enforcement or security researchers, and threat intelligence feeds that match indicators of compromise against internal telemetry.

Template section for your IR plan:

• Alert triage criteria: Define severity levels (Critical, High, Medium, Low) with specific examples. A single failed login is informational. Five hundred failed logins from the same source IP targeting an admin account in 10 minutes is critical.
• Validation checklist: Before declaring an incident, the analyst must confirm the alert is not a false positive, identify the affected systems and data, determine the attack vector if possible, and assess whether the activity is ongoing.
• Incident classification matrix: Map incident types (ransomware, data exfiltration, insider threat, DDoS, phishing compromise) to their severity level and the corresponding response playbook.
• Evidence preservation protocol: The first responder must capture volatile data (running processes, network connections, memory) before taking any containment action that could alter it. Document chain of custody from the first moment.

The average time to identify and contain a breach is 258 days for organizations without a plan and 184 days for those with one. That 74 day gap exists because unprepared teams waste time figuring out who should do what instead of actually doing it.

Phase 3: Containment

Containment prevents the incident from spreading while preserving evidence for investigation. NIST distinguishes between short term containment (immediate actions to stop the bleeding) and long term containment (sustainable measures that let you investigate without further exposure).

Template section for your IR plan:

• Short term containment: Isolate affected systems from the network by disabling switch ports or moving them to a quarantine VLAN. Block known malicious IPs and domains at the firewall. Disable compromised user accounts. These actions should happen within the first hour.
• Long term containment: Apply temporary network segmentation rules. Set up enhanced monitoring on systems adjacent to the compromised ones. Redirect DNS for affected domains. Build clean systems in parallel if recovery will require a full rebuild.
• Containment decision matrix: For each incident type, define pre-approved containment actions that the IR team can execute without waiting for executive approval. A SOC analyst at 3 AM should not need to call the CEO to isolate a workstation that is actively encrypting file shares.

Containment is also where legal considerations become urgent. If your organization is subject to breach notification laws, the clock may start ticking the moment you confirm that personal data was accessed. Your legal advisor should be notified during containment, not after recovery.

Phase 4: Eradication

Eradication removes the threat from your environment entirely. This means eliminating malware, closing the vulnerability the attacker exploited, removing backdoors and persistence mechanisms, and revoking any credentials the attacker may have captured.

Template section for your IR plan:

• Root cause identification: Determine exactly how the attacker gained initial access. Was it a phishing email? An unpatched VPN appliance? A compromised vendor credential? If you do not identify the root cause, the attacker will return through the same door.
• Malware removal procedures: Run endpoint scans with updated signatures. Check for scheduled tasks, registry modifications, startup items, and cron jobs the attacker may have planted. Verify that no command and control callbacks are occurring from any system.
• Credential reset protocol: Reset passwords for all accounts that had access to compromised systems. Revoke and reissue API keys, certificates, and access tokens. Force re-enrollment for multi-factor authentication on affected accounts.
• Vulnerability remediation: Patch the vulnerability that was exploited. If a patch is not available, implement a compensating control (additional network segmentation, enhanced monitoring, or disabling the affected service).

Phase 5: Recovery

Recovery brings affected systems back to normal operations. The critical principle here is that recovery must be verified, not assumed. A system that appears clean may still harbor a deeply embedded backdoor.

Template section for your IR plan:

• System restoration priority: Restore systems in order of business criticality, following the RTO values defined in Phase 1. Verify each system's integrity before reconnecting it to the production network.
• Data restoration: Restore from backups taken before the compromise began. Verify backup integrity with hash comparisons before restoring. If the attacker was in your environment for weeks, your most recent backups may also be compromised.
• Validation testing: Run vulnerability scans against restored systems. Monitor network traffic for anomalies during the first 48 hours after restoration. Confirm that all indicators of compromise from the investigation are absent.
• Graduated reconnection: Do not reconnect everything at once. Bring systems back online in stages, monitoring each stage for signs of reinfection before proceeding to the next.

Phase 6: Post-Incident Activity

Post-incident activity is the phase that separates organizations that improve from those that repeat the same mistakes. NIST calls this the most important phase because it drives continuous improvement of the entire incident response capability.

Template section for your IR plan:

• Post-incident review meeting: Hold a structured debrief within 5 business days of incident closure. Include every person who participated in the response. Use a blameless format that focuses on process gaps, not individual errors.
• Timeline reconstruction: Build a complete timeline from initial compromise through detection, containment, eradication, and recovery. Identify where delays occurred and why.
• Lessons learned report: Document what worked, what failed, and what needs to change. Assign specific action items with owners and deadlines. Typical findings include detection gaps, communication breakdowns, missing tools, and unclear authority.
• Plan updates: Revise the incident response plan based on findings within 30 days. Update playbooks, contact lists, and procedures. Communicate changes to the entire IR team.
• Metrics to track: Mean time to detect (MTTD), mean time to contain (MTTC), mean time to recover (MTTR), total business impact in hours and dollars, and number of systems affected.

Roles and Responsibilities

A plan without clear ownership is a suggestion, not a procedure. Define these roles before an incident forces you to improvise.

IR Lead (Incident Commander): Coordinates the entire response. Makes containment and escalation decisions. Serves as the single point of authority during the incident. This person does not perform technical analysis; they direct traffic and remove obstacles.

Security Analysts: Perform technical investigation and forensic analysis. Operate the SIEM, review logs, analyze malware samples, and identify indicators of compromise. In a security operations center, these are typically the first responders who triage alerts and escalate confirmed incidents.

IT Operations Lead: Manages system isolation, backup restoration, and infrastructure changes required during containment and recovery. Coordinates with the IR Lead on which systems to take offline and in what order.

Communications Coordinator: Handles all internal and external communications. Drafts employee notifications, customer disclosures, press statements, and regulatory filings. Every external statement must be reviewed by legal before release.

Legal Advisor: Determines notification obligations, manages attorney-client privilege over forensic findings, coordinates with law enforcement if criminal activity is involved, and advises on regulatory compliance throughout the response.

Executive Sponsor: A C-level leader (typically the CISO or CTO) who authorizes business-impacting decisions such as shutting down revenue-generating systems, engaging external forensics firms, or approving ransom negotiations.

Tabletop Exercise Tips

A plan you have never tested is a plan you do not have. Tabletop exercises reveal gaps that reading the document never will: the contact number that goes to voicemail, the containment step that requires a tool nobody has installed, the escalation path that skips a critical decision-maker.

How to run an effective tabletop exercise:

1. Choose a realistic scenario. Base it on incidents that have actually occurred in your industry. A ransomware attack that starts with a phishing email and spreads via lateral movement is a strong first scenario. For later exercises, try supply chain compromise, insider threat, or cloud misconfiguration leading to data exposure.

2. Set the stage with injects. Divide the scenario into stages, each introduced with a new piece of information (an "inject"). Stage 1: "An employee reports their screen is locked with a ransom message." Stage 2: "Three more workstations on the same subnet are now displaying the same message." Stage 3: "Your backup server is unreachable." Each inject forces the team to reassess and adapt.

3. Assign actual roles. Participants should respond from their designated IR role, not as observers. If your communications coordinator is in the room, they should describe exactly what message they would send, to whom, and through what channel.

4. Time-box the exercise. 60 to 90 minutes is ideal. Anything longer loses focus. Anything shorter does not generate enough pressure to reveal real gaps.

5. Debrief immediately. Capture findings while they are fresh. Ask three questions: What went well? What broke? What will we change in the plan before the next exercise?

The CISA Tabletop Exercise Packages provide free, ready-to-run scenarios for organizations that want structured exercises without building them from scratch.

76% of organizations experienced at least one ransomware attack in 2025, yet only 37% had a fully tested incident response plan. Tabletop exercises conducted quarterly improve actual response times by 25 to 40%, according to the SANS 2025 Incident Response Survey. The investment is a few hours per quarter. The return is measured in days of downtime prevented and millions in breach costs avoided.

From Document to Capability

An incident response plan is not a compliance checkbox. It is the difference between a coordinated 4-hour containment and a chaotic 96-hour scramble that costs millions. The logistics company from the opening of this article eventually wrote their plan. It took them two weeks. They spent another afternoon running their first tabletop exercise, which revealed that their backup restoration process had a 6-hour gap nobody had noticed.

The best time to write your incident response plan was before your last security incident. The second best time is today. Start with the six NIST phases. Fill in the template sections for your specific environment. Assign roles to real people with real phone numbers. Then test it. Revise it. Test it again. The plan is never finished because your environment, your threats, and your team are always changing.

Every organization gets hit eventually. The question is not whether you will face a cybersecurity incident. The question is whether you will respond with a tested plan or with panic.