We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 Incident Response Playbook Template

Translate Rev. 3's CSF 2.0 outcomes into a playbook incident handlers can use under pressure.

Rev. 3 is not itself a step-by-step playbook; each organization needs procedures that reflect its technology, risks, authority, providers, and notification duties.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
3 sections4 primary sources
Overview

Use this organization-authored template to build one scenario-specific . It is not an official NIST form and SP 800-61 Rev. 3 does not require this wording. Rev. 3 says playbooks can document actionable tasks for scenarios, while organizations should use the lifecycle that suits them, define authority, tailor procedures to their systems and risks, and add any applicable legal or contractual duties.

Section 1

Decide whether the scenario needs its own playbook

Create or split a playbook when responders would face materially different declaration criteria, technology, authority, containment tradeoffs, evidence sources, provider dependencies, notification paths, or recovery methods. For example, a supplier-hosted ransomware event may require provider action and contract-specific communications that an internally hosted account compromise does not.

The playbook should tell responders when it starts, who leads, which actions each role may authorize, how the team prioritizes the incident, when to escalate or elevate it, what evidence to preserve, when recovery may begin, and who can declare recovery complete. It should also say when to switch to another playbook or invoke continuity, disaster recovery, crisis communication, or legal procedures.

  • Define the scenario boundary: affected services, assets, identities, data, locations, providers, threat conditions, and business consequences.
  • Set entry, branching, handoff, recovery-initiation, and exit criteria that responders can evaluate from available facts.
  • Assign primary and backup authority for declaration, containment, evidence collection, communications, restoration, and recovery completion.
  • Reference controlling notification procedures and contracts without presenting NIST as the source of a reporting deadline.
Section 2

Fill-in template for an incident response playbook

Complete this template for one scenario, such as ransomware, account takeover, denial of service, or supplier compromise. Link detailed technical procedures instead of burying them in the playbook, and make critical contacts and decision criteria usable when normal systems or personnel are unavailable.

Rev. 3's model uses Govern, Identify, and Protect for preparation; Detect, Respond, and Recover for active handling; and ID.IM for improvements identified before, during, or after an incident. NIST also says an organization may use another lifecycle that suits it.

  • Identity and control: [Playbook title, scenario, owner, approver, version, last exercise, next review, and linked plans or technical procedures]
  • Purpose and scope: [Covered services, assets, identities, data, locations, providers, business processes, assumptions, exclusions, and conditions that require another playbook]
  • Entry and declaration: [Observable trigger, validation steps, incident criteria, declaration authority, incident lead, initial priority factors, and false-positive path]
  • Roles and access: [Primary and backup incident lead, handlers, asset owners, legal, privacy, communications, recovery personnel, providers, authorized actions, credentials, and fallback contacts]
  • Immediate actions: [Triage, scope and impact estimate, prioritization, escalation or elevation, containment options and tradeoffs, eradication, provider coordination, and links to detailed procedures]
  • Evidence and records: [Facts and investigation actions, incident data and metadata, decision log, time sources, access restrictions, integrity and provenance controls, retention rule, and chain of custody when warranted]
  • Communications: [Coordination, notification, public communication, and information-sharing decisions; controlling procedures or contracts; approvers; secure channels; and update cadence]
  • Recovery: [Initiation criteria, authorization, restoration-asset checks, root-cause remediation, restoration order, integrity checks, asset-owner confirmation, monitoring, residual risk, and completion criteria]
  • Branches and stop conditions: [Facts that change strategy, require specialist or legal help, invoke another plan, delay an action, or make the playbook unsafe to continue]
  • Improvement: [After-action report owner, lessons captured during and after the event, corrective-action owner, priority, due date, verification evidence, and retest trigger]
Section 3

Design, exercise, and maintain the playbook

Draft and approve the playbook with the people who will make or execute its decisions, including asset owners and relevant providers. An exercise should test entry criteria, handoffs, unavailable personnel, compromised communications, incomplete facts, containment tradeoffs, provider permissions, notification assessment, restoration integrity, and the authority to return systems to production.

Revise the playbook when architecture, suppliers, authority, notification duties, contacts, recovery dependencies, threat information, exercises, or real incidents expose a gap. Track the resulting action through ID.IM and retest changes that affect decisions or operating capability.

  • Define the scenario, scope, entry criteria, known dependencies, and connection to other response, continuity, and recovery plans.
  • Map decision authority, internal and external roles, secure communications, and provider permissions.
  • Write triage, analysis, containment, eradication, evidence, legal-assessment, communication, and recovery decision points.
  • Exercise under realistic uncertainty and record failed entry criteria, missing authority, decision delay, failed handoffs, inaccessible procedures, and missing evidence.
  • Assign each improvement through ID.IM with an owner, priority, due date, acceptance evidence, and retest condition.
Recommended next step

Write and exercise the scenario playbook

Define entry criteria, authorized actions, provider handoffs, evidence, communications, and recovery checks.

Assessment workflow
Open Assessment Autopilot for NIST SP 800-61 Rev. 3

Create cited tasks, evidence requests, and review checkpoints for this NIST SP 800-61 Rev. 3 scope.

Explore next step
Talk to Sorena
Review this NIST SP 800-61 Rev. 3 scope with Sorena

Review decision authority, procedures, evidence gaps, and exercise results for this incident-response scope.

Explore next step
Primary sources

References and citations

NIST SP 800-61 Rev. 3 Incident Response
csrc.nist.gov4 citations
Referenced sections
  • Final April 2025 publication used for lifecycle choice, roles, policies and procedures, optional playbooks, declaration and prioritization, evidence, communications, recovery, and improvement.
  • Section 2.3 says incident response policies are organization-specific and should define scope, terms, roles, authorities, prioritization, recovery initiation, and performance measures. It also describes playbooks as an optional way to document actionable scenario tasks.
  • Sections 2.1 and 2.3 ground lifecycle choice and playbook use. DE.AE-08 covers declaration criteria; RS.MA covers triage, priority, escalation, elevation, and recovery initiation; RS.AN covers investigation records and evidence; RS.CO covers communications; RC.RP covers recovery execution and completion.
Show 1 more
  • Section 2.2 describes the internal and external roles that may participate in response. Section 2.3 calls for procedures that explain who performs each step and how. ID.IM identifies improvements from evaluations, exercises, operational work, and incident response plans.
NIST CSF 2.0 (CSWP 29)
doi.org3 citations
Referenced sections
  • Official CSF 2.0 source for outcome-based, organization-tailored implementation and the six Functions.
  • CSF 2.0 defines desired outcomes but does not prescribe the actions or responsible individuals used to achieve them, so each organization should tailor this template.
  • CSF 2.0 supports tailoring outcomes to organizational mission, stakeholder expectations, threat landscape, requirements, and risk priorities.
NIST Cybersecurity Framework 2.0
doi.org
Referenced sections
  • Official source for the six CSF Functions and ID.IM improvement outcomes used to organize the template.

Related guides

NIST SP 800-61 Rev. 3 CSF 2.0 Incident Profile Guide

Map NIST SP 800-61 Rev. 3 across CSF 2.0 preparation, Detect-Respond-Recover operations, and continuous improvement without treating the profile as a law or playbook.

NIST SP 800-61 Rev. 3 FAQ: practical implementation questions

Answers on incident declaration, severity, roles, communications, notification clocks, evidence, recovery, and continuous improvement under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 Incident Communications and Escalation

Separate incident coordination, notification, public communication, information sharing, escalation, and elevation, with owners and decision records.

NIST SP 800-61 Rev. 3 Incident Severity and Response Targets

Build organization-defined incident severity bands and response targets from NIST risk factors without claiming that NIST prescribes levels or deadlines.

NIST SP 800-61 Rev. 3 Post-Incident Evidence Log Workflow

Preserve incident records and data, document recovery, produce the after-action report, and verify corrective actions under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 vs CISA playbooks: practical side-by-side comparison

Choose NIST SP 800-61 Rev. 3 for an organization-wide incident-response risk model and CISA's playbooks for detailed FCEB incident and vulnerability procedures.

Show all related guides (20)

NIST SP 800-61 Rev. 3 vs ISO 22301 business continuity: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 for cybersecurity incident response and ISO 22301:2019 with Amendment 1:2024 for the business continuity management system.

NIST SP 800-61 Rev. 3 vs ISO/IEC 27035: practical side-by-side comparison

Compare NIST SP 800-61 Rev. 3's CSF 2.0 outcome profile with the ISO/IEC 27035 incident-management process, planning, and ICT response guidance.

NIST SP 800-61 Rev. 3 vs NIS2 incident reporting: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 to run incident response and the applicable NIS2 national law to assess significant-incident reporting and legal deadlines.

NIST SP 800-61 Rev. 3: escalation decision workflow for incident communications

Run incident coordination, required notifications, public updates, and voluntary information sharing as separate, documented decision streams.

NIST SP 800-61 Rev. 3: What Changed from Rev. 2

See how NIST SP 800-61 Rev. 3 replaced Rev. 2's incident-handling guide with a CSF 2.0 Community Profile and what teams should update.

Using NIST SP 800-61 Rev. 3 for Incident Response

Use NIST SP 800-61 Rev. 3 to assign incident-response outcomes, owners, records, communications, and improvements while tracking binding duties separately.

Event vs. Incident in NIST SP 800-61 Rev. 3

An event is observable activity. Declare an incident when analysis shows the occurrence meets documented cybersecurity incident criteria.

How should teams handle communications under NIST SP 800-61 Rev. 3 incident response?

Plan incident coordination, formal notifications, public communication, and voluntary information sharing under NIST SP 800-61 Rev. 3.

How should teams handle lessons learned under NIST SP 800-61 Rev. 3 incident response?

Capture incident-response lessons as they emerge, prioritize them through CSF 2.0 Improvement, and verify changes to plans, controls, training, and recovery.

How should teams handle post-incident evidence under NIST SP 800-61 Rev. 3 incident response?

Preserve incident records, collected data, metadata, integrity, provenance, access controls, and retention decisions under NIST SP 800-61 Rev. 3.

How should teams handle reporting clocks under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal reporting deadline. Build a clock register from each applicable law, regulation, policy, and contract.

How should teams handle severity under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal severity scale. Use documented risk factors to estimate severity and urgency, prioritize response, and reassess.

What should recovery include in a NIST SP 800-61 Rev. 3 incident response process?

Select, authorize, prioritize, and verify recovery actions; check restoration assets and restored systems; confirm service restoration; and document recovery closure.

Which CSIRT roles should teams define under NIST SP 800-61 Rev. 3?

Define incident-response leadership, handlers, technical specialists, legal, communications, HR, facilities, asset owners, and providers under NIST SP 800-61 Rev. 3.