6 min read · Updated September 2026
A priority intelligence requirement is a question about the external threat landscape that an organisation needs answered in order to make a decision, written as a question rather than a topic and ranked against the other questions competing for the same collection effort. PIRs are what an intelligence function collects against; everything downstream is answerable to them.
Read first: The intelligence cycle (the cycle this sits at the top of)
Most intelligence functions that are struggling are struggling here. Not at collection, which is largely a purchasing problem, and not at analysis, which is a hiring problem, but at the prior question of what the organisation actually needs to know. Arriving at a set of requirements that are both relevant and answerable is the hardest task in standing up a capability, and it stays hard at every size of organisation.
The symptom of getting it wrong is recognisable: a team producing a respectable volume of reporting that nobody can connect to a decision, and a stakeholder asking, reasonably, what any of it was for.
The single most common defect in a requirement set is that the entries are topics. "Ransomware" is not a requirement. "Threat actors" is not a requirement. Neither can be answered, which means neither can be closed, which means no piece of collection can ever be judged against it.
A requirement is phrased as a question, and a good one reaches for the who, what, where, when and why of an adversary: their objectives, their capabilities, the methods they favour. What tactics, techniques and procedures are likely to be used by the threat actors targeting our industry is a requirement. It has an answer, the answer can be wrong, and you can tell when you have it.
Start broad and narrow down. An opening requirement as simple as which threat actors are targeting my organisation is a legitimate starting point, because it opens the line of inquiry that later requirements refine. What it must not do is stay that vague once the function matures.
PIRs address the external threat landscape. They are not the place for questions about your own controls, your own tooling or your own security performance. Those are worth asking, and they belong to a different function with a different reporting line.
The distinction matters more than it sounds. Once internal control questions enter the requirement set, the intelligence team starts being measured on the organisation's defensive posture rather than on its understanding of the threat, and collection quietly reorients toward what is easy to observe internally rather than what is happening outside.
Not every intelligence need carries the same weight, and pretending otherwise is how a requirement set becomes a wish list. Prioritisation means assessing which threats present the greatest risk to this organisation and pointing finite collection and analyst time at those first.
Assigning explicit priority numbers to requirements, and to the sub-questions beneath them, gives analysts something to work from when two things compete for the same afternoon. Without it, the ranking still happens, but it happens implicitly and usually in favour of whatever arrived most recently.
Priorities are not set once. If an actor known for targeting your sector escalates, the requirement set should move to follow it. A requirement list that has not changed in a year is describing a threat landscape that does not exist.
A requirement on its own is usually too broad to collect against directly. Essential elements of information are the sub-questions that break it into parts a collector can actually pursue.
If the requirement is which threat actors are targeting my organisation, the elements beneath it might be: what motivates them, what their primary method of attack is, and which specific systems or data they go after. Each of those is narrow enough to point an asset at, and together they answer the parent question with more depth than any single sweep would have produced.
This layering is also what makes an answer auditable. When a report claims to address a requirement, you can ask which element it satisfied, and the question has a real answer.
Many requirements are standing: ongoing questions that are never finished and are revisited continuously, because the answer changes. Which threat actors are targeting my organisation is the type. Its value comes from being asked repeatedly.
Others are specific and time-bounded, raised in response to something that just happened, answered once, and closed. Both are legitimate. Managing them as though they were the same thing is not: standing requirements never close, so mixing them into a list of open taskings makes the list permanently alarming and therefore ignorable.
Structuring requirements around the major threat vectors, phishing, malware, hacking, denial of service and insider threat, gives coverage a shape you can inspect. It is immediately visible which vector has three requirements and which has none, and that gap is a conversation worth having rather than an oversight nobody noticed.
This is also what makes requirement coverage legible to people outside the intelligence function. A stakeholder who would struggle to evaluate a list of questions can see at once that nothing in the set addresses the way their business unit is most likely to be attacked.
A requirement set is an unusually revealing document. It says what an organisation believes it is exposed to, which threats it is worried enough about to spend money on, and, by omission, where it knows it cannot see. That is a description of your own weaknesses and intelligence gaps, written down and prioritised.
It should be classified and handled accordingly, and it is worth being deliberate about who outside the function sees the whole list rather than their own part of it.
Every intelligence report should name the requirement it addresses. This sounds administrative and is not. It is the mechanism that keeps the function honest, because it makes two things visible at a glance: which requirements are generating reporting, and which reporting exists without a requirement behind it.
It also teaches stakeholders the vocabulary. A recipient who repeatedly sees that a report answers a question they helped write starts to understand what the function is for, and starts asking better questions.
Metrics against requirements answer a question that is otherwise a matter of opinion: is this working. Tracking which requirements are consistently served and which are consistently unserved tells you where the capability is thin, and it does the same job for vendors, whose performance can be assessed against the requirements they were bought to satisfy rather than against the volume of material they deliver.
A requirement that nothing can answer is not a failed requirement. It is a collection gap, and it should be raised as one to whoever decides on investment.
Different parts of the organisation have genuinely different intelligence needs, and a good requirement set absorbs them. The risk is that the loudest business unit, or the one closest to the intelligence team, ends up over-represented while a quieter one with more exposure is under-served.
Incorporating business unit requirements without bias is a discipline rather than a process step. It usually means someone periodically asking which parts of the organisation appear nowhere in the requirement set, and whether that is a judgement or an accident.
Requirements only become operational when each one is matched to an asset capable of answering it. That matching exercise is the collection plan: each requirement paired with the tool, source or relationship best suited to it, based on a sober view of what each asset can actually do.
Not every asset is good at every question. A network monitoring tool may be excellent at identifying malware communication patterns and useless at establishing why an actor is doing what they are doing. The pairing has to respect that, and where a requirement has no capable asset behind it, the plan has surfaced a gap that was previously invisible.
Conundrum treats requirements as the primary object rather than as configuration. They are written as questions, held at three nested tiers so organisation-level, sector-level and global questions do not compete in one flat list, and the wording is yours to edit, which re-ranks what surfaces beneath it rather than just relabelling a filter.
Every generated report names the requirement it answers, and requirement coverage is visible per threat vector, so the gaps described above are on screen rather than discoverable only by audit.
