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

Lesson 12 — The Alert Was Medium — The Account Was Global Admin

The alert did not arrive with flashing red lights. It was marked Medium.

Then the analyst opened the identity details and noticed one field that changed the entire triage decision: the affected account held Global Administrator privileges.

Technical severity describes the detection. Priority must also describe what is at risk.

Reassess the Alert Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy medium severity alert involving a Global Administrator

The label said Medium

The identity context said something very different. Privileged accounts can turn apparently modest activity into a high-consequence investigation.

✓ Check identity privilege

✓ Add entity criticality

✓ Measure potential impact

✓ Re-rank the queue

Case briefing

11:26 — NEW ALERT SEVERITY MEDIUM ALERT Unusual sign-in properties ACCOUNT svc-cloudadmin@contoso.com SIGN-IN Successful SOURCE Unfamiliar IP address IDENTITY DETAIL Global Administrator QUEUE POSITION Originally below three High alerts QUESTION DOES "MEDIUM" STILL DESCRIBE THE OPERATIONAL PRIORITY?

Investigation objective

Add identity criticality, privilege and business consequence to technical severity so the alert is prioritised according to real risk.

Investigator's rule

Severity belongs to the alert. Criticality belongs to the entity. Triage requires both.

Stage 1 — understand what the severity label does not tell you

The alert can tell you	The alert may not tell you
How the detection logic scored the activity	How important the affected account is to your organisation
Which behaviour triggered the rule	What systems the identity can administer
Whether the product classified it Low, Medium or High	Whether compromise could affect the entire tenant
Some supporting entities and evidence	Your organisation's business-specific risk context

Medium is not a verdict

The severity label can be completely reasonable for the behaviour detected while still understating the urgency created by the affected identity.

Privilege changes consequence

A successful suspicious sign-in to a standard account and the same sign-in pattern to a highly privileged administrator do not carry the same potential impact.

Stage 2 — add identity context

ALERT CONTEXT Medium severity Unusual sign-in Successful authentication + ENTITY CONTEXT Global Administrator Tenant-wide administrative capability Access to sensitive configuration Potential to create or modify privileged access = TRIAGE PRIORITY RISES

Ask what the identity can do

During triage, the important question is not simply “Who is the user?” It is “What could this identity do if the activity is malicious?”

Business context matters too

Privilege is one form of criticality. Executives, finance users, service identities and accounts controlling sensitive systems can also require elevated priority.

Stage 3 — validate privileged role context

Before escalating solely because of a label in the case notes, confirm the identity's privileged role context using the authoritative identity information available to your investigation.

Do not assume an account is privileged because its name contains “admin”. Validate the role or privilege evidence.

Names can mislead

svc-cloudadmin sounds important, but naming conventions are not evidence. A normal-looking account can hold powerful roles, while an “admin” account may not.

Current privilege is what matters

Determine whether the identity actually has privileged access relevant to the incident, and record how that was established.

Stage 4 — use KQL to inspect the sign-in pattern

Once the account's criticality is understood, use a focused query to establish whether the suspicious sign-in is isolated or surrounded by additional authentication activity.

12345 678910 1112131415

let TargetUser = "svc-cloudadmin@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          ResultType,
          ResultDescription
| order by TimeGenerated desc

Look around the alert

A single successful sign-in may be preceded by failures, followed by access to additional applications, or repeated from the same source. The surrounding timeline can change confidence.

Do not let privilege replace evidence

Global Administrator status raises consequence. It does not prove the sign-in was malicious. Continue validating the actual activity.

Stage 5 — compare it with the High alerts already in the queue

Alert	Severity	Context	Triage view
Malware blocked on kiosk	High	Prevented; low-value device; no follow-on evidence	Important, but can wait briefly
Failed password spray	High	Attempts unsuccessful; standard accounts	Investigate, but no confirmed access yet
Suspicious attachment blocked	High	Message quarantined before delivery	Control appears effective
Unusual Global Admin sign-in	Medium	Successful; unfamiliar source; privileged identity	Move to the top

Priority can outrank severity

You are not changing the vendor's severity label. You are making an operational decision based on information the label cannot fully represent.

Explain the re-prioritisation

Document why the Medium alert moved ahead of the High alerts: successful authentication plus verified privileged access created greater potential consequence.

Stage 6 — build a simple entity-criticality check

WHEN TRIAGING AN ALERT: WHAT HAPPENED? ↓ HOW SEVERE IS THE DETECTION? ↓ WHICH ENTITY IS INVOLVED? ↓ IS THE ENTITY PRIVILEGED OR CRITICAL? ↓ WHAT COULD THE ENTITY ACCESS OR CHANGE? ↓ WAS THE ACTIVITY SUCCESSFUL? ↓ WHAT IS THE CONSEQUENCE IF THIS IS REAL? ↓ RE-RANK THE QUEUE IF REQUIRED

The alert was Medium. The potential impact was not.

Stage 7 — write the triage finding

TRIAGE FINDING The alert was initially classified Medium. The affected identity was verified as holding Global Administrator privileges. The sign-in was successful and originated from an unfamiliar source. Three existing High alerts involved activity that was blocked or unsuccessful. DECISION Re-prioritise the Medium alert for immediate investigation because verified entity criticality and successful access increase potential impact. IMPORTANT Privilege increases consequence. It does not independently prove compromise.

Lesson 12 key takeaways

Technical severity and operational priority are not the same thing.
Always identify the user, device, workload or service affected by an alert.
Verify privileged access rather than inferring it from an account name.
Global Administrator involvement can dramatically increase potential consequence.
Successful activity often deserves more attention than activity that was blocked or failed.
Business-critical identities can matter even when they are not technically privileged.
Use focused KQL to understand the authentication activity surrounding the alert.
Privilege raises risk but does not prove malicious activity.
Re-rank the queue when entity context changes the potential impact.
Document why an alert was promoted or deprioritised.

Module 2 — alert triage

You have added entity criticality to the triage decision. Next, Agent Foskett examines another common trap: treating a suspicious-looking indicator as proof before checking where it came from.

Next: Lesson 13 — The IP Address Looked Malicious — Until We Checked the Context

Continue your SOC Analyst training

Module 2 focuses on alert triage, prioritisation, entity criticality and separating evidence from assumptions.

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

Add identity, asset and business criticality to technical alert severity.

← Previous lesson

Lesson 11 — The Same Alert Fired on 30 Devices Distinguish one widespread incident from repeated low-value alerts.

✅ Current lesson

Lesson 12 — The Alert Was Medium — The Account Was Global Admin Add entity criticality and business context to technical severity.

Next lesson →

Lesson 13 — The IP Address Looked Malicious — Until We Checked the Context Validate indicators before treating reputation as proof.

SOC alert severity and privileged identity criticality

Lesson 12 of the Agent Foskett SOC Analyst Academy teaches analysts why a medium-severity security alert involving a Global Administrator can require higher operational priority than technically higher-severity alerts.

Global Administrator security alert investigation with KQL

Learn how to combine Microsoft security alert severity with identity privilege, business context, successful authentication evidence and KQL sign-in analysis to make defensible SOC triage decisions.