A Specific Intelligence Requirement is a narrowly framed intelligence question that defines exactly what information is needed for a decision or task. It is used in intelligence planning to turn broad objectives into targeted collection and analysis requirements, so analysts can focus collection on named entities, behaviours, locations, or time periods.
What Makes a Specific Intelligence Requirement Distinct
A specific intelligence requirement narrows an intelligence problem into a decision-ready question. It turns a broad need into a precise focus on the entity, behaviour, location, event, or time window that actually matters, so collection is targeted instead of diffuse.
This distinction matters because intelligence work fails when the question is too broad. A well-formed requirement gives analysts a clear boundary for what to collect, what to ignore, and what “useful enough” looks like for the decision-maker.
How Specific Intelligence Requirements Shape Collection
Specific intelligence requirements sit between strategy and collection. They translate higher-level objectives into actionable asks that collection teams can satisfy, then give analysts a basis for prioritising sources, methods, and reporting. NHIMG’s Threat Intelligence Guide covers the CTI lifecycle, including how intelligence requirements guide collection and analysis.
In practice, the requirement should be specific enough that an analyst can judge whether an incoming report answers it. If it cannot be answered with evidence, time bounds, and a clearly scoped subject, it is still too vague to drive effective collection.
Good Requirements Versus Vague Questions
Good requirements are narrow without becoming trivial. They often name the actor, asset, behaviour, geography, or timeframe that matters, and they avoid compound wording that hides multiple questions inside one sentence. That precision makes it easier to assign ownership and measure whether the intelligence function produced something decision-useful.
Vague questions create wasted collection and hard-to-use reporting. “What are the threats to us?” is too broad to guide action, while a specific requirement can point at a named business unit, a priority adversary behaviour, or a defined operational period that needs coverage.
Why Specificity Improves Intelligence Value
The value of a specific intelligence requirement is focus. It helps the team spend collection effort on the most decision-relevant information, reduces noise, and improves the chance that finished intelligence answers a real operational or strategic need. The result is better prioritisation, clearer success criteria, and less reporting that is interesting but unusable.
Specificity also supports feedback. When a requirement is written tightly, stakeholders can tell whether it was answered, partially answered, or left open. That feedback loop is essential in intelligence programmes because requirements often evolve as the situation changes.
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 NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Adversary Tactics and Techniques | CTI requirements often target adversary behaviours and attack paths described by ATT&CK. |
| Recommendation — Map collection requirements to ATT&CK techniques and prioritize reporting on the techniques most relevant to the threat model. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Specific intelligence requirements support a risk-driven decision process and prioritisation of collection effort. |
| ID.RA-01 — Asset Vulnerability and Threat Identification | Specific requirements narrow what threats, entities, and conditions need to be identified and analyzed. | |
| Recommendation — Use risk priorities to define intelligence requirements that answer the decisions most important to the organisation. Define intelligence requirements around the threats, assets, and conditions you need to identify and assess. | ||
Practitioner Guidance
Why practitioners should care: A specific intelligence requirement is only useful when it is written tightly enough to direct collection and produce a decisive answer. The best requirements reflect a real decision, not a general curiosity, and they should be reviewed whenever the operational context changes.
Common misunderstanding: Teams sometimes treat intelligence requirements as broad topic areas, when they are really decision questions with a scope boundary. If the wording does not let an analyst decide whether evidence satisfies it, it is not yet specific enough.
Practitioner takeaway: Treat specificity as a quality test, not a paperwork exercise, because the requirement is the filter that determines whether intelligence work stays focused or drifts into noise.
Related resources from NHI Mgmt Group
- When should merchants prioritize network-scale fraud intelligence over a merchant-specific model?
- What is the difference between global fraud intelligence and industry-specific fraud modelling?
- How should security teams operationalize threat intelligence to test whether controls can withstand a specific attack path?
- When should organisations map evidence to a specific requirement instead of a framework label?