Threat Intelligence PIRs: A Workbook and Collection Plan

A priority intelligence requirement, or PIR, turns an expectation of intelligence into a question that supports a specific decision. “Track ransomware” gives an analyst a topic. “Which supplier access arrangements should we review before the next maintenance window?” creates work with an identifiable customer, evidence requirements, and an end.

In a Reddit discussion dated September 11, 2026, an analyst moving into CTI asks what the work involves day to day. Replies include the needs of the teams receiving intelligence. The thread illustrates a scoping problem; it does not measure how the entire profession operates.

The workbook below addresses that problem. You can maintain it in a shared document or your existing ticketing system. Its value depends on the decisions it supports and the collection it allows you to stop.

Start with a decision someone will actually make

Interview the intended customer before adding new sources. Ask them to describe a recent choice: an exception they accepted, an access path they retained, a control they delayed, or an investigation that started too late. Identify the point at which better information would have changed their decision.

This approach is consistent with the CTI Capability Maturity Model, which organizes program development around support for internal stakeholders. The model cannot replace your interviews. A fraud manager, detection team, and legal function need different answers, even when they read about the same threat.

Record four things in the customer's language: the decision, the options still available, the last useful delivery time, and the consequences of getting it wrong. If the choice is already irreversible, background research might still be useful, but it does not automatically deserve a place among active PIRs.

A stakeholder might request “daily monitoring of actors targeting us” without naming a corresponding action. Clarify whether they need to select hunt scenarios, reassess a supplier, prepare an exercise, or change an access rule. That precision makes the eventual research easier to assign and review.

An analyst should also identify decisions that belong elsewhere. A request to list every unsupported system is primarily an inventory problem. CTI can add relevant threat context, but it cannot create a reliable asset inventory by reading external reports.

Write a question narrow enough to answer

A useful PIR identifies a target, a time horizon, and a connection to action. Avoid questions that assume their own answer. “How do we prove this supplier is dangerous?” commissions confirmation. “What evidence supports changing its access, and what supports retaining it?” permits a challenge to the initial concern.

The FIRST curriculum on PIRs emphasizes limited requirements, adaptation as conditions change, and stakeholder involvement. The worksheet here is a practical proposal for applying those principles in a company, rather than reproducing a military collection organization.

Compare these formulations:

• Too broad: What threats affect our sector?
• Still unclear: Which groups attack our technology suppliers?
• Actionable: Which supplier remote access arrangements permit the techniques described in the selected campaigns, and which exceptions should change before maintenance?

The final question needs external observations and internal verification. An honest partial answer remains possible: the campaigns are documented, but the access inventory cannot yet support a decision. The PIR reveals a data gap instead of hiding it inside a general report.

The guide to strategic, operational, and tactical intelligence explains the wider audiences. The requirement itself should remain attached to one concrete decision.

Use a PIR worksheet that fits on one screen

The following original template is deliberately compact. Uncertainties and stopping conditions are required working fields, even when the customer would prefer an immediately certain answer.

Identifier: PIR-ACCESS-01
Priority question:
Decision to support:
Decision owner:
Options still available:
Included scope:
Excluded scope:
Last useful delivery date:
Evidence needed to answer:
Accessible sources and their owners:
Important information gaps:
Delivery format:
Completion or suspension conditions:
Conditions for reopening:
Assigned analyst and next review:

The excluded scope prevents quiet expansion. Research into supplier access does not automatically include every subcontractor, every company subsidiary, and every vulnerability in the supplier's products. Each addition consumes time and can change the permissions needed to collect information.

The last useful delivery date is more than an administrative deadline. An assessment delivered after a change freeze cannot guide that week's modifications. It could still support monitoring or the next maintenance window, but the customer and analyst should explicitly agree to that revised purpose.

Keep an actual decision owner. “Leadership” or “the SOC” is not enough when two teams disagree about the consequences of a restriction. The analyst develops the assessment; an identifiable stakeholder chooses between the options.

Break the question into evidence requirements

A well-written question does not immediately become a search query. Break it into observable elements, then connect each element to a source capable of knowing it.

In the remote access example, the first branch concerns campaigns: which techniques and prerequisites appear in the selected reporting? The second concerns local exposure: which accounts, gateways, and exceptions permit those prerequisites? The third concerns the decision: which services depend on that access, and which alternatives exist?

A threat report can inform the first branch. It cannot prove that an internal account has a particular permission. Conversely, a configuration export describes access but does not establish that an adversary is currently using the corresponding technique. Do not make one source fill another source's role.

Before purchasing more coverage, examine threat intelligence sources and their evidence. The NCSC Cyber Assessment Framework's C1 principle connects source selection with business and sector needs. Turn that principle into a testable question: which part of this requirement can the source actually illuminate?

Preserve negative findings carefully. A source returning no relevant reporting might have no visibility into that technology or region. Record the limitation instead of converting an empty result into evidence that the threat does not exist.

Build the collection plan before running searches

A collection plan specifies an action, an expected output, and an effort allowance. “Search the internet” does not let anyone track progress or explain why collection ends. Use a small work item for each evidence requirement.

Need: identify access conditions used in the selected campaigns
Collection: read the selected primary reports
Output: technique, prerequisite, date, source, limitation
Owner: CTI analyst
Initial effort: one bounded research session
Possible follow-up: request clarification from the source
Stop when: the necessary prerequisites are documented

In another work item, the identity team supplies a dated account inventory, ownership information, and access restrictions. A third asks the application owner to explain operational dependencies. This prevents the analyst from discovering at the deadline that decisive information was available only through another team.

Account for human response time. An API request can be quick, while log access approval or an ownership check holds the assessment for days. Start the requests most likely to block the conclusion early, then continue independent research while they move through their normal process.

The OSINT workflow for SOC analysts describes potential source families. The PIR plan selects the ones that answer your question and records what they cannot cover. It should also identify sources you considered and rejected, with a short reason, so the next analyst does not repeat the same search.

Worked example: reviewing supplier maintenance access

The following case is fictional. A company is preparing maintenance on its order management system. A supplier connects remotely. The operations owner must choose between retaining existing access, restricting it to the maintenance window, or postponing the intervention.

The PIR becomes: “Do the supplier's access arrangements permit the abuse techniques described in the selected reporting, and which option reduces exposure without preventing maintenance?” The decision concerns this access for this intervention. It does not attempt to attribute a campaign or assign the supplier a universal risk rating.

The analyst extracts technical prerequisites from reporting. The identity team confirms that some accounts have permanent access. Operations explains that a temporary named account can perform the same task. The SOC checks which logs would support an examination of that account's use. These are hypothetical findings used only to demonstrate the workflow.

The assessment can recommend an option without declaring the supplier compromised. Permanent access creates an abuse opportunity described in the evidence; an operational alternative exists; the available information does not establish an intrusion. The owner can reduce an exposure without waiting for an actor's identity.

If the identity team cannot provide the inventory, the conclusion changes. The analyst records the missing information and proposes a verification action before maintenance. They do not substitute the configuration of a company described in a public report for their own unknown configuration.

The worksheet also preserves the cost of the alternative. If temporary access requires an on-call operator, that dependency belongs in the decision. Omitting it makes the recommendation look easier to implement than the evidence supports.

Define completion, suspension, and reopening rules

A permanent PIR can become an unlimited subscription to research. Define several possible endings when you open it.

Completed with an answer means the customer has the agreed evidence needed to choose. No longer applicable follows a project or scope change. Suspended preserves a useful requirement blocked by inaccessible information. Keep these outcomes separate in reporting: they explain very different kinds of work.

Add a collection value rule. If new searches repeat the same sources without reducing the uncertainty that matters, ask the customer to decide whether further effort is justified. Additional time reading derivative articles cannot replace a missing access log. The effort allowance does not determine truth, but it is a constraint the assessment should acknowledge.

Reopening should follow a defined event: a relevant new technique, an access change, a replacement supplier, or contradictory local evidence. A newer publication does not always justify restarting the file. State how it changes the decision before collecting again.

There should also be a way to reopen a requirement after a decision. If implementation fails or a key assumption changes, the old assessment may no longer support the chosen option. Retain that link between the intelligence requirement and the operational action.

Deliver an answer that preserves its limitations

The final product repeats the exact question, the answer, the decisive evidence, and the consequence for each option. Put raw observations in an accessible appendix. The customer should understand the assessment without reading your browsing history, and should find the sources when they challenge it.

Separate an absence of detected activity from missing data. “No relevant events in the available logs” does not mean “no possible abuse.” Specify the covered period, queried systems, and missing telemetry. The guide to reusing report evidence supports keeping dated observations instead of an isolated conclusion.

For an executive customer, use the decision-oriented CTI brief template to turn the answer into a clear choice with supporting evidence.

After the choice, ask which evidence mattered and which material was unnecessary. If the report made no difference, investigate why: the question arrived too late, the options were already closed, or the research missed the real uncertainty. That feedback improves the next requirement without treating every accepted recommendation as a proven success.

Test the workbook with one live requirement

Choose an upcoming decision and complete the worksheet with its owner. Have the teams responsible for evidence review the collection plan. Remove searches whose outputs cannot influence an available option. Schedule the assessment review before the useful deadline, leaving time to resolve a challenge.

When a requirement needs IP or domain context, the first IOC lookup with the IsMalicious API can help add that enrichment to the evidence file. Keep the result as one dated observation among others. Answering the PIR remains an analysis of the evidence relevant to the decision, with explicit gaps and an accountable owner.