NIST SP 800-61 Rev. 3 How should teams handle severity under NIST SP 800-61 Rev. 3 incident response

Use severity as one documented input to incident management, not as a substitute for incident declaration or a complete risk assessment. Validate the report first. Estimate severity and urgency from the facts available, and mark assumptions or missing information that could change the result.

Use organization-defined factors consistently. Rev. 3 examples are asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization, and recoverability. Define each factor, its evidence, how factors combine, who decides, and when judgment may override the calculated result.

Categorize the incident separately by type, such as data breach, ransomware, account takeover, or denial of service. For prioritization, consider scope, likely impact, time-critical nature, and resource availability. Incidents should not be handled first-come, first-served when risk and resource limits require a different order.

Use the result to choose response priority and strategy, decide whether more resources or management involvement are needed, and apply recovery-initiation criteria. Escalation generally increases resources or response time frames; elevation usually involves higher management. Record either decision and its operational consequence.

Example: ransomware disrupting an essential service, affecting many assets, with uncertain persistence and no verified clean restoration source may warrant a higher response priority than a contained account compromise on a noncritical asset. This is an illustration, not a NIST severity level; the organization's approved factors and the actual evidence control the result.

Keep magnitude and severity distinct. Magnitude asks how broad the incident is and should be validated by looking for compromise indicators, persistence, and related activity on known and potential targets. A small confirmed scope can still be urgent, while a broad but contained incident may require a different strategy.

A severity label alone does not determine an external reporting duty, contractual notice, insurance classification, recovery target, or public statement. Apply those instruments independently and retain the cross-reference when severity evidence informs them.

Document the severity and urgency decision, the facts and assumptions used, the applicable criteria, the main factors, the decision owner, and the operational consequences. Show why the incident has its current rating and which new fact would require reassessment.

Track severity separately from incident category, response priority, escalation, elevation, recovery status, magnitude, and external notification classification. These decisions can influence one another, but Rev. 3 does not define them as a single scale.

For each factor, retain the source evidence and time assessed. Record conflicting signals, unavailable evidence, manual overrides, the approving authority, and the action that follows. A label without its rationale and consequence does not show that prioritization worked.

Track incident status with a current summary, relevant indicators of compromise, assigned actions, expected time frames, and next steps. Validate the status often enough to identify incidents that need more resources or a different response strategy; the organization should define the cadence for each priority.

Review the severity method after exercises, incidents, missed service targets, repeated overrides, material changes to assets or dependencies, and changes in risk appetite or external requirements. Keep the prior method and decision record when a later reassessment changes the rating.