Artifact GuideGLOBALNIST SP 800-61 Rev. 3

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

Use Rev. 3 as a Community Profile, then tailor its outcomes into a scoped Current Profile, Target Profile, and action plan.

Govern, Identify, and Protect prepare the organization; Detect, Respond, and Recover handle incidents; Identify Improvement carries lessons back into every Function.

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

NIST SP 800-61 Rev. 3 is a : a published baseline of outcomes for organizations that share an incident-response use case. It supplies input to an organization-specific Target Profile. A completed assessment and operational playbooks require organization-specific evidence and decisions. Rev. 3 adds recommendations, considerations, notes, and relative incident-response priorities to CSF outcomes; it does not prescribe one technology stack, maturity level, severity scale, or legal reporting deadline.

Section 1

How Rev. 3 divides preparation, incident response, and improvement

Rev. 3's lifecycle figure places Govern, Identify, and Protect in the preparation layer. They are broader cybersecurity risk-management activities that prevent some incidents, prepare the organization, and reduce impact, but NIST does not treat them as incident response itself. Detect, Respond, and Recover form the active incident-response layer.

Identify Improvement (ID.IM) connects lessons to change. Lessons can emerge in any Function and should be analyzed, prioritized, and used to adjust policies, processes, procedures, safeguards, monitoring, and recovery arrangements without waiting for a formal post-incident meeting.

  • Preparation: Govern, all Identify Categories, and Protect.
  • Active handling: Detect, Respond, and Recover.
  • Continuous learning: Identify Improvement, informed throughout preparation and response.
Section 2

Use the profile as outcomes and priorities, not a universal procedure

Section 3 assigns High, Medium, or Low priority to the Community Profile's CSF elements and adds incident-response recommendations (R), considerations (C), and notes (N). These ratings express typical relative importance to incident response. They do not classify a live incident, set response times, or measure implementation maturity.

A Community Profile is not the same as an Organizational Profile. Build a Current Profile to record which outcomes the chosen scope is achieving and how. Build a Target Profile to select and prioritize desired outcomes based on mission, stakeholder expectations, threats, requirements, and risk objectives. Gaps between them become a prioritized action plan.

The CSF Tiers Partial, Risk Informed, Repeatable, and Adaptive characterize the rigor of cybersecurity risk governance and management practices. They can provide context for Current and Target Profiles, but they do not replace the outcome-by-outcome assessment or function as incident severity levels.

  • Choose and document the organization, service, system, data, supplier, technology, and location boundary, including assumptions and exclusions.
  • For the Current Profile, record whether and how each selected outcome is achieved, with an owner, procedure, evidence source, and known limitation.
  • For the Target Profile, record the desired outcome, priority, rationale, dependency, accountable owner, and target evidence.
  • Analyze gaps, create an action plan, and document where law, policy, contract, or another framework adds mandatory requirements.
  • If Tiers are used, record the selected Tier and rationale separately from Rev. 3's High, Medium, and Low profile priorities and from live-incident severity.
Section 3

Translate the six Functions into accountable evidence

For each selected outcome, name the responsible role, operating procedure, evidence source, review frequency, dependency, and exception. Preparation evidence may include policies, critical-service and dependency maps, asset inventories, supplier responsibilities, monitoring coverage, exercise results, communication procedures, and recovery criteria. Active-response evidence may include declarations, triage decisions, action logs, incident data, notifications, containment and eradication records, restoration validation, and after-action reports.

Rev. 3 spreads responsibility beyond a computer security incident response team. Depending on the organization and incident, leadership, incident handlers, technology professionals, legal, public affairs, human resources, physical security, asset owners, and external providers may make or execute decisions. The profile should expose missing authority and handoffs rather than assigning every outcome to the security team.

  • Name primary and backup authority for declaration, containment, public communication, legal notification, and recovery completion.
  • Record the source, timestamp, actor, action, rationale, and integrity controls for response records.
  • Define third-party information flows, authority to act, restrictions, and escalation paths in contracts before an incident.
  • Track corrective actions through ID.IM with priority, owner, due date, and verification evidence.
Section 4

Boundaries visitors should not miss

NIST developed Rev. 3 under its federal information-security responsibilities, and other authority may make standards or guidelines binding on federal agencies. The publication says nongovernmental organizations may use it voluntarily. Whether any part is mandatory for a specific organization depends on applicable law, policy, contract, procurement terms, or incorporation by another authority.

The profile includes notification and communication outcomes but does not create a universal deadline. An organization must separately map current duties for its sectors, operating locations, affected customer locations, data, contracts, and other relevant characteristics.

  • Do not turn NIST guidance into a false statutory deadline unless another instrument actually incorporates it.
  • Do not call Rev. 3 a certification or claim that following it alone establishes compliance.
  • Do not mistake profile priority ratings for incident severity or response-time targets.
Section 5

A practical profile-to-playbook workflow

Start with the mission, services, consequences, requirements, and risk direction for a defined scope. Use Rev. 3 to select relevant outcomes, document the Current Profile, define the Target Profile, analyze gaps, and create a prioritized action plan. Then write scenario playbooks that invoke the resulting capabilities and identify who can make time-sensitive decisions.

Exercise the playbooks with the internal and external participants named in the profile. Preserve decisions and evidence during real events. As lessons emerge, route them through ID.IM, verify accepted changes, and update the Current Profile when evidence shows the outcome is being achieved. Revisit the scope and Target Profile when mission, technology, suppliers, threats, requirements, or risk direction materially change.

  • 1 | Scope | Record mission, critical services, assets, data, locations, technologies, dependencies, suppliers, stakeholders, requirements, assumptions, and exclusions.
  • 2 | Current Profile | Select relevant Rev. 3 outcomes and document present achievement, owner, procedure, evidence, limitation, and dependency.
  • 3 | Target Profile | Select and prioritize desired outcomes using risk, mission, stakeholder, threat, and requirement inputs; do not copy every Community Profile priority without analysis.
  • 4 | Action plan | Record each gap, risk rationale, action, owner, dependency, resource need, target evidence, due date, and acceptance decision.
  • 5 | Operationalize | Translate outcomes into authority, scenario playbooks, technical procedures, provider agreements, communication routes, exercises, and recovery criteria.
  • 6 | Verify and update | Test handoffs and decisions, collect outcome evidence, route lessons through ID.IM, and update the Current Profile only when the changed capability is demonstrated.
Primary sources

References and citations

doi.org
Referenced sections
  • Section 3.1 provides the five-step Organizational Profile method: scope, gather information, create the Profile, analyze gaps and plan actions, then implement and update.
csrc.nist.gov
Referenced sections
  • Rev. 3 provides the incident-response Community Profile, lifecycle relationships, participant model, operational recommendations, and ID.IM improvement loop used in this workflow.
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 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.
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.