Your Threat Intel Program Is Measuring the Wrong Thing
Most CTI programs measure IOCs ingested and reports published — activity, not effect. Here's what operationalized intelligence actually looks like.
Most CTI programs can tell you exactly how many indicators they ingested last quarter. Almost none can tell you how much their detection coverage improved as a result.
That asymmetry is the structural failure. Not a funding problem, not a staffing problem, not a vendor problem — a measurement problem. Programs measured by output volume are incentivized to produce volume. The security posture improvement is downstream of that incentive, unchecked and unmeasured.
Only 55% of CTI teams have any method for measuring their own effectiveness, according to the SANS 2025 CTI Survey [1] — and that’s up from 36% the year before. Nearly half of all CTI programs operate with no feedback loop between what they produce and what changes downstream.
The Measurement Problem
The standard CTI scorecard: reports published, IOCs ingested, feeds subscribed, alerts generated. These numbers are easy to collect, easy to put in a slide deck, and genuinely useless as a measure of program effectiveness.
They measure activity. A CTI team that publishes 40 reports per quarter and ingests 3 million IOCs is visibly busy. Whether any of it changed what the SOC detected, how fast analysts resolved alerts, or whether a single incident was correctly attributed — that’s a different question, and the metrics don’t touch it.
The consequence is that CTI programs can sustain high activity for years while the catch rate stays flat. I broke down how detection coverage compounds in The Detection Funnel: the average organization successfully detects around 6% of adversary techniques active in its environment. A CTI program that doesn’t close the Stage 1 gap — that doesn’t add net-new working detections — is not moving that number.
Failure Mode 1: The IOC Feed Trap
IOC feeds feel like intelligence because they’re high-volume, automated, and produce a continuous stream of something to act on. The SIEM is ingesting. The TIP is populating. The dashboard shows green.
Here is what is happening underneath: 90% of C2 servers have a lifetime under five days. DGA-based domains rotate in under 24 hours. IP addresses used for malicious infrastructure are recycled to legitimate services in days to weeks. A typical enterprise SIEM ingests between 500,000 and 2 million new IOCs daily from 10 to 20 feeds. Most expire before anyone acts on them.
The correct mental model for IOC feeds is enrichment infrastructure, not detection intelligence. A feed doesn’t tell you what to detect — it tells you what to do when you’ve already detected something. An alert fires, the analyst opens it, and the IOC match surfaces actor attribution, campaign context, known behavior. That’s genuinely useful for response and investigation triage. It is not detection coverage.
The problem compounds when the enrichment pipeline isn’t actually consulted during investigations. An organization can have a fully operational TIP running 15 feeds with SIEM integration — and if analysts close alerts before pulling context, or if the workflow doesn’t surface enrichment at the moment it’s needed, that’s enrichment theater. The infrastructure exists. The outcome doesn’t.
On the steelman: Short-lived IOCs do catch opportunistic attackers. Not sophisticated actors with fresh infrastructure, but ransomware crews reusing C2 IPs, commodity malware recycling domains, credential stuffers running the same botnet across campaigns. This is real catch, and it matters — the majority of what most organizations deal with day-to-day is opportunistic, not nation-state. The IOC pipeline also forces the SOC to maintain structured ingestion, TIP integration, and SIEM correlation — infrastructure that has value regardless of indicator freshness.
This is fair. The argument is not that IOC feeds should be scrapped. It is that IOC ingestion volume should not be the metric by which a CTI program is evaluated — because optimizing for that metric produces programs that look busy and don’t improve detection precision or recall.
Failure Mode 2: Reports Written for the Wrong Room
The second structural failure is distribution.
CTI programs typically produce two types of output for two different audiences — and consistently route them to the wrong one.
Strategic reports (actor profiles, campaign analyses, geopolitical context, emerging threat trends) require organizational context and risk tolerance to interpret. They belong with security leadership and risk teams. Instead, they land in analyst inboxes because those are the people subscribed to the distribution list.
Tactical intelligence (fresh IOCs, specific TTPs, detection opportunities, YARA and Sigma rules) requires immediate operationalization by detection engineers and SOC analysts. Instead, it gets summarized into a weekly brief that reaches the CISO three days after the technique was used in the wild against a peer organization.
The content isn’t wrong. The routing is.
This failure is maturity-dependent — well-aligned teams with clear stakeholder maps produce reports that reach the right consumers. But the teams that get this right have usually had a forcing conversation at the report level: who is this for, what decision does it need to drive, and what does that consumer need to do with it within the next 48 hours? Most programs never ask those questions. They produce a format and distribute it uniformly.
What Operationalized Intelligence Actually Looks Like
The test for whether CTI is actionable: did it change what your detection program can detect?
This splits based on what the intelligence contains.
TTP-based intelligence maps to detection engineering. An actor profile that documents a specific technique — lateral movement via token manipulation, cloud enumeration before exfiltration, credential dumping through specific tooling — gives a detection engineer something concrete to write against. But it’s only immediately actionable if the required log source is already ingested. If the technique requires a data source your SIEM doesn’t have, the report isn’t unactionable — it’s a gap finding.
Gap findings are arguably the highest-signal output CTI can produce. They identify specific coverage holes against a specific named threat, which is a far more compelling investment argument than a generic audit result. The friction is that “we found a detection gap” can read internally as a CTI failure when it’s actually CTI doing exactly what it should: telling the organization where a real adversary could operate without being seen.
IOC-based intelligence maps to threat hunting and response enrichment, not real-time detection. The operationalization path is a scheduled hunt — run this query against the last 90 days to look for these indicators — or an enrichment integration that surfaces context during investigation. Treating IOCs as real-time detection signals is where the alert noise problem enters: as I covered in Alert Fatigue Is an Offensive Technique, alert volume without signal precision is a burden on analyst attention, not a benefit to it. A high-expiry IOC generating 200 matches per day before going stale is queue noise with a source attribution.
There is also a roadmap problem at the handoff. A CTI report identifying an active campaign lands while the detection engineering team is mid-sprint on insider threat work. CTI wants action now; DE has committed scope. Without a shared prioritization model that weighs active threat relevance against in-flight work, the report waits — not because either team is wrong, but because the programs run on different cycles with no integration point. That gap is structural, not operational. Process won’t fix it without a shared prioritization framework.
Three Metrics That Would Replace the Current Ones
Detection coverage delta per threat actor profile. For the threat actor groups most likely to target your organization, how many new or improved detection rules exist this quarter that trace back to CTI input? This measures whether intelligence reaches the detection layer — and it forces CTI to maintain working relationships with detection engineering rather than distributing reports into a void.
Attribution rate. Of confirmed incidents over the past 12 months, what percentage were correctly attributed to an actor CTI had previously profiled? This measures predictive accuracy, not just descriptive volume. It’s also politically difficult: no CTI team wants to be graded on whether their actor profiles predicted the actual attackers, because every missed attribution is visible. That exposure is the point — it creates accountability for the quality of the threat model, not just the quantity of its outputs.
Investigation acceleration. When alerts are enriched with CTI context — actor attribution, campaign TTPs, related indicator clustering — do investigations resolve faster? This is the hardest metric to instrument because investigation draws on many signal types and the CTI contribution is genuinely difficult to isolate. It’s also politically difficult for the same reason attribution rate is: if enrichment doesn’t show a measurable acceleration, the metric makes the pipeline look ineffective even if other parts of the program are working. Both obstacles are real. The metric is worth pursuing anyway — “we don’t know if enrichment is useful to investigators” is a worse position than a flawed measurement.
None of these are easy to collect. All three require CTI to maintain active working relationships with detection engineering, the SOC, and incident response. That requirement is the point. Programs measured by IOC volume don’t need those relationships. Programs measured by detection delta can’t function without them.
Closing
Before the next CTI report goes out, answer one question: if this intelligence doesn’t result in a new or improved detection, a gap finding that drives a coverage investment, or an investigation that closes faster — does the organization benefit from it in any concrete way?
If the answer is no, you have a research function, not a CTI program.
The goal of threat intelligence is not intelligence. It is security posture improvement. Everything between those two points — the feeds, the reports, the platforms, the analyst hours — is infrastructure for getting there. Measuring the infrastructure instead of the outcome is how programs stay busy for years while the detection catch rate never moves.
Resources
- SANS 2025 Cyber Threat Intelligence (CTI) Survey — SANS Institute (55% of CTI teams measure their own effectiveness, up from 36% the prior year).