From Stakeholder Need to Intelligence Requirement

From Stakeholder Need to Intelligence Requirement

Turn a concern into an answerable requirement

An intelligence requirement states what a stakeholder needs to understand so they can make a decision. It directs effort and supplies a standard for deciding when the work is useful enough to deliver.

Compare three formulations:

A strong requirement usually contains six elements:

1. Consumer: Who owns or influences the decision?
2. Decision: What real choice will the intelligence inform?
3. Core question: What uncertainty must be reduced?
4. Scope: Which assets, business processes, regions, actors, behaviors, or scenarios are included or excluded?
5. Time: When is the answer needed, and what period should it assess?
6. Use criteria: What form and level of confidence or detail will be sufficient to act?

A reusable pattern is:

For [consumer] to decide [choice] by [deadline], assess [uncertainty] across [scope and horizon], including [decision-relevant factors].

This is a starting pattern, not mandatory prose. The requirement must be understandable to both consumer and analyst.

Ask about the decision, not only the topic

Stakeholders sometimes describe a desired product because that is easier than articulating a decision: “Send me a weekly threat report.” A productive requirements conversation explores the underlying need:

• What changes after you read the report?
• Which decisions recur weekly?
• What would cause you to act differently?
• Which assets or outcomes matter most?
• What do you already receive, and where does it fall short?
• What is the cost of answering too late or incorrectly?

Suppose the request comes from a vulnerability manager: “Tell me which vulnerabilities threat actors are using.” The actual choice may be which remediation work to accelerate. A better requirement considers exploitation evidence, exposure, asset criticality, attack prerequisites, compensating controls, and remediation cost. Popularity alone does not determine organizational relevance.

Requirements are negotiated

The consumer owns the need; the intelligence team advises what can be answered responsibly. Together they may narrow scope, change timing, identify inaccessible evidence, or define an interim answer. Never imply that a broad question can be answered with precision merely to satisfy demand.

Analyst habit: Write the decision as a verb—prioritize, contain, invest, accept, notify, investigate, redesign. If the requirement contains no meaningful choice, clarify it before building a collection plan.

Decompose, prioritize, and maintain requirements

A broad requirement becomes manageable when decomposed into specific intelligence requirements and information needs.

For the Northbridge resilience requirement, useful sub-questions might be:

• Which business services would create the greatest harm if unavailable?
• Which initial-access and privilege pathways are plausible in the current environment?
• Which extortion behaviors have been observed against comparable organizations?
• Which controls would prevent, detect, contain, or recover from those behaviors?
• Which assumptions and intelligence gaps could change the prioritization?

An information need is narrower and more directly collectible. For example, answering the question about pathways may require current external exposure, identity architecture, phishing telemetry, incident history, trusted-party access, and credible reporting about adversary behavior.

The chain should remain traceable:

If a collection task cannot be traced upward to a requirement and decision, challenge its priority.

Prioritize explicitly

Resources are finite. Score requirements using simple, explainable criteria rather than whoever asks loudest:

• Decision impact: How consequential is the choice?
• Urgency: When does delay reduce value?
• Threat relevance: Is the uncertainty connected to plausible exposure and harm?
• Feasibility: Can available sources support a responsible answer?
• Uniqueness: Is the answer already available elsewhere?
• Effort and opportunity cost: What other work will be delayed?

A numeric score can support discussion, but it should not conceal judgment. Record the rationale and resolve conflicts with accountable stakeholders.

Define completion and review

Requirements should have a review date or trigger. Close, revise, pause, or replace them when:

• the decision has been made;
• the relevant time window has passed;
• the environment or stakeholder changes;
• collection shows the question cannot be answered as framed;
• the uncertainty has been reduced enough for action;
• feedback reveals a different need.

“Finished” rarely means every fact is known. It means the consumer has a timely, defensible answer sufficient for the decision, with remaining gaps visible.

Practice: repair a weak request

Weak request: “Track threat groups targeting our sector.”

A stronger version could be:

For the security architecture lead to prioritize identity and endpoint improvements during the next planning cycle, assess which recurring adversary behaviors create plausible paths to Northbridge’s payment and customer-data services, the conditions that enable those paths, and the controls that would most reduce exposure.

Notice what changed: the focus moved from collecting actor names to understanding behaviors, organizational exposure, and a decision.

Key takeaways

• A topic is not a requirement; a requirement connects uncertainty to a decision.
• Decomposition creates traceability from decision to collection task.
• Priority should reflect impact, urgency, relevance, feasibility, uniqueness, and cost.
• Requirements are living agreements and should be reviewed, not allowed to become permanent collection habits.