Alert triage is the core skill of security operations: taking a raw security alert and deciding, quickly and defensibly, whether it represents a real threat and what should happen next. It is the medical metaphor on purpose — like an emergency department, a SOC always has more incoming work than capacity, and the job is to sort by severity and urgency so attention goes where it matters.
What an alert actually is
An alert is not proof of an attack. It is the output of a detection rule — a piece of logic running over a company's logs that flags patterns someone decided were worth a human look. "More than 500 failed logons from one IP in ten minutes." "An Office application spawned PowerShell." "Outbound data volume exceeded 50 GB overnight."
Rules are deliberately written to over-trigger, because a rule that misses a real attack (a false negative) is far more expensive than one that flags something benign. The consequence: most alerts in most queues are false positives — real activity that tripped a rule but turns out to be an administrator, a backup job, a scanner, or a misconfigured application.
The triage decision
Every triage ends in two decisions:
- The verdict — is this a true positive (real, malicious or unauthorised activity) or a false positive (benign activity that matched the rule)?
- The action — escalate to a senior analyst, close it but keep monitoring, or close it as fully resolved.
These are independent decisions. Malware that the antivirus quarantined before it ever executed is a true positive that can close as resolved. A password spray that MFA fully blocked is a true positive that might close with monitoring. Confusing "was it real?" with "does it need escalating?" is one of the most common junior mistakes.
Why speed matters: MTTR
SOCs measure mean time to respond (MTTR) — how long an alert waits between arriving and being resolved. It matters because attacker damage compounds with time: a command-and-control channel triaged in five minutes gives the attacker five minutes; triaged in five hours, five hours. Good analysts are fast not because they rush, but because they run a practised routine: check the rule, check the entities, read the evidence, corroborate, decide.
A worked example: triaging a C2 beaconing alert
Here is how the process looks on a realistic alert.
The alert: a workstation in Finance is making outbound HTTPS connections to a single external IP every 60 seconds, and has been for four hours.
Step 1 — understand what the rule saw. Beaconing detection fires on regularity. The flow records show 243 connections with an average interval of 60.02 seconds and a standard deviation of 0.31 seconds. Humans do not browse like that; software on a timer does.
Step 2 — check the entities. The source is a finance workstation, not a server that might legitimately poll an API. The destination IP belongs to a hosting provider with no relationship to any sanctioned business service.
Step 3 — read the corroborating evidence. The endpoint agent attributes the connections to rundll32.exe — a Windows system utility that has almost no legitimate reason to talk to the internet. A network signature has separately matched a known Cobalt Strike beacon profile.
Step 4 — check threat intelligence. The destination scores 9.1/10 across nine independent feeds, tagged as C2 infrastructure on a bulletproof hosting range.
Step 5 — decide. Four independent signals point the same way: machine-regular timing, an implausible source process, a signature match, and hostile infrastructure. Verdict: true positive. Action: escalate immediately — a confirmed C2 channel means the host is already compromised and needs isolation, which is beyond an L1 analyst's authority.
Total time for an experienced analyst: three to five minutes.
What good triage looks like
The same discipline that convicts that beacon clears the false positives. The counterpart example: a "port scanning" alert whose source turns out to be the security team's own vulnerability scanner, running a signed Tenable binary, inside an approved change window. Same rigour, opposite verdict — and the evidence, not the alert title, made both calls.
Good triage, in short: read the evidence before forming the verdict, corroborate across at least two independent sources, treat clean IP reputation and scary rule names with equal suspicion, and write the reasoning down so the next analyst can reconstruct it.
The only way to get good at this is repetition. SOCentre gives you a simulated queue of exactly these alerts — C2 beacons, phishing, brute force, and the false positives that waste real SOCs thousands of hours — with your verdict, action, and MTTR scored on every decision. Start on the free tier and work your first shift.