A step-by-step walkthrough of the Intelligence Requirements Process — the repeatable workflow that turns a stakeholder question into an evidence-backed answer that actually changes decisions.
Most CTI teams can name their Priority Intelligence Requirements. Far fewer can describe the process that turns a stakeholder's question into an evidence-backed answer that actually changes a decision.
The Intelligence Requirements Process is what closes that gap. It is the repeatable workflow that takes a vague concern from leadership, refines it into a structured requirement, drives collection and analysis, and delivers a defensible answer back to the decision maker — with the evidence to support it.
This post walks through the full lifecycle, step by step, with concrete examples at each stage.
Why a Process Matters
Without a defined process, intelligence work becomes a series of one-off favors. A stakeholder asks a question, an analyst chases sources, a report goes out, and nobody remembers six months later whether the answer was right, who acted on it, or what it cost.
A documented Intelligence Requirements Process does four things:
- Standardizes intake so requests are captured the same way every time.
- Forces refinement before collection burns hours on the wrong question.
- Creates traceability between evidence, analysis, and the final answer.
- Enables measurement of impact, accuracy, and timeliness.
If your team cannot point to where a requirement entered the pipeline, how it was scoped, what sources answered it, and which decision it informed — you do not have a process. You have improvisation.
The Six Stages of the Intelligence Requirements Process
The process below is a working version of the classic intelligence cycle, adapted for modern CTI teams. Each stage has a clear input, a clear output, and a clear owner.
Stakeholder question | v 1. Intake & Triage | v 2. Requirement Definition | v 3. Collection Planning | v 4. Analysis & Production | v 5. Dissemination | v 6. Feedback & Review | v Evidence-backed answer
Stage 1: Intake and Triage
Every requirement starts with a question. The job of intake is to capture it consistently and decide whether it belongs in the queue.
What to capture
- Requester — name, role, team
- Original question — in the stakeholder's own words, verbatim
- Decision context — what choice does the answer inform
- Deadline — when is the decision being made
- Sensitivity — who can see the answer
Triage criteria
Not every question becomes a Priority Intelligence Requirement. Use a simple filter:
- Is the question decision-linked, or is it curiosity?
- Is the deadline realistic given the scope?
- Does the team have access to the sources required to answer it?
- Does it duplicate an existing requirement or finished product?
If the answer to any of the first three is "no," push back to the requester before accepting the work.
Example
"Are we going to get hit by ransomware?"
This is not yet a requirement. Triage rewrites it as a scoping conversation: which business unit, which threat actors, what time horizon, and what decision is on the table — patch prioritization, tabletop scope, or insurance renewal?
Stage 2: Requirement Definition
Refine the triaged question into a formal Priority Intelligence Requirement with structured sub-components.
A well-formed PIR has:
| Element | Description |
|---|---|
| Statement | The decision-linked question, written as a single sentence |
| Rationale | Why this matters and which decision it supports |
| Intelligence Requirements (IRs) | Broader information needs that contribute to the PIR |
| Essential Elements of Information (EEIs) | Specific data points needed to answer each IR |
| Owner | The analyst accountable for delivery |
| Deadline | When the answer is needed |
| Success criteria | What "answered" looks like |
Example
PIR: "Which ransomware groups are most likely to target our European operations in the next 90 days, and what initial access vectors should we prioritize for detection?"
IRs:
- Active ransomware groups targeting our sector in EMEA
- Recent campaigns against organizations of similar size and posture
- Known initial access vectors used by those groups
EEIs:
- List of ransomware groups with confirmed EMEA activity in the last 6 months
- MITRE ATT&CK techniques observed in those campaigns
- Indicators of compromise tied to those techniques
- Vulnerabilities exploited for initial access
Defining the requirement this precisely is the single highest-leverage step in the process. Skipping it is why so many CTI reports feel generic.
Stage 3: Collection Planning
Now that you know the EEIs, decide where the data will come from. Collection planning maps each EEI to a source and a method.
Source categories
- Internal telemetry — EDR, SIEM, identity logs, email security
- Commercial threat intelligence — vendor feeds, finished reporting, dark-web monitoring
- Open-source intelligence (OSINT) — vendor blogs, government advisories, researcher reporting
- Information-sharing communities — ISACs, trust groups, peer networks
- Human sources — vendor briefings, conference contacts, partner exchanges
What to document
For each EEI, capture:
- Which source(s) will be queried
- Who is responsible for collection
- The deadline for handing collected data to the analyst
- Any access, licensing, or legal considerations
Collection planning prevents two failure modes: redundant collection across multiple analysts and silent gaps where nobody owns a source.
Stage 4: Analysis and Production
This is where collected data becomes intelligence. The goal is not to summarize what was found — it is to answer the PIR with reasoning the stakeholder can follow.
Analytical discipline
- Separate evidence from assessment. State what is observed, then state what it means.
- Use confidence language consistently. "High confidence," "moderate confidence," and "low confidence" should map to your team's documented definitions, not analyst feel.
- Show the chain. Every assessment should trace back to specific evidence in the report.
- Address alternative explanations. What else could the evidence mean, and why is your assessment more likely?
Production format
Match the format to the audience. A CISO reading on a phone needs a different artifact than a SOC manager building detection rules. Common formats:
- Executive brief — one page, decision-focused, no jargon
- Analyst report — full evidence, sources, and methodology
- Detection package — IOCs, ATT&CK mappings, hunt queries
- Briefing deck — for live presentation to a stakeholder group
Always include the original PIR at the top so the reader knows exactly what question is being answered.
Stage 5: Dissemination
Getting the right product to the right people, in the right channel, at the right time.
Practical rules
- Push, do not publish. Send the product directly to the requester and named recipients. Do not assume they will find it in a portal.
- Match channel to urgency. Time-sensitive answers go via the channel the stakeholder actually watches (Slack, Teams, email, phone) — not a quarterly newsletter.
- Respect sensitivity. Apply handling caveats (TLP, internal classifications) consistently and verify the distribution list before sending.
- Confirm receipt. For high-priority requirements, get an acknowledgment that the product was read.
A brilliant report nobody opens has the same impact as no report at all.
Stage 6: Feedback and Review
The process does not end at dissemination. Feedback closes the loop and feeds the next cycle.
What to ask the requester
- Did the product answer the question?
- Was the timing right?
- Did it influence the decision? If so, how?
- What was missing, unclear, or unnecessary?
What to review internally
- Were the EEIs the right ones?
- Did collection cover the gaps, or did we improvise?
- Was the confidence language calibrated against what actually happened?
- Should this PIR be retired, refreshed, or expanded?
Capture the answers in a lightweight after-action note attached to the requirement. Over time, this becomes the most valuable training data your team has.
Common Failure Modes
Even teams with a documented process slip in predictable ways. Watch for these:
- Skipping requirement definition. Jumping from intake straight to collection produces generic reports that miss the decision.
- Treating collection as a checklist. If an EEI cannot be collected, the requirement needs to be renegotiated — not quietly dropped.
- Hiding uncertainty. Overstating confidence to sound authoritative destroys trust the first time the assessment is wrong.
- No feedback loop. Without Stage 6, the team never learns whether its work mattered.
- Process for its own sake. The artifacts exist to support better decisions. If a stage is not adding value, fix it — do not perform it.
Tying the Process to Evidence
The phrase "evidence-backed answer" is the standard the process exists to enforce. Every assessment in a finished product should be traceable to:
- A specific piece of collected data
- The source it came from
- The reasoning that connects evidence to conclusion
- The confidence level and what would change it
When stakeholders ask "how do you know?" — and the good ones always do — the analyst should be able to walk them through the chain in under two minutes. If they cannot, the process broke somewhere between Stages 3 and 4, and the next review should focus there.
Key Takeaways
- The Intelligence Requirements Process is the workflow that turns stakeholder questions into evidence-backed answers, organized in six stages: intake, definition, collection, analysis, dissemination, and feedback.
- Requirement definition is the highest-leverage stage. Precise PIRs, IRs, and EEIs prevent wasted collection and vague reporting.
- Evidence discipline — separating observation from assessment, using calibrated confidence language, and showing the chain — is what makes an answer defensible.
- Feedback is not optional. Without it, the team has no way to know whether its work changed any decisions.
A repeatable process is what turns a group of capable analysts into a CTI program leadership trusts. The stakeholder's question is the input. The evidence-backed answer is the output. The process is everything in between.