Two people cannot read every alert. A feed that publishes a hundred indicators a day across three sources will bury a security team of two by Tuesday, and the buried items are usually the ones that matter. The fix is not a better feed or a longer shift. It is a workflow: a repeatable path that takes raw feed items, strips the noise, ranks what is left against the environment you actually run, and hands the survivors to a human with a deadline attached.

Tier your sources before you tune anything

Not every feed deserves the same attention, and pretending otherwise is how triage collapses. Sort your sources into three tiers and treat them differently on the way in.

• Tier 1 — vendor and CERT advisory feeds. Slower, lower volume, high relevance. These get read the day they arrive, even if the item is not actionable yet.
• Tier 2 — sector and ISAC-style feeds. Relevant to your industry, medium volume. These go through scoring like everything else.
• Tier 3 — bulk indicator feeds. High volume, low context. These should never reach a human inbox unfiltered. They exist to feed enrichment and hunting queries, not to generate tickets.

Write the tier next to each source in the runbook. When someone asks why a feed is quiet, the tier explains it.

Stage everything in one place, but only one

Pick a single landing zone: your SIEM, a threat intel platform, or even a dedicated mailbox with a parser if that is what you have. The rule is that items arrive in one queue with a consistent shape, because two analysts working from two inboxes will duplicate work without knowing it. Each item needs a timestamp, source, indicator type, indicator value, and the raw text of the report. If you cannot extract an indicator, keep the report as a document item so it is still searchable during an incident.

Deduplicate before you score

Most feed volume is repetition. The same malicious IP appears in four reports, written four ways, with different defanging. Normalize first, then match.

1. Undo defanging: hxxp becomes http, [.] becomes a dot, example[dot]com becomes a domain.
2. Lowercase domain names and drop trailing dots. Normalize IPv6 notation and strip single-host masks like /32 and /128.
3. Decide one canonical form per indicator type. Domain-level indicators lose their paths; full URLs get hashed and stored separately.
4. Key the record on type plus value, not on the feed that delivered it.
5. Append new sources to the existing record instead of creating a new one. Three feeds reporting the same IP is a confidence signal and should raise its score, not triple the queue.

Then build the other half of deduplication: a known-good list. Your own domains, your mail gateway, your vulnerability scanner, the CDNs and cloud ranges you depend on. Keep it short and review it monthly. Whitelisting an entire provider range because one alert was annoying is how you miss the next campaign.

Score against your own environment

A feed's severity rating describes the campaign, not your risk. Score in four parts and add them up.

• Feed severity (0–3): what the source claims.
• Confidence (0–3): how many independent sources carry it, and how recently it was seen in the wild.
• Asset match (0–3): do you run the product, vendor, or platform named in the report?
• Exposure (0–5): is the affected asset internet-facing, is it holding credentials or customer data, does it sit on the path to something more valuable?

Set two thresholds and stick to them. Low scores get archived with the record intact so a later search can find them. Mid-range items go to a weekly review pile. High scores open a ticket immediately. The exact numbers matter less than applying the same numbers every time — your thresholds are a decision you already made, which is the whole point on a bad day.

If you cannot name the asset an item touches, it is not an incident yet. It is a lead.

Escalate with a two-person rule

With two analysts, escalation has to be cheap and unambiguous. Name who is on triage each week and who holds the ticket queue. Escalate immediately, without waiting for the next shift, when any of these are true:

• Credentials, session tokens, or keys belonging to your organisation appear in the item.
• An internet-facing asset is named and the exploitation is described as active.
• The indicator matches traffic already seen in your logs.
• The report names your organisation, your customers, or a supplier you depend on.

Everything else follows the queue. Define acknowledgement windows that fit your coverage — thirty minutes for the top tier during working hours, same day for the middle, weekly for the rest — and write them where both of you can see them. One practical rule that saves arguments: whoever is on triage owns the call for that shift. Disagreements go to the weekly review, not into the ticket thread at 11pm.

Close the loop every week

Block thirty minutes, same slot every week. Open the archive, the ticket queue, and the mid-range pile. Ask three questions: which items turned out to be real, which feeds produced nothing usable, and which rule caused the most wasted effort. Then make one change — retire a source, loosen a filter, add a detection. One change per week compounds; a full process rewrite every quarter does not survive contact with a busy Monday.

Write it down and keep it short

The workflow only works if either of you can run it alone. Put the tiers, thresholds, escalation triggers, and response windows on a single page, with the query or script that produces the queue next to it. Review that page when something goes wrong, and note what you changed. A one-page runbook that both analysts actually follow will outperform a beautiful process document that nobody opens, and it means that when one of you is on holiday, triage still happens.

Photo: AMORIE SAM / Pexels