Most cyber threat intelligence programmes collect far more than anyone uses, because nobody wrote down which decisions the intelligence is meant to support. Priority intelligence requirements (PIRs) fix that by stating, in business language, the questions leadership and defenders need answered, and by tying every feed, report and hunt to one of them. This template gives a ready-to-adapt structure: scope and triggers, roles, how to elicit requirements, the PIR register, the collection plan, production and dissemination, and review. It is written for CTI leads, SOC and incident response managers, and CISOs setting direction for an intelligence function. The wider programme is in the Threat Intelligence Guide; this page is the requirements document that should sit at its centre.
How to use this template
- Replace placeholders: every [Organisation], [Role] and bracketed value. Delete examples that do not fit; keep the numbering.
- Keep it short: FIRST's CTI curriculum stresses that PIRs should be limited and well scoped ("less is more"). Aim for 5 to 10 PIRs for the whole organisation.
- Write in business language: a PIR that only the CTI team understands will not be prioritised or funded.
- Treat it as a living document: FIRST describes PIRs as fluid; re-evaluate them when the business or threat environment changes, not only on the annual cycle.
- Structure note: sections follow the house playbook numbering but are adapted to the intelligence cycle: direction (sections 1 to 3), collection (4 to 5), processing and production (6), dissemination (7) and feedback (8).
1. Scope and triggers
1.1 Purpose. This document sets out the intelligence requirements of [Organisation], who owns each one, how they are collected against, and how results are delivered. All intelligence collection, purchased feeds and analyst time must trace to a requirement in section 4.
1.2 Scope. Cyber threats to [Organisation]'s people, systems, products, data, suppliers and brand, including threats to human and non-human identities (staff accounts, service accounts, API keys, OAuth applications and AI agents).
1.3 Triggers for review. Requirements are reviewed [every six months] and additionally when any of the following occurs:
- A major business change: acquisition, new market or country, new product line, major cloud or SaaS migration.
- A significant incident at [Organisation] or a close peer in the sector.
- A new regulatory obligation that depends on threat awareness.
- A stakeholder reports that intelligence products no longer support their decisions.
- A collection source is lost, added or changes its terms.
2. Roles and contacts
| Role | Responsibility | Named person |
|---|---|---|
| Executive sponsor | Approves PIRs; resolves conflicts in priority; receives the quarterly review | [CISO or equivalent] |
| CTI lead (requirements owner) | Runs elicitation, maintains this document and the collection plan, reports coverage | [Name] |
| Requirement owners (stakeholders) | Own one or more PIRs; state the decisions they support; give feedback on products | [Names per PIR] |
| Collection manager | Maps sources to requirements; manages feed contracts and sharing communities | [Name] |
| Analysts | Produce assessments against requirements; grade sources; state confidence | [Team] |
| Consumers | SOC, incident response, vulnerability management, identity team, fraud, product security, executives | [Team leads] |
FIRST recommends that PIRs are not built by the intelligence or collection manager alone, and suggests a risk working group that includes an executive representative, legal, human resources, finance, marketing, internal security and product security. Add the identity and access management team where identity threats are in scope.
3. Detection and triage: eliciting requirements
This section describes how needs are found and triaged into requirements.
- Identify decisions, not topics: interview each stakeholder with three questions: what decisions do you make that depend on knowing about threats; how often; and what would you do differently if you knew more. FIRST frames PIRs around key decision points and courses of action.
- Record in business terms: capture what is at risk, the decision needed and the options available, before translating to technical questions.
- Triage the long list: score each candidate on business impact of the decision, frequency, and whether intelligence can realistically answer it. Merge duplicates.
- Select PIRs: the executive sponsor approves the top 5 to 10. Others become standing information requirements or are rejected with a reason.
- Break down: each PIR is decomposed into specific intelligence requirements and essential elements of information (section 4.2) that collection can target.
| Stakeholder | Typical decision | Candidate requirement |
|---|---|---|
| Board and CISO | Where to invest; risk appetite | Which threat actor groups are most likely to target [Organisation] in the next 12 months, and with what objectives? |
| SOC and detection engineering | Which detections to build and tune | Which techniques are actors targeting our sector currently using against our identity provider, edge devices and cloud? |
| Vulnerability management | What to patch first | Which vulnerabilities in our technology stack are being exploited or are likely to be? See the EPSS Guide. |
| Identity team and service desk | Help desk verification, MFA policy | Are social engineering campaigns against help desks and MFA reset processes targeting our sector? |
| Fraud and customer identity | Account takeover controls | Are credentials or session tokens for our customers or staff being sold or used? |
| Third-party risk | Supplier onboarding and response | Have any critical suppliers been compromised or named in leak sites? |
4. Containment: the requirements register
This section contains the register, which keeps collection within agreed limits.
4.1 Hierarchy. [Organisation] uses three levels:
- Priority intelligence requirement (PIR): a leadership-level question tied to a decision. Few, stable, owned by a named stakeholder.
- Intelligence requirement (IR): a more specific question that helps answer a PIR. Owned by the CTI lead.
- Essential element of information (EEI): a concrete, collectable fact, such as "new phishing domains imitating [brand]" or "posts offering access to [Organisation] VPN accounts".
4.2 Register. Copy this table for each PIR.
| Field | Entry |
|---|---|
| PIR ID and title | PIR-[03]: Identity-focused intrusion against [Organisation] |
| Question | Which actors are targeting identity providers, help desks and machine credentials of organisations like ours, and how? |
| Decision supported | Prioritising identity controls, help desk verification rules and detection content each quarter |
| Owner | [Head of identity and access management] |
| Consumers | SOC, identity team, service desk manager, CISO |
| Intelligence requirements | IR-03.1 Active campaigns against our IdP and SSO platform; IR-03.2 Social engineering of help desks in our sector; IR-03.3 Theft and sale of tokens, API keys and session cookies |
| Essential elements of information | Actor techniques mapped to MITRE ATT&CK; lookalike domains; infostealer logs containing our domains; leaked keys in public code |
| Priority and timeliness | High; urgent findings within [4] hours, summary monthly |
| Product type | Flash alert, monthly brief, detection requests |
| Review date | [Date] |
Example PIR-03 is relevant to most organisations: groups such as those described in the Scattered Spider Threat Actor Profile have repeatedly used help desk social engineering and identity provider access. See the Account Recovery and Help Desk Security Guide for the controls that intelligence on this PIR should feed.
5. Eradication: the collection plan
This section removes collection that serves no requirement. For each EEI, record where the answer can come from and how well each source covers it.
| EEI | Internal sources | External sources | Coverage (full, partial, none) | Gap action |
|---|---|---|---|---|
| Infostealer logs containing our domains | EDR telemetry, IdP sign-in anomalies | Commercial feed [name], national CERT notifications | [Partial] | [Evaluate a credential exposure service] |
| Help desk social engineering in sector | Service desk call records, incident tickets | Sector ISAC, peer sharing group | [Partial] | [Join sector working group] |
| Exploited vulnerabilities in our stack | Asset inventory, scanner results | CISA KEV, EPSS, vendor advisories | [Full] | None |
- Retire unused sources: any feed that maps to no EEI for two consecutive reviews is a candidate for cancellation.
- Grade sources: rate each source and item using a reliability scale A (reliable) to F (cannot be judged) and a credibility scale 1 (confirmed) to 6 (cannot be judged), as described in FIRST's CTI curriculum; record combined grades such as B2.
- Sharing rules: handle shared material according to its Traffic Light Protocol label (TLP 2.0: RED, AMBER, AMBER+STRICT, GREEN, CLEAR), and record any sharing agreements, following the planning steps in NIST SP 800-150. See the Threat Intelligence Platform Buyer's Guide for tooling.
6. Recovery: production standards
This section sets how analysis is turned into products that answer requirements.
- Every product cites a requirement: the header of each report lists the PIR and IR IDs it answers.
- Bottom line first: follow FIRST's briefing structure for leadership (who, what, when, why, and what you need the leader to do) in 3 to 5 sentences, with technical detail in an annex.
- State likelihood and confidence separately: use estimative terms (highly unlikely, unlikely, even chance, likely, highly likely) for likelihood, and high, moderate or low for confidence, in separate sentences, as the FIRST curriculum recommends.
- Make it actionable: each product ends with recommended actions, such as detection requests to the SOC, patch priority changes or identity control changes. See the Threat Hunting Guide for turning intelligence into hunts.
- Use shared models: map adversary behaviour to MITRE ATT&CK and describe campaigns with the Diamond Model where useful. See the Cyber Kill Chain and Diamond Model Guide.
7. Communication and notification
| Product | Audience | Frequency | Channel |
|---|---|---|---|
| Flash alert | SOC, owners of affected PIRs | As needed, within [4] hours | [Ticket queue and chat channel] |
| Operational brief | SOC, incident response, identity, vulnerability management | [Weekly] | [Email or TIP] |
| Strategic assessment | CISO, risk committee | [Quarterly] | [Briefing] |
| Board summary | Board or audit committee | [Twice yearly] | [Board pack] |
| Detection request | Detection engineering | As needed | [Backlog] |
Mark every product with a TLP label and a distribution list. External sharing with peers or an ISAC follows the sharing rules in section 5.
8. Post-incident review: feedback and retirement
- Feedback after use: requirement owners rate products on relevance, timeliness and actionability ([1 to 5]) at least quarterly.
- After every major incident: ask whether an existing PIR should have warned of it, and whether collection or production failed. Record the answer and add or adjust requirements.
- Retire requirements: PIRs that no longer support a live decision are closed with a note, not left to grow the list.
- Report coverage: the CTI lead reports to the sponsor the measures in the implementation section.
Implementation guidance
Rollout.
- Weeks 1 to 2: interview 8 to 12 stakeholders using the questions in section 3; build the long list.
- Week 3: run the working group session; agree 5 to 10 PIRs with the sponsor.
- Weeks 4 to 5: decompose into IRs and EEIs; build the collection plan and mark gaps.
- Week 6: tag every current feed and product to a requirement; flag untagged ones for review.
- Quarter 2: issue the first products under the new structure, collect feedback, adjust.
Small organisations can run with 3 to 5 PIRs, rely on free sources (national CERT alerts, CISA KEV, sector ISAC) and a managed intelligence service, and review twice a year. Large organisations should keep the register in the threat intelligence platform, link requirements to collection and products automatically, and assign deputies to each requirement owner. See the Threat Intelligence Maturity Model for where requirements management sits in programme maturity.
Measures.
- Percentage of products tagged to a requirement (target 100 percent).
- Percentage of PIRs with at least one product in the last quarter.
- Average stakeholder feedback score per PIR.
- Number of detection or control changes made as a result of intelligence.
- Percentage of paid sources mapped to at least one EEI.
Framework mapping.
| Framework | Reference | How this template supports it |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02, ID.RA-03, GV.OC-02 | Receiving threat intelligence; identifying threats; understanding stakeholder needs |
| NIST SP 800-53 Rev. 5 | PM-16, PM-15, SI-5, RA-3 | Threat awareness programme; security groups and associations; alerts and advisories; risk assessment |
| ISO/IEC 27001:2022 Annex A | A.5.7 | Threat intelligence |
Common failure patterns. Requirements written by the CTI team alone; dozens of PIRs that are really topics; feeds bought before requirements exist; products without a requirement reference; and no feedback loop, so the register goes stale within a year.
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence Maturity Model · OpenCTI Guide · Threat Hunting Guide