Lesson 91 — Monday 09:02 — The Queue Is Already Full
You have been on shift for two minutes.
The queue is already full.
Everything wants your attention.
But not everything deserves it first.
The loudest alert is not always the most important.
Prioritise using evidence, context, potential impact and signs of active compromise.
09:02 — shift opening
Investigation objective
Run a realistic shift-opening triage by deciding what requires immediate attention, what can be correlated, what needs more context and what can safely wait.
Investigator's rule
Queue order is not investigation priority.
09:03 — establish context before priority
| Alert | Initial signal | Context that matters |
|---|---|---|
| Malware blocked | High severity | Was execution prevented? What happened before and after? |
| Unusual sign-in | Medium severity | The identity is a Global Administrator |
| Phishing click | High severity | Did credentials or a session become compromised? |
| PowerShell | Low severity | Developer device may explain the behaviour |
| MFA prompts | Medium severity | Same privileged account as the unusual sign-in |
Severity is one input
Severity helps organise the queue, but it does not know every business fact, identity privilege, asset role or correlated signal available to your SOC.
Context can reorder the queue
A medium alert involving a privileged identity may deserve attention before a high alert where malicious activity appears to have been prevented.
09:04 — correlate before you prioritise
Alert count is not incident count
Look for shared accounts, devices, IP addresses, time windows and attack stages before treating every queue item independently.
Correlation changes urgency
An unusual sign-in plus repeated MFA prompts against the same privileged account is more concerning than either alert considered alone.
09:05 — inspect the privileged identity
let Account = "admin@contoso.com";
EntraIdSignInEvents
| where Timestamp > ago(2h)
| where AccountUpn =~ Account
| project Timestamp,
AccountUpn,
IPAddress,
Country,
Application,
ErrorCode
| order by Timestamp ascAsk the first useful question
Did authentication succeed, and does the activity fit the administrator's expected location, device and application pattern?
Investigate the evidence, not the label
“Unusual sign-in” is the alert's interpretation. Your job is to reconstruct what actually happened.
09:07 — the timeline gets worse
Priority 1 emerges
The privileged identity now has correlated signals and evidence of successful access. That combination can justify immediate escalation and containment consideration.
Keep uncertainty explicit
The evidence is concerning, but high priority does not mean predetermined verdict. Validate whether the sign-in and MFA activity were legitimate.
09:08 — rank the work
| Priority | Case | Reason |
|---|---|---|
| 1 | Global Admin sign-in + MFA prompts | Privileged identity, correlated signals, successful activity |
| 2 | Phishing link clicked | Possible credential or session compromise |
| 3 | Malware blocked on finance device | Important asset; prevention status still needs validation |
| 4 | PowerShell on developer device | Potentially expected context; validate after higher-risk cases |
The ranking is provisional
New evidence can change it immediately. Successful malware execution or a privileged phishing victim could reorder the queue.
Triage is dynamic
You continuously allocate analyst attention based on the best evidence currently available.
09:10 — verify the malware claim
let Device = "FIN-WS-042";
DeviceProcessEvents
| where Timestamp > ago(2h)
| where DeviceName =~ Device
| project Timestamp,
DeviceName,
AccountName,
InitiatingProcessFileName,
FileName,
ProcessCommandLine
| order by Timestamp asc“Blocked” is not the end
Confirm whether anything executed before prevention, whether persistence appeared, whether credentials may have been exposed and whether related activity exists elsewhere.
Asset importance still matters
A finance workstation may carry sensitive business context. Prevention reduces urgency only when surrounding evidence supports that conclusion.
09:13 — inspect the phishing case
A click is a pivot, not a verdict
Determine whether the click led to credential theft, session compromise, malware execution or no successful compromise at all.
Build the timeline
Look immediately after the click for authentication and post-authentication activity. The sequence often reveals whether the email became a larger incident.
09:15 — validate the developer PowerShell alert
| Evidence | Interpretation |
|---|---|
| Developer workstation | PowerShell may be common |
| Known engineering account | Expected user context |
| Internal script path | Supports legitimate activity |
| No suspicious follow-on activity | Reduces concern |
| Matches historical pattern | Strong benign context |
Low priority is not ignored
You still need enough evidence to justify why the alert can wait or be closed. “It is only low severity” is not a defensible reason.
Normal context is evidence, not immunity
A developer workstation can still be compromised. Validate the specific activity rather than trusting the device label.
09:18 — record the triage decision
Document why the order changed
A later analyst should be able to understand why a medium-severity identity alert moved ahead of a high-severity malware alert.
Protect analyst attention
The objective is not to clear the largest number of alerts first. It is to direct limited attention toward the activity with the greatest current risk.
Decision point — what do you do first?
The queue is a decision problem
Alert triage is not clerical sorting. It is rapid risk assessment under incomplete information.
The decision can change
Every new piece of evidence can promote, demote, merge or expand an investigation.
09:20 — investigation finding
Lesson 91 key takeaways
- Queue order is not investigation priority.
- Alert severity is useful but never sufficient on its own.
- Identity privilege and asset importance can change priority.
- Correlate alerts before assuming each one is a separate incident.
- Multiple medium alerts can form one critical investigation.
- Successful activity often changes urgency.
- “Blocked” malware still requires surrounding evidence to be checked.
- A phishing click is an investigative pivot, not proof of compromise.
- Known normal behaviour must be validated against the specific evidence.
- Triage rankings are provisional and should change with new evidence.
- Document why one case was prioritised over another.
- The goal is not to clear the queue fastest — it is to protect what matters first.
Module 10 — Complete SOC Investigation Scenarios
Lesson 91 opened a realistic SOC shift by forcing you to prioritise competing alerts. Lesson 92 follows one phishing case as it crosses the boundary from email investigation into identity compromise.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 10: Complete SOC Investigation Scenarios
How should a SOC analyst prioritise a full alert queue?
Lesson 91 of the Agent Foskett SOC Analyst Academy runs a realistic shift-opening triage scenario involving malware, phishing, privileged identity activity, repeated MFA prompts and PowerShell alerts.
SOC alert triage and prioritisation
Learn how severity, identity privilege, asset importance, successful activity, alert correlation and signs of active compromise help analysts decide which investigation requires attention first.
