Incident Response Plan Template: Build Your IR Plan in 2026

When a security incident hits, every minute without a plan costs money. IBM reports that organizations with a tested incident response plan save an average of $2.66 million per breach compared to those without one. Here is how to build yours.

Why You Need an Incident Response Plan

A security incident is not a matter of if but when. The 2025 Verizon Data Breach Investigations Report found that 83% of organizations experienced more than one data breach. Without a documented incident response (IR) plan, teams scramble during a crisis — wasting critical hours deciding who to call, what to shut down, and how to communicate with stakeholders.

An IR plan eliminates decision-making under pressure by pre-defining every action. It aligns your team on roles, establishes communication channels, provides step-by-step playbooks, and ensures you meet regulatory notification deadlines. Compliance frameworks including SOC 2, PCI DSS, HIPAA, and GDPR all require a documented incident response capability.

The NIST Incident Response Framework

The most widely adopted IR framework comes from NIST SP 800-61 Rev. 2. It defines four phases that form the backbone of any effective IR plan:

Phase 1: Preparation

Preparation is everything you do before an incident occurs. This is where most of your IR investment should go.

• Build your IR team: Define roles — Incident Commander (owns decisions), Technical Lead (coordinates investigation), Communications Lead (manages internal/external messaging), Legal Counsel, and Executive Sponsor
• Create a contact list: Include IR team members, executives, legal counsel, PR team, insurance carrier, external forensics firm, and law enforcement contacts. Store this outside your primary systems (printed copy, secure mobile app) in case systems are compromised
• Deploy detection tools: SIEM, EDR, network monitoring, and external scanning. Use the SecureBin Exposure Checker regularly to detect external-facing vulnerabilities before attackers do
• Document your environment: Maintain current network diagrams, asset inventories, data flow maps, and critical system dependencies
• Establish communication channels: Set up out-of-band communication (separate Slack workspace, Signal group, satellite phone) that does not depend on potentially compromised infrastructure
• Prepare forensic tools: Pre-image critical systems, maintain forensic workstations, and keep bootable USB drives with analysis tools ready

Phase 2: Detection and Analysis

When an alert fires, you need a systematic process to determine whether it is a real incident and assess its severity.

• Triage the alert: Is this a true positive or false positive? Check multiple data sources to corroborate the finding
• Classify the incident: Use a predefined severity scale (P1-Critical through P4-Informational) based on data sensitivity, system criticality, and business impact
• Document everything: Start a timeline from the moment the incident is detected. Record every action, finding, and decision with timestamps. This log becomes critical for forensics, legal proceedings, and post-incident review
• Identify scope: Determine which systems, data, and users are affected. Check for lateral movement indicators
• Preserve evidence: Take memory dumps, disk images, and log snapshots before making any changes. Evidence integrity is essential for legal proceedings

Phase 3: Containment, Eradication, and Recovery

Short-term containment stops the bleeding immediately. Isolate compromised systems from the network, block malicious IP addresses at the firewall, disable compromised accounts, and revoke exposed credentials. The goal is to prevent further damage while preserving evidence.

Long-term containment addresses the root cause. Patch the vulnerability that was exploited, rebuild compromised systems from known-good images, implement additional monitoring on affected segments, and verify that the attacker no longer has access.

Eradication removes all traces of the attacker from your environment. Delete malware, remove backdoors, close unauthorized accounts, and rotate all credentials that may have been compromised. Use strong generated passwords for all credential rotations.

Recovery restores normal operations. Bring systems back online in a controlled manner, monitor closely for signs of re-compromise, validate that all business functions are operating correctly, and gradually reduce heightened monitoring to normal levels.

Phase 4: Post-Incident Activity

The post-incident review is where organizations learn and improve. Conduct a blameless retrospective within 5 business days of incident closure. Document what happened, how it was detected, what worked well, what failed, and specific improvements to prevent recurrence. Update your IR plan based on lessons learned.

Incident Severity Classification

• P1 — Critical: Active data breach, ransomware, compromised production database, customer data exposed. Response: Immediate all-hands, executive notification within 30 minutes, legal/PR engaged within 1 hour.
• P2 — High: Compromised employee account, malware on corporate network, unauthorized access to internal systems. Response: IR team mobilized within 1 hour, containment within 4 hours.
• P3 — Medium: Phishing email received, vulnerability discovered in production, suspicious network activity. Response: Investigation within 24 hours, remediation within 72 hours.
• P4 — Low: Failed login attempts, minor policy violation, informational security alert. Response: Document and review during regular security review cycles.

Incident Response Playbooks

Ransomware Playbook

1. Immediately isolate affected systems from the network (disconnect Ethernet, disable Wi-Fi)
2. Do NOT power off systems — volatile memory contains forensic evidence
3. Identify the ransomware variant from ransom note and encrypted file extensions
4. Check nomoreransom.org for available decryptors
5. Assess backup integrity — are backups intact and not encrypted?
6. Engage executive team for business impact assessment and potential payment decision
7. Notify law enforcement (FBI IC3 in the US)
8. Begin recovery from backups or clean rebuild
9. Investigate initial access vector and remediate

Data Breach Playbook

1. Identify what data was accessed or exfiltrated (scope assessment)
2. Contain the access vector — patch vulnerability, revoke credentials, block IP
3. Engage legal counsel to determine notification obligations
4. Begin regulatory notification process (see our Data Breach Response Plan guide)
5. Prepare customer notification with specific details about what data was affected
6. Offer credit monitoring or identity protection if PII was exposed
7. Document the complete chain of events for regulatory filings

Compromised Credentials Playbook

1. Immediately reset the compromised password and revoke all active sessions
2. Enable MFA if not already active on the account
3. Review account activity logs for unauthorized actions
4. Check for forwarding rules, API keys, or OAuth grants created by the attacker
5. Scan for credential reuse across other systems
6. Notify the user and require password changes on any accounts using the same credentials

Communication Templates

Internal Escalation (P1/P2)

Pre-draft an escalation message template: "SECURITY INCIDENT [Severity Level] — [Brief Description]. Detected at [Time]. Affected systems: [List]. Current status: [Investigating/Contained/Recovering]. IR team assembled. Next update in [timeframe]. Do not discuss outside of [designated channel]."

Customer Notification

Pre-draft a customer communication template covering: what happened, when it happened, what data was affected, what you are doing about it, and what the customer should do (change passwords, monitor accounts). Have legal review all customer communications before sending.

Testing Your IR Plan

An untested IR plan is barely better than no plan. Conduct these exercises regularly:

• Tabletop exercises (quarterly): Walk through a scenario verbally with the IR team. "It is Tuesday at 2 AM. Your SIEM alerts on 50 GB of data being exfiltrated to an unknown IP. What do you do?"
• Technical drills (semi-annually): Actually isolate a test system, practice forensic imaging, test backup restoration, and verify communication channels work
• Full simulation (annually): Engage a red team to simulate a real attack. Measure detection time, response time, containment effectiveness, and communication accuracy

Frequently Asked Questions

How often should we update our incident response plan?

Review and update the IR plan at least annually, after every significant incident, and whenever there are major changes to your infrastructure, team, or business (new cloud providers, acquisitions, office moves). The contact list should be verified quarterly — phone numbers and roles change more often than you think. After every tabletop exercise, incorporate lessons learned into the plan within two weeks.

Do small companies need an incident response plan?

Yes. Small companies are disproportionately targeted because attackers know they have weaker defenses. A small company IR plan does not need to be 50 pages — a 5-10 page document covering the basics (contact list, severity classification, playbooks for the top 3 scenarios, and communication templates) is infinitely better than nothing. The plan scales with your organization. Start simple and add detail as you grow.

Should we pay ransomware demands?

This is a business decision that should involve executive leadership, legal counsel, and law enforcement. The FBI recommends against paying because it funds criminal organizations and does not guarantee data recovery. However, organizations with no viable backups and critical data at stake sometimes choose to pay. The best strategy is prevention: maintain tested backups, segment your network, and deploy EDR. If you must consider payment, engage a professional ransomware negotiation firm rather than communicating directly with attackers.

What compliance frameworks require an incident response plan?

SOC 2 requires documented incident management procedures. PCI DSS Requirement 12.10 mandates an incident response plan that is tested annually. HIPAA requires breach notification within 60 days of discovery. GDPR requires notification to supervisory authorities within 72 hours. ISO 27001 requires incident management controls (Annex A.16). Nearly every compliance framework requires some form of IR capability.

The Bottom Line

An incident response plan is not optional — it is the difference between a contained security event and a catastrophic breach. Use this template as your starting point: define your team, classify severity levels, build playbooks for your most likely scenarios, pre-draft communications, and test everything regularly. The time you invest in preparation pays for itself the moment your first real incident hits.

Related tools: Exposure Checker, SSL Checker, DNS Lookup, Password Generator, Hash Generator, and 70+ more free tools.