Threat intelligence metrics: which ones matter and which mislead?

Measure threat intelligence by decisions changed, not volume collected. Useful metrics tie a piece of intel to an action: a detection added, a patch moved up, a block applied. Misleading ones count feeds, indicators or reports, which rise whether or not anyone is safer.

Why do the usual numbers fail?

Volume is easy to count, so it becomes the dashboard. "We ingest 40 feeds" tells you about your plumbing. It says nothing about outcomes. NIST's guide to cyber threat information sharing frames the purpose as improving your own security posture and defines the information broadly: indicators of compromise, attacker tactics and techniques, recommended actions and findings from incident analysis. A metric should follow that purpose.

Which metrics mislead?

Indicator count. More indicators can mean more noise. Many go stale, since addresses and domains get reused or abandoned.

Number of feeds or sources. Overlap is common. Ten feeds may carry the same item ten times.

Reports consumed. Reading is not acting.

Raw alerts from intel matches. A match rate without a check on how many were real tells you about the list, not the threat.

Threat actor name coverage. Knowing every group name is trivia unless you know which techniques those groups use that you cannot detect.

Which metrics hold up?

Intel to action rate. Of the items you received, what share led to a concrete change? Define "change" up front: a new detection rule, a changed patch order, a blocked destination, a hunt.

Time from receipt to action. Measured per item type. A report on a vulnerability under active exploitation should reach a decision quickly. A strategic trend report does not need that clock.

Detection coverage against techniques you care about. MITRE ATT&CK is a knowledge base of adversary tactics and techniques from real-world observation. Map the techniques relevant to your sector, then count which you can detect. That turns intel into a gap list.

Precision of intel-driven alerts. Of alerts that came from intel, how many were true positives after triage? Track it per source so you can drop weak ones.

Stakeholder decisions informed. Count the times a security leader or engineering lead used a brief to decide something, and note the decision.

How does exploitation intel differ?

For vulnerabilities, two public signals help. CISA's Known Exploited Vulnerabilities catalog says organizations should use it as an input to their vulnerability management prioritization framework. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days, published daily on a 0 to 1 scale.

Neither says whether the flaw is reachable in your code or running in your environment. A good metric here is how long known-exploited items that actually affect you stay open, not how many appear in the catalog.

A constructed example

A team reports "12,000 indicators ingested this quarter." Replace it with three lines: 9 intel items led to action, median time from receipt to action was two days for exploitation reports, and 4 of 15 ATT&CK techniques on the sector list lack a detection. All numbers here are invented to show the format. The second report tells leadership where to spend.

What to do

1. Write down the three decisions intel is supposed to influence in your company.
2. Tag every item you receive with the action it caused, or "none."
3. Report intel to action rate and time to action, split by item type.
4. Pick a technique list from ATT&CK and track detection coverage on it.
5. Review sources quarterly and drop those with no actions and low precision.
6. Keep volume numbers as an internal cost figure, not a success measure.

Quick check

Sources

• NIST SP 800-150, Guide to Cyber Threat Information Sharing
• MITRE ATT&CK
• CISA Known Exploited Vulnerabilities Catalog
• FIRST EPSS

Last reviewed: 18 October 2026.