Threat intelligence only earns its budget when it changes what a SOC does next: which detection rule fires, which patch jumps the queue, which alert gets escalated instead of dismissed. A feed of IP addresses and file hashes sitting in a dashboard with no link to your own environment is not intelligence. It is a subscription.
- Indicators of compromise (IPs, hashes, domains) decay in days. Attacker techniques persist for years. Programmes built only on IOC feeds are always chasing yesterday's infrastructure.
- A feed only matters once it is filtered against your own asset list, cloud footprint, and third-party dependencies. Unfiltered feeds mostly report on infrastructure you were never going to touch.
- Regulators and assessors under NESA and comparable GCC frameworks want evidence that intelligence changes detection and response, not a vendor invoice and a monthly PDF.
- The fastest way to make threat intel operational is to map it into MITRE ATT&CK and write it straight into your SIEM and EDR rule sets, not into a separate dashboard nobody opens.
Why most threat intel programmes produce dashboards instead of decisions
Most GCC threat intel deployments follow the same pattern. A team buys a commercial feed, points it at the firewall or SIEM, and treats ingestion as the finish line. Nobody validates whether the indicators ever matched real traffic. Nobody reviews which feeds are actually useful against the organisation's own exposure. The result is a world map with blinking dots and a ticker of IPs that looks impressive in a steering committee slide and does almost nothing for detection.
This happens because threat intelligence gets procured like a compliance line item rather than engineered like a capability. A feed subscription is easy to buy and easy to point to during an audit. Building intelligence requirements, validating source relevance, and wiring outputs into detection logic takes ongoing analyst time that most SOCs, especially outsourced or understaffed ones, do not budget for.
Indicators expire, techniques do not
The useful distinction here is the one security researcher David Bianco popularised as the Pyramid of Pain. IP addresses and file hashes sit at the bottom: trivial for an attacker to change and cheap for a defender to act on, but nearly worthless as a long term signal because they rotate constantly. Tools, and above them tactics, techniques and procedures (TTPs), sit near the top: expensive for an attacker to change because doing so means rebuilding their entire toolkit and operating model.
A blocklist built from yesterday's command and control IPs tells you almost nothing about tomorrow's campaign. A detection rule built around a technique, such as unusual PowerShell execution chains, credential dumping via LSASS access, or a phishing kit that harvests session tokens to bypass MFA, keeps working even after the attacker rotates infrastructure. Any threat intel programme that spends most of its energy on IOC feeds and almost none on TTP-based detection engineering has the investment upside down.
This is also why "we block tens of thousands of malicious IPs a day" is a weak metric. It measures feed volume, not relevance. The number that matters is how many of those indicators would ever have reached the organisation's actual attack surface in the first place, and almost nobody tracks that number because it requires mapping the feed against real asset and exposure data.
What NESA and comparable GCC frameworks actually expect
NESA's Information Assurance Standards, along with equivalent expectations under frameworks like ISO 27001 and sector guidance from central banks, expect entities to demonstrate a threat-informed approach to defence, not simply a paper trail. In practice, assessors want to see intelligence tied to concrete controls: patch prioritisation driven by which vulnerabilities are being actively exploited against similar organisations, detection rules that map to named techniques, and response playbooks that reflect how real intrusions in the sector actually unfold.
A contract with a threat intel vendor and a monthly report of blocked indicators satisfies a checkbox but does not demonstrate any of that. The gap shows up during incident response, when a SOC that has never validated its feeds discovers its detection rules have not moved in months while attacker infrastructure and tooling have moved several times over. Compliance and operational effectiveness are not the same thing, and an assessor who asks the right follow up questions will find the difference quickly.
Building a programme that starts with requirements, not feeds
The order matters. Most failed programmes start with "which feed should we buy" and work backwards. A working programme starts with intelligence requirements: what are the organisation's crown jewel assets, which threat actor categories realistically target this sector and region, and what would a successful attack against this specific environment look like end to end.
For a UAE bank or financial services firm, that generally narrows the priority list to financial malware families, ransomware affiliates and extortion crews with a track record of Gulf and wider MENA activity, phishing infrastructure targeting Arabic-language users and MFA bypass techniques, and third-party or supply chain exposure through software vendors and managed service providers. For a government or critical infrastructure entity, the priority shifts toward state-linked intrusion sets, spear phishing against named individuals, and OT/ICS-adjacent exposure where relevant.
Once requirements exist, source selection follows naturally. A platform like Recorded Future's threat intelligence feeds earns its cost when it can be tuned against those requirements and enriched with the organisation's own asset inventory, rather than ingested as a generic global feed. Digital risk platforms such as Cyble's dark web and brand monitoring add value specifically where brand impersonation, leaked credentials, and dark web chatter about the organisation itself matter more than generic IOC volume.
Turning feeds into detections that actually fire
An enrichment layer is what separates a working programme from a dashboard. When a new indicator arrives, the useful question is not "do we have this on a blocklist now" but "does this match anything in our own telemetry, and does it correspond to a technique we can detect independently of this one indicator." That means checking the indicator against internal logs going back weeks, not just applying it forward.
The output should land directly in the tools that make decisions: SIEM correlation rules, EDR or XDR behavioural detections, SOAR playbooks for automated containment, and vulnerability scanner prioritisation. A SIEM platform such as FortiSIEM is only as good as the rule logic and enrichment feeding it; a threat intelligence source that never reaches the correlation engine has no operational value regardless of how current it is. If a team cannot answer "which of our SIEM rules map to a named ATT&CK technique versus a static indicator," that is usually the clearest sign the programme needs to be rebuilt around techniques rather than feeds.
Where different intelligence sources actually earn their keep
Not every source serves the same purpose, and treating them interchangeably is where budgets get wasted.
- Commercial threat intel platforms (for example Recorded Future or similar enterprise feeds) give broad coverage and support executive reporting, but only pay off once tuned against the organisation's own asset and exposure data.
- Digital risk and OSINT-heavy platforms such as Cyble add value where brand impersonation, credential leakage, and dark web exposure specific to the organisation are the concern, which generic IOC feeds rarely cover well.
- Government and regional sharing channels, including NCA ECC advisories and GCC CERT bulletins, are usually the fastest route to region-specific and NESA-relevant threat context, and they matter directly for demonstrating a threat-informed posture to assessors.
- Sector information sharing bodies such as FS-ISAC for financial services give timely, sector-specific detail on phishing kits, fraud patterns and ransomware activity that generic commercial feeds do not prioritise.
- Internal telemetry, meaning SOC alerts, EDR detections, and historical logs, is consistently the highest-value source because it reflects what has actually touched the environment rather than what might touch someone else's.
External feeds tell you what is happening to organisations like yours. Internal telemetry tells you what is happening to you. A programme that under-invests in the second while over-investing in the first is optimising for the wrong signal.
The test that separates a working programme from a subscription
Before renewing a threat intel contract or adding another feed, ask three questions the vendor's dashboard will not answer for you. Can the team point to a specific SIEM rule, EDR detection, or patch decision that changed because of this source in the last quarter? Does at least one intelligence source get validated against internal telemetry rather than taken at face value? Is detection logic organised around named techniques that survive an attacker rotating infrastructure, or around indicators that expire within days?
If the honest answer to any of those is no, the fix is not a new vendor. It is redirecting analyst time from ingesting more data toward mapping the data already on hand to the intelligence requirements that should have driven the purchase in the first place.
