← Cyber Intelligence Foundations
Module 1: Start With the Decision
From Security Data to Intelligence Write an Intelligence Requirement
Module 2: Build an Evidence Base
Collect Evidence With a Plan Evaluate Sources and Claims
Module 3: Analyze, Report, and Improve
Describe Adversary Behavior Without Overclaiming Indicators of Compromise and Their Types Use Indicators With Context Write and Review a Decision-Ready Assessment
Module 4: Turn Intelligence Into Better Defense
Build a Bounded Defensive Hunt Keep Intelligence Useful Over Time
Module 5: Apply Intelligence to Common Security Problems
Build Vulnerability Intelligence That Prioritizes Action Analyze Identity and Social-Engineering Threats Analyze Malware and Ransomware Activity
Module 6: Operate Intelligence as a Capability
Work With Stakeholders and Decision-Makers Govern Intelligence and Handle Information Responsibly Share Structured Intelligence and Automate Safely
Module 1: Start With the Decision

Write an Intelligence Requirement

Convert a broad concern into a question that collection and analysis can actually answer.

About this learning content: Courses, lessons, assessments, explanations and illustrations may be created with the help of artificial intelligence. We review and check the material and do our best to avoid incorrect or outdated information, but mistakes, omissions or ambiguous questions may remain. Please verify information before relying on it for professional, security, legal or operational decisions. Read the full notice or report an issue.

In this lesson, you will learn to:

  • Write a prioritized intelligence requirement with a consumer, decision, scope, timeframe, and answer standard.

Write an Intelligence Requirement

This lesson teaches the first practical planning skill: writing a requirement that has a consumer, decision, scope, timeframe, and success condition. You will turn an unhelpful request into a small set of answerable questions.

Replace Broad Concerns With Answerable Questions

Stakeholders often begin with a concern rather than a requirement: “Are we at risk from ransomware?” or “Tell me about this threat actor.” These prompts are understandable, but they are too broad to guide collection. They have no defined decision, timeframe, scope, or stopping point, so an analyst can gather information indefinitely and still disappoint the requester.

Improve the request by asking five questions. Who needs the answer? What decision will it support? Which assets, sector, geography, or adversary are in scope? By when is the answer needed? What would count as useful evidence? For example: “By Friday, can the SOC identify whether Northstar has observable exposure to the credential-theft infrastructure described in Advisory X, and which logs should be searched first?”

Notice what this version does not promise. It does not ask whether Northstar is safe. It asks for evidence about a defined exposure and identifies the next defensive use. A good requirement makes uncertainty manageable without hiding it.

Turn a broad concern into a precise requirementA funnel narrows a broad security concern through five filters into a bounded intelligence requirement. REQUIREMENTS DESIGNNarrow the question before collecting BROAD CONCERN: ARE WE AT RISK?1. Consumer and decision2. Scope and priority3. Timeframe and evidenceBOUNDED REQUIREMENT: ANSWERABLE BY FRIDAY
Turn a broad concern into a precise requirement — Five filters narrow a vague concern into a bounded question with a consumer, decision, scope, timeframe, and evidence standard.

Prioritize Requirements and Define Done

A team rarely has capacity to answer every question at once. Prioritize requirements by decision impact, time sensitivity, uncertainty, and feasibility. A requirement connected to an imminent containment decision may outrank a strategic trend question. A question with no available data may need a collection-gap response rather than a rushed conclusion.

Define what “done” means before work begins. A completion condition might be: “Compare the advisory’s named domains against the organization’s DNS and proxy data for the previous 30 days; report confirmed sightings, search limitations, and recommended follow-up.” This does not mean the threat is fully understood. It means the requested slice of uncertainty has been examined transparently.

Keep a requirement register with an owner, priority, status, due date, and last update. When a requirement changes, record why. This simple habit protects the analyst from scope drift and helps stakeholders distinguish a delayed answer from an answer that found no evidence.

Prioritize intelligence questions by decision valueA two-axis matrix ranks intelligence questions by decision impact and time sensitivity. REQUIREMENT TRIAGEAnswer the most valuable question first TIME SENSITIVITY →DECISION IMPACT →long-term trendplan laterurgent investigationanswer nowstrategic planningcontainment decision
Prioritize intelligence questions by decision value — A simple matrix compares decision impact and time sensitivity to show which requirements should be answered first.

Resources

← Previous: From Security Data to Intelligence Next: Collect Evidence With a Plan →