How to Write an Intelligence Requirement That Produces a Useful Answer
Turn broad threat concerns into prioritized, answerable intelligence requirements with a named consumer, decision, scope, time horizon, collection questions, success criteria, and review triggers.
An intelligence requirement is the question that keeps CTI connected to a decision. Without one, teams collect whatever is available, write about whatever is interesting, and measure how much they produced. With a good requirement, analysts know which evidence matters, when the answer is due, and what useful looks like.
“Tell us about ransomware” is not an intelligence requirement. “Which ransomware access methods are most likely to affect our European manufacturing sites during the next six months, and which control decisions should we prioritize?” is close to one. This guide shows how to turn a concern into a governed, answerable requirement.
Begin With the Decision
Ask the requester:
- What will you decide, approve, investigate, prioritize, prepare, or stop doing?
- When will you make that decision?
- What happens if the answer is wrong or late?
- Which uncertainty is preventing the decision now?
- What evidence would change your current view?
If no decision exists, the request may be general awareness, education, or curiosity. Those can be legitimate services, but they should not displace priority intelligence work without an explicit choice.
Include the Essential Fields
A complete requirement records:
- Question: one clear sentence;
- Consumer and owner: the person accountable for the decision;
- Decision: how the answer will be used;
- Priority: importance, urgency, and rationale;
- Scope: threat, organization, geography, technology, business process, and exclusions;
- Time horizon: period being assessed;
- Delivery deadline and cadence: when and how often;
- Product: alert, assessment, briefing, dataset, or recurring service;
- Satisfaction criteria: what the answer must contain;
- Review triggers: events that change or close the requirement.
Define ambiguous terms. “Critical supplier,” “material disruption,” and “state-sponsored” need agreed meanings if they change scope or priority.
Rewrite Broad Requests Into Answerable Questions
Use this pattern:
Which threat development or behavior is most likely to affect specified organizational exposure during a defined period, with what consequence, and which decision should the consumer consider?
Broad: “What should we know about AI threats?”
Better: “Which attacker uses of generative AI are changing phishing exposure for our customer-support workforce during the next 12 months, and should we change identity, email, or training controls?”
Broad: “Monitor our suppliers.”
Better: “Which cyber events affecting providers with privileged access could interrupt our payment service this quarter, and which warning should trigger continuity action?”
Avoid requirements that presuppose the answer, such as “Prove Group X is targeting us.” Ask whether the evidence supports that hypothesis and which alternatives remain plausible.
Decompose the Requirement Without Losing Traceability
Break the requirement into analytic questions, then collection questions.
A ransomware requirement may need analytic questions about initial access, targeted sites, likely operational consequence, and current control gaps. The access question may create collection tasks for access-broker listings, sector incident reports, exposed service inventory, authentication telemetry, and vulnerability evidence.
Every collection task should map back to the requirement. This lets the team stop collecting material that cannot change the answer and explain which gap prevents a stronger judgment.
Plan for evidence that could weaken the leading hypothesis, not only confirm it.
Prioritize Transparently
Consider:
- consequence of the supported decision;
- urgency and decision deadline;
- size of current uncertainty;
- likelihood that intelligence can reduce it;
- organizational exposure and risk tolerance;
- collection and analytic cost;
- dependencies on other requirements.
A senior request can still be too broad or unanswerable. Reframe it rather than accepting impossible scope. Keep the active priority set small enough that the team can deliver and review it reliably.
Manage Requirements as Living Decisions
Maintain a register with status, owner, priority, current product, latest judgment, gaps, review date, and decisions influenced. Use states such as proposed, approved, active, paused, satisfied, superseded, and retired.
Review after incidents, business changes, new markets, architecture changes, supplier shifts, and major external events. Feedback may reveal that the question was wrong, the cadence was late, or the consumer needed a different product.
The full operating cycle is described in The CTI Lifecycle.
The Requirement Quality Check
Before approval, confirm that a named consumer owns a real decision; the question is neutral and answerable; scope, exclusions, and time horizon are explicit; priority has a rationale; subordinate questions trace to the requirement; success and stopping criteria are known; and a review trigger exists.
A strong requirement does not guarantee the analyst will know the answer. It guarantees that everyone knows which uncertainty matters and what evidence would make the answer useful. For guidance on writing the final product, use How to Write a CTI Report.
Frequently asked questions
What is the difference between a topic and an intelligence requirement?
A topic names an area of interest, such as ransomware. A requirement asks an answerable question for a named consumer and decision, with scope, time horizon, priority, and an expected useful output.
What makes a requirement a priority intelligence requirement?
A PIR supports a consequential or time-sensitive decision and receives explicit collection and analytic priority. Senior sponsorship alone does not make every broad request a PIR.
How many priority requirements should a CTI team have?
Keep the number small enough that the team can collect, analyze, deliver, and review them reliably. The correct number follows capacity and decision importance rather than a universal target.
Who owns an intelligence requirement?
A named consumer or decision owner should own the need and priority, while CTI owns the analytic framing and production process. Collection and source owners support subordinate tasks.
When should an intelligence requirement be closed?
Close or retire it when the decision is complete, the question is answered to the agreed standard, the need becomes irrelevant, or another requirement supersedes it. Preserve the history and any continuing warning indicators.
