Priority Intelligence Requirements (PIRs)

Priority Intelligence Requirements (PIRs) are the engine that drives a focused, effective cyber threat intelligence program. Without well-defined intelligence requirements, CTI teams risk producing intelligence that no one asked for and no one uses. PIRs ensure that collection, analysis, and reporting efforts are aligned with what the organization actually needs to know to make decisions and manage risk.

Learning Objectives

Understand the intelligence requirements hierarchy from strategic to tactical levels
Write effective PIRs that are specific, measurable, answerable, relevant, and timely
Manage the PIR lifecycle from creation through retirement
Connect PIRs to collection activities and analytical products
Align intelligence requirements with organizational risk priorities

The Intelligence Requirements Hierarchy

Intelligence requirements exist in a hierarchy that flows from broad organizational concerns down to specific, actionable information needs. Understanding this hierarchy is essential because each level serves a different audience and drives different types of intelligence work.

Standing Intelligence Requirements (SIRs)

SIRs are the highest-level, enduring intelligence needs of an organization. They represent broad areas of concern that remain relatively stable over time — typically months or years. SIRs are usually defined by senior leadership or a CISO-level stakeholder.

Examples of SIRs:

What threat actors are targeting our industry sector?
What is the current ransomware threat landscape relevant to our organization?
What vulnerabilities in our technology stack are being actively exploited in the wild?

SIRs are too broad to directly drive collection. They must be decomposed into more specific requirements.

PIRs break down SIRs into more focused questions that can be answered through intelligence collection and analysis. They are prioritized based on organizational risk, urgency, and decision-making needs. A single SIR may generate multiple PIRs.

Examples of PIRs derived from the SIR "What threat actors are targeting our industry sector?":

Which threat actors have conducted intrusions against healthcare organizations in the United States in the past 12 months?
What initial access techniques are these threat actors using against organizations with similar technology stacks?
Are any threat actors specifically targeting electronic health record (EHR) systems?

PIRs are the primary mechanism through which leadership communicates intelligence needs to the CTI team.

Essential Elements of Information (EEIs)

EEIs are the specific, granular data points needed to answer a PIR. They define exactly what information must be collected. EEIs are the level at which collection activities are planned and executed.

Examples of EEIs for the PIR "Which threat actors have conducted intrusions against healthcare organizations in the United States in the past 12 months?":

Names and aliases of threat groups reported targeting US healthcare
MITRE ATT&CK techniques associated with each group
Known malware families used by each group
Known infrastructure (C2 domains, IPs) associated with each group
Dates and descriptions of reported incidents

Specific Requests for Information (SRIs)

SRIs are ad hoc, time-sensitive intelligence requests that arise from specific events or operational needs. Unlike PIRs, which are planned and prioritized, SRIs are reactive.

Examples:

"We just saw this IP in our logs — is it associated with any known threat actor?"
"A zero-day was announced in our VPN appliance — what do we know about exploitation in the wild?"
"Our CEO is traveling to Country X next week — what is the cyber threat posture there?"

SRIs should be tracked and managed, but they exist outside the normal PIR hierarchy. If the same type of SRI recurs frequently, it may indicate a gap in the PIR framework that should be addressed.

Level	Scope	Audience	Timeframe	Example
SIR	Broad, enduring	Senior leadership	Months to years	"What is the ransomware threat to our sector?"
PIR	Focused, prioritized	CTI leadership, SOC leads	Weeks to months	"Which ransomware groups target our industry and what are their TTPs?"
EEI	Specific, granular	CTI analysts, collectors	Days to weeks	"What C2 infrastructure is associated with LockBit operations in Q1 2026?"
SRI	Ad hoc, event-driven	Any stakeholder	Hours to days	"Is this hash associated with a known campaign?"

Writing Effective PIRs

A poorly written PIR leads to unfocused collection and vague analysis. Good PIRs follow the SMART-like criteria adapted for intelligence:

Specific

The PIR must be narrow enough to be answerable. Avoid vague or overly broad questions.

Poor: "What are the cyber threats to our organization?"
Better: "Which threat actors are actively targeting the financial services sector using supply chain compromise techniques?"

Measurable

You should be able to determine when a PIR has been answered, at least partially. The PIR should allow the analyst to assess whether the answer is complete.

Poor: "How bad is the threat landscape?"
Better: "How many ransomware incidents affecting US financial institutions were publicly reported in the past 6 months, and which groups were responsible?"

Answerable

The PIR must be something your team can actually answer given available sources and capabilities. A PIR requiring access to classified intelligence is not answerable by a team without that access.

Poor: "What will APT28 do next?" (Predictive, not answerable with certainty)
Better: "What TTPs has APT28 used in campaigns against government contractors in the past 12 months?"

Relevant

The PIR must connect to organizational risk, decision-making, or operational needs. Intelligence produced in response to the PIR should be actionable.

Poor: "What new malware was discovered globally this month?" (Too broad, not tied to organizational risk)
Better: "What new malware families targeting Apache Struts have been observed, given our use of that framework?"

Time-Bound

The PIR should include a temporal scope that defines the period of interest and implies a review cadence.

Poor: "What vulnerabilities are being exploited?"
Better: "Which CVEs disclosed in the past 90 days affecting our technology stack have confirmed exploitation in the wild?"

Key Principle: A PIR should be a question that, when answered, enables a decision or action. If the answer to a PIR does not change anyone's behavior, the PIR is not relevant enough.

PIR Lifecycle Management

PIRs are not static. They have a lifecycle that must be actively managed:

Creation

PIRs are created through collaboration between CTI leadership, SOC managers, risk management, and senior stakeholders. The process typically involves:

Reviewing organizational risk assessments and threat landscape reports
Identifying knowledge gaps that, if filled, would improve decision-making
Drafting PIRs and decomposing them into EEIs
Prioritizing PIRs based on risk impact and urgency
Assigning ownership and collection responsibilities

Active Collection

Once approved, PIRs drive collection planning. Each EEI is mapped to one or more collection sources (threat intelligence feeds, open-source research, vendor reports, internal telemetry, information sharing communities). The CTI team actively works to answer the PIR through collection and analysis.

Review and Refinement

PIRs should be reviewed on a regular cadence:

Quarterly review: Assess whether each PIR is still relevant, whether the threat landscape has changed, and whether new PIRs are needed
Event-driven review: Major incidents, new threat actor campaigns, or significant organizational changes (mergers, new technology deployments) should trigger a PIR review
Annual overhaul: A comprehensive review of the entire PIR framework to ensure alignment with organizational strategy

During reviews, PIRs may be modified, reprioritized, or retired.

Retirement

PIRs should be retired when:

The question has been definitively answered and the answer is unlikely to change
The threat or risk that drove the PIR no longer exists
Organizational priorities have shifted
The PIR has been superseded by a more refined requirement

Retired PIRs should be archived, not deleted — they provide institutional memory and may be reactivated.

How PIRs Drive Collection

The connection between PIRs and collection activities is the most operationally important aspect of the PIR framework. Without this connection, PIRs are just a list of questions on a shelf.

Collection Planning

For each PIR, the CTI team develops a collection plan that maps EEIs to sources:

EEI	Source Type	Specific Source	Collection Frequency
Threat groups targeting healthcare	Commercial TI feed	Recorded Future, Mandiant	Daily automated
TTPs used by identified groups	MITRE ATT&CK	ATT&CK group pages	Monthly manual review
Active C2 infrastructure	OSINT	VirusTotal, Shodan, OTX	Weekly automated
Reported incidents	Government advisories	CISA alerts, FBI PINs	Daily automated

Gap Analysis

Collection gap analysis identifies EEIs that cannot be answered by current sources. Gaps represent either:

A need for new collection sources (additional feeds, ISAC membership, vendor subscriptions)
A need to task existing sources more specifically
An EEI that may not be answerable and should be reformulated

Feedback Loop

The most critical element is the feedback loop from analysis back to PIRs. When analysts produce intelligence in response to a PIR, they should assess:

Was the PIR fully answered, or do gaps remain?
Did the analysis reveal new questions that should become PIRs?
Were the collection sources adequate, or are new sources needed?

Alignment with Organizational Risk

PIRs must ultimately connect to organizational risk. A PIR framework disconnected from risk management produces intelligence that is interesting but not actionable.

Effective alignment methods include:

Map PIRs to risk register entries: Each PIR should trace back to one or more risks in the organizational risk register
Involve risk stakeholders: Risk management, IT leadership, and business unit leaders should participate in PIR development
Report against PIRs: Intelligence reports should explicitly reference which PIR they address
Measure PIR impact: Track whether intelligence produced in response to PIRs led to decisions or actions (new detections deployed, vulnerabilities patched, architecture changes made)

Key Takeaways

Intelligence requirements exist in a hierarchy: SIRs (broad, enduring) decompose into PIRs (focused, prioritized), which decompose into EEIs (specific, collectible), with SRIs handling ad hoc needs
Good PIRs are specific, measurable, answerable, relevant, and time-bound
PIRs must be actively managed through a lifecycle of creation, collection, review, and retirement
The value of PIRs is in their connection to collection — a PIR that does not drive collection activity is not functioning
PIRs should align with organizational risk to ensure intelligence products are actionable
Regular review cadences (quarterly at minimum) keep the PIR framework relevant

Practical Exercise

Develop a PIR framework for a fictional organization:

Define the organization: Choose an industry (healthcare, finance, energy, defense contractor) and define its basic technology stack (e.g., "mid-size hospital using Epic EHR, Windows endpoints, Palo Alto firewalls, Office 365")
Write 3 SIRs: Define three broad, enduring intelligence concerns for this organization
Decompose into PIRs: For each SIR, write 2-3 specific PIRs following the SMART criteria
Define EEIs: For one PIR, write 4-5 EEIs that specify exactly what information needs to be collected
Map to sources: For each EEI, identify at least one realistic collection source (open-source, commercial, internal, or community)
Identify gaps: Note which EEIs cannot be answered with publicly available sources — what would you need?

Learning Objectives

The Intelligence Requirements Hierarchy

Standing Intelligence Requirements (SIRs)