Writing Intelligence Requirements Before Buying Feeds

Most intelligence programmes start with a purchase and end with a subscription nobody reads. The order is backwards: requirements first, collection second, and a decision that the intelligence is supposed to change at the end of the chain.
An intelligence requirement is not a topic list. It is a question specific enough that an answer would change a decision, with an owner and a deadline attached. "What is happening in our sector" is not a requirement. "Which of our internet-facing products has an exploit being used in the wild, and what should we do this week" is.

Build from decisions, not from feeds

Start with the decisions the organisation already makes: patch scheduling, access approvals, supplier onboarding, incident escalation, and business travel. For each, write the question that intelligence would answer, the person who would act, and the timeframe. NIST's guidance on cyber threat intelligence sharing and the OWASP threat modelling approach both push in the same direction, which is to define what the consumer needs rather than what the collector can produce.

Priority tiers and consumer mapping

Three tiers work in practice. Strategic requirements serve executives and cover sector-level risk, regulation and long-horizon exposure. Operational requirements serve security leadership and cover campaigns and actor behaviour against the organisation's sector and technology stack. Tactical requirements serve detection and response teams and cover tooling, techniques and indicators.
Mapping every requirement to a named consumer matters more than the taxonomy. Unassigned requirements become newsletters.

Evaluation criteria

Feed quality can be assessed with four questions. Does the source state its confidence and evidence? Does it distinguish observation from inference? Does it arrive fast enough to inform the decision it was written for? Does it acknowledge its collection limitations?
A feed that scores well on none of these still feels productive because volume is visible. Volume is not a measure of anything.

Running the loop

The productive cadence is quarterly. Review which requirements produced decisions, retire the ones that never could, and add the questions that incident reviews exposed. Track two numbers: the share of requirements with a recent answer, and the number of decisions that cited intelligence. If the second number is zero after two quarters, the requirements are decoration.
Frameworks such as MITRE ATT&CK help translate actor behaviour into observable techniques, which makes operational requirements testable against existing detection coverage. That translation step is what stops intelligence from being interesting and makes it actionable.

References

• NIST, Guide to Cyber Threat Information Sharing (SP 800-150): https://csrc.nist.gov/pubs/sp/800/150/final
• MITRE ATT&CK: https://attack.mitre.org/
• OWASP, Threat Modeling Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
• ENISA, Cyber Threat Landscape: https://www.enisa.europa.eu/topics/cyber-threats
• FIRST, EPSS: https://www.first.org/epss/