The 7-Step Triage Workflow

The triage workflow is the most important skill a SOC analyst develops. It’s not creative — it’s a repeatable procedure that produces consistent, documentable decisions under time pressure. The goal is not speed for its own sake; it’s accurate decisions at sustainable speed.

The 7-Step Triage Workflow

Step 1: Read the full alert

Not the headline — the full alert. Read every field. The rule name, the log source, the raw telemetry that triggered it, the enrichment that’s already attached, the severity. Most new analysts start pivoting before they’ve finished reading the alert and miss a field that would have changed their approach.

Specific things to read in the raw alert:

• Process command line — the full command, not just the process name
• Source/destination IP — both ends of the connection, not just the flagged one
• Account name — the actual UPN or samAccountName, not just “admin”
• Timestamp — the event time, not the ticket creation time (they can differ by hours)
• Parent process — what spawned the flagged process

Step 2: Known FP check

Before touching the SIEM, ask: has this exact alert been documented as a benign pattern? Most SOC platforms maintain an allowlist or “suppressed alert” table. Search it for the alert rule name + the key entity (process name, IP, user).

If it matches: close as Benign-TP, note the allowlist entry, move to the next alert. This step takes under 60 seconds and can save 15 minutes on common benign patterns.

Step 3: Enrich

Collect context across six dimensions before forming any hypothesis:

Step 4: Pivot to raw telemetry

Now go to the SIEM and look at the raw events. The alert is a summary — the telemetry is the evidence.

Common pivot sequence:

1. Expand the time window around the alert — 15 minutes before and after. What else happened on this host?
2. Check parent process — what spawned the flagged process? A malicious child process is far more concerning if the parent is winword.exe than if it’s powershell.exe (already flagged as a development tool).
3. Check network connections — did the process make any outbound connections? To what IP? On what port?
4. Check file writes — did the process drop any files? Where?
5. Check lateral connections — did the host make any SMB/RDP/WMI connections to other hosts immediately after the suspicious activity?

Each pivot either confirms, refutes, or complicates your working hypothesis.

Step 5: Form a working hypothesis

After enrichment + pivots, write a single sentence (or two) that captures your current belief about what happened:

“I believe this is a legitimate PowerShell script run by jsmith for cloud infrastructure automation — consistent with his on-call role, his history of similar activity, and the command line matching a known SRE script pattern. I assess benign-TP.”

Or:

“I believe this is a malicious PowerShell dropper executed by an attacker on FINANCE-LAPTOP-04. Evidence: PowerShell spawned from outlook.exe (T1566.001 — spearphishing), encoded command decodes to an HTTP download from 45.33.32.156 (VirusTotal: 28/72 malicious), no TIP history for this host making outbound HTTP to cloud providers. Escalating to L2.”

A hypothesis forces you to commit. Analysts who skip this step tend to write vague dispositions (“looks suspicious, passing to L2”) that give L2 nothing to work with.

Step 6: Decide

Match your hypothesis to the four dispositions:

• TP: Malicious activity confirmed. If you have containment authority, act. Otherwise, escalate with the hypothesis + evidence summary.
• Benign-TP: Activity matches the rule but is authorized. Close. Add to allowlist if it’s a recurring pattern. Flag to DE if the rule needs a targeted exclusion.
• FP: Rule fired incorrectly. Close. Tag for DE review. If you’ve seen this FP 3+ times today, escalate the tuning need — don’t just close quietly.
• Escalate: Evidence is ambiguous after multiple pivots. Write what you found and what you tried, then hand to L2.

Step 7: Document and close or escalate

Your documentation is the audit trail. It should contain:

ALERT: [Rule name + ticket ID]
ENRICHMENT: [Key facts: user role, host criticality, TIP result]
PIVOTS: [What you checked and what you found]
HYPOTHESIS: [Your explicit belief about what happened]
DISPOSITION: [TP/FP/Benign-TP/Escalate]
ATT&CK: [Technique ID if TP or escalation]
NEXT ACTION: [Who does what next]

A disposition that reads “FP, closed” is not a disposition. A disposition that reads “FP — PowerShell command is the SCCM software deployment agent run from the helpdesk account during patching window; matches known-FP pattern from 2024-03-14 allowlist entry. No investigation needed.” — that’s a disposition.