Incident Response Plan Template

An incident response plan is the governing document that defines how your organization detects, responds to, and recovers from cybersecurity incidents. A good IR plan is not an 80-page binder that collects dust -- it is a concise, actionable document with clear roles, pre-authorized decisions, escalation paths, and tested playbooks for your most likely threat scenarios. This guide walks through what an IR plan must contain, compares three proven template frameworks (Expert, NIST 800-61, and ISO 27035), and shows how to customize a template for your organization's size and regulatory environment.

Most organizations that have an incident response plan still fail their first real incident. The reason is almost always the same: the plan was written for compliance, not for execution. It was authored by a consultant, reviewed once by legal, filed in SharePoint, and never practiced. When the ransomware note appears, nobody opens it because nobody knows where it is, and even if they did, it does not answer the questions that actually matter in the first 60 minutes.

The templates described in this guide take a different approach. They are built from operational experience across 150+ real tabletop exercises and structured to answer the questions that arise under pressure, not the questions that look good in an audit.

What Should an Incident Response Plan Contain?

Every effective IR plan contains the same core sections, regardless of which framework it follows. The sections below represent the minimum viable structure. Organizations can add industry-specific sections (healthcare, financial services, critical infrastructure), but removing any of these creates dangerous gaps.

How Do the Three IR-OS Templates Compare?

IR-OS provides three distinct starting templates, each aligned with a different framework philosophy. All three produce a complete, operational IR plan -- they differ in structure, terminology, and emphasis.

Expert Template

The Expert template is built from practitioner experience across 150+ tabletop exercises. It prioritizes operational clarity over framework compliance. Sections are organized by the questions that arise during a live incident rather than by framework phase. This template is ideal for organizations that want an immediately executable plan and will map it to compliance frameworks afterward.

NIST 800-61 Template

The NIST SP 800-61 template follows the four-phase lifecycle: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. This is the most widely referenced framework in the United States and the default expectation for organizations subject to federal regulations or working with federal agencies. See our NIST Incident Response Framework deep dive for full phase-by-phase guidance.

ISO 27035 Template

The ISO 27035 template follows the international standard for information security incident management. It uses a five-phase structure: Plan and Prepare, Detection and Reporting, Assessment and Decision, Responses, and Lessons Learned. This template suits multinational organizations that need alignment with the ISO 27000 family of standards and is particularly relevant for organizations with European operations or ISO 27001 certification.

The best IR plan template is the one your team will actually use. Framework alignment matters for compliance, but operational clarity matters for survival. Choose the template that matches how your organization makes decisions under pressure.

How Do You Customize a Template for Your Organization?

A template provides structure. Customization makes it operational. The following steps transform any template from a generic document into a plan your team can execute at 3 AM on a Saturday.

1. Name every role. Replace every title with a name and a phone number. Add a backup for each. A plan that says "the Incident Commander" without specifying who that is will produce a 30-minute argument when the incident starts.
2. Map to your infrastructure. Generic containment steps are useless. Your plan must reference your actual network segments, cloud providers, identity platform, backup architecture, and critical applications by name.
3. Define pre-authorized decisions. Document which actions can be taken without additional approval: isolating a production system, engaging outside counsel, contacting the cyber insurer, taking the website offline. These decisions consume the most time during live incidents.
4. Write scenario-specific playbooks. At minimum, create playbooks for ransomware, data exfiltration, business email compromise, and insider threat. Each playbook should contain the first 10 actions in sequence, not a flowchart.
5. Validate with a tabletop exercise. Run a 90-minute scenario against the plan with the actual named personnel. Every gap, ambiguity, and missing contact will surface. Fix them immediately. See our tabletop exercise guide for methodology.

The IR-OS AI Plan Coach guides this customization process interactively, asking targeted questions about your organization and generating plan sections tailored to your answers.

What Are the Most Common Mistakes in IR Plan Templates?

After reviewing hundreds of IR plans across organizations of all sizes, the same failure patterns appear repeatedly. Avoiding these mistakes is as important as including the right sections.

• Written for audit, not for use. Plans that are 60+ pages long with policy language and no operational detail. Nobody reads them during an incident.
• No named individuals. Roles are assigned to titles, not people. When the incident starts, nobody knows who is the Incident Commander today.
• No pre-authorized decisions. Every critical action requires approval from someone who is unreachable, traveling, or asleep.
• Outdated contact information. DFIR retainer lapsed six months ago. Outside counsel left the firm. The insurer changed their claims hotline number.
• No scenario-specific playbooks. A single generic procedure for all incident types. Ransomware and data exfiltration require fundamentally different first actions.
• Never tested. The plan was written, approved, and filed. It has never been exercised. The first time it is used in practice is during a real incident.

When Should You Replace a Template With a Custom Plan?

Templates are starting points, not destinations. The progression from template to mature IR plan follows a predictable path:

1. Month 1: Select a template (Expert, NIST, or ISO) and complete the customization steps above. You now have a functional baseline plan.
2. Month 2-3: Run your first tabletop exercise against the plan. Document every gap and update the plan immediately.
3. Month 4-6: Add scenario-specific playbooks for your top three threat types. Validate external retainer agreements.
4. Month 7-12: Run quarterly exercises, each targeting a different scenario. Incorporate lessons into the plan after each exercise.
5. Year 2+: The plan is now a living document shaped by your organization's actual experience. The original template structure remains as scaffolding, but the content is entirely yours.

Organizations that skip the template phase and attempt to build from scratch typically take 6-12 months longer to achieve the same maturity level. The template provides the structure; your exercises and incidents provide the substance.

How Does an IR Plan Connect to Broader Security Governance?

An incident response plan does not exist in isolation. It connects to and depends on several other governance documents and capabilities:

• Business Continuity Plan (BCP) -- Defines recovery priorities and acceptable downtime. The IR plan's recovery phase must align with BCP-defined RTOs and RPOs.
• Disaster Recovery Plan (DRP) -- Provides the technical recovery procedures that the IR plan's recovery phase depends on.
• Risk Register -- Identifies the threats and assets that the IR plan's playbooks should address. If ransomware is your top risk, the IR plan needs a detailed ransomware playbook.
• Vendor Management -- Third-party incidents require coordination with vendors. The IR plan should include procedures for third-party breach notification and response.
• Crisis Communications Plan -- Major incidents require stakeholder communication. The IR plan's communication templates should align with the broader crisis communications framework.

IR-OS maintains these connections within the platform, ensuring that updates to the IR plan automatically surface dependencies with related governance documents. The CIRM framework provides the overarching structure for how these documents work together during a cyber incident.