Triage alerts like a SOC analyst: check the rule, the data and the context, classify, prioritise and write a clear note.
Why it matters
A busy SOC can receive hundreds or thousands of alerts a day. Most are harmless. Triage is the skill of deciding, quickly and consistently, which alerts need action now, which can wait, and which can be closed. Good triage stops real incidents from hiding in the noise; bad triage either misses them or burns out the team by escalating everything.
The triage questions
For each alert, a tier 1 analyst works through roughly the same questions, usually in 5 to 15 minutes:
- What does the rule detect? Read the rule logic, not just the title.
- Is the data right? Is the log complete, is the time correct, does the host or user exist?
- What is the context? Who is the user, what is the host (a laptop, a domain controller, a test VM?), is there a change ticket or a known scan?
- Is it malicious, suspicious or benign? Check reputation of IPs, domains and file hashes, and look at activity just before and after.
- What is the impact if it is real? A crown-jewel server or an admin account raises the stakes.
- What next? Close with a reason, escalate to tier 2 or IR, or contain now if the playbook allows.
Classifying the outcome
| Outcome | Meaning | Action |
|---|---|---|
| True positive | Malicious activity confirmed | Escalate or contain per playbook |
| Benign true positive | Rule worked, activity is authorised | Close; consider tuning or an exception |
| False positive | Rule matched something it should not | Close; send a tuning request |
| Needs more information | Cannot decide yet | Gather data, ask the user or owner, escalate if time runs out |
Prioritising: severity times asset value
Most SOCs set priority from two things: how bad the activity is and how important the target is. A simple matrix:
| Low-value asset (test VM) | Normal asset (staff laptop) | Critical asset (domain controller, payroll, admin account) | |
|---|---|---|---|
| Low severity | P4 | P4 | P3 |
| Medium severity | P4 | P3 | P2 |
| High severity | P3 | P2 | P1 |
P1 means work it now and page the on-call lead; P4 can wait in the queue. Teams write their own version into their playbooks.
Enrichment: gathering context fast
- Asset inventory or CMDB: what the host is and who owns it.
- Identity directory: the user's role, manager, usual location and recent password or MFA changes.
- Threat intelligence: reputation of IPs, domains and hashes. Free sources include VirusTotal and AbuseIPDB. Never upload a company's confidential files to public services; search by hash instead.
- SIEM pivots: everything the same user, host or IP did in the hour around the alert.
Many SOCs automate this with SOAR (security orchestration, automation and response) playbooks that attach the context to the alert before a human sees it.
Worked example: two alerts, two outcomes
Alert A: "Possible brute force: 120 failed SSH logins on scan-lab01." The host is a lab VM owned by the security team, the source IP is the internal vulnerability scanner, and a change ticket shows a scheduled credentialed scan. Outcome: benign true positive, P4, close with the ticket reference and suggest an exception for the scanner IP on that host.
Alert B: "PowerShell launched by WINWORD.EXE on fin-lt-07." The laptop belongs to an accounts payable clerk. The command line contains -EncodedCommand and a long base64 string. One minute later the laptop made its first-ever connection to a newly registered domain. Outcome: true positive (likely a malicious macro), high severity on a finance user's machine: P2. Following the playbook, the analyst isolates the laptop with the EDR tool, escalates to IR with the evidence, and notes the domain so others can be checked.
Writing it down
Every triaged alert needs a short note that someone else can follow:
Alert: PowerShell spawned by WINWORD.EXE on fin-lt-07 (user m.okafor)
Time (UTC): 2026-10-23 13:02:41
Findings: encoded PowerShell; outbound connection 13:03 to invoice-docs-check[.]com (registered 3 days ago, no reputation)
Classification: True positive (likely malicious macro)
Priority: P2 (high severity, finance user)
Actions: host isolated via EDR 13:11; escalated to IR (ticket IR-2291); domain added to watchlist
Notice the defanged domain ([.]): it stops anyone accidentally clicking a malicious link in a ticket.
Common mistakes
- Closing because "it is always a false positive". Attackers rely on alert fatigue. Check each alert, and fix noisy rules instead of ignoring them.
- Escalating with no context. "Alert fired, please check" wastes tier 2 time. Pass on what you found and why it matters.
- Taking actions outside the playbook. Containment can disrupt the business; know what you are authorised to do.
- No notes. Undocumented triage cannot be reviewed or improved.
Quick recap
- Triage asks what the rule detects, whether the data is right, what the context is, whether it is malicious, what the impact is and what to do next.
- Classify as true positive, benign true positive, false positive or needs more information.
- Prioritise by severity and asset value, enrich with inventory, identity, intelligence and SIEM pivots, and write a short, defanged note.
Try it
Open the Do tab and triage five sample alerts.