Lesson 1 — The Alert Queue Has 47 Alerts — Where Do You Start?
Your shift begins. Microsoft Sentinel, Defender XDR and identity detections have been busy overnight.
There are 47 alerts waiting in the queue.
Some are high severity. Some involve privileged identities. Some affect ordinary endpoints. Several look
almost identical. One low-severity alert touches a domain controller. Another high-severity alert has weak
supporting evidence. You cannot investigate everything at once — so your first SOC decision is not
how to investigate. It is what deserves your attention first.
Your first SOC shift
It is 7:03 AM. The overnight queue contains 47 alerts across identity, endpoint, email and cloud activity. Your job is to decide which alert becomes the first investigation.
Case briefing
Investigation objective
Learn a repeatable method for triaging a busy alert queue. Instead of selecting alerts by severity alone, evaluate the potential impact, confidence, affected asset, identity privilege, attack context, evidence quality and whether immediate action may be required.
Investigator's rule
Severity is an input, not a decision. A high-severity alert may be noisy or already contained. A lower-severity alert involving a domain controller, privileged identity or active attack chain may deserve attention first.
Stage 1 — do not open the first alert yet
The instinct of a new analyst is often to click the first red alert at the top of the queue. Resist that instinct. Before opening an individual alert, scan the queue as a whole. You are looking for concentration, repetition and anything that changes the potential business impact.
Look for concentration
Five alerts affecting the same device in ten minutes may represent one developing incident rather than five independent tasks. Queue triage begins by recognising relationships before spending time on individual details.
Look for consequence
An alert affecting a test workstation and an alert affecting a domain controller do not carry the same potential consequence. The technology may report similar severity while the organisation faces very different risk.
Stage 2 — severity and priority are not the same thing
Vendor severity tells you how the detection system has classified the activity. SOC priority is the analyst's decision about how urgently the organisation needs that activity investigated.
| Signal | What it tells you | What it does not tell you |
|---|---|---|
| Severity | How serious the detection logic considers the observed behaviour. | The actual business impact in your environment. |
| Confidence | How strongly the available evidence supports suspicious or malicious activity. | Whether the affected asset is important. |
| Asset value | How damaging compromise of the device, workload or data could be. | Whether malicious activity actually occurred. |
| Identity risk | Whether the account has privilege, sensitive access or unusual authentication context. | Whether the user intentionally performed the activity. |
| Containment status | Whether a control blocked, quarantined or otherwise limited the activity. | Whether earlier or related activity succeeded. |
A blocked alert can wait — sometimes
If malware was detected and prevented on an ordinary endpoint, that may reduce immediate urgency. But do not close it simply because prevention succeeded. You still need to ask whether execution, persistence or lateral movement occurred before the block.
A low alert can become urgent
A suspicious outbound connection from DC-01 may be labelled low severity, but the asset changes the question. Why is a domain controller communicating with that destination, and what happened immediately before it?
Stage 3 — add business and identity context
Now enrich the queue. Ask what each affected entity means to the organisation. The same technical signal can have dramatically different priority depending on where it occurs.
Privileged identities change the calculation
An unusual sign-in involving privileged.admin@contoso.com deserves stronger scrutiny than the same signal on a low-impact test account. Privilege increases the potential consequence if the alert is genuine.
Critical assets change it too
Domain controllers, identity infrastructure, security systems, production servers and sensitive workloads should influence triage. The queue is not merely a list of detections; it is a list of possible consequences.
Stage 4 — score the six candidate alerts
You do not need a complicated mathematical formula. A simple analyst comparison forces you to articulate why one alert should move ahead of another.
| Alert | Initial severity | Context discovered | SOC priority |
|---|---|---|---|
| Suspicious PowerShell — Finance-LT-044 | High | Interactive execution; investigation required. | High |
| Repeated MFA failures — marketing.user | High | No successful sign-in yet; possible MFA fatigue attempt. | High |
| Unusual sign-in — privileged.admin | Medium | Privileged identity; successful authentication. | Critical |
| Suspicious connection — DC-01 | Low | Critical identity infrastructure; unexplained outbound traffic. | Critical |
| Malware prevented — HR-LT-118 | Medium | Defender reports prevention; no additional evidence yet. | Medium |
| Impossible travel — test.account | High | Known test identity used by the security team. | Low after validation |
There can be more than one urgent alert
Here, both the privileged sign-in and domain-controller connection deserve immediate attention. In a larger SOC, they may be assigned simultaneously. If you are the only available analyst, choose the event with the greatest combination of potential impact and evidence of active compromise, then document why.
Priority must be explainable
“It looked bad” is not a triage rationale. “Low-severity network activity was prioritised because it originated from a domain controller and the destination was unexplained” is a decision another analyst can understand and defend.
Stage 5 — make the first investigation decision
Agent Foskett selects the DC-01 suspicious network connection for immediate investigation. Not because the alert engine called it the most severe — it did not — but because compromise of a domain controller could affect authentication and the wider environment, and the unexplained outbound connection may represent active command-and-control or another significant security event.
Agent Foskett's five-minute triage workflow
Your triage evidence board
| Evidence | What it changes | Typical effect on priority |
|---|---|---|
| Privileged or highly sensitive identity | Raises the potential consequence of successful compromise. | Increase |
| Domain controller or critical production asset | Raises possible organisational impact. | Increase significantly |
| Multiple related alerts on one entity | May reveal a developing attack chain. | Increase / group |
| Successful authentication after repeated MFA attempts | Changes an attempted attack into possible account compromise. | Increase significantly |
| Security control confirms activity was prevented | May reduce immediate urgency if no related activity succeeded. | Potential decrease |
| Known approved test activity | Can explain the detection after validation. | Decrease / close appropriately |
| Severity alone | Provides useful vendor context but not complete organisational priority. | Never use alone |
Write the triage decision like an analyst
Example: The alert queue contained 47 detections across identity, endpoint and network activity. Initial triage considered vendor severity together with affected entity, privilege, asset criticality, containment status and available supporting evidence. A low-severity suspicious network connection from DC-01 was elevated for immediate investigation because the affected device is critical identity infrastructure and the outbound destination had not yet been explained. Higher-severity alerts remained queued or were assigned based on their own context. Alert severity informed the decision but was not used as the sole measure of operational priority.
Lesson 1 key takeaways
- Scan the whole alert queue before opening the first alert.
- Severity and SOC priority are related, but they are not the same thing.
- Add asset value and identity privilege before deciding urgency.
- Successful activity usually matters more than failed activity, but context still decides.
- A prevented threat may be lower urgency, but still requires validation for earlier or related activity.
- Multiple alerts affecting the same entity may represent one incident.
- A low-severity alert on critical infrastructure can outrank a high-severity alert on a low-value asset.
- Do not dismiss an alert as testing or expected behaviour until that explanation is validated.
- Your triage decision should be explainable to the next analyst.
- The analyst's job is not to chase red icons. It is to identify risk from evidence and context.
Module 1 — inside the SOC
You have chosen what to investigate first. The next problem is equally important: understanding exactly what the alert is claiming before you start building a theory around it.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 1: Inside the SOC: Thinking Like an Analyst
How to triage a SOC alert queue
Lesson 1 of the Agent Foskett SOC Analyst Academy teaches security operations analysts how to prioritise alerts using severity, confidence, asset criticality, identity privilege, attack context and supporting evidence.
SOC analyst alert prioritisation training
Learn why alert severity alone is not enough, how critical assets and privileged identities change operational priority, and how to make explainable evidence-based triage decisions across Microsoft security operations.
