Lesson 20 — Building a Repeatable SOC Triage Workflow
A good analyst can triage an alert. A mature SOC can do it consistently.
Over the previous nine lessons, Agent Foskett has dealt with repeated alerts, privileged identities,
misleading indicators, historical context, critical servers, maintenance windows, weak-signal correlation,
queue pressure and missing evidence.
Now we turn those individual skills into one workflow that can be repeated at 8:00 AM, 2:00 PM or during the worst shift of the month.
From alert to decision
The workflow combines technical evidence, business context and analyst judgement without allowing any single field to decide the case.
The Module 2 challenge
Investigation objective
Turn the triage skills from Module 2 into a repeatable process that helps analysts decide what matters first, what evidence is missing and what action is justified.
Investigator's rule
A workflow should guide judgement, not replace it. The process creates consistency while leaving room for evidence and context to change the answer.
Stage 1 — rapid screen
The first pass is not a full investigation. It is a quick attempt to understand what the queue contains and where immediate risk may exist.
| Rapid question | Why ask it? |
|---|---|
| What happened? | Understand the behaviour behind the alert title. |
| Did it succeed? | Successful suspicious activity often changes urgency. |
| Is it still active? | Ongoing compromise may require immediate action. |
| What entities are involved? | Users, devices, IPs and workloads become investigation pivots. |
| Was it blocked or contained? | Prevention can reduce immediate exposure without removing the need to validate. |
| Is another incident already investigating it? | Prevents duplicated analyst effort. |
Severity starts the conversation
Use severity as an initial signal, but never let it become the final queue order. A Medium successful privileged sign-in can outrank a High blocked event.
Success changes urgency
Failed, blocked and quarantined events can still matter. But successful authentication, execution, persistence or data access deserves immediate attention to what happened next.
Stage 2 — add entity and business context
Criticality is not a shortcut
A critical entity increases potential impact. It does not prove that the alert is malicious. Keep confidence and impact as separate parts of the decision.
Containment depends on context too
Isolating a laptop and isolating a production server are not operationally equivalent. The response should consider both security urgency and business consequence.
Stage 3 — search for recurrence and history
History creates a baseline
Previous investigations can dramatically accelerate triage when they are documented well. They tell you what normal looked like last time.
Recurrence can increase concern
If suspicious activity returns after remediation or spreads to additional entities, repetition is not reassuring — it may indicate persistence or failed containment.
Stage 4 — validate operational context
Change tickets, maintenance windows, deployment schedules and user statements can all explain unusual activity. They must match the actual telemetry.
| Context source | Validation question |
|---|---|
| Change record | Does the time, device, implementer and action match? |
| User statement | Does telemetry support what the user says happened? |
| Known administration | Does process ancestry and command line match the expected tool? |
| Threat intelligence | Does reputation fit the event context, or is it being treated as proof? |
| Previous incident | Does today's evidence actually match the previous case? |
Stage 5 — correlate before you isolate
Correlate with evidence
Shared entities, close timing and logical attack progression strengthen correlation. Do not combine alerts merely because they appeared during the same shift.
Correlation reduces queue pressure
Grouping related alerts prevents analysts from repeatedly investigating different pieces of the same attack as though they were independent cases.
Stage 6 — use KQL to answer the next question
KQL is most useful during triage when the query is tied to a specific decision. Start narrow, answer the question, then pivot again if necessary.
let TargetDevice = "FIN-LT-044";
let StartTime = ago(2h);
DeviceProcessEvents
| where Timestamp > StartTime
| where DeviceName =~ TargetDevice
| project Timestamp,
AccountName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
Question before query
“Show me everything” is rarely the best triage query. “What launched PowerShell?” or “Did this file execute?” gives the investigation direction.
Pivot only when necessary
Once the evidence answers the question, decide whether you have enough to act. Do not keep querying simply because more telemetry exists.
Stage 7 — check whether suspicious activity is still active
let TargetDevice = "FIN-LT-044";
DeviceNetworkEvents
| where Timestamp > ago(30m)
| where DeviceName =~ TargetDevice
| summarize
ConnectionCount=count(),
LastSeen=max(Timestamp)
by InitiatingProcessFileName,
RemoteIP,
RemoteUrl
| order by LastSeen desc
Active threat raises priority
Recent suspicious execution, current network communication or expanding scope can move an incident ahead of older events where the activity has stopped.
Time is evidence
The difference between “last seen two minutes ago” and “last seen three days ago” can materially change the containment decision.
Stage 8 — identify the minimum missing evidence
Do not chase perfect certainty
The SOC needs defensible decisions, not omniscience. If the evidence supports containment, waiting to understand every attacker action can increase harm.
Preserve uncertainty honestly
If something remains unknown, say so. “Not yet established” is better investigation language than turning an assumption into a fact.
Stage 9 — choose the operational decision
| Decision | When it fits |
|---|---|
| Close | Evidence supports expected or benign activity and important uncertainties are resolved. |
| Continue | A specific evidence gap still prevents a defensible verdict. |
| Escalate | Risk, complexity, scope or uncertainty requires additional expertise or authority. |
| Contain | Credible active compromise or unacceptable ongoing risk justifies action. |
| Tune / improve detection | Repeated known behaviour is creating operational noise without useful security value. |
Stage 10 — document so the next analyst can continue
Notes are part of the investigation
If another analyst cannot understand why you made the decision, the triage process is incomplete even if the decision itself was correct.
Defensible beats impressive
A simple investigation with clear evidence and reasoning is more valuable than a complicated investigation whose conclusion cannot be traced back to facts.
The complete Agent Foskett triage workflow
Module 2 final exercise
There is no useful shortcut here. Work through the process. The goal is not to guess the verdict from the alert title. The goal is to build a decision that another analyst could review and defend.
Lesson 20 key takeaways
- A repeatable workflow creates consistency without replacing analyst judgement.
- Start with a rapid screen before committing time to deep investigation.
- Severity is an input; success, active threat, criticality and impact affect operational priority.
- Identify entities early because they become your investigation pivots.
- Use previous investigations as baselines, not inherited verdicts.
- Validate change windows and operational explanations against telemetry.
- Correlate weak signals when shared entities, time and behaviour support one incident story.
- Ask a decision-changing question before writing the next KQL query.
- Collect the minimum evidence needed for a defensible decision.
- Choose clearly between close, continue, escalate and contain.
- Document facts, reasoning, uncertainty and next actions.
- Re-rank continuously because the SOC queue changes as new evidence arrives.
Module 2 complete — Alert Triage: Deciding What Matters First
You started this module with repeated alerts and ended with a complete operational triage workflow. You can now combine severity, evidence, entity criticality, history, change context, correlation, KQL and analyst judgement into a repeatable decision process.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 2: Alert Triage — Deciding What Matters First
Repeatable SOC alert triage workflow
Lesson 20 of the Agent Foskett SOC Analyst Academy brings alert prioritisation, entity criticality, recurrence, change context, weak-signal correlation, evidence collection and operational decision-making into a repeatable SOC triage workflow.
Microsoft Defender XDR KQL for SOC triage
Learn how SOC analysts use focused Microsoft Defender XDR KQL queries, endpoint telemetry and contextual evidence to determine active threat, reduce uncertainty, prioritise incidents and make defensible close, escalate or contain decisions.
