Artifact GuideGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 Using the Incident Response Profile

Use Rev. 3's CSF 2.0 Community Profile to assign outcomes, decision authority, scenario procedures, response records, and improvement work.

Nongovernmental organizations may use Rev. 3 voluntarily. The publication does not itself create certification, universal severity levels, or notification deadlines; applicable laws, regulations, policies, and contracts remain separate.

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

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Start by defining the services, assets, data, dependencies, and jurisdictions the incident-response program covers. Then use NIST SP 800-61 Rev. 3 to assign outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. Rev. 3 is a for most organizations, regardless of sector or size, but it is not a complete playbook or a substitute for organization-specific legal, regulatory, policy, and contractual analysis.

Section 1

Decisions to make before applying Rev. 3

Choose an incident-response lifecycle that fits the organization. NIST uses a CSF 2.0 model, but it says organizations should use the lifecycle framework or model that suits them best. Whichever model is chosen, incident response should be considered throughout cybersecurity risk management.

Before an incident, define who can declare an incident, change priorities, increase resources, involve higher management, approve containment, start recovery, communicate externally, and declare recovery complete. Record deputies and fallback channels, not only primary contacts.

  • Scope the services, assets, data, locations, providers, and consequences the response program must address.
  • Assign authority for declaration, prioritization, containment, communications, recovery initiation, and recovery completion.
  • Maintain legal and contractual notification duties as an overlay because Rev. 3 does not supply universal triggers or deadlines.
Section 2

Scope the program before mapping the profile

Start with mission-critical services, assets, data, locations, business impacts, external dependencies, and legal or contractual reporting duties. The same organization may need different procedures and authority paths for ransomware, cloud compromise, data breach, account takeover, denial of service, and supplier compromise.

Map Rev. 3 outcomes only after the boundary is explicit. A scope may cover the whole organization, one critical service, a financial-system environment, or a ransomware scenario. Record assumptions and exclusions so a supplier-hosted service, unmanaged asset, or regional operation does not silently fall outside the response model. Govern, Identify, and Protect support preparation and impact reduction. Detect, Respond, and Recover cover active incident work. ID.IM uses evaluations, tests, exercises, operational experience, and lessons learned to identify improvements.

  • Inventory critical services, technology, data, recovery dependencies, and external providers.
  • Define event-to-incident criteria, risk evaluation factors, recovery-initiation and completion criteria, and decision authority.
  • Maintain a separate obligations matrix for laws, regulations, contracts, customer promises, and sector rules.
Section 3

Core operating records and accountable roles

Connect preparation records to each incident file, then connect the incident file to recovery and improvement. Rev. 3 calls for recording investigation actions and preserving the integrity and provenance of those records. It also calls for collecting incident data and metadata and preserving their integrity and provenance. Formal chain-of-custody procedures may not be used for every incident, but retention still follows the organization's evidence-preservation procedures and data-retention policies.

Responsibility is distributed. Leadership, incident handlers, technology professionals, legal and privacy teams, public affairs, human resources, physical security, asset owners, and providers may need named authority and tested contact paths.

  • Current and Target Profile, incident policy, scenario playbooks, contact and authority matrix, exercise results, and provider responsibility map.
  • Incident declaration, triage and prioritization rationale, action timeline, analysis records, communications, containment and eradication decisions, and evidence register.
  • Recovery initiation and completion criteria, recovery authorizations, restored-asset integrity checks, after-action report, and tracked corrective actions.
  • Organization-defined measures for outcomes such as detection coverage, decision time, restoration integrity, repeat incidents, and corrective-action closure.
Section 4

Claims and operating shortcuts to avoid

Do not describe Rev. 3 as a law, certification, mandatory four-phase procedure, or source of universal service-level targets. It supersedes Rev. 2 and moves changing implementation detail into NIST's online resource ecosystem.

Contracting for incident-response work does not transfer every responsibility. Define provider responsibilities, information flows, authority to contain or restore, restrictions on sharing, and escalation terms in the relevant agreements and procedures.

  • Do not turn NIST guidance into a false statutory deadline unless another instrument actually incorporates it.
  • Do not treat every adverse event as an incident; declare incidents against defined criteria and known or assumed facts.
  • Do not process incidents first-come, first-served; prioritize using organization-defined risk factors and reassess as facts change.
Section 5

Implementation workflow from profile to improvement

Use Rev. 3 to identify desired outcomes, then translate them into policy, capabilities, procedures, authority, records, and review triggers that fit the organization. Tests, exercises, operational work, and completed incidents should feed improvements through ID.IM.

During an incident, assess legal, regulatory, policy, and contractual notification duties alongside technical handling. Rev. 3 recommends complying with current incident-notification requirements, but the applicable external instrument sets each trigger, recipient, content requirement, and deadline.

  • Baseline capabilities against the Rev. 3 Community Profile and prioritize Target Profile gaps.
  • Write and exercise scenario playbooks with internal teams, asset owners, leadership, and relevant providers.
  • During handling, log declaration, risk, authority, actions, analysis, communications, evidence, and recovery decisions.
  • Verify the integrity of recovered assets, document the end of recovery against defined criteria, and route unresolved risk through the organization's risk process.
  • Route lessons into owned improvements and verify that the changed control or process operates as intended.
  • Reassess the profile and supporting procedures after material service, technology, supplier, threat, legal, contractual, or organizational changes, as well as after exercises and incidents expose a gap.
Primary sources

References and citations

doi.org
Referenced sections
  • Supports moving from Current Profile outcomes to prioritized Target Profile outcomes.
doi.org
Referenced sections
  • ID.IM supports improvements from evaluations, tests, exercises, and operations; RS.CO supports current notification requirements; RC.RP supports restoration integrity and recovery completion.
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 Response Playbook Template
Build a scenario-specific incident playbook with declaration criteria, authority, third-party coordination, response evidence, legal overlays, and recovery exit criteria.
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.
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.