NIST SP 800-61 Rev. 3

Why does it matter?

Section 2.1 explains why the publication changed shape. When Rev. 2 was written, incidents were relatively rare, narrow in scope and usually handled within a day or two, so a closed cycle run by a dedicated team was realistic. Today incidents occur frequently, cause far more damage and often take weeks or months to recover from, and lessons learned should be shared as soon as they are identified rather than after recovery ends. Rev. 3 answers by treating incident response as a continuous part of cybersecurity risk management and by giving every organization the CSF 2.0 vocabulary for planning, running and improving it.

Key benefits include:

• Incident response inside risk management

Fig. 2 places Govern, Identify and Protect as preparation, Detect, Respond and Recover as incident response, and the Improvement Category (ID.IM) between them, so response sits in the same governance the rest of the program uses.

• A shared vocabulary

Every recommendation is tied to a CSF 2.0 Function, Category and Subcategory, with identifiers such as GV.OC-03.R1, so incident response can be discussed with executives, auditors, insurers and regulators in terms they already know.

• A model that reflects modern incidents

Section 2.1 assumes long, complex incidents and continuous improvement instead of a loop that restarts after each event, and says organizations should use the life cycle model that suits them best.

• Roles beyond the response team

Section 2.2 names leadership, incident handlers, technology professionals, legal, public affairs, human resources, physical security and facilities, asset owners and contracted third parties.

• Current without reissuing the document

Section 1.1 says how-to detail changes too fast for a static publication; playbooks, implementation guidance and mappings to other standards are maintained online through the CPRT.

How does it work?

NIST SP 800-61 Rev. 3 is a 48-page publication in three parts. Section 1 introduces the document, defines event, adverse event and cybersecurity incident, and lists seven incident examples from a botnet flooding a service to a vendor's software compromised before distribution. Section 2 explains incident response as part of cybersecurity risk management: the CSF 2.0-based life cycle model (2.1), roles and responsibilities (2.2) and policies, processes and procedures (2.3). Section 3 presents the CSF 2.0 Community Profile in Table 2 (Preparation and Lessons Learned) and Table 3 (Incident Response). References, a glossary and the Appendix C change log complete the document.

Implementation starts by comparing the organization's existing incident response plan and playbooks with the Profile's Subcategories and recording where each is met, partially met or missing. Teams then assign owners for each Function, align detection sources, escalation paths, containment and eradication steps and recovery criteria with the Detect, Respond and Recover outcomes, define reporting and notification obligations (GV.OC-03.R1 says cybersecurity requirements should include incident notification and data breach reporting), and schedule exercises and post-incident reviews so that lessons learned reach the Improvement Category and change the program. Section 2.3 lists what the policy should contain, from a statement of management commitment to performance measures, and points to the CISA playbooks for procedure examples.

Section 3 sets the mechanics of the Profile. Each row's priority says how it relates to incident response: High means a core incident response activity for most organizations, Medium directly supports it and Low indirectly supports it. The last column holds items tagged R for a recommendation (something the organization should do), C for a consideration (something it should consider doing) and N for a note; the tag and number appended to the CSF ID give a unique identifier, and items made at the Function or Category level also apply to their components. Most Table 2 elements carry lower priorities and no recommendations, while every Table 3 element has recommendations or considerations; organizations are expected to customize the priorities.

Key Elements

• CSF 2.0-based life cycle model (Section 2.1, Fig. 2)

Replaces the Rev. 2 cycle of preparation, detection and analysis, containment, eradication and recovery, and post-incident activity with a model built on the six CSF 2.0 Functions.

• Mapping from the old phases (Table 1)

Preparation maps to Govern, Identify (all Categories) and Protect; Detection and Analysis to Detect and Identify (Improvement); Containment, Eradication and Recovery to Respond, Recover and Identify (Improvement); Post-Incident Activity to Identify (Improvement).

• Preparation through Govern, Identify and Protect

Broader risk management activities that prevent some incidents, prepare the organization for those that occur and reduce their impact; the bottom level of Fig. 2, not incident response itself.

• Incident response through Detect, Respond and Recover

Outcomes for discovering, prioritizing, containing, eradicating and recovering from incidents, and for reporting, notification and other communications; every Table 3 row carries recommendations or considerations.

• Continuous improvement (ID.IM)

The Improvement Category receives lessons learned from every Function as they are identified, not only after recovery ends, and feeds them back to all Functions.

• Roles and third parties (Section 2.2)

Internal roles from leadership to asset owners; third parties under a shared responsibility model whose duties, information flows and authority to act are defined in contracts, with NDAs against unauthorized disclosure.

• Policy elements and playbooks (Section 2.3)

Management commitment, purpose and objectives, scope, definitions, roles and authorities, prioritization and severity guidelines and performance measures; procedures written as playbooks for the most common incidents.

What does it cover?

Section 1.1 says the publication helps organizations incorporate incident response recommendations and considerations throughout their cybersecurity risk management activities and gives a common language for communicating internally and externally about incident response plans. Section 3 says the Community Profile is intended for use by most organizations regardless of sector, size or other factors, and that narrower versions could be developed for federal agencies, small businesses or educational institutions. The scope covers adverse cybersecurity events only, not natural disasters or power failures, and the publication leaves detailed technical procedures and playbooks to the online resources it references rather than carrying them in print.

What are its objectives?

The abstract and Section 1 set out what the publication aims to do:

Help organizations prepare for incident responses, reduce the number and impact of incidents that occur, and improve the efficiency and effectiveness of detection, response and recovery (abstract).

Integrate incident response into cybersecurity risk management across the organization rather than isolating it in one team (Section 2.1).

Organize incident response recommendations and considerations as a CSF 2.0 Community Profile with a shared taxonomy (Section 3).

Clarify the roles and responsibilities of internal teams, leadership and third parties in incident response (Section 2.2).

Support incident reporting, notification and other incident-related communications through the Detect, Respond and Recover Functions (executive summary).

Connect organizations to current online implementation resources and cross-standard mappings through the CPRT (Section 1.1).

Framework in Context

NIST SP 800-61 Rev. 3 draws its structure from CSF 2.0. Section 1.1 points readers to the CSF 2.0 resources, the Incident Response project page and the CPRT, whose mappings associate CSF 2.0 outcomes with the NIST SP 800-53 Rev. 5 controls that help achieve them. Within the NIST series it sits alongside the Risk Management Framework in NIST SP 800-37 Rev. 2 and the risk assessment guidance of NIST SP 800-30 Rev. 1, and Section 2.3 cites the CISA playbooks for procedure examples. Appendix C records a full rewrite that shifted the focus from handling incidents to incorporating incident response throughout risk management, reorganized the content as a Community Profile and moved most hyperlinks online.

Common Framework Mappings

NIST SP 800-61 Rev. 3 is commonly mapped to other control frameworks and standards so that one incident response program can evidence several obligations at once, and the NIST CPRT publishes reference mappings for the Profile.

Mapped frameworks include:

NIST CSF 2.0

NIST 800-53 Rev.5

NIST 800-37 Rev.2

NIST SP 800-30 Rev. 1

ISO 27001:2022

ISO 27002:2022

ISO/IEC 27035

CIS Controls v8.1

SOC 2 (AICPA TSC 2017)

NIST CSF v1.1