Most PIR templates were written for enterprise IT. When you drop them into a plant or a substation program, they either go unanswered or produce reports no operations leader will read.
Priority Intelligence Requirements are the backbone of a serious CTI program. But the standard PIR templates floating around the industry were written with enterprise IT in mind: ransomware, phishing, cloud exposure. Drop those unchanged into an OT program and two things happen. The PIRs either go unanswered because the collection sources do not exist, or they generate reports no plant manager will read.
What makes an OT PIR different
An OT PIR needs to survive three tests:
- It ties to a decision an operations leader actually makes (maintenance window, patch deferral, vendor access, network segmentation change).
- It is answerable from sources the program can realistically collect (vendor advisories, ISAC feeds, honeypot data, internal telemetry).
- It has a defined shelf life. OT changes slowly, but not never.
Examples that hold up
- Which adversaries have demonstrated interest in the specific vendor stacks deployed in our substations in the last twelve months?
- What new vulnerabilities affect the engineering workstation software used by our field technicians, and which are being exploited in the wild?
- What ICS protocol scanning is targeting our public IP ranges, and has any of it progressed beyond initial reconnaissance?
- Which third party service providers with remote access to our OT environment have been publicly reported as breached in the last quarter?
Each of these ties to a real decision: patching, contractor access review, firewall change, vendor risk conversation.
Examples that do not
- What is the state of the ICS threat landscape?
- Are we being targeted by nation state actors?
These sound serious. They are not requirements. They are anxieties. A CTI team cannot answer them, and no one can act on the answer.
Tie them to the collection plan
Every PIR should map to at least one collection source that could plausibly answer it. ThreatSpire ties PIRs directly to evidence, actor profiles, and IOC records so an analyst can see, at a glance, whether a requirement is being fed or is quietly starving. Starved PIRs are usually a sign the requirement was written for the wrong audience.