PIRs are the contract between CTI and the people who use it. A practical guide to writing, ranking, and operating Priority Intelligence Requirements without turning your program into a paperwork exercise.
Most CTI programs fail the same way: they drown in feeds, alerts, and reports nobody asked for. The fix isn''t more data — it''s Priority Intelligence Requirements (PIRs). PIRs are the contract between intelligence and the people who use it. Get them right and every analyst hour maps to a decision somebody actually needs to make.
This guide covers what PIRs are, how to write them, and how to operate them without turning your CTI function into a paperwork exercise.
What is a Priority Intelligence Requirement?
A Priority Intelligence Requirement is a specific, decision-driving question a stakeholder needs answered to act. It has four properties:
- Specific — narrow enough that an analyst knows when it''s answered.
- Decision-linked — tied to an action a named stakeholder will take.
- Time-bound — has a review cadence or expiration.
- Collectable — your team can plausibly gather evidence against it.
PIRs originated in military doctrine (the "PIR" in US Army FM 2-0 is the commander''s prioritized intelligence question), but the concept transfers cleanly to cyber: the CISO, SOC lead, fraud team, and product security all have decisions that intelligence should inform.
PIR vs. intelligence requirement vs. EEI
- Intelligence Requirement (IR) — any question intel could answer.
- Priority Intelligence Requirement (PIR) — the IRs leadership has ranked as most important. Usually 5–15 active at a time.
- Essential Element of Information (EEI) — the sub-questions and indicators that, when answered, satisfy a PIR.
A PIR without EEIs is a wish. EEIs are what analysts actually collect against.
Why PIRs matter for cyber threat intelligence
Without PIRs, CTI teams default to feed-driven work: ingest IOCs, write whatever the news cycle suggests, hope someone reads it. With PIRs, work becomes requirements-driven: every report, hunt, and brief traces back to a stakeholder decision.
Concretely, PIRs let you:
- Say no to low-value asks without political damage ("that doesn''t map to a current PIR").
- Justify tooling, headcount, and data purchases in stakeholder language.
- Measure CTI value as decisions supported, not reports produced.
- Stop analysts from rewriting the same vendor blog three times a quarter.
How to develop Priority Intelligence Requirements (step by step)
1. Identify your stakeholders and their decisions
Start with people, not threats. List every team that consumes intelligence — SOC, IR, vulnerability management, fraud, exec leadership, product security, legal/privacy, third-party risk — and for each, write down the recurring decisions they make. Examples:
- SOC lead: "Which detections do I tune this sprint?"
- CISO: "Should we accelerate the MFA rollout?"
- Fraud: "Is this campaign targeting our brand or industry-wide?"
If a team can''t name a decision, they're not a real stakeholder for CTI yet.
2. Convert decisions into questions
Each decision becomes a question phrased so an answer is conceivable. Bad and good examples:
| Bad PIR | Why it fails | Better PIR |
|---|---|---|
| "Track all ransomware" | Not specific, not decision-linked | "Which ransomware groups have targeted [our sector] in the last 90 days, and what initial-access TTPs did they use?" |
| "Monitor the dark web" | Not collectable as written | "Are credentials, source code, or internal documents belonging to [company] being offered for sale on monitored forums?" |
| "Understand APT28" | No decision attached | "Has APT28 shifted toward initial-access techniques our current EDR coverage does not detect?" |
3. Rank ruthlessly
Cap your active list — most mature teams run 8–12 PIRs. If everything is priority, nothing is. Score candidates on (a) decision impact, (b) likelihood the question becomes relevant, (c) your ability to collect. Drop the bottom of the list; park them in a backlog.
4. Decompose into EEIs
For each PIR, write the sub-questions that, taken together, answer it. For the APT28 PIR above:
- Which initial-access techniques has APT28 used in the last 12 months?
- Which of those map to ATT&CK techniques our EDR detects?
- Which gaps could we close with existing tooling vs. new investment?
EEIs are where collection planning starts.
5. Assign owners and cadence
Every PIR needs a named analyst owner, a stakeholder owner (who receives the answer), and a review date. A PIR with no owner dies quietly.
Operating PIRs day to day
Writing PIRs is the easy part. The failure mode is letting them rot. Three habits that keep them alive:
- Quarterly reviews with stakeholders. Walk through each PIR: still relevant? answered? needs reshaping? Kill what''s stale.
- Tie every product to a PIR. Every finished report, brief, or detection content references the PIR(s) it serves. If nothing maps, ask why you did the work.
- Track answered vs. open. A simple status — open / partially answered / answered / retired — is enough. Resist the urge to build a Jira empire around it.
Common pitfalls
- Treating PIRs as a one-time exercise. They drift as the business and threat landscape change. Review quarterly at minimum.
- Writing PIRs in analyst language. If the stakeholder can''t read the PIR and recognize their own decision, rewrite it.
- Confusing PIRs with collection sources. "Monitor Telegram" is a source, not a requirement.
- Too many PIRs. Past ~15, prioritization breaks down and the list becomes a backlog you call a priority list.
Where ThreatSpire fits
ThreatSpire is built requirements-first: PIRs are first-class objects, EEIs decompose under them, and every finding, IOC, and actor profile ties back to the PIR it serves. When a stakeholder asks "why are we tracking this?", the answer is one click, not a hunt through Confluence.
If you''re standing up a CTI program — or rebuilding one that turned into a report factory — start with five PIRs you can defend in front of your CISO. Everything else follows.