A practical, step-by-step process for developing Priority Intelligence Requirements that drive decisions instead of noise. Includes concrete examples, templates, and a checklist.
Most threat intelligence teams know they need Priority Intelligence Requirements. Far fewer have a repeatable process for creating them. The result is a collection of vague objectives that sound strategic but do not actually guide collection, analysis, or reporting.
This post walks through a practical, step-by-step process for developing PIRs that focus your CTI program and produce decisions instead of noise. Every step includes a concrete example you can adapt to your organization.
Step 1: Identify the Decision Makers
Before you write a single requirement, you need to know who is going to use the intelligence. PIRs are not analyst exercises — they are decision-support tools. If the people making security, business, or operational decisions are not involved in the requirement process, you will produce reporting that answers questions nobody asked.
Who to include
- CISO or security leadership — sets risk appetite and controls investment
- Incident response leadership — needs early warning and context for response
- Business stakeholders — M&A, legal, supply chain, physical security
- SOC managers — need tactical requirements that translate into detection rules and alert tuning
What to ask them
Do not start with "What threat intelligence do you want?" Most stakeholders do not know what intelligence can provide. Start with decisions:
- What decisions are you making in the next 6–12 months that could be improved with better threat context?
- What keeps you up at night? Not in general — specifically, what scenario would cause the most damage or disruption?
- If you had perfect visibility into one threat area, which one would change how you allocate resources?
Example
A financial services CISO is preparing for a proposed acquisition in Q3. She needs to know whether the target company has exposure to active threat actors, unresolved vulnerabilities, or prior compromise that could affect integration timelines or valuation. This is not a generic threat question. It is a decision-linked information gap with a deadline.
Step 2: Translate Decisions into Information Gaps
Once you know what decisions are being made, work backward to what information is missing. A decision maker cannot act on awareness alone. They need specific, actionable intelligence that closes a known gap.
The gap framework
For each decision, identify:
- What they know now — current assumptions, existing data, accepted risk
- What they need to know — the missing information that would change the decision
- What happens if they decide without it — the cost of acting on incomplete information
Example
| Decision | Current knowledge | Information gap | Cost of ignorance |
|---|---|---|---|
| Approve acquisition | Target company has standard security controls | Is the target actively targeted by ransomware groups? Are there indicators of prior compromise? | Integration delay, regulatory scrutiny, unexpected remediation costs |
| Allocate SOC resources | We monitor general threat feeds | Which adversaries are most likely to target our sector in the next 90 days? | Wasted effort on low-relevance alerts; missed high-relevance activity |
| Adjust travel security policy | Standard corporate travel policies apply | Have threat actors increased targeting of executives in our operating regions? | Physical safety risk, targeted espionage, reputational damage |
Each gap is a candidate PIR. Not every gap becomes a PIR — some are too broad, too narrow, or not collectible. But starting from decisions ensures that whatever you select will be relevant.
Step 3: Draft the PIR Using the Standard Format
A well-formed PIR is a single question. It should be specific enough to guide collection and analysis, but broad enough that the answer actually influences a decision.
The PIR formula
What is [specific threat or adversary activity] regarding [target of interest], and how does it affect [decision or action] within [timeframe]?
Drafting rules
- One PIR, one question. If you find yourself using "and" multiple times, you probably have two PIRs.
- Include the target. "Our organization" is acceptable, but "our cloud infrastructure" or "our European subsidiaries" is better.
- Name the decision. The PIR should make it obvious what action the intelligence supports.
- Set a timeframe. Intelligence has a shelf life. A PIR without a deadline produces stale answers.
Example: Drafting from the acquisition scenario
Weak: "Tell us about threats to the acquisition target."
Better: "What is the current threat actor activity targeting [acquisition target] or its sector, and are there indicators of compromise or pre-positioning that would increase integration risk if the deal closes in Q3?"
The second version specifies the target, the type of threat activity, the indicators of interest, and the decision timeframe. An analyst reading it knows exactly what to look for and why it matters.
Step 4: Break the PIR into Intelligence Requirements and EEIs
A PIR is too high-level to guide collection directly. You need to decompose it into sub-requirements and specific data points.
The hierarchy
| Level | Purpose | Example |
|---|---|---|
| PIR | Strategic question tied to a decision | "What is the threat landscape facing our acquisition target, and what exposure would increase integration risk if the deal closes in Q3?" |
| IR | Broad information need | "What ransomware groups are actively targeting [target's sector] and what are their TTPs?" |
| EEI | Specific data point to collect | "MITRE ATT&CK techniques observed in campaigns against [sector] in the last 12 months" |
How to decompose
Start with the PIR and ask: "To answer this, what do I need to know?" Each answer becomes an IR. Then ask: "To answer each IR, what specific data do I need?" Each answer becomes an EEI.
Example decomposition
PIR: What is the current threat actor activity targeting [acquisition target] or its sector, and are there indicators of compromise or pre-positioning that would increase integration risk if the deal closes in Q3?
IR 1: What threat actors are actively targeting the target's sector?
- EEI 1.1: List of threat actor groups reported in [sector] in the last 12 months
- EEI 1.2: Campaign timelines and targeting preferences for each group
- EEI 1.3: Initial access vectors most commonly used against [sector] organizations
IR 2: Has the target or its infrastructure shown indicators of compromise?
- EEI 2.1: Known domain/IP associations of the target in threat intelligence feeds
- EEI 2.2: Dark web references to the target in data leaks or actor communications
- EEI 2.3: Publicly reported breaches or security incidents involving the target
IR 3: What vulnerabilities or exposures increase integration risk?
- EEI 3.1: Critical or high vulnerabilities in target's publicly visible technology stack
- EEI 3.2: Misconfigurations or exposed services identified in external reconnaissance
- EEI 3.3: Third-party or supply chain dependencies with known threat actor interest
Now collection has a shopping list. Analysts know what sources to query, what queries to run, and what format the answer should take.
Step 5: Validate Collectability and Feasibility
Not every information gap can be closed with available resources. Before finalizing a PIR, test whether you can actually answer it.
The collectability check
For each EEI, ask:
- Do we have access to the sources needed? If the answer requires human intelligence or access to closed forums you cannot reach, the EEI may need to be revised or dropped.
- Can we obtain the data within the PIR's timeframe? Some intelligence takes months to develop. If the decision is in 30 days, a 90-day collection requirement is useless.
- Do we have the analytical capacity to process it? Raw data is not intelligence. If you lack the expertise to interpret the findings, the PIR will stall.
What to do when collection fails
If an EEI is not collectible, you have three options:
- Revise the EEI. Can you get a proxy indicator? For example, if you cannot access dark web communications directly, can you use public reporting that references them?
- Revise the IR. Can you answer a slightly different question that still supports the decision?
- Revise the PIR. Is the decision itself dependent on information you cannot obtain? If so, flag this to the decision maker early.
Example
The acquisition PIR includes an EEI about dark web references to the target. Your team does not have dark web access. Instead of dropping the EEI, you revise it: "Public reporting or security vendor disclosures referencing the target in relation to dark web activity or data leaks." This shifts the collection burden to sources you already have — open-source reporting and commercial threat feeds.
Step 6: Assign Ownership and Set a Review Cycle
A PIR without an owner becomes orphaned. A PIR without a review cycle becomes stale.
Ownership structure
| Role | Responsibility |
|---|---|
| PIR owner | Usually a senior analyst or team lead. Accountable for ensuring the PIR is answered on time and to standard. |
| Collection manager | Identifies sources, assigns collection tasks, and tracks gaps. |
| Analyst lead | Ensures analysis is rigorous, sourced, and tied back to the PIR. |
| Stakeholder liaison | The decision maker or their representative who validates that the PIR still reflects the decision being made. |
Review cadence
- Monthly: Active PIRs in short timeframes or fast-moving threat areas
- Quarterly: Standard operational PIRs
- Ad hoc: When major events occur — breaches, geopolitical shifts, organizational changes
At each review, ask:
- Is the decision still being made?
- Is the timeframe still valid?
- Has the threat landscape changed enough to require revision?
- Are we making progress on collection, or are we blocked?
Example
The acquisition PIR is owned by the CTI team lead, with the CISO as stakeholder liaison. Because the deal timeline is in Q3, the PIR is reviewed every two weeks. At the first review, the team identifies that the target has shifted its cloud provider — an IR is updated to reflect the new infrastructure. At the second review, a new ransomware group is reported targeting the sector — an EEI is added to track its TTPs.
Step 7: Produce the Answer and Tie It to Action
A PIR is not complete when the analyst finishes writing. It is complete when the decision maker has what they need to act.
The answer format
The final intelligence product should follow a simple structure:
- Bottom line up front. The direct answer to the PIR, in one or two sentences.
- Evidence and sources. What was observed, where it came from, and how confident you are.
- Assessment. What the evidence means for the organization and the decision.
- Gaps and limitations. What you still do not know and how that affects confidence.
- Recommended actions. Specific, feasible steps the decision maker can take based on the intelligence.
Example output: Acquisition PIR
BLUF: Two ransomware groups have actively targeted the acquisition target's sector in the last six months. External reconnaissance identified three critical vulnerabilities in the target's publicly visible infrastructure, and one dark web reference suggests possible prior data exposure. These findings increase integration risk and justify pre-close security due diligence.
Evidence: [Specific campaign reports, CVEs, reconnaissance findings, dark web reference with source attribution]
Assessment: The target is in a actively targeted sector with known vulnerabilities. The integration timeline should include a 30-day remediation window or a valuation adjustment to account for security investment.
Gaps: No direct evidence of target compromise was found, but dark web visibility is incomplete. Confidence in "no compromise" is moderate, not high.
Recommended actions:
- Conduct pre-close external compromise assessment
- Negotiate integration security budget or timeline
- Require vulnerability remediation as a closing condition
- Add target infrastructure to post-acquisition monitoring scope
Common Pitfalls to Avoid
Even teams that follow the steps can undermine their PIR process. Watch for these:
- PIRs that describe monitoring, not decisions. "Monitor for ransomware activity" is a task, not a requirement. "Will ransomware actors target our sector in Q3, and what vectors should we prioritize?" is a PIR.
- Too many PIRs. A small CTI team cannot actively pursue ten strategic PIRs. Start with three to five and add only as capacity allows.
- Analysts writing PIRs in isolation. The best PIRs come from conversation with decision makers, not from analysts guessing what leadership cares about.
- Treating PIRs as permanent. Threat landscapes change. A PIR written in January may be irrelevant by June. Review and retire actively.
- Ignoring the action step. If the final intelligence product does not include recommended actions, the decision maker is left asking "So what?" — and the PIR has failed its purpose.
Summary: The PIR Development Checklist
Use this checklist every time you develop a new PIR:
- Identify the decision maker and the decision they need to make
- Define the specific information gap that prevents the decision
- Draft the PIR as a single, specific, decision-linked question with a timeframe
- Decompose into IRs and EEIs that guide collection
- Validate that each EEI is collectible with available sources and capacity
- Assign a PIR owner and set a review cycle
- Produce the answer in a format that includes evidence, assessment, gaps, and recommended actions
- Track whether the intelligence influenced the decision
Priority Intelligence Requirements are not a theoretical framework. They are a practical tool for making threat intelligence operational. The teams that use them well stop producing reports and start producing decisions.