Cybersecurity & Information Security

Severity vs. Priority: How to Rank Security Incidents

6 min readPublished: August 5, 2026

Professional visual illustration on Severity vs. Priority in information security in the SOC and operations domain

Quick answer

Severity describes the potential impact and gravity of an incident; Priority determines the actual order and speed of handling. An incident can be severe but not urgent if it's isolated and contained, or of medium severity but high priority if it's active on a critical asset. Professional ranking combines credibility, Scope, asset criticality, identity, business exposure, containment status, and time.

In SOC systems, several scores sometimes appear in parallel: Alert Severity, Incident Severity, Risk Score, Magnitude, or Priority. When the team uses them as if they are the same, the result is an inconsistent work queue: an old, isolated “High” incident pushes aside a “Medium” activity currently occurring on a manager’s account.

Microsoft describes Severity as a measure of the potential impact on assets, while the unified incident queue adds a Priority mechanism that also considers asset criticality, rarity, MITRE techniques, and high-profile threats. In QRadar, the Magnitude of an Offense is calculated from a combination of Severity, Relevance, and Credibility along with other factors. These examples illustrate that no single score fits every decision.

The goal is not to replace the tools' scores, but to create an organizational language that explains why an incident is being handled now, who is handling it, and what will cause a change in ranking.

What is Severity

Severity describes the gravity of the possible or observed outcome: compromise of confidentiality, integrity, or availability; number of assets and users; system criticality; data sensitivity; and attacker's level of control. It answers the question: “If the scenario is real, how severe is it?”

In most tools, the values are Informational, Low, Medium, and High, and sometimes Critical. It is important to understand who determined the value: Detection vendor, local Rule, analytical engine, or analyst. Alert Severity can be inherited by an Incident, but after investigation, it is permissible and sometimes necessary to update it.

Severity is not proof of authenticity. A High rule with a high False Positive rate does not make every match a severe incident. Therefore, severity must be separated from Confidence.

What is Priority

Priority determines the order of handling and the level of urgency. It answers: “What do we deal with first?” Beyond severity, it considers time, incident status, containment capability, available personnel, SLA, and business context.

An active Ransomware incident on one workstation might receive critical Priority due to its rapid spread, even before the Scope is known. In contrast, a severe historical leak that has already been contained might remain High Severity but a lower Priority for immediate investigation, as long as there is no active compromise.

Priority should be dynamic. With the discovery of an additional asset, successful login, Privilege change, or Containment failure — it increases. After isolation, Revoke, and verification that there is no spread — urgency can be reduced without necessarily changing the incident's severity.

Why the Two Metrics Are Different

If only Severity is used, the work queue is controlled by the tool's initial score. If only manual Priority is used, it is difficult to compare incidents and perform Review. The correct combination is a relatively stable Severity that describes Impact, and an operational Priority that is updated according to the incident's status.

You can add Confidence or Likelihood as a third axis. For example: High Severity, Low Confidence, Medium Priority until verification; or Medium Severity, High Confidence and an active incident — High Priority.

In QRadar, Magnitude is an example of a combined score: Severity, Relevance, and Credibility along with Asset Weight, number of Events, Offense age, and vulnerabilities. It is useful for prioritization but still requires understanding the context.

Factors Affecting Severity

Impact on confidentiality, integrity, and availability.
Criticality of the asset and business service.
Sensitivity and scope of the information.
Level of access: User, Local Admin, Domain Admin, or Cloud Admin.
Number of assets, users, and environments involved.
Attack stage: Initial Access versus Exfiltration or Impact.
Recovery capability and whether valid backups exist.

Factors Affecting Priority

Whether the activity is happening now.
Rapid spread or short window of action.
Reliability of detection and supporting evidence.
Critical asset or identity involved.
Whether the incident is contained or access is still active.
SLA, team availability, and coordination requirement.
Existence of an active threat relevant to the organization.
Immediate business impact, even if technical severity is medium.

Practical Ranking Matrix

You can start with a matrix of Severity and Confidence, and then adjust Priority according to activity status and criticality. There is no universal formula; the model should be transparent, documented, and tested on real incidents.

It is recommended to add a Reason line to each decision. “Priority High — Active session on privileged identity; containment not completed” is clearer than the score alone.

Severity	Confidence	Status	Typical Priority
High	High	Active/Uncontained	Critical
High	Medium	Temporarily Contained	High
High	Low	No supplementary evidence	Medium until verification
Medium	High	Critical asset or spread	High
Medium	Medium	Activity ended	Medium
Low	High	Large volume or operational impact	Medium
Low	Low	Single instance with no impact	Low

Examples from the SOC

Scenario	Severity	Priority	Justification
Old Malware found in an isolated Archive file	High	Low-Medium	Severe potential, but no active execution
Active Password Spray with no success	Medium	High	Short containment window and user scope
Login to Global Admin from a new country	High	Critical	Sensitive identity and potentially active session
Production server not sending logs	Medium	High	Loss of visibility on a critical asset
Adware on a disconnected lab workstation	Low	Low	Limited impact and existing Containment

How to Update Ranking During Investigation

Establish Review points: after Triage, after initial Scope, after the first action, and before closing. At each point, ask what has changed in Impact, Confidence, and activity status. Score updates should include Timestamp, Owner, and justification.

Do not reduce Severity merely to meet SLA. If the incident is severe but contained, you can keep High Severity and reduce Priority. This preserves the historical risk picture and prevents misleading reports.

In team metrics, also analyze Reclassification: how many incidents increased or decreased in rank, and what caused it. Consistent changes can indicate an incorrectly classified Rule or an outdated Asset Criticality.

Practical Checklist

Is it clear who determined the initial Severity?
Did I assess Impact and not just Detection name?
Is Confidence documented separately?
Is the incident active or contained?
Are critical assets/identities involved?
Does the Priority include an operational justification?
Has the next Review point been set?
Is the score change saved in the Audit Trail?

Common Mistakes

Marking every High Alert as a Critical incident.
Using Severity and Priority as synonyms.
Not updating rankings after isolation or scope expansion.
Ignoring asset criticality and data sensitivity.
Building a complex formula that no one understands.
Measuring SLA in a way that encourages artificial Severity reduction.

Summary and CTA

Build a matrix of five lab scenarios and give each Severity, Confidence, and Priority with a justification statement. Compare the result to the Triage article and escalation criteria. In HPI's Cybersecurity & AI course, you practice making decisions based on context, not just reading a score from the system.

FAQ

Does the vendor's Severity obligate the organization?

No. It is a starting point. It should be adapted to the environment, asset, Scope, and local policy.

Can Priority be higher than Severity?

Yes. Active activity on a critical asset or a short containment window can justify a high Priority even when the estimated Impact is medium.

When do you change Severity?

When evidence changes the assessment of impact or Scope. A change should be documented with a justification.

What is Magnitude in QRadar?

A score that helps prioritize Offenses and is calculated, among other things, by Severity, Relevance, Credibility, assets, and events. It is not identical to Severity alone.

Do you need Critical above High?

Only if the organization is able to define different criteria and actions. Too many categories create inconsistency.