Ask most threat intel teams what they are collecting and you will get a list of feeds. Ask what questions those feeds are meant to answer and the room goes quiet. That silence is the whole problem.

Collection without requirements is hoarding

The default failure mode of a threat intel function is to collect first and figure out relevance later. Feeds get subscribed to because they were available, indicators pile up in a platform, and analysts spend their days triaging a firehose whose purpose no one ever defined. It feels productive — the dashboards are full — but it produces almost nothing that changes a defender's behavior.

The discipline that fixes this is older than cyber: intelligence requirements. Before you collect anything, you write down the specific questions the organization needs answered. Then collection, analysis, and dissemination all serve those questions — and everything that does not serve them, you are allowed to ignore. That permission to ignore is the entire value. An intel program without requirements cannot say no to anything, so it drowns.

What a real requirement looks like

"Monitor the threat landscape" is not a requirement. It is a mission statement, and you cannot collect against it. A real intelligence requirement is specific enough that you can tell whether a given piece of information answers it. Compare:

  • Vague: "Track ransomware threats." Against this, everything is relevant, so nothing gets prioritized.
  • Real: "Which ransomware groups have, in the last ninety days, targeted mid-market healthcare providers in our region, and what initial-access techniques did they use?" Now you know exactly which sources to watch, what to extract, and when a finding is done.

The good requirement scopes the actor, the target profile that resembles you, the timeframe, and the decision it feeds. It has an owner who will actually use the answer, and it has an expiry — requirements go stale, and a list you never prune becomes the same firehose you were trying to escape.

Three tiers of requirement, three audiences

Requirements are not one list. They stratify by who consumes the answer, and conflating the tiers is why intel reports so often land wrong:

  • Strategic — for leadership and risk decisions. "Is our sector seeing a shift in attacker objectives that should change our security investment next year?" Answered in briefings, measured in quarters.
  • Operational — for the SOC and detection engineering. "What techniques are the groups targeting us actually using this month, and do our detections cover them?" Answered in detection rules and hunt hypotheses.
  • Tactical — for the tools and the responders. "What indicators tied to active campaigns against us should be blocking or alerting right now?" Answered in feeds and firewall rules, measured in hours.

Most programs write tactical requirements — indicators are easy to collect — and then wonder why leadership finds the intel useless. Leadership had strategic questions you never wrote down, so you never answered them.

The feedback loop that keeps it honest

Requirements are not set once. The cycle is: requirements drive collection, collection feeds analysis, analysis produces answers, and — critically — the consumers of those answers tell you whether they were useful, which reshapes the requirements. Skip that last step and requirements drift from reality within a quarter. The single best question an intel lead can ask a stakeholder is: "Of the last month of reporting, what actually changed a decision you made?" The honest answer is usually humbling, and it is the most valuable input you will get.

Where to start

If your intel program grew organically around feeds, run the exercise backwards. Sit down with the SOC lead, the CISO, and whoever owns risk, and ask each: "What do you wish you knew about threats that you currently do not?" Write the answers as specific, scoped, owned questions. That list — usually shorter than people expect, often under fifteen items — becomes your collection plan. Everything you are collecting that does not serve it is a candidate to cut, and cutting it is how you win back the analyst hours to actually answer the questions that matter.

Intelligence is not the data. It is the answer to a question someone needed answered. Write the questions first.

Everything downstream — the feeds, the platform, the analyst headcount — is justified only to the extent it answers a question you wrote down on purpose. Start with the questions, and the rest of the program finally has something to be accountable to.