At a glance
- Problem
- More alerts than any team can investigate, most of them noise
- Goal
- A fast, repeatable order of work that surfaces the real one early
- Score by
- Impact if true, times likelihood it is true, times reachability in your estate
- Enemy
- Alert fatigue: the queue that trains analysts to close without looking
- Lever
- Enrichment and context, applied before a human is spent
- Standard
- NIST SP 800-61 incident handling; risk = likelihood × impact
Triage is a scarcity problem
Most detection programmes do not fail for lack of alerts; they fail for lack of a defensible way to order them. Analyst hours are the scarce resource, and prioritisation is how you spend them. The borrowed word is right: triage assumes you cannot treat everyone at once and forces a rule for who is seen first. The alternative, working the queue top to bottom or newest-first, guarantees that the one alert that mattered is investigated only by luck.
The goal of triage is not to investigate everything. It is to make sure the few alerts that deserve a human get one before the window to act on them closes, and that the rest are dispositioned honestly rather than ignored.
Severity is not priority
The most common mistake is treating a tool's severity label as the priority order. Severity is a property of the rule, how bad this class of event would be in the abstract. Priority is a property of this alert, in your environment, right now. A “critical” alert on a decommissioned test box you can prove is offline outranks nothing; a “medium” on the domain controller that holds your crown jewels may be the most important thing in the queue. Sorting by raw severity is how teams spend their best hours on their least important events.
The three factors that set priority
Priority is a product, not a sum, of three questions. If any one is near zero, the priority is low regardless of the others:
- Impact if true. If this alert is a real incident, how bad is it? A crown-jewel asset, a privileged identity, or regulated data raises this sharply.
- Likelihood it is true. How confident are we that this is a genuine detection and not noise? A validated, corroborated indicator scores far higher than an unverified one.
- Reachability in your estate. Does this threat plausibly apply here at all? An exploit for software you do not run, or an attack on a control you have already closed, is real and irrelevant.
Priority = impact × likelihood × reachability. Because it multiplies, a huge impact with near-zero reachability is still low priority, and a modest impact that is highly likely and directly reachable can outrank it. The factors that most teams skip are the last two, exactly the ones enrichment can answer.
A working triage rubric
| Band | Looks like | Action |
|---|---|---|
| P1 · Now | High impact, likely true, reachable: crown-jewel asset or privileged identity, corroborated indicator | Investigate immediately; consider incident |
| P2 · Soon | Two of three factors high; real but not on a critical asset | Work within the shift |
| P3 · Queue | One factor high; plausible but unconfirmed or low-value | Batch; revisit if new signal arrives |
| P4 · Close | Validated benign, or true but unreachable | Disposition with a reason; feed the tuning loop |
The rubric matters less than having one. A written, shared band definition makes triage consistent across analysts and shifts, and turns “why did you close that?” from an argument into a lookup.
Enrichment before a human
The highest-leverage move in triage is to answer the likelihood and reachability questions automatically, before an analyst opens the alert. Attaching asset criticality, identity context, and a validated verdict on the indicators turns a bare alert into a scored one. An alert that arrives already annotated with “indicator corroborated by three independent sources, on a Tier-0 asset” sorts itself; the analyst spends their time deciding, not gathering. Validation, covered in How to validate threat intelligence, is the input that makes the likelihood factor real rather than a guess.
Alert fatigue is a security risk
A queue full of noise does not just waste time; it actively degrades judgement. When almost every alert is benign, analysts learn, correctly on the base rates, that the next one probably is too, and start closing without looking. That habit is where real incidents die. Alert fatigue is therefore not a morale problem to be managed but a detection failure to be fixed, and the fix is upstream: fewer, better alerts, which is the subject of How to reduce false positives.
The dangerous state is not a big queue; it is a big queue that is almost all noise. That is the condition under which a well-run SOC quietly stops reading, and the one genuine alert of the month closes in four seconds with everything else.
The cost of getting the order wrong
Mis-prioritisation has an asymmetric cost. Spending an hour on a P3 that turns out benign is a small, recoverable waste. Leaving a real P1 in the queue while you work lower bands is how a contained intrusion becomes a breach. The whole point of a disciplined order of work is to bias the mistakes toward the cheap kind, over-investigating the occasional false alarm, rather than the expensive kind, missing the real one because it did not shout loudly enough.
Faster verdicts, better order
Much of triage time is spent establishing whether the indicators in an alert are actually bad, the likelihood factor, by hand. A correlation platform collapses that: paste the indicator, get a verdict that leads with the answer and carries its evidence, and feed that straight into the priority score. Forensia is built for exactly this decision, turning an unfamiliar indicator into an escalate, block, monitor, or close call with the supporting evidence and the explicit coverage limits, so the order of your queue rests on something firmer than a severity label.
Key takeaway
Prioritisation is triage under scarcity, and severity is not priority. Score each alert by impact if true, times likelihood it is true, times reachability in your estate, and because it multiplies, the factors most teams ignore, likelihood and reachability, are the ones that decide the order.
Answer those two with enrichment before a human is spent, keep a written rubric so the order is consistent, and treat alert fatigue as the detection failure it is. The measure of good triage is simple: the real one gets seen while there is still time to act.
References & further reading
- NIST, SP 800-61: Computer Security Incident Handling Guide, on prioritising and handling incidents.
- MITRE, ATT&CK, for reasoning about the impact and stage of an alerted technique.
- FIRST, CVSS, an example of the severity-versus-environmental-priority distinction.
- SANS, reading room papers on SOC triage and alert fatigue.
- OverWatch Labs, How to reduce false positives and How to validate threat intelligence.