Define threat-intelligence requirements

Write an intelligence requirement as a question that a named person needs answered to make a decision. Include the systems or business activity concerned, the time available and the evidence that would change that person's choice. This gives research a stopping point and makes an unanswered question useful rather than invisible.

The Home Office's 2019 guide puts customer requirements at the start of its intelligence process and treats intelligence as support for an organisation's defenders. It is a historical government capability guide, not a current purchasing specification for every business. The worksheet below is our own smaller-scale way to apply the decision-first principle.

Replace a topic with a decision

“Tell us about ransomware” is a subject area. It does not establish which part of the organisation matters or what the reader can do with the answer. Ask the requester:

1. What are you deciding? Examples include which access route to review, what to cover in an exercise or which monitoring gap to investigate.
2. What can change? Find the person with authority to change a configuration, allocate time or accept a residual risk.
3. When is the answer needed? A decision next week requires a different research plan from a long-term architecture review.
4. What do we already know locally? An asset inventory or supplier agreement may answer an applicability question better than more external reports.
5. What would count as enough evidence? Set a threshold appropriate to the action, and record what remains uncertain.

If the requester cannot name a decision, arrange a short discussion about the underlying concern. Avoid buying a feed to compensate for an undefined question.

Worked example: a supplier access review

Fictional scenario. Merefield Supply operates a warehouse and a customer-order service. Its operations manager is deciding whether the next maintenance window should include a review of supplier access. The following is an invented requirement, not an account of an attack on a real company.

The key improvement is the local question. A report about a different authentication method may be useful context, but it does not automatically justify changing the warehouse service.

Make a small collection plan

For each question, name a source and the reason it can answer it. Separate sources that describe the threat from records that establish your exposure.

NIST SP 800-150 is a useful reference when the collection plan involves exchanging information with other organisations. It covers setting sharing goals, selecting sources and agreeing rules for distribution. Keep those agreements visible alongside the research plan.

Prioritise requirements you can use

A short queue helps prevent every incoming report becoming urgent. Compare requirements using three questions: is a decision approaching, could the answer materially change it, and is the relevant evidence obtainable? Record a reason for priority rather than assigning a precise-looking score without a defined meaning.

Some requests should be narrowed. “Prove we cannot be affected” is not a realistic research outcome. A bounded alternative is: “Establish whether the prerequisite described in this advisory exists on the listed systems, and record what the checks could not establish.”

Close the requirement with an outcome

At the decision meeting, record the answer, evidence limits, action chosen and owner. “We could not determine whether this supplier account is still required” is a valid result if it creates a specific ownership task.

Ask the decision owner whether the work helped. If the answer arrived after the maintenance window or described technology the organisation does not use, amend the next requirement. Continue with assessing sources before treating collected material as a reliable basis for action.