How to Write Priority Intelligence Requirements for a Bank SOC

Most bank SOCs receive far more threat intelligence than anyone can read. Without priority intelligence requirements (PIRs), feeds pile up indicators, nobody can say which ones matter, and the board question "which threats should we worry about?" gets a generic answer. This guide shows threat intelligence and SOC analysts in banks, payment firms and trading businesses how to write PIRs tied to business risk, wire them into Microsoft Sentinel and measure whether the intelligence is changing anything.

Start from business risk, not from feeds

The intelligence cycle starts with direction: someone has to say what they need to know. If you start from the feeds you already buy, you end up describing the threat landscape in general rather than the threats to your bank. Start instead with what the business cannot afford to lose.

In UK financial services, a ready made list often exists already. Under the FCA and PRA operational resilience rules, firms identify their important business services, such as making payments, giving customers access to accounts or executing trades, and set impact tolerances for them. Each of those services has an owner, and each owner is a potential consumer of intelligence.

Then list the threat areas that could hurt those services. Most banks end up with a similar set, weighted differently by business model.

Write PIRs someone can actually answer

A PIR is a question, not a topic. "Ransomware" is a topic. "Which ransomware groups are currently targeting UK banks or their critical suppliers, and how do they get initial access?" is a question you can answer, update and close. A useful PIR has five parts:

• The question, specific enough that you would know when it has been answered.
• The decision it supports, such as which controls to fund or which detections to build first.
• The consumer, a named role who will act on the answer.
• The time horizon, for example the next 12 months for strategic questions or the next week for tactical ones.
• A review date, so stale PIRs are retired rather than left to drift.

PIRs also sit at different levels, and each level has a different audience and rhythm. Make sure your set covers all three, or you will serve the SOC well and the board badly, or the other way round.

Break each PIR into collection questions

A PIR is usually too broad to collect against directly. Split each one into a few specific questions, then decide where the answers will come from. For PIR-01, that might be: which lure themes are customers reporting, which sender domains appear in reported phishing, and which mailbox rule patterns appear in confirmed compromises.

• Internal telemetry first: fraud case notes, user phishing reports, SOC incidents and customer complaints are often the best source for fraud PIRs.
• Sector sharing: communities such as FS-ISAC share campaign details and indicators between financial institutions.
• Government: NCSC advisories and alerts, and joint advisories from international partners.
• Commercial feeds: judge each one by which PIRs it answers, not by the number of indicators it supplies.
• Open source: vendor research blogs, certificate transparency logs and public reporting on supplier incidents.

Tag intelligence by PIR in Sentinel

Once PIRs exist, make them visible in your tooling. Ask whoever manages your threat intelligence platform to add a tag such as PIR-01 to indicators that relate to each requirement. Those tags travel with the indicator into Sentinel.

Use the current tables. Sentinel stopped ingesting into the legacy ThreatIntelligenceIndicator table in 2025 and support for it ended on 31 May 2026. Indicators now land in ThreatIntelIndicators, with STIX objects such as threat actors and attack patterns in ThreatIntelObjects. Indicators are republished every 7 to 10 days, so take the latest row per indicator before counting.

ThreatIntelIndicators
| where TimeGenerated > ago(14d)
| summarize arg_max(TimeGenerated, *) by Id
| where IsDeleted == false
| where isnull(ValidUntil) or ValidUntil > now()
| extend FeedSource = base64_decode_tostring(tostring(split(Id, "---")[0]))
| extend PIR = extract(@"(PIR-\d+)", 1, tostring(Tags))
| extend PIR = iff(isempty(PIR), "Untagged", PIR)
| summarize Indicators = dcount(Id) by FeedSource, PIR, ObservableKey
| order by FeedSource asc, Indicators desc

The FeedSource line decodes the source name from the first part of the indicator ID, which is the method Microsoft uses in its own example queries. A feed whose indicators are almost all "Untagged" is supplying data that nobody has linked to a requirement.

Counting indicators only tells you what you hold. The more useful question is which feeds produced matches in your own telemetry. This query joins active IP indicators to Entra ID sign in logs, which suits PIR-01 because BEC usually starts with a stolen login.

let ActiveIPs = ThreatIntelIndicators
    | where TimeGenerated > ago(14d)
    | summarize arg_max(TimeGenerated, *) by Id
    | where IsDeleted == false
    | where isnull(ValidUntil) or ValidUntil > now()
    | where ObservableKey == "ipv4-addr:value"
    | extend FeedSource = base64_decode_tostring(tostring(split(Id, "---")[0]))
    | project IndicatorIP = ObservableValue, FeedSource, Confidence, Tags;
SigninLogs
| where TimeGenerated > ago(30d)
| join kind=inner ActiveIPs on $left.IPAddress == $right.IndicatorIP
| summarize SignIns = count(),
    Successful = countif(ResultType == "0"),
    Users = dcount(UserPrincipalName),
    SampleUsers = make_set(UserPrincipalName, 10)
    by FeedSource, IndicatorIP
| order by Successful desc, SignIns desc

Turn PIRs into hunts and detections

Indicators expire. Techniques last much longer. For each operational PIR, map the behaviours you learn about to MITRE ATT&CK techniques, then check whether you have a detection or a scheduled hunt for each one. The gaps become your detection engineering backlog, already ranked by business risk.

Then report on the PIRs the way the business reads risk. A quarterly summary like the one below gives the CISO something concrete for the budget conversation in the scenario.

Review, report and retire PIRs

PIRs are not permanent. Review them every quarter with their consumers, and immediately after a major incident, a new regulatory requirement or a change in the business, such as launching a new payment product. Ask three questions each time: was the PIR answered, did the answer change a decision, and is the question still the right one?

1. L0
   Feed drivenIntelligence is whatever arrives. Reports describe the landscape in general.
   Common start
2. L1
   PIRs writtenA small set of agreed questions with named consumers and review dates.
   CTI team
3. L2
   PIRs in toolingIndicators tagged by PIR, techniques mapped to ATT&CK and to detections.
   CTI and SOC
4. L3
   PIRs drive spendFeed renewals, detection backlog and testing scenarios all justified against PIRs.
   CISO

Well maintained PIRs also feed regulatory work. Threat led penetration testing under CBEST in the UK, or TLPT under DORA for EU entities, begins with a targeted threat intelligence phase, and your PIR answers give that phase a strong starting point. Your important business services self assessment benefits in the same way, because severe but plausible scenarios are easier to defend when they rest on documented intelligence.

Key takeaways

Book thirty minutes with your Head of Fraud and your operational resilience lead this month and draft three PIRs together. Then run the first query above to see how much of your current intelligence already relates to them. The gap between the two is usually the clearest argument you will have for where the intelligence budget should go next.

Written by Riz, Senior Cybersecurity Consultant, Finance