Artifact GuideGLOBALNIST SP 800-61 Rev. 3

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

Define severity bands and response targets from organization-specific risk factors, then reassess them as incident facts and resource needs change.

NIST prescribes no universal severity scale or SLA. Its guidance supports risk-based triage, prioritization, escalation or elevation, status tracking, and recovery decisions.

Back to main artifactReview sources
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

is NIST's April 2025 incident-response guidance for cybersecurity leaders, responders, and others who prepare for, detect, respond to, or recover from incidents in organizations of any size or sector. It supersedes Revision 2 and does not prescribe severity levels, labels, or service-level deadlines. Build an organization-defined model from . NIST examples are asset criticality, functional impact, data impact, stage of observed activity, threat-actor characterization, and recoverability. Use those factors to estimate severity and urgency, categorize and prioritize the incident, decide on , and determine when recovery should start. Assess legal, regulatory, contractual, and internal-policy deadlines separately.

Section 1

What NIST says to use for severity and response timing

First perform a preliminary review of the report to verify that a occurred, then estimate severity and response urgency. A suspicious or adverse event is not automatically a confirmed incident. A more detailed review categorizes the incident type. Prioritization determines how quickly response should occur by considering scope, likely impact, time-critical nature, and resource availability.

A useful internal target model links each band to factor thresholds and specific actions. The label alone does nothing. Record what evidence triggered the band, which and communication targets follow, who can change the priority, and when reassessment is required. Treat the targets as organization-defined unless a named law, regulation, contract, or policy supplies the deadline.

  • Triage and validate the report before treating it as a confirmed incident.
  • Estimate severity and urgency from the information available, recording assumptions and confidence limits.
  • Categorize the incident type and prioritize response using scope, likely impact, time sensitivity, and available resources.
  • Escalate resources or time frames and elevate to higher management when the defined risk factors or decision thresholds require it.
  • Apply recovery criteria to known and assumed incident characteristics, including possible disruption caused by recovery work.
Sources for this answer
NIST SP 800-61 Rev. 3 Incident Response
Official publication record for the final Rev. 3 guidance and its supplemental resources.
NIST SP 800-61 Rev. 3 DOI
RS.MA-02 through RS.MA-05 support validation, severity and urgency estimates, categorization, prioritization, escalation, elevation, and recovery-initiation criteria.
NIST CSF 2.0 (CSWP 29)
Explains that CSF outcomes do not prescribe a single implementation, severity scale, or response timer.
Section 2

Build bands and targets without attributing them to NIST

Choose the number and names of severity bands that responders can apply consistently. For each band, define factor thresholds, decision authority, response actions, communication paths, and target times. Label the result as the organization's model, because NIST does not publish universal P1-P4, Sev 1-Sev 4, or similar bands.

Separate targets for acknowledgment, validation, prioritization, , containment decision, stakeholder updates, and recovery decision. A target may come from internal risk appetite, policy, contract, or an external requirement. Record its source; do not describe every internal target as a legal deadline or NIST requirement.

Example: an isolated ransomware infection on a replaceable user endpoint with no evidence of spread or data access may meet a lower organization-defined band than ransomware disrupting a critical service while files are being copied. The second case may score higher for asset criticality, functional impact, data impact, observed-activity stage, and recoverability. This is an illustrative application of NIST's factors, not a NIST classification; the organization's documented thresholds and current evidence control.

  • Factor set: asset criticality, functional impact, data impact, stage of observed activity, threat-actor characterization, and recoverability. Prioritization inputs: scope, likely impact, time-critical nature, and available response resources.
  • Band definition: threshold or decision rule, examples, required approver, and explicit borderline-case handling.
  • Target set: acknowledgment, validation, prioritization, , containment decision, update cadence, and recovery decision.
  • Override rules: the facts or dependencies that permit a faster or slower target, who approves the change, and how the reason is recorded.
  • External overlay: any legal, regulatory, policy, or contractual trigger and deadline assessed independently from the internal severity band.
Sources for this answer
NIST SP 800-61 Rev. 3 Incident Response
Official record for Rev. 3 and its current supplemental incident-response resources.
NIST SP 800-61 Rev. 3 DOI
RS.MA identifies example risk evaluation factors and says prioritization should consider scope, likely impact, time-critical nature, and available resources.
NIST CSF 2.0 (CSWP 29)
Supports organization-defined implementation choices rather than universal band names or service levels.
Section 3

Decision record and accountable owners

For each incident, record who made the classification, when it was made, which facts and assumptions were available, how each risk factor was evaluated, which band and targets were assigned, and when the next reassessment is due. Track the incident summary, indicators of compromise, assigned actions, expected time frames, status, and next steps as response work proceeds.

Keep linked entries for later changes. A priority may rise or fall as scope, impact, attacker activity, recoverability, or resource availability changes. Preserve the former decision and the reason for the change rather than overwriting the history. Protect the confidentiality and integrity of incident records and restrict access to authorized personnel.

  • Incident lead and deputy with authority to assign or revise the band and targets.
  • Decision timestamp, reporter, affected assets and services, incident type, known facts, assumptions, and evidence links.
  • Factor-by-factor rationale, assigned band, , external deadlines, and any approved override.
  • Escalation and elevation decisions, requested resources, higher-management involvement, and resulting actions.
  • Current status, missed-target explanation, next reassessment trigger, recovery decision, and final closure criteria.
Sources for this answer
NIST SP 800-61 Rev. 3 Incident Response
Official record for the final Rev. 3 publication.
NIST SP 800-61 Rev. 3 DOI
RS.MA supports status tracking and risk-based priority changes; RS.AN-06 supports recording investigation actions and preserving record integrity and provenance.
NIST CSF 2.0 (CSWP 29)
Supports documented organizational outcomes while leaving implementation details to the organization.
Section 4

Common classification and target mistakes

Severity is a risk decision, not a decorative label. A band should change authority, response actions, communications, target times, or review cadence. If two bands trigger the same work, responders have no operational reason to distinguish them.

Do not collapse incident priority, legal reportability, and business continuity activation into one field. They may use overlapping facts, but each applies its own criteria and can reach a different result.

  • Do not attribute organization-defined band names or targets to NIST.
  • Do not handle reports first-come, first-served when risk requires different priorities.
  • Do not lock the first estimate; reassess when facts, impacts, or resources change.
  • Do not assume an internal high-severity label automatically triggers a legal or contractual notice.
  • Do not start recovery from the label alone; apply defined recovery criteria to known and assumed incident characteristics, including possible disruption caused by recovery work.
  • Do not confuse Rev. 3's High, Medium, and Low with live-incident severity bands; the profile ratings express typical relative importance of CSF elements to incident response.
Sources for this answer
NIST SP 800-61 Rev. 3 Incident Response
Official NIST publication record for Rev. 3.
NIST SP 800-61 Rev. 3 DOI
RS.MA says incidents should not be handled first-come, first-served and ties triage, prioritization, escalation, elevation, and recovery initiation to risk evaluation factors.
NIST CSF 2.0 (CSWP 29)
Confirms that the organization must choose how to achieve the relevant outcomes.
Section 5

Workflow from report to recovery decision

Use a repeatable workflow, but allow loops. New analysis can change category, priority, authority, communications, containment, and recovery timing. Keep the decision log synchronized with the incident status.

The outputs are an initial and current risk classification, sourced , an action and status record, escalation and elevation history, and a documented recovery decision. Review completed incidents and exercises to improve factor definitions, examples, targets, and authority paths.

  • Step 1 | Intake | Capture the incident report and affected asset or service.
  • Step 2 | Triage and validate | Perform a preliminary review, determine whether a occurred, and estimate severity and urgency.
  • Step 3 | Categorize | Perform a more detailed review and assign an incident type.
  • Step 4 | Prioritize | Apply the factor set and assign organization-defined , considering scope, likely impact, time sensitivity, and available resources.
  • Step 5 | Escalate or elevate | Add resources or change time frames, involve higher management when required, and record the decision.
  • Step 6 | Reassess and recover | Update the classification as facts change and apply recovery criteria before starting recovery processes.
Sources for this answer
NIST SP 800-61 Rev. 3 Incident Response
Official publication record for the April 2025 final.
NIST SP 800-61 Rev. 3 DOI
RS.MA-02 through RS.MA-05 support the validation, categorization, prioritization, escalation, elevation, and recovery-decision sequence.
NIST CSF 2.0 (CSWP 29)
Supports organization-defined procedures and target outcomes.
Recommended next step

Define the internal severity model

Set factor thresholds, band definitions, response targets, authority, overrides, reassessment triggers, and separate external deadlines.

Assessment workflow
Open Assessment Autopilot

Create tasks and evidence requests for factor definitions, targets, decision authority, and incident records.

Explore next step
Talk to Sorena
Review the severity model

Check factor thresholds, target sources, override authority, external overlays, and evidence gaps.

Explore next step
Primary sources

References and citations

NIST SP 800-61 Rev. 3 DOI
doi.org
Referenced sections
  • RS.MA-02 through RS.MA-05 support the validation, categorization, prioritization, escalation, elevation, and recovery-decision sequence.
"Prioritize how quickly incident response should be performed"
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 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.