Intelligence requirements are the specific questions a security team wants answered to guide collection and analysis. They define what information is needed about threats, actors, assets, or campaigns, and prevent unfocused reporting. Good requirements are prioritised, measurable, and tied to decisions such as blocking, hunting, or hardening.
How intelligence requirements shape the intelligence cycle
Intelligence requirements turn a broad collection effort into a directed one. They define the questions the team must answer, keep analysts focused on decision-relevant gaps, and stop reporting from drifting into interesting but unusable detail.
Well-formed requirements usually connect to an owner, a decision, and a time horizon. That is what makes them operational rather than academic: they are written to support specific actions, not to create a general library of threat facts.
What makes a requirement effective
Strong requirements are specific enough to be answered, but not so narrow that they miss the pattern around the issue. They often refer to actors, campaigns, techniques, assets, or business processes, and they should be phrased so analysts can tell whether the question has been answered.
Priority matters as much as wording. A security team cannot pursue every possible question at once, so requirements should distinguish between strategic questions that guide planning and tactical questions that drive immediate hunting or blocking.
How intelligence requirements reduce noise
Requirements act as a filter for collection, triage, and analysis. Without them, teams can end up consuming feeds, reports, and telemetry that do not support any real decision, which creates volume without clarity.
When requirements are maintained properly, they also improve handoff between stakeholders. Security operations, threat hunting, incident response, and risk teams can all work from the same set of agreed questions, even if they use different sources and methods to answer them.
For organisations building a threat intelligence programme, a useful reference point is the Threat Intelligence Guide, which places intelligence requirements in the broader CTI lifecycle.
From requirements to action
Intelligence requirements should lead to a measurable output, such as a hunt hypothesis, a block decision, a hardening change, or an alerting rule. If a requirement cannot influence a decision, it is usually too vague, too broad, or not owned by the right team.
They also need maintenance. Threat models change, business priorities shift, and prior gaps get closed, so requirements should be reviewed and retired when they no longer drive action. A good requirement set evolves with the organisation rather than remaining fixed as a static document.
When teams are buying or structuring a capability around those questions, the Threat Intelligence Platform Buyer’s Guide is useful because it frames requirements as a practical evaluation and operating concern, not just a planning exercise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Enterprise Matrix | CTI requirements are often written to hunt specific adversary tactics and techniques. |
| Recommendation — Map priority questions to relevant ATT&CK techniques and drive detections from those gaps. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Intelligence requirements often define what should be monitored and investigated. |
| Recommendation — Use monitored threat questions to tune detection coverage and investigation triggers. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Requirements help define what threat and risk information the organisation needs to identify. |
| ID.RA-02 — Cyber threat intelligence is received from information-sharing forums and sources | The term directly concerns what intelligence the team needs to collect and analyse. | |
| Recommendation — Define intelligence questions that expose relevant risks and document the resulting gaps. Establish intake questions that align shared threat intelligence to organisational decisions. | ||
Practitioner Guidance
Governance implication: Treat intelligence requirements as owned decision support, not as a generic backlog of questions. Each requirement should have a clear consumer, a priority, and an expected decision outcome, otherwise it tends to accumulate without driving analysis.
What to watch for: Requirements that are too broad, duplicated across teams, or written in abstract language usually produce unfocused reporting. A strong requirement is one that analysts can actually test against the available collection and mark complete when answered.
Practitioner takeaway: The best requirements are specific enough to guide collection, but decision-linked enough to prove their value once answered.