Incident Response Plan Template: NIST-Aligned, Ready to Use

This article delivers a ready-to-adopt, NIST SP 800-61 Rev. 3–aligned incident response plan template with playbooks, a communications checklist, and a tabletop script you can implement in 30–90 days. Whether you are building a program from scratch or remediating gaps found in a recent assessment, the package below gives you a structured starting point grounded in current NIST incident management guidance.

What the package includes:

• Master IRP document: Policy statement, scope, roles and responsibilities, escalation matrix, and incident classification criteria
• Sample playbooks/runbooks: Scenario-specific response steps (ransomware, phishing, data exfiltration) mapped to MITRE ATT&CK techniques
• Communications checklist: Internal notification, executive briefing, regulator notification, and public statement templates
• Tabletop exercise script: A facilitator-ready scenario with inject sequence, discussion prompts, and after-action report template
• 30/60/90 adoption plan: Phased milestones for assigning owners, customizing critical fields, running your first tabletop, and publishing the plan

Immediate next actions:

1. Download the template package and assign a named IR owner today
2. Customize the contact list, escalation matrix, and incident classification thresholds within 30 days
3. Schedule your first tabletop exercise within 30 days of customization

CisoSafe's vCISO team can accelerate this process for regulated organizations that need compliance-mapped deliverables on a defined timeline.

Table of Contents

• What is an incident response plan template and when do you need one?
• Core components every security incident response plan must include
• How does the incident response lifecycle map to your template?
• How to adapt the template for your organization, tech stack, and compliance obligations
• How to write playbooks and runbooks that actually get used
• How to test and maintain your plan so it stays effective
• What the downloadable package contains and a 30/60/90 adoption plan
• What changed in NIST SP 800-61 Revision 3 and what it means for your template
• When should you engage a vCISO for IR planning?
• Key Takeaways
• The gap between a documented plan and a tested one
• CisoSafe builds and tests your incident response program
• Authoritative sources and further reading

What is an incident response plan template and when do you need one?

An incident response plan (IRP) template is a pre-structured document that gives your organization a reusable framework for detecting, containing, and recovering from cybersecurity incidents. It is not the same as a playbook or runbook. The master IRP establishes governance: who is authorized to declare an incident, who communicates with regulators, and what the escalation chain looks like. Playbooks are scenario-specific procedures that sit beneath the master plan. Runbooks are the step-by-step technical instructions that support each playbook.

Use a template when:

• You are building an incident response program for the first time and need a compliant starting structure
• A risk assessment, audit finding, or regulatory review has identified a gap in your current IR documentation
• Your organization has undergone a merger, acquisition, or significant technology change that invalidates the existing plan
• You need to demonstrate IR readiness for SOC 2, HIPAA, PCI DSS, or CMMC compliance

Who should review and approve the IRP:

• CISO or vCISO (program owner and technical authority)
• Legal counsel (regulatory notification obligations, evidence handling, attorney-client privilege considerations)
• Communications or PR lead (external messaging and media response)
• IT operations and security engineering (technical accuracy of procedures)
• HR (employee-related incidents, insider threat procedures)
• Executive leadership or board representative (management commitment statement)

Lean vs. comprehensive template: A small organization with a limited tech stack can start with a lean, 10–15 page master plan and two or three prioritized playbooks. An enterprise or heavily regulated firm typically needs a full playbook matrix, a formal change management process for the IRP, and documented integration with third-party vendors and cyber-insurance carriers. The template structure below scales to both.

Core components every security incident response plan must include

A complete IT security incident response plan template covers governance, operations, and communications. Missing any one of these layers creates gaps that auditors and, more importantly, real incidents will expose.

Required sections and what each must contain:

• Policy statement and scope: Management commitment, which systems and personnel are covered, and the legal or regulatory drivers (e.g., HIPAA Security Rule, PCI DSS Requirement 12.10)
• Roles, responsibilities, and authorities: A RACI-style matrix covering the IR team lead, analysts, legal, communications, IT operations, and executive sponsor. Include explicit authority to isolate systems or revoke credentials.
• Escalation matrix: Tiered decision points with named roles (not individuals) and contact information for each tier, including after-hours coverage
• Contact lists and external dependencies: Cyber-insurance carrier (claim notification timelines), outside legal counsel, forensics retainer, relevant regulators (HHS, FTC, state attorneys general), and managed service providers
• Incident classification and declaration criteria: Severity levels (P1–P4 or equivalent) with concrete examples for each, and the threshold at which an event becomes a declared incident
• Investigation and evidence-handling procedures: Chain of custody requirements, forensic image standards, log preservation, and legal hold triggers. The SANS Incident Handler's Handbook is a widely used reference for structuring these technical steps.
• Containment, eradication, and recovery checklists: Phase-specific actions with sign-off fields and timestamps
• Communications plan: Internal notification templates (executive briefing, all-staff), external templates (customer notification, regulator notification), and a media holding statement
• Playbooks/runbooks directory: A linked index of scenario playbooks with owner, version number, and last-reviewed date
• Performance measures and review cadence: Key metrics (time to detection, time to containment, lessons-learned closure rate) and a defined review schedule

The table below maps each component to its primary purpose and the audience most responsible for it.

How does the incident response lifecycle map to your template?

NIST SP 800-61 Rev. 3 restructured the incident response life cycle around NIST CSF 2.0 Functions: Detect, Respond, and Recover handle active incident activities, while Govern, Identify, and Protect support preparation. Lessons Learned maps back into Identify (specifically ID.IM-04, which requires that incident response plans be established, communicated, maintained, and improved). This framing matters for your template because it tells you which documents belong where.

The table below shows which template artifacts belong in each lifecycle phase.

MITRE ATT&CK is the standard taxonomy for populating the Detect and Analyze phases. When you write a detection playbook, map each trigger to a specific ATT&CK technique ID (e.g., T1486 for ransomware data encryption). This gives analysts a shared language and helps prioritize which detections to instrument first. For guidance on mapping IR activities to the CSF, CisoSafe's framework resources cover the full alignment in detail.

Because Rev. 3 encourages modularization, treat the master IRP as an index and governance artifact. Keep actionable technical playbooks as separate, versioned files that link back to the plan. This approach, supported by NIST's incident response project guidance, prevents the master document from becoming a sprawling technical manual that no one reads during an actual incident.

How to adapt the template for your organization, tech stack, and compliance obligations

A template is only as useful as its customization. The most common failure mode is downloading a generic IRP, filling in the organization name, and calling it done. Auditors and real incidents both reveal that gap quickly.

Adaptation checklist:

• Define your scope: which systems, data types, and business units are covered
• Inventory critical assets and map them to incident scenarios (crown jewels first)
• Document your tech stack: EDR, SIEM, ticketing system, cloud providers, and how each feeds into detection and evidence collection
• Identify third-party dependencies: MSPs, cloud vendors, SaaS providers, and their contractual incident notification obligations
• Map legal and contractual obligations: HIPAA breach notification (60-day rule), PCI DSS Requirement 12.10.7, CMMC IR.L2 practices, SOC 2 availability and security criteria

Compliance mapping by framework:

• SOC 2: Auditors expect a documented IRP, evidence of testing (tabletop records), and a defined notification process for security incidents affecting customer data
• HIPAA: Requires a formal incident response procedure under the Security Rule (45 CFR § 164.308(a)(6)), including analysis of security incidents and documentation of outcomes
• PCI DSS v4.0: Requirement 12.10 mandates an incident response plan tested at least annually, with defined roles, communication procedures, and coverage of all in-scope system components
• CMMC Level 2: IR.L2-3.6.1 and IR.L2-3.6.2 require establishing an operational IR capability and tracking, documenting, and reporting incidents

The NIST SP 800-61 Rev. 3 Community Profile includes priority tables (High/Medium/Low) for each CSF element in the context of incident response. Use those priority indicators to decide which template sections to customize first. For SMBs, CisoSafe's guidance on security frameworks for smaller firms provides a practical starting point for right-sizing the plan.

Pro Tip: The two areas organizations most consistently under-invest in during customization are evidence handling and third-party coordination. Evidence handling procedures that lack chain-of-custody documentation can compromise legal proceedings. Third-party coordination gaps mean your MSP or cloud provider does not know their notification obligations until an incident is already in progress. Address both before your first tabletop.

How to write playbooks and runbooks that actually get used

A playbook that is too abstract gets ignored during a real incident. A runbook that is too granular becomes outdated within months. The right structure is specific enough to guide action and modular enough to stay current.

Standard fields every playbook must include:

• Trigger: The specific alert, detection signal, or report that activates this playbook (e.g., EDR alert for process injection on a domain controller)
• Quick triage steps: Three to five questions that determine severity and scope within the first 15 minutes
• Data sources: Which logs, tools, and systems to query (SIEM, EDR, firewall, identity provider)
• Containment steps: Ordered actions to limit spread, with explicit authority requirements (who can isolate a system)
• Escalation criteria: Conditions that trigger escalation to the next tier, legal, or executive leadership
• Eradication and recovery steps: Actions to remove the threat and restore service, with validation checkpoints
• Artifacts to collect: Specific log files, memory images, network captures, and ticket fields required for the after-action report

Sample ransomware containment playbook snippet (structural example):

Trigger: EDR detects mass file encryption activity or shadow copy deletion on any endpoint

Triage (first 15 minutes):

1. Confirm the alert is not a false positive (check process lineage, parent process)
2. Identify affected systems and determine if encryption is still active
3. Classify severity: P1 if domain controller or file server is affected

Containment:

1. Isolate affected endpoints from the network (do not power off — preserve volatile memory)
2. Disable compromised accounts identified in the process tree
3. Block known C2 indicators at the firewall and DNS layer
4. Notify IR team lead and legal counsel per escalation matrix

Red Canary's published playbook resources and the SANS Incident Handler's Handbook both provide additional real-world detection signals and response sequences you can adapt for your environment.

Checklist for converting a runbook into a tabletop-ready script:

1. Replace technical commands with decision-point questions ("What would you do if the domain controller is unreachable?")
2. Add inject cards: pre-written scenario updates that introduce complications mid-exercise
3. Define the facilitator role and observer role separately
4. Include a debrief section with three standard questions: What worked? What did not? What needs to change in the plan?
5. Assign a scribe to capture decisions and gaps in real time

Linking playbooks to the master IRP: Each playbook should carry a document ID, version number, owner, and last-reviewed date in its header. The master IRP's playbooks directory section lists each playbook by scenario, document ID, and owner. When a playbook is updated, the directory entry is updated and the IRP version log records the change.

How to test and maintain your plan so it stays effective

A plan that has never been tested is a hypothesis. Testing validates assumptions, surfaces gaps, and builds the muscle memory your team needs when a real incident hits.

Types of exercises, from least to most intensive:

1. Walkthrough review: The IR team reads through the plan together and flags outdated contacts, unclear procedures, or missing playbooks. Takes two to three hours. Good for newly published plans.
2. Tabletop exercise: A facilitated discussion-based scenario where participants talk through their responses to a simulated incident. No live systems. Typically two to four hours.
3. Functional exercise: Participants actually execute procedures (pulling logs, drafting notifications) without affecting production systems. Tests operational readiness.
4. Full technical exercise / red-blue integration: Red team simulates an adversary; blue team responds using the IRP and playbooks. Most resource-intensive but delivers the highest fidelity.

Short tabletop sequence example:

1. Facilitator presents the scenario: "At 2:15 AM, your SOC receives an alert for unusual outbound data transfer from a server in your legal document management system."
2. Inject 1 (15 minutes in): "The transfer has been ongoing for six hours. Estimated 40 GB of data has left the network."
3. Inject 2 (30 minutes in): "A ransom note appears on three workstations. The attacker claims to have exfiltrated client files."
4. Discussion prompts: Who declares the incident? When does legal get notified? What is your regulator notification timeline?

Key metrics to track:

• Mean time to detect (MTTD): How long from initial compromise to detection
• Mean time to contain (MTTC): How long from detection to containment
• Lessons-learned closure rate: Percentage of after-action findings resolved within 90 days

Update cadence and version control:

• Review the master IRP at least annually and after every declared incident
• Update playbooks whenever the underlying technology, threat landscape, or personnel changes
• Use a version log (date, change description, author, approver) in the IRP itself
• After each incident or exercise, conduct an after-action review (AAR) within five business days. Capture what worked, what failed, and specific plan changes required. Assign each finding an owner and a due date.

What the downloadable package contains and a 30/60/90 adoption plan

Open-source template repositories, such as the coalition-ir/incident-response-plan-template on GitHub, provide a modular starting structure that mirrors the NIST lifecycle. A well-structured package typically includes:

• during.md / after.md: Phase-specific response and recovery procedures
• playbooks/ folder: Individual scenario playbooks as separate versioned files
• roles/index.md: Role definitions and contact placeholders
• info.yml: Organization-specific values (company name, IR hotline, legal contact) injected across all documents at build time
• Example .docx output for auditors and board presentations

Some community repositories, including the counteractive incident-response-plan-template, include a Makefile that uses pandoc to generate .docx and PDF outputs from the same markdown source. This templating pattern (info.yml + Makefile + markdown) speeds customization and produces repeatable exports for auditors without maintaining separate document versions.

30/60/90 adoption plan:

1. Days 1–30: Assign an IR program owner. Populate info.yml with accurate contacts, asset classifications, and regulatory obligations. Identify your top three incident scenarios and confirm a playbook exists for each.
2. Days 31–60: Customize containment, eradication, and recovery checklists for your tech stack. Validate the escalation matrix with all named roles. Conduct a walkthrough review with the full IR team.
3. Days 61–90: Run your first tabletop exercise using the scenario most likely to affect your organization. Complete the after-action report. Publish version 1.0 of the plan with management sign-off. Schedule the next annual review.

First-deploy checklist:

• Contact list verified and tested (call the numbers)
• Playbooks prioritized for top three scenarios
• Evidence-handling procedures reviewed by legal counsel
• Cyber-insurance carrier notified of the plan's existence and claim notification process confirmed
• All named roles have acknowledged their responsibilities in writing

What changed in NIST SP 800-61 Revision 3 and what it means for your template

NIST finalized SP 800-61 Revision 3 in April 2025. The change is more than a refresh. Rev. 3 retires the previous four-phase model (Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity) and replaces it with a CSF 2.0–aligned structure: Detect, Respond, and Recover as the active incident functions, with Govern, Identify, and Protect supporting preparation.

The core shift in Rev. 3: NIST explicitly acknowledges that technical response details now vary too much across organizations and threat types to be maintained in a single static publication. The master IRP is now framed as a governance and coordination artifact. Detailed technical procedures belong in modular, externally linked playbooks and runbooks that teams maintain and version independently of the master document.

This has direct implications for how you structure your template:

• Keep the master IRP under 20 pages. It should govern, not instruct.
• Maintain playbooks as separate, versioned files with their own review cadence
• Reference CSF 2.0 Function labels (DE, RS, RC) in your template sections so auditors can map your controls directly to the framework
• Include a "supplemental resources" section in the master IRP that links to playbooks, the NIST Cybersecurity and Privacy Reference Tool (CPRT), and your asset inventory

Checklist to make your template Rev. 3–friendly:

• Master IRP contains policy, scope, roles, escalation, and metrics only (no embedded technical commands)
• Each playbook file carries a version number, owner, and last-reviewed date
• Template links to external implementation artifacts (SIEM runbooks, cloud provider IR guides)
• CSF 2.0 Function labels appear in section headers or a compliance mapping table
• A version metadata block at the top of the master IRP records the document version, approval date, and next review date

The NIST SP 800-61 Rev. 3 Community Profile also includes priority tables for each CSF element. Use the High-priority items in Table 3 (Incident Response) to validate that your template covers the activities NIST considers core for most organizations.

When should you engage a vCISO for IR planning?

Building a complete, compliance-mapped incident response program in-house requires security program expertise, legal coordination, and time most regulated organizations do not have in surplus. A vCISO engagement delivers the program structure without the cost of a full-time hire.

What CisoSafe's vCISO and IR planning services deliver:

• Customized master IRP aligned to NIST SP 800-61 Rev. 3 and your specific compliance obligations (SOC 2, HIPAA, PCI DSS, CMMC)
• Prioritized playbook development for your top three to five incident scenarios
• Facilitated tabletop exercise with a written after-action report
• Compliance mapping table linking IRP sections to auditor-expected controls
• Ongoing advisory to maintain and update the plan as your environment changes

Typical 60–90 day engagement flow:

1. Weeks 1–2: Scoping call, asset inventory review, regulatory obligation mapping
2. Weeks 3–4: Draft master IRP with roles, escalation matrix, and classification criteria
3. Weeks 5–8: Playbook development for prioritized scenarios; legal and communications plan review
4. Weeks 9–10: Tabletop exercise facilitation and after-action report
5. Weeks 11–12: Final IRP publication, team training, and compliance documentation package

Who benefits most: Regulated SMBs and mid-market organizations in legal, oil and gas, energy, and healthcare that lack a full-time CISO, are approaching a compliance audit, or have experienced an incident that exposed gaps in their current program. For energy sector organizations, the role of incident response in energy operations presents domain-specific considerations that a vCISO engagement addresses directly.

Key Takeaways

A complete, NIST SP 800-61 Rev. 3–aligned incident response plan template requires a lean master IRP for governance, modular playbooks for scenario-specific action, and a tested tabletop exercise to validate both.

The gap between a documented plan and a tested one

Most organizations that call a vCISO after an incident have a plan. The document exists. What they do not have is a plan that anyone has actually practiced, a communications template that legal has reviewed, or an evidence-handling procedure that would survive scrutiny in a regulatory investigation.

The instinct to build a comprehensive master document first is understandable, but it is usually the wrong priority. A 40-page IRP with embedded technical commands is harder to maintain, harder to use under pressure, and harder to keep current than a lean governance document backed by three well-tested playbooks. Rev. 3's push toward modularization is not bureaucratic preference. It reflects how real incidents unfold: fast, ambiguous, and rarely matching the scenario you planned for in detail.

The most effective approach is to protect your highest-value assets first, cover your most likely incidents first, and exercise the plan before you think it is ready. The gaps you find in a tabletop are far less costly than the gaps you find during a live ransomware event. Clarity of roles matters more than procedural completeness. A team that knows who declares the incident, who calls the lawyer, and who talks to the press will outperform a team with a perfect document and no practice.

Common pitfalls to avoid: embedding technical commands in the master IRP (they go stale immediately), omitting a communications plan (regulators and customers will not wait while you draft one), and skipping the evidence chain (a forensically sound image taken too late is often inadmissible). Prioritize those three before anything else.

CisoSafe builds and tests your incident response program

Regulated organizations across the United States face a concrete problem: the gap between a downloaded template and a defensible, audit-ready incident response program is measured in expertise and time, not good intentions. CisoSafe closes that gap directly. As a Houston-based vCISO firm serving law firms, energy operators, and compliance-sensitive mid-market organizations, CisoSafe delivers a fully customized, NIST SP 800-61 Rev. 3–aligned IRP, prioritized playbooks, and a facilitated tabletop exercise in a 60–90 day engagement. No full-time CISO hire required, no multi-year consulting contract. The deliverable is a published, management-approved plan with a compliance mapping table your auditors can work from on day one.

Request a scoping call or a sample deliverable at cisosafe.com and have a working incident response program before your next audit window opens.

Authoritative sources and further reading

• NIST SP 800-61 Rev. 3 (April 2025): The current standard for U.S. incident response recommendations, aligned to CSF 2.0. Start here for policy and lifecycle guidance.
• NIST SP 800-61 Rev. 2 (August 2012): The previous version; still widely referenced for its detailed four-phase model and plan element checklists. Useful for teams transitioning to Rev. 3.
• NIST SP 800-61 Rev. 3 PDF: Full text including the CSF 2.0 Community Profile tables with High/Medium/Low priority indicators for each IR element.
• NIST Incident Response Project (CSRC): Landing page for all NIST incident response publications, tools, and supplemental resources. Includes links to the NIST Cybersecurity and Privacy Reference Tool (CPRT) for framework mappings.
• coalition-ir/incident-response-plan-template (GitHub): Open-source modular IRP template with info.yml, playbooks folder, and roles directory. A practical starting point for teams that want a git-managed, version-controlled plan.
• counteractive/incident-response-plan-template (GitHub): Community template with Makefile, pandoc output support, and example .docx releases. Useful for teams that need to deliver formatted documents to auditors or boards.
• SANS Incident Handler's Handbook: A widely used reference for structuring technical investigation procedures, triage checklists, and escalation steps. Available through the SANS Reading Room.
• MITRE ATT&CK Framework (attack.mitre.org): The standard taxonomy for mapping adversary techniques to detection and containment actions in playbooks. Use technique IDs to make playbook triggers precise and auditable.
• CIS Incident Response Policy Templates: The Center for Internet Security publishes policy-level templates and checklists useful for governance sections and compliance mapping. Available through the CIS SecureSuite member resources.
• Red Canary Threat Detection Report and Playbook Resources: Practical playbook examples and detection-to-response mappings based on real-world incident data. Useful for populating detection triggers and containment steps in runbooks.

Recommended

• The Role of Incident Response in Energy Operations
• Critical Infrastructure Security Framework: 2026 Guide
• CISO Safe | Virtual CISO & Cybersecurity Compliance Services
• Top 4 TrustedCISO.com Alternatives 2026