Agent Foskett Academy • SOC Analyst Academy • Module 2 • Lesson 18 • Alert Triage

Lesson 18 — The Incident Queue Was Growing Faster Than We Could Clear It

At 8:00 AM the SOC had 23 open incidents. By 9:00 AM there were 41. At 10:15 AM the queue passed 60.

There were High alerts, Medium alerts, repeated alerts, blocked attacks, suspicious sign-ins and incidents involving critical systems. The team could not investigate everything at once.

So the real question became: what must we investigate first?

A busy queue is a prioritisation problem before it becomes an investigation problem.

Prioritise the Queue Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy prioritising a growing incident queue

Sixty incidents — three analysts

Sorting by severity is easy. Deciding what creates the greatest risk right now requires context.

✓ Identify active threats

✓ Add entity criticality

✓ Consider successful activity

✓ Re-rank continuously

Case briefing

10:15 — SOC QUEUE OPEN INCIDENTS: 63 ANALYSTS AVAILABLE: 3 INCIDENT A HIGH Malware blocked on test workstation INCIDENT B MEDIUM Successful unfamiliar sign-in Global Administrator INCIDENT C HIGH Password spray All attempts failed INCIDENT D LOW PowerShell + external connection Production finance server INCIDENT E MEDIUM Suspicious inbox rule Executive mailbox INCIDENT F HIGH Known phishing message Quarantined before delivery SORT BY SEVERITY? A → C → F → B → E → D SORT BY RISK? THAT ORDER LOOKS VERY DIFFERENT.

Investigation objective

Prioritise a growing incident queue using threat activity, entity criticality, potential impact, confidence and time sensitivity rather than severity alone.

Investigator's rule

The next incident should be the one where delay creates the greatest risk. That is not always the incident with the highest severity label.

Stage 1 — separate severity from urgency

Factor	Question
Severity	How strongly did the detection classify the observed behaviour?
Success	Did the suspicious action succeed, or was it blocked?
Entity criticality	Is the user, device or workload privileged or business-critical?
Active threat	Could malicious activity still be occurring right now?
Potential impact	What could happen if the incident is genuine?
Confidence	How much evidence supports the malicious hypothesis?
Time sensitivity	Will waiting make containment, evidence collection or recovery harder?

Blocked activity can wait — sometimes

A High-severity event that was fully prevented may be less urgent than a Medium event where privileged access succeeded and remains active.

Low severity can still be urgent

A weak detection on a critical server with active suspicious network behaviour may deserve immediate attention even if the alert itself is Low.

Stage 2 — create a first-pass queue

FIRST PASS 1. ACTIVE + SUCCESSFUL? ↓ 2. PRIVILEGED / CRITICAL ENTITY? ↓ 3. HIGH POTENTIAL IMPACT? ↓ 4. STRONG CORRELATED EVIDENCE? ↓ 5. TIME-SENSITIVE CONTAINMENT? ↓ 6. BLOCKED / FAILED / ALREADY CONTAINED? ↓ 7. REPEATED NOISE / KNOWN BENIGN PATTERN? THIS DOES NOT REPLACE INVESTIGATION. IT DECIDES WHERE INVESTIGATION STARTS FIRST.

Triage is deliberately fast

You do not need the final verdict before assigning priority. You need enough evidence to decide which incident deserves the next analyst minute.

Do not over-investigate while triaging

If you spend 40 minutes proving the first incident is benign while 62 others wait untouched, the queue has controlled you instead of the other way around.

Stage 3 — use KQL to rapidly assess active endpoint activity

For the Low-severity production-server incident, a quick query can establish whether suspicious processes and connections are still occurring.

12345 678910 11121314

let TargetDevice = "FIN-SRV-02";
DeviceNetworkEvents
| where Timestamp > ago(30m)
| where DeviceName =~ TargetDevice
| summarize
    Connections=count(),
    LastSeen=max(Timestamp)
    by InitiatingProcessFileName,
       InitiatingProcessCommandLine,
       RemoteIP,
       RemoteUrl
| order by LastSeen desc

Recent activity changes urgency

If the suspicious process contacted the external host two minutes ago, the incident may still be active. That is different from an isolated event that stopped twelve hours earlier.

Ask the smallest useful question

During queue pressure, KQL should answer focused triage questions quickly: Is it still happening? How many assets? Which account? Was it successful?

Stage 4 — re-rank the six incidents

Incident	Context	Operational priority
B — Medium	Successful unfamiliar sign-in to Global Administrator	1 — Immediate
D — Low	Production finance server; suspicious connection still active	2 — Immediate
E — Medium	Suspicious inbox rule on executive mailbox	3 — High
C — High	Password spray; all attempts failed	4 — Investigate
A — High	Malware blocked on test workstation	5 — Validate containment
F — High	Phishing quarantined before delivery	6 — Validate / close

Priority is temporary

This ranking is correct only for the evidence available now. If the password spray suddenly produces a successful privileged sign-in, Incident C moves immediately.

The queue is dynamic

New evidence, new alerts and containment actions continuously change risk. Queue management is repeated triage, not a one-time morning sort.

Stage 5 — work in triage passes

PASS 1 — RAPID SCREEN Identify obvious urgent / contained / duplicate cases ↓ PASS 2 — ENTITY CONTEXT Privileged users Critical servers Executives Sensitive workloads ↓ PASS 3 — ACTIVE THREAT Successful access Current connections Ongoing execution Expanding scope ↓ PASS 4 — CORRELATION Group related alerts Remove duplicate work Find multi-stage incidents ↓ PASS 5 — RE-RANK Assign analyst attention based on current risk

Grouping reduces wasted effort

If ten alerts belong to one incident, ten analysts should not independently rediscover the same attack story. Correlation can reduce queue pressure as well as improve investigation quality.

Noise needs engineering

If a detection repeatedly consumes triage time without producing useful security outcomes, record the pattern for detection tuning rather than accepting permanent queue noise.

Stage 6 — know when to escalate the queue itself

Queue condition	Operational response
Critical incidents waiting unassigned	Escalate staffing / incident-management support.
Large correlated campaign	Move from individual triage to coordinated incident response.
Repeated duplicate alerts	Group incidents and involve detection engineering.
Backlog aging beyond acceptable limits	Reassess priorities and operational capacity.
Evidence of active compromise across critical systems	Escalate immediately; queue volume becomes secondary.

Sometimes the most important escalation is not an incident. It is the fact that the SOC no longer has enough capacity to manage the risk safely.

Stage 7 — build the pressure-triage workflow

QUEUE GROWING ↓ RAPID SCREEN ↓ SUCCESSFUL / ACTIVE? ↓ CRITICAL ENTITY? ↓ HIGH IMPACT? ↓ CORRELATED EVIDENCE? ↓ TIME-SENSITIVE? ↓ BLOCKED / CONTAINED? ↓ GROUP DUPLICATES ↓ ASSIGN PRIORITY ↓ INVESTIGATE ↓ RE-RANK AS NEW EVIDENCE ARRIVES

Write the operational triage note

QUEUE TRIAGE NOTE 63 open incidents were reviewed using severity, success, active threat, entity criticality, potential impact and containment status. A Medium alert involving a successful unfamiliar Global Administrator sign-in was prioritised first. A Low alert involving active suspicious network activity on a production finance server was prioritised second. Several High alerts involving blocked or failed activity remained important but were placed behind incidents with active or successful compromise risk. DECISION Assign analyst capacity according to current risk, not severity order alone. Reassess the queue as new evidence arrives.

Lesson 18 key takeaways

A growing incident queue requires deliberate prioritisation.
Severity is one input to priority, not the entire decision.
Successful and active suspicious activity often deserves faster attention than blocked activity.
Privileged identities and critical assets can raise operational priority.
Ask focused questions during triage rather than fully investigating every incident immediately.
Use KQL to determine whether suspicious activity is recent, active or expanding.
Group related alerts to reduce duplicated investigative work.
Re-rank incidents whenever new evidence changes the risk.
Persistent noise should feed detection-engineering improvements.
Escalate operational capacity when critical risk is waiting because the SOC cannot keep up.

Module 2 — alert triage

You have now prioritised a SOC queue under pressure without simply sorting from High to Low. Next, Agent Foskett investigates an alert where the correct verdict cannot yet be reached — because one important piece of context is still missing.

Next: Lesson 19 — The Alert Needed More Context Before a Verdict

Continue your SOC Analyst training

Module 2 focuses on prioritisation, queue pressure, weak-signal correlation, context and defensible triage decisions.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 2: Alert Triage — Deciding What Matters First

Prioritise under pressure using risk, active threat, entity criticality and impact rather than severity alone.

← Previous lesson

Lesson 17 — Five Low-Severity Alerts Formed One High-Risk Story Correlate weak signals during triage.

✅ Current lesson

Lesson 18 — The Incident Queue Was Growing Faster Than We Could Clear It Prioritise under pressure without simply sorting by severity.

Next lesson →

Lesson 19 — The Alert Needed More Context Before a Verdict Identify the minimum additional evidence needed for a defensible decision.

How to prioritise a growing SOC incident queue

Lesson 18 of the Agent Foskett SOC Analyst Academy teaches analysts how to prioritise security incidents using active threat, successful activity, entity criticality, potential impact, confidence and time sensitivity instead of relying on severity alone.

SOC queue management and KQL rapid triage

Learn how to use Microsoft Defender XDR KQL for rapid incident assessment, identify current suspicious network activity, group related alerts and continuously re-rank a busy security operations queue.