What is Alert Triage?

In a SOC, alert triage is the decision step between a detection firing and someone spending real time on it. A SIEM, EDR or firewall rule raises an alert, and the triage analyst has a few minutes to answer: did the rule fire on what it was written to catch, does the activity matter in this environment, and who has to act next. Triage ends in a verdict and a routing decision; deep forensics belongs to Tier 2 and incident response. The SOCSimulator blog's alert triage guide walks through the four stages (queue intake, evidence assessment, verdict, disposition) with a brute-force login alert taken from the queue all the way to the escalation note.

There are four possible verdicts

• A true positive means the rule fired and the activity is malicious or a clear policy violation, for example Word spawning an encoded PowerShell command on a finance laptop.
• A false positive means the rule fired on something it was never meant to catch, like a DLP rule matching a card-number pattern inside a test data file.
• A benign true positive is exactly what the rule describes and really happened, but it is authorized: the vulnerability scanner tripping a port-scan rule, or an admin running PsExec inside an approved change window. Closing a benign true positive as a false positive sends the tuning ticket to the wrong place, because the rule works; what it needs is an exclusion for that scanner or that window.
• Inconclusive is the fourth outcome: not enough evidence yet, so the alert is escalated or held for more data instead of guessed at.

Tier 1 alert triage in practice means building context around the IP, the user and the host before deciding anything.

• For the IP: internal or external, which asset or owner it maps to, its reputation and ASN in threat intelligence, and whether the geolocation fits where this user normally signs in.
• For the user: role, whether the account is privileged or a service account, recent authentication history, and any change in the last day such as a password reset or a new MFA device.
• For the host: its criticality in the CMDB, what the EDR process tree shows around the alert time, and whether other alerts hit the same machine in the same window.

Severity then comes from two axes instead of gut feel: asset criticality (a domain controller or payment server outranks a guest-wifi laptop) against confidence (one ambiguous signal versus several indicators that corroborate each other). The SLA clock runs the whole time and scales with priority, so a P1 gets minutes and a P4 gets hours.

Knowing when to escalate is most of the Tier 1 job

The usual triggers are:

• malicious code that executed rather than being blocked,
• a privileged account or crown-jewel asset in the chain,
• the same activity on more than one host,
• data leaving the network,
• or a response Tier 1 is not authorized to carry out, such as isolating a server.

Escalate as well when you cannot reach a verdict inside the time budget. A clear case with good context takes three to ten minutes, and if one alert has already taken forty, you have moved into investigation and it belongs with Tier 2. A useful escalation note says what fired, which evidence you checked, your verdict and how confident you are, the entities involved with timestamps, and the action you recommend.

Case management (Jira Service Management, ServiceNow, or the SIEM's own case module) tracks each alert's severity, owner and SLA clock. Playbooks, whether manual runbooks or SOAR automation, fix the evidence-gathering steps for common alert types, so a reported phishing email gets the same checks whoever picks it up. Teams measure triage with MTTA (mean time to acknowledge) and MTTR, and a missed SLA on a critical alert has contractual consequences for a managed SOC. Every false positive you close should also produce a tuning ticket, since rule tuning is what shrinks a noisy queue over time.