The last threat intelligence (TI) program I sat with had a wall of dashboards, two analysts writing weekly tactics, techniques, and procedures (TTP) reports, and a detection engineering team three desks away that hadn't read any of them. Both teams were good. Neither one had a process that closed the loop.
The intel existed. It still didn't reach the place where it would change a decision.
That program isn't an outlier. Per Recorded Future's 2025 State of Threat Intelligence report, 76% of enterprises spend $250,000 or more per year on external threat intelligence products and 91% plan to increase that spend in 2026, even as they ingest thousands of indicators of compromise (IOCs) per day.
Recent SANS SOC survey work keeps flagging the same things: alert volume, passive TI dissemination, and structured SOC tasks that nobody automated. A TI program that can't point to a specific detection rule it caused to exist or a specific investigation it made faster last quarter is producing deliverables that look like work but function more as a library nobody visits than as a working capability.
In brief:
- Most TI never reaches a detection rule or accelerates an investigation. The format mismatch between PDF-style delivery and detection engineering workflows is the structural cause, not analyst motivation.
- TI is three functions, not one. Raw intelligence sits in portals, contextual intelligence maps feeds to your environment, and operational intelligence rewrites what your SIEM does. Most programs only staff the first one well.
- Detection engineers are routing around their internal TI teams. SANS detection-engineering survey work tracks reliance on vendor-provided detection rules climbing year over year, even as internal TI-to-rule translation stays underfunded. That's the format mismatch showing up in procurement data.
- The only metric that matters is what intelligence changed last quarter. Detection rules deployed, investigations accelerated, coverage gaps closed. Feed count is vanity.
The orthodoxy I'd push back on is the framing that TI is a single capability producing a single output. It isn't. It's three different functions with three different audiences, and most programs only staff one of them well. The volume conversation, the operationalization conversation, and the measurement conversation all stay stuck until that distinction gets named.
Volume stopped correlating with value a long time ago
The assumption behind most TI procurement is that more feeds and more reports produce better security outcomes. A Google Cloud survey of more than 1,500 IT and cybersecurity professionals found 61% feel overwhelmed by feed volume and 59% struggle to derive clear action from TI data.
David Bianco's Pyramid of Pain identified the underlying problem more than a decade ago: most TI feeds deliver indicators at the bottom of the pyramid (hashes, IPs, domains) that are trivial for adversaries to rotate. Teams default to these because they're commercially available and easy to count.
TTP-level intelligence at the top costs adversaries real effort to change, but translating TTPs into detection logic requires engineering capacity most TI programs don't have and don't fund.
What "consumed" actually means in most programs
How TI reaches analysts is well-documented in SANS SOC Survey work: most of it arrives as email digests, formal reports, and PDFs. A document about a ransomware group's TTPs might get read, skimmed, or never opened. The TI team counts it as delivered either way.
The harder question is whether that delivery changed anything, and most programs can't answer it because they don't measure CTI effectiveness at all, a gap SANS CTI Survey work has documented year after year.
Forrester's measurement guidance for TI programs has told practitioners to stop relying on consumption metrics like IOC counts and reports-read tallies. That advice exists because consumption metrics remain the default. You can't close a gap you aren't measuring.
The three layers most programs conflate
I used to lump these together. Sitting through enough investigations changed that. The translation failure between layer one and layer three is where every program I've examined either earns its budget or quietly loses it.
A more useful distinction, informed by the National Institute of Standards and Technology's (NIST) Cybersecurity Framework 2.0 and MITRE's operational frameworks, separates intelligence into three layers. Most programs have Layer 1 infrastructure, some Layer 2, and very few have a measured Layer 3.
Raw intelligence sits in portals nobody checks
Raw TI is unprocessed threat data that hasn't been mapped to your environment. IP addresses, file hashes, CVE disclosures, threat actor reports in a threat intelligence platform (TIP) or vendor inbox.
NIST SP 800-207 describes this category as "most likely to be under the control of a service rather than the enterprise." A STIX/TAXII feed ingested into your SIEM, a PDF of a ransomware group's TTPs, a list of malicious domains from an Information Sharing and Analysis Center (ISAC).
The defining characteristic is that an analyst must go looking for it. It doesn't appear in a workflow unless someone retrieves it.
Contextual intelligence maps feeds to your actual environment
Contextual intelligence is TI enriched against your specific environment: asset inventory, identity systems, business criticality, network topology. NIST CSF 2.0 treats receiving intelligence (subcategory ID.RA-02) and integrating it contextually (subcategory DE.AE-07) as distinct maturity outcomes in different functional areas.
A Cobalt Strike beacon IOC means one thing when it lights up against an unmanaged developer laptop in Lagos and something else when it hits a domain controller in your primary identity provider's network. The feed gives you the same indicator either way. The SOC needs the second framing to triage.
Without this layer, the same raw IOC means everything to the feed and much less to the SOC.
Operational intelligence changes what your SIEM does
Operational intelligence is TI translated into active detection rules, response playbooks, or automated enrichment. MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center is explicit about using CTI to prioritize defenses, monitoring, and other actions, and to operationalize threat-oriented defense, adversary emulation, hunting, and response.
The analyst doesn't just receive a report. They receive an alert from a Sigma rule that was written from a TTP report, version-controlled, mapped to a specific MITRE ATT&CK technique, and deployed to production.
The translation from intelligence finding to deployable rule is the layer most programs never staff.
TI treated as a sidecar, not a system input
Katie Nickels, SANS FOR578 instructor, has framed the same problem on the SANS Threat Analysis Rundown: a TI team's value rests on how integrated it is with the broader security function, not how much intel it produces in isolation.
Anton Chuvakin has named the same problem the "intelligence-detection gap"; the chronic mismatch between what TI teams produce and what detection engineers can use, with neither side staffed to close it.
A detection lead at a mid-market fintech put it to me more bluntly last quarter: we get great TI from our provider, and we have no way to make any of it run on Monday morning. That's the gap in one sentence.
SANS SOC Survey work has repeatedly found that most SOCs use CTI primarily for incident response, a reactive posture that leaves proactive detection unfunded. SANS detection-engineering survey work tracks the parallel move on the engineering side: detection teams leaning harder on vendor-provided rules year over year, with internal TI-to-rule translation rarely staffed as a dedicated function.
That's a measurable retreat from internal TI as a source of detection content.
Enrichment without a decision attached to it
SpecterOps named the format mismatch in a practitioner blog post on detection engineering backlogs: "CTI can provide a list of all known methods of Kerberoasting via links to blogs and open-source proofs-of-concept... instead of an attached intelligence report PDF of 15 high-level explanations of Tactics, Techniques, and Procedures... The former... provides useful information that detection engineers can use to gauge the completeness of technique coverage, and the latter provides very little actionable information for a detection engineer."
The TI team produces a deliverable. The detection engineering team can't use it. Both teams count the interaction as collaboration.
Amitai Cohen's taxonomy of intelligence failure in threat detection names four failure modes: failure of observability (no logs collected), failure of utilization (logs exist but no rules built), failure of analysis (rules triggered but results misread), and failure of action (activity recognized but response too slow).
I've watched roughly a dozen TI programs at close range. I haven't run one. The pattern I keep seeing is unread TI stalled at the utilization boundary, and it's what the operators inside those programs told me was breaking, not a theory I built from outside.
The information exists. Nobody translated it into something the detection stack can execute.
Where AI helps and where it adds more unread pages
The SANS 2025 SOC Survey indicates that 40-42% of SOCs use AI/ML tools without defining them as part of the workflow, and 42% deploy AI/ML out-of-the-box with no customization.
The most concrete emerging AI application is automated translation of TI artifacts into structured detection rules, with active arXiv research on LLM-assisted detection engineering and ATT&CK mapping. AI-generated rules still require review and tuning. If you lack asset inventory, entity context, or usable TI pipelines, AI processes alerts and produces enriched output that still isn't actionable.
Gartner has also predicted that over 40% of agentic AI projects will be canceled by the end of 2027. The failure is often organizational as much as technical: AI needs the same asset inventory, behavioral baselines, and TI pipeline integration that non-AI operationalization needs.
What security leaders should be asking their programs to prove
In the programs I've looked at, "reading" TI has to mean intelligence changed a detection rule, informed a coverage gap analysis, or accelerated an investigation. Opening a PDF isn't the outcome.
The shift from static feeds to calibrated context needs three things: TI findings mapped to ATT&CK techniques and translated into Sigma rules within a defined service-level agreement (SLA); ATT&CK Navigator layers showing detection coverage against the threat actor TTP sets that matter to you; and SOC triage outcomes (true-positive and false-positive rates per rule) feeding back to the TI team on a defined cadence.
Mandiant's CTI scorecard work and ISACA's 2025 threat-led guidance both tie this back to business requirements and measurable risk reduction.
Three questions separate programs producing reports from programs producing outcomes.
- For each intelligence product delivered last quarter, can you show me the detection rule it produced or the investigation it accelerated? If the answer is "we delivered 47 reports," the program is measuring output.
- What percentage of your IOC feed generated a validated true positive in the last 90 days? If nobody knows, the feed is running on faith.
- Which threat actor TTPs are you currently unable to detect, and what's the plan to close those gaps? Without an ATT&CK Navigator layer answering that, the coverage conversation is theoretical.
Intelligence that doesn't change a rule doesn't count as read
The move I'd push hardest on is mapping last quarter's intelligence products to the rules they produced, before procurement signs off on the next feed. The exercise is free, the gap it exposes is usually the program's real problem, and the structural fix tends to follow from naming the gap.
In the programs I've seen do this well, the team running it stops calling itself a TI team within a year. It starts calling itself a detection enablement function. The name change is honest. The work was never really intelligence in isolation.
Frequently asked questions about threat intelligence
Why does most threat intelligence go unread in SOCs?
The cause is structural, not analyst motivation. TI arrives primarily as PDFs and email digests, per SANS SOC Survey work, while detection engineers need ATT&CK-mapped behavioral logic they can translate into Sigma rules.
The format mismatch means intelligence sits in portals without reaching the SIEM or endpoint detection and response (EDR) tooling where it would change an outcome.
How do you measure threat intelligence program effectiveness?
Shift from volume metrics (IOCs ingested, reports delivered) to decision metrics. Mandiant's balanced scorecard approach for CTI ties objectives, metrics, and targets to business requirements and measurable risk reduction.
The most direct metric is what percentage of delivered intelligence produced a deployed detection rule or accelerated an investigation with a validated result.
What's the difference between raw, contextual, and operational threat intelligence?
Raw intelligence is unprocessed data (IOC feeds, vendor reports, CVE disclosures) sitting in a portal. Contextual intelligence is the same data enriched against your specific assets, identities, and business criticality. Operational intelligence is TI translated into active detection rules, automated enrichment, or response playbooks.
Can AI fix the threat intelligence operationalization gap?
AI can accelerate translation of TI artifacts into detection rules, and LLM pipelines for ATT&CK mapping are an active research area.
But 42% of SOCs deploy AI tools with zero customization per SANS reporting, and without asset inventory, behavioral baselines, and integrated TI pipelines, AI generates more unread output rather than better decisions.
Why are detection engineers bypassing threat intelligence feeds?
SANS detection-engineering survey work documents year-over-year growth in reliance on vendor-provided detection rules. When TI teams deliver high-level PDF reports instead of detection-ready metadata, engineers route around the bottleneck by consuming pre-built vendor content.
The handoff fails because the two teams lack a shared format, shared tooling, and shared accountability.