Every threat intelligence feed promises relevance. Subscribe to half a dozen and you get volume instead. A mid-size security team can receive thousands of indicator matches a day, and the real failure is not a missed feed — it is that analysts quietly stop reading them.

Triage is what prevents that. It is not about reading faster; it is about deciding in a few minutes whether an alert deserves attention now, later, or never. The workflow below rests on three inputs most teams already have: asset criticality, context, and confidence. Put them in the right order and the noise drops sharply without suppressing anything real.

The order matters more than the individual steps. Most teams triage in the wrong sequence — they start with the indicator, decide whether it looks scary, and only then ask what it hit. Flip that and the same alert queue becomes dramatically more manageable.

Start With the Asset, Not the Alert

An alert is only as serious as the thing it lands on. A credential-stuffing attempt against a lab VM and the same attempt against your identity provider are not the same event, even when the indicator is identical. So look up the asset first, not the indicator.

This feels backwards to analysts who came up through malware analysis, where the artifact is the puzzle. But in a queue-processing context, the asset is the filter. A thousand alerts against Tier 3 hardware is an afternoon of boredom. One alert against a domain controller is a page. Knowing that before you read the indicator saves you from reading nine hundred and ninety-nine of them.

If you don't have criticality tiers yet, build a rough one today. Four levels are enough:

• Tier 0 — domain controllers, identity providers, VPN and remote access gateways, backup infrastructure, build and code-signing systems.
• Tier 1 — internal applications that carry revenue, customer data, or finance workflows.
• Tier 2 — ordinary user endpoints and standard servers.
• Tier 3 — test, lab, and soon-to-be-retired systems.

Tag these where your detection stack can read the tag — asset inventory, CMDB, or EDR groups. If tagging everything is unrealistic, tag Tier 0 and Tier 1 by hand this week. That alone caps the damage from false positives: an alert on Tier 3 hardware should need strong evidence before it consumes anyone's afternoon.

An indicator without an asset is trivia. An asset without an indicator is inventory. Triage lives where the two meet.

Add Context: Relevance Beats Reputation

Intelligence tells you something is dangerous somewhere. Context tells you whether it is dangerous here. Ask a fixed set of questions every time:

• Does this indicator appear elsewhere in our telemetry, and in which direction?
• Does the asset run the software, protocol, or service the indicator relates to?
• Is the indicator specific (a file hash, an exact hostname) or broad (a shared hosting range, a whole cloud region)?
• What would normal activity for this host look like at this hour?
• If the alert is true, what breaks or leaks?

That last question does more work than any scoring model. An alert whose worst case is a noisy laptop gets a ticket. An alert whose worst case is an attacker holding a session on your VPN gateway gets a phone call.

A concrete example: your feed flags an IP address associated with a known scanning campaign. On a Tier 2 endpoint behind a firewall that only makes outbound connections, a single blocked inbound packet is expected background noise — the internet scans everything, constantly. The same IP appearing in a successful authentication log on your VPN gateway is a different story, and the alert text will look almost identical in both cases. Only the asset and the direction of the connection tell them apart.

Be careful with geography. "Unusual country" was a weak signal even before remote work and cloud egress scattered traffic across the map. Use it as one input, never as the deciding one.

Score Confidence Separately From Severity

Two questions get tangled constantly: how bad would this be, and how likely is it to be true? Answer them in separate columns. Severity comes from the asset tier and how far along the attack chain the observed activity sits. Confidence comes from the evidence itself.

Mixing them produces the classic triage error of treating a high-severity, low-confidence alert the same as a high-severity, high-confidence one — and then burning a shift on it. Keep the axes apart and the decision becomes mechanical.

A confidence scale you can defend

• 1 — single low-quality source, no corroboration, an indicator category known for noise: scanners, sinkholes, shared infrastructure.
• 2 — credible source but a broad or aging indicator, or one that matches infrastructure you can't attribute to a specific actor.
• 3 — reputable source with a specific indicator (hash, exact domain) and at least one match in your own telemetry.
• 4 — multiple independent sources agree, the indicator is specific, and the observed behavior on the host is consistent with what the intelligence describes.
• 5 — corroborated intelligence plus corroborating local evidence: the process tree, the network connection, and the indicator all line up.

Combining the two axes

• High severity, high confidence — escalate immediately. Wake someone. Preserve evidence before you remediate.
• High severity, low confidence — investigate now with a time box, usually thirty to sixty minutes. If it stays low-confidence, park it with a note and a scheduled recheck.
• Low severity, high confidence — ticket it, contain automatically if your tooling allows, and review in the next working block.
• Low severity, low confidence — close it with a reason code. This is the bucket that should be swallowing most of your queue, and there is no shame in it.

Put Speed Limits on Each Bucket

A triage scheme without service targets drifts back into "someone will get to it." Write down how fast each combination should be handled, and hold the line even when the queue is ugly:

1. Escalate within fifteen minutes for Tier 0 plus confidence 4 or 5.
2. Investigate the same shift for Tier 1 plus confidence 3 or higher.
3. Ticket for the next business day for Tier 2 at any confidence.
4. Auto-close with a reason code for Tier 3 at confidence 1 or 2, keeping the record for retrospection.

The auto-close rule is the one teams resist, and it is the one that buys back the most hours. Closing is not deleting — the alert stays searchable, and if the same indicator later shows up on Tier 0, the prior closures become useful history rather than wasted work.

Feed the Results Back Into Detection

Triage produces data, not just decisions. Every alert you close as a false positive is a hint about a rule that needs tuning. Capture the reason in a consistent taxonomy — expected administrative activity, known scanner, stale indicator, misconfigured internal tool — and review the counts monthly.

If a single rule produces more than a few closures of the same reason, fix the rule instead of training analysts to ignore it. A detection that nobody acts on is worse than no detection at all, because it teaches the team that alerts don't matter.

When to Break the Rules

Two situations justify ignoring the workflow entirely. The first is an active incident: once you know something is happening, triage discipline becomes containment discipline. The second is a credible, targeted campaign against your sector, where intelligence specific to your industry temporarily raises the baseline confidence of everything related to it.

Everything else follows the order: asset, then context, then confidence separated from severity. It won't make the feeds smaller, but it makes the queue survivable — and a queue that gets read every day catches more than one that gets abandoned after a month.

Photo: AlphaTradeZone / Pexels