Lesson 38 — Prioritising Incidents: Severity Is Not the Whole Story

Learning objectives

• Explain why incident severity and investigation priority are not the same thing.
• Use affected assets, privilege, scope and business impact during triage.
• Use alert, behavioural and threat context to refine priority.
• Recognise when a lower-severity incident deserves immediate attention.
• Build a repeatable prioritisation decision instead of relying on instinct.

The SOC queue

Your queue contains 40 open incidents. You cannot investigate all of them first.

Sorting by severity is useful — but a SOC analyst needs to understand what is at risk, how credible the evidence is, how far the activity has spread and what could happen next.

Factor 1 — severity

Start with severity because it is a useful indicator of potential impact. High-severity incidents generally deserve faster attention than low-severity incidents.

But do not stop there. Microsoft itself describes prioritisation as using severity and other factors.

Factor 2 — asset criticality

Ask what the affected asset means to the organisation.

A domain controller, production database, payment system or executive mailbox can make otherwise ordinary-looking activity much more urgent than the same signal on an isolated lab machine.

Factor 3 — privilege

Compromise of a highly privileged identity can change the blast radius dramatically.

Global administrators, security administrators, service principals with powerful permissions and privileged service accounts deserve additional attention because successful misuse can affect many systems.

Privilege is not only a user role

Think about what the entity can actually do.

An application identity with access to sensitive cloud resources may be more dangerous than a human account with an impressive-sounding title but limited technical permissions.

Factor 4 — scope

How many users, devices, mailboxes, applications, IP addresses or cloud resources are involved?

A single endpoint alert may be manageable. The same indicator across 25 devices suggests a very different investigation.

Scope can grow

Your first read may show one affected user. Hunting may reveal six more.

Priority is therefore not a one-time field you mentally set and forget. Reassess it as the investigation changes the known blast radius.

Factor 6 — behavioural context

Microsoft Sentinel UEBA builds behavioural context for users, hosts, IP addresses, applications and other entities. Deviations from historical, peer and organisational behaviour can help analysts identify unusual activity.

A first-time action is interesting. A first-time action combined with unusual geography, unusual timing and privileged access is more interesting.

UEBA scores are context

Sentinel's UEBA data can expose investigation-priority and anomaly scores to help triage unusual behaviour.

Use them as additional evidence — not as an automatic declaration that an entity is compromised.

Factor 8 — business impact

Security telemetry cannot always tell you what a system means to the business.

An incident affecting payroll on payday, manufacturing control during production, customer data or a critical authentication service may require faster escalation because operational impact is higher.

Know your environment

The strongest analysts understand both the technology and the organisation.

Asset tags, CMDB data, watchlists, identity information and documented critical systems can provide context that raw alerts alone cannot.

The incident queue helps you triage

The Microsoft Defender incident queue is designed to help analysts filter, sort and prioritise incidents. Current guidance describes prioritisation using severity together with broader incident context.

Use the queue to reduce the problem space — then apply analyst judgement.

Automation can help

Microsoft Sentinel automation rules can change incident severity, assign owners, add tasks and update status based on defined conditions.

This allows known business context to influence triage consistently instead of depending entirely on a busy analyst noticing it manually.

Do not chase every anomaly

Unusual does not automatically mean malicious. A travelling executive, a newly deployed application or a legitimate administrator can all generate anomalous behaviour.

Behavioural context raises questions. Evidence answers them.

Do not ignore blocked attacks

A blocked action may reduce immediate impact, but it can still reveal an attacker attempting access, testing credentials or targeting a critical asset.

Priority depends on the wider story, not simply whether one action succeeded.

Common mistake — sort by High and stop thinking

Severity sorting is a sensible starting point. Treating it as the complete prioritisation strategy is not.

Context can move an incident ahead of something that initially looks more severe.

Common mistake — first in, first out

A SOC queue is not a supermarket checkout.

A newly created incident involving a critical privileged identity may legitimately jump ahead of an older low-impact case.

Common mistake — ignore business context

Two technically identical incidents can have completely different consequences depending on the asset involved.

Know what matters to the organisation you are defending.

Common mistake — priority never changes

An incident can begin as Low or Medium and become urgent when the investigation reveals lateral movement, privileged access or a wider blast radius.

Reprioritise when the evidence changes.

Best practices

• Use severity as a starting signal, not the whole decision.
• Know your critical assets and privileged identities.
• Consider scope and blast radius.
• Use UEBA and threat context to enrich triage.
• Distinguish unusual from malicious.
• Reassess priority as new evidence appears.
• Document why an incident was escalated or deprioritised.

Agent Foskett takeaway

The loudest alert is not always the most dangerous incident.

The most important question is not simply, “How severe is it?”

Ask what is at risk, how far it reaches, how strong the evidence is — and what happens if you are wrong.