Incident Severity Levels: The Practical 2026 Matrix Guide

Incident severity levels decide which incident gets your best people first, and NIST SP 800-61 Rev. 3 is blunt about the alternative: incidents should not be handled first-come, first-served. Your responders are finite. If the queue order is set by alert timestamps, a noisy low-impact event will take the analyst who should be on the quiet credential theft in your finance environment.

This post builds incident severity levels from the six risk evaluation factors Rev. 3 names, separates severity from priority, and walks through a hypothetical morning where three alerts arrive at once. The matrix is our design. The factors and the principles behind them are NIST’s.

What Rev. 3 says about incident severity levels

Rev. 3 is a CSF 2.0 Community Profile, not a step-by-step handling guide (our NIST 800-61 Rev 3 overview explains the shift). It does not define a set of incident severity levels for you. What it does is set the rules any scheme has to follow. They sit in the Incident Management Category, RS.MA, which is rated High priority like every Respond Subcategory.

• RS.MA R1: because of resource limitations, incidents should not be handled first-come, first-served.
• RS.MA R2: triage, prioritization, escalation, elevation and the decision to start recovery should all rest on a set of risk evaluation factors. NIST says that set can be simple or very complex, depending on your needs and maturity.
• RS.MA N2: example factors are asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization and recoverability.
• RS.MA R3: track each incident’s status with a summary, indicators of compromise, the status and time frame of each assigned action, and next steps.
• RS.MA-02.R1: do a preliminary review to confirm an incident has occurred, then estimate its severity and the urgency of the response.
• RS.MA-03.R2: prioritize how quickly to respond based on scope, likely impact, time-critical nature and resource availability.

Section 2.3 of Rev. 3 also lists “guidelines for prioritizing incidents” and estimating severity as an element of the incident response policy. If your policy is silent on incident severity levels, that is a gap an assessor can point to. Our incident response policy post covers the other policy elements.

The six factors, defined so two analysts score them the same way

Incident severity levels are only as consistent as the factor definitions underneath them. A factor name is not a scoring rule. “Asset criticality” means nothing at 03:00 unless the analyst can look up the answer. Each factor needs a definition, a source of truth, and level descriptions written in business terms. Here is how we define them.

Asset criticality

How important the affected assets are to the mission. Score it from your asset inventory, not from memory. Rev. 3’s ID.AM-05 asks you to prioritize assets by classification, criticality, resources and mission impact, so the input should already exist. If it does not, that is your first fix.

Functional impact

What the business can no longer do right now. A degraded internal wiki and a stopped order pipeline are both outages. They are not the same score.

Data impact

Whether data confidentiality, integrity or availability has been affected, and which data classes are involved. Score from your data inventory and classification scheme. Regulated data raises this score because it may bring notification duties.

Stage of observed activity

How far the attacker has progressed. Reconnaissance against your perimeter is a different problem from credential dumping on a server, which is different again from data leaving the network.

Threat actor characterization

What you know about who is behind the activity: opportunistic commodity malware, a financially motivated group, a capable and persistent intruder, or an insider. Score it on evidence, and mark it “unknown” rather than guessing.

Recoverability

Whether you can restore what is affected, and at what cost. An incident you can reverse from tested backups is less severe than one where the only copy of a dataset is encrypted or gone.

A four-tier matrix for incident severity levels

Score each factor from 1 (low) to 4 (critical). The table gives the level descriptions we use. Replace the examples with your own assets and data classes before you adopt it.

Factor	1 Low	2 Moderate	3 High	4 Critical
Asset criticality	Non-production or single user device	Internal business system	Production system supporting a key process	Crown-jewel system or identity infrastructure
Functional impact	No service effect	Minor degradation, workaround exists	Key service unavailable to some users	Key service unavailable to all users
Data impact	No sensitive data involved	Internal data exposed or altered	Confidential data exposed or altered	Regulated or customer data exfiltrated or destroyed
Stage of activity	Attempted, blocked	Initial access on one asset	Privilege escalation or lateral movement	Exfiltration, destruction or encryption under way
Threat actor	Automated, untargeted	Opportunistic, low capability	Targeted or financially motivated	Persistent, capable, or a privileged insider
Recoverability	Self-healing or trivial	Recoverable with existing resources	Recoverable with outside help or significant effort	Not recoverable, or recovery is uncertain

Then convert the factor scores into one of four incident severity levels with two rules. These rules are our recommendation, not NIST text:

1. The highest factor sets the floor. A single 4 means at least SEV-2. Averages hide the one factor that will hurt you.
2. Two or more factors at 4 make it SEV-1. So does any 4 on functional impact for a service customers depend on.

Level	Trigger	Who is told	Response posture
SEV-1 Critical	Two or more factors at 4, or functional impact at 4 on a customer-facing service	Executive leadership, legal, communications	Incident lead named immediately, continuous working session
SEV-2 High	Any factor at 4, or three or more at 3	Security leadership, asset owner, legal on standby	Incident lead named, regular status updates the same business day
SEV-3 Moderate	Highest factor is 3	Security manager, asset owner	Handled within the security team’s normal shift
SEV-4 Low	All factors at 2 or below	Recorded in the ticket only	Queued and handled in order of priority

The “who is told” column is elevation in Rev. 3’s terms: involving a higher level of management. Escalation, by contrast, means adding resources or time (RS.MA-04 N1). Your incident severity levels should drive both, and the policy should say which.

Severity vs priority: two different questions

Incident severity levels answer “how bad is this?” Priority answers “what do we work on next?” A high-severity incident is not automatically the next one to work on. Rev. 3’s RS.MA-03.R2 lists the inputs to priority: scope, likely impact, time-critical nature and resource availability. Two of those are not severity at all.

Take two SEV-2 incidents. One is a contained malware infection awaiting a rebuild. The other is an active session on a server that is still moving. The second gets the next analyst, because waiting changes its outcome. The first can wait an hour without getting worse.

The decision rule: assign severity from the matrix, then set priority within each severity band by asking “does delay make this worse, and do we have the people to act now?” Record both in the ticket. Never lower a severity to make the queue look manageable.

Rating early and re-rating often

Treat your first severity call as provisional. RS.MA-02.R1 calls it a preliminary review, and DE.AE-04 asks you to estimate impact and scope and then review and refine the estimate. RS.AN-08 warns that a superficial look at magnitude can let an incident continue on other targets without your knowledge.

• Score on known and assumed characteristics. If you cannot rule a factor out, score the plausible worst case and say so.
• Re-score incident severity levels at each status update, and whenever a factor changes: a new host, a new data class, evidence of exfiltration.
• Track and validate the status of all open incidents (RS.MA-04.R1), so the ones that need more resources or a new strategy are spotted.
• Downgrade only when evidence removes the condition that set the score, and record who approved it.

Worked example: incident severity levels on a busy morning (hypothetical)

The following scenario is fictional. The organization, systems and events are invented to show how the matrix works.

A hypothetical wholesale distributor runs a two-person security team. At 08:40 a user reports a phishing email. At 08:55 the EDR console flags a credential-dumping tool on a file server used by finance. At 09:05 the help desk logs a complaint that the public website is slow.

Handled first-come, first-served, the phishing report takes the first analyst. Here is the same queue scored against the matrix.

Event	Highest factors	Severity	Priority call
Phishing email, no click, sender blocked	Stage 1, all others 1	SEV-4	Queue; purge the message from other mailboxes when time allows
Credential dumping on finance file server	Stage 3, asset 3, threat actor 3, data 3	SEV-2	First. Delay lets privilege escalation become lateral movement
Public website slow	Functional impact scored 3 as the plausible worst case until the cause is known	SEV-3 provisional	Second analyst triages to rule out a denial of service

Four of six factors score 3 for the file server, which already exceeds the “three or more at 3” trigger. An hour later the analyst finds the same account used on the domain controller. Asset criticality moves to 4 and stage of activity to 4. Two factors at 4 make it SEV-1, so the incident lead triggers elevation to executive leadership and legal. The website turns out to be a capacity issue and is closed as a non-incident.

Nothing in the example required judgement that could not be written down in advance. That is the point of defining incident severity levels before you need them.

Common mistakes with incident severity levels

• Severity by alert source. An alert from an expensive tool is not more severe than a user report. Score the incident, not the detector.
• Too many levels. Five or six incident severity levels invite argument at the boundaries. Four gives each tier a distinct consequence.
• Levels with no consequence. If SEV-2 and SEV-3 trigger the same people and the same cadence, merge them.
• No owner for the asset data. The matrix depends on inventories. Without ID.AM data, analysts guess.
• Never tested. Run historical incidents through the matrix and see whether the results match what leadership would have wanted.

Incident severity levels FAQ

Does NIST SP 800-61 Rev. 3 define incident severity levels?

No. It lists example risk evaluation factors and says triage and prioritization should rest on them, but leaves the scale to you. The NIST SP 800-61 Rev. 3 profile expects you to tailor it.

How many incident severity levels should we use?

Use as few incident severity levels as still change behavior. Four levels, each with a distinct notification list and response posture, is a practical default.

Is severity the same as priority?

No. Severity measures impact and scope. Priority also weighs how time-critical the incident is and which responders are available.

Who can change an incident’s severity?

Anyone on the response can raise it. Lowering it should need the incident lead’s approval, recorded with the evidence that justified it.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Severity and Prioritisation Matrix, the Incident Declaration Criteria and the Incident Escalation and Elevation Procedure — for $99.