Writing an intelligence requirement

Most of what gets called an intelligence requirement is really a subject heading. "Ransomware." "Threat actors targeting our sector." "Supply chain risk." Nobody objects to any of them, which is the problem: a question nobody objects to is usually a question nobody is waiting on either.

The test is blunt. If the answer does not support a decision, it is not an intelligence requirement. It might still be worth knowing. It is not a requirement, and treating it as one is how collection queues fill with work that no one is going to act on.

Start at the decision, not at the question

This is the part people skip, and skipping it is what produces the subject headings.

Before writing the question, write down the decision. Four things about it, and all four are harder than they look:

• What decision must the answer support? Stated as a choice, not a topic. "Whether to require an independent callback before a supplier bank-detail change" is a decision. "Supplier fraud" is not.
• Who owns it and can actually act? A named person with the authority. If nobody owns the decision, the answer has nowhere to land.
• What action or resource commitment follows? What visibly changes depending on the answer.
• What happens if the answer is not there by the deadline? Sometimes the honest answer is that the decision gets made anyway on the basis of caution. That is worth knowing in advance, because it tells you how much the collection is really worth.

That last question does more work than the other three. If the decision goes ahead unchanged whether or not the answer arrives, you have found out cheaply that this is not a requirement.

Then narrow the question

With the decision written down, the question becomes easier to draft and much easier to cut. Four checks, each of which usually shortens it:

• What do we need to know?
• What uncertainty does that reduce?
• How does the answer support the decision already written down?
• Can it be collected and delivered in time? Say how.

Requirements tend to arrive too broad and get narrowed by these, which is the right direction of travel. "What are the threats to our payment process" survives none of them. "Could supplier impersonation bypass our current payment-change checks" survives all four.

Say what kind of requirement it is

Classifying it is not bureaucracy. The category tells you where the answer is going to come from, and therefore who has to go and get it and how long it will take.

• BIR, business information requirement. What the business needs to understand about its own operations and exposure.
• ECIR, executive critical information requirement. What leadership must know to make a decision at their level.
• PTIR, priority threat intelligence requirement. A prioritized question about an adversary, their capability, or their activity.
• IIR, internal information requirement. The answer comes mostly from your own people and systems.
• EPI, essential protected information. What about you must not become known to an adversary.

The practical value shows up immediately with IIR. A question answerable from your own sign-in records and help desk has a completely different timeline to one that depends on external reporting, and confusing the two is how a one-hour question gets scheduled like a one-week one.

EPI is the one that gets left out most often, because it runs the other way. It is not about what you need to learn but about what you need to keep from being learned, and a program that never asks it is only looking in one direction.

Three tests

Before any collection effort is spent, the requirement has to survive all three.

• Decision support. Explain how the answer supports a defined decision. If the explanation is vague, the requirement is.
• Time sensitivity. Define the window in which the answer is still useful. An answer that arrives after the decision is a report, not intelligence.
• Collectability. Explain how the organization can realistically obtain the answer. Not in principle. With the people and access it actually has.

Collectability is where good questions die, and it is better for them to die here than three weeks into an effort. A requirement that needs visibility you do not have is not a requirement yet. It is an argument for getting that visibility, which is a different piece of work with a different owner.

Threshold, trigger, time

A requirement without these is answerable but not actionable, and this is the step most often left off.

• Threshold. What measurable level matters. Not "unusual activity" but a stated amount, count, or condition.
• Trigger. What event means someone reports or acts right now, rather than in the next summary.
• Time. When the decision is required, and how fast a finding has to travel once it exists.

Writing these down in advance is what keeps a finding from being debated at the moment it arrives. Agreeing beforehand that one confirmed password submission triggers a reset is a two-minute conversation. Having it after the confirmation, at speed, with people who disagree, is not.

Write the final question in one sentence

Then name where the answer will come from, and who receives it and by what route. A requirement with no delivery path produces an answer that sits with the analyst who found it.

Stated in full, a finished requirement reads roughly like this: determine within one hour whether any employee entered a password on the fake site, report any confirmed submission immediately, so the security manager can order a reset. Decision, question, threshold, time, and recipient, in one sentence.

If you cannot write your requirement that way, the thing that is missing is almost never the wording. It is usually the decision, and it was missing before you started writing.

Drawn from the Intelligence Requirements Worksheet by Christopher G. Ruel and Ajay Menendez, authors of Cyber Threat Intelligence Planning: A Special Forces Approach.