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.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
3

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
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.
Primary sources

References and citations

doi.org
Referenced sections
  • CSF 2.0 supports tailoring outcomes to organizational mission, stakeholder expectations, threat landscape, requirements, and risk priorities.
doi.org
Referenced sections
  • Official source for the six CSF Functions and ID.IM improvement outcomes used to organize the template.
csrc.nist.gov
Referenced sections
  • 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.
Related guides

Explore more topics

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.
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.
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.
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.