Priority Intelligence Requirements: The PIRs Your CTI Program Is Missing

I audited a threat intelligence program running 37 sources.

Thirty-seven. The team was proud of that number. They thought it made them look mature during the audit.

I asked one question: how does each of these get used, and who does it go to? Which one goes to the SOC. Which one goes to the board. Which one triggers a patch cycle.

Nobody in the room could answer. Not the analysts. Not the leadership. Their own monthly reports gave away the truth their words wouldn’t.

That’s not a collection problem. It’s a requirements problem. And it’s the single most common thing wrong with CTI programs I’ve seen in 30 years of doing this work.

The 3-Question Test Your CTI Program Probably Fails

Before you read another word, ask your program three questions:

1. Who is actually targeting us, specifically?
2. What do they want from us?
3. Which of their techniques would slip past our current controls?

Most programs can’t answer any of the three with precision. They can describe the general threat landscape. They can name ransomware, phishing, insider risk. What they can’t do is connect any of that to their own environment in a way that changes what an analyst does on a Tuesday morning.

That gap is what a large source count is often hiding. A long list of feeds feels like coverage. It isn’t. It’s a factory floor — the place where raw material gets made. A real program is what happens after: who receives the intelligence, what tier it goes to, what decision it triggers. Without that second half, the first half means nothing.

What a PIR Actually Is (And Why “Ransomware” Isn’t One)

A Priority Intelligence Requirement, or PIR, is a specific, answerable question tied to a decision someone in your organization actually needs to make.

“Ransomware” is not a PIR. It’s a topic. Topics tell your team to watch everything, which in practice means they watch nothing in particular.

Here’s the difference:

Topic (not useful): Ransomware

PIR (useful): Which ransomware groups have targeted organizations in our industry and revenue band in the last 90 days, and what initial access techniques did they use?

The first version produces a dashboard. The second version produces a decision — maybe a change to email filtering, maybe a patch priority, maybe a briefing to the board. One is a Google search. The other is intelligence.

Standing vs. Ad Hoc Requirements

Not every PIR runs forever. Standing requirements are ongoing — the kind of question your program should always be able to answer, like which threat actors are active against your sector. Ad hoc requirements are tied to a specific moment — a new vendor relationship, an M&A deal, a breach at a peer company that raises a specific question about your own exposure.

The mistake most programs make is writing everything as standing and never retiring anything. An ad hoc requirement that never closes doesn’t stay useful. It just becomes another source of noise sitting on top of the noise you already have.

Why Requirements Start With the Victim, Not the Adversary

It’s tempting to build your PIR set by starting with the adversary — profiling threat actors and working outward from there. That’s backwards.

Adversaries don’t target you specifically. They target the category you belong to — your industry, your size, your data, your insurance coverage. A ransomware group isn’t after your company by name. It’s after companies like yours.

Which means before you can write a useful requirement about who’s coming for you, you have to understand why anyone would come for you in the first place. What do you actually have that’s valuable? What makes you attractive? What does your exposure look like from outside your own network, not from inside where you already know all the context?

Skip that step and your requirements end up monitoring the general threat landscape instead of the specific threats with both motive and opportunity to hit you.

The 5-Step Process to Build Your PIR Set

1. Identify your crown jewels. The 3–5 assets that would hurt most if compromised — data, systems, intellectual property, client trust.
2. Identify who would want them. For each asset, who benefits from taking it, exposing it, or disrupting it? Competitors, ransomware groups, nation-states, insiders.
3. Map to your environment. Where do these assets actually live, and what’s the realistic path in — internet-facing systems, third parties, privileged accounts?
4. Write requirements as questions. Not topics. Specific, answerable questions tied to each asset.
5. Assign a consumer and a cadence. Every requirement needs an owner — someone who receives the answer and does something with it — and a rhythm for how often it gets revisited.

That fifth step is where most programs quietly fail. They’ll do steps one through four, then never close the loop on who’s actually supposed to read the output.

The Most Common PIR Mistakes

• Writing topics instead of questions. “Ransomware” again. It always comes back to this.
• Building the PIR set from what current feeds already cover, instead of from actual risk. This just reverse-engineers your existing subscription list into a set of “requirements” that were never really requirements.
• Running too many at once. Somewhere past 10–12 active PIRs, most teams lose the ability to actually track and act on all of them. More requirements isn’t more rigor. It’s the same collection-without-filter problem, one layer deeper.
• Never retiring anything. A requirement that answered a question two years ago and hasn’t been touched since is dead weight, not diligence.

Why This Matters for Regulated Industries

If you’re in healthcare, financial services, or legal, you likely already have PIRs you haven’t formally named. Regulatory obligations — breach notification timelines, sector-specific reporting requirements, client confidentiality duties — are, functionally, standing intelligence requirements. Someone needs a specific answer, on a specific cadence, tied to a specific decision.

The difference between a mature program and an immature one in these industries usually isn’t sophistication. It’s whether those obligations have been written down as actual requirements with an owner attached, or whether they’re just assumed to be “covered” because a feed exists somewhere that touches the topic.

That 37-source client eventually got down to 11 sources and 8 real requirements. Same coverage. A fraction of the noise. And for the first time, an answer when someone in the boardroom asked where the money was going.

If you want to build your own PIR set from scratch, I put together a free worksheet that walks through this exact 5-step process — download the PIR Starter Checklist and start with your own crown jewels.