KRIs for threat intelligence

The KRIs in this domain measure whether your threat intelligence program is producing operational outcomes, not whether you have feeds, but whether those feeds are producing detections; not whether you have reports, but whether those reports are influencing decisions; not whether you're monitoring, but whether you're monitoring the right things for your specific threat profile.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Intelligence-to-Detection pipeline coverage

What to measure. Percentage of threat intelligence indicators (IOCs: IP addresses, domains, file hashes, URLs) from active feeds that are operationally integrated into at least one detection control, SIEM, firewall blocklist, EDR, email gateway, or DNS filtering, with automated distribution.

Why it matters. IOCs that live in a TI platform but aren't pushed to detection tools protect nothing. Integration coverage measures whether your intelligence investment is connected to the controls that can act on it. Manual IOC distribution is too slow and too inconsistent to be a real control at the volume modern TI feeds generate.

• Threat intelligence platform (Recorded Future, Intel 471, MISP, OpenCTI, Anomali): feed inventory and indicator export configurations
• SIEM: TI lookup tables or threat intelligence integrations (Splunk ES threat intel framework, Sentinel TI blade)
• Firewall / proxy: IP and domain blocklists sourced from TI feeds, integration status and freshness
• EDR: custom IOC import, hash, IP, domain indicator sets from TI
• DNS filtering (Cisco Umbrella, Cloudflare Gateway): threat category feeds and custom block lists from TI

How to calculate. (Active TI feeds with automated indicator distribution to ≥1 detection control) ÷ (total active TI feeds) × 100 Also: IOC match rate, count of SIEM alerts or firewall blocks triggered by TI-sourced indicators per month

Status	Criteria
Green	>90% of feeds with automated integration; IOC match rate tracked monthly; indicator freshness <24 hours
Amber	60–89% integrated; or indicator distribution manual for some feeds; or freshness latency >48 hours
Red	<60% integrated; or TI feeds with no operational distribution; or IOC match rate unknown (not measuring whether TI is producing detections)

2. Threat actor relevance coverage

What to measure. Percentage of threat actor groups active in your industry vertical and geography that are actively tracked in your TI program, with current TTPs (tactics, techniques, procedures) mapped and at least one detection rule covering their primary techniques.

Why it matters. Generic threat intelligence is less valuable than intelligence tuned to your specific threat profile. An organization in healthcare faces different threat actors than one in financial services. Relevance coverage measures whether your intelligence program is tracking the adversaries most likely to target you, not all adversaries, which is impossible, but the ones your threat model identifies as most probable.

• Threat intelligence platform: threat actor profiles with industry targeting metadata
• MITRE ATT&CK Groups: industry-filtered threat actor list (https://attack.mitre.org/groups/) as a reference baseline
• ISAC membership: Financial Services ISAC, Health-ISAC, E-ISAC, sector-specific threat actor intelligence
• FBI/CISA advisories: threat actors actively targeting your sector in trailing 12 months
• SIEM/EDR detection rules: ATT&CK technique coverage for tracked threat actor TTPs (cross-reference with ATT&CK Navigator)

How to calculate. (Threat actors relevant to your sector with active tracking profile + at least one TTP detection rule) ÷ (total relevant threat actors identified across your sector) × 100

Status	Criteria
Green	>80% of sector-relevant threat actors with active tracking and detection coverage; threat actor profiles reviewed quarterly
Amber	50–79%; or tracking without detection coverage; or threat actor review less frequent than annual
Red	<50%; or no sector-specific threat actor profiling; or generic threat feeds with no industry tuning

3. Dark web and credential exposure monitoring coverage

What to measure. Whether continuous monitoring is active for your organization's credentials, data, and brand across dark web forums, paste sites, criminal marketplaces, and breach databases, and the mean time from detection to response (credential reset, incident investigation, breach notification assessment).

Why it matters. Dark web and paste site credential exposure provides advance warning that your users' credentials are available to attackers, before those credentials are used in an attack. Organizations that detect and reset compromised credentials before they're used prevent the incident. Organizations that discover them during the incident response investigation are always behind.

• Dark web monitoring services (Recorded Future Identity Intelligence, Intel 471, Flare, SpyCloud, Digital Shadows): monitoring scope and alert volume
• Have I Been Pwned enterprise API: bulk check of corporate email domains against breach databases
• Azure AD Identity Protection / Entra ID: leaked credential risk detections from Microsoft's credential monitoring network
• SIEM: dark web exposure alerts correlated with identity risk signals (unusual login patterns concurrent with credential exposure)

KRI values.

• Monitoring active: coverage of company email domain(s), executive names, and key infrastructure in dark web monitoring service
• Exposed credential volume: count of corporate credentials found in new breach data per quarter
• Mean time to reset: hours from dark web credential detection alert to confirmed password reset and MFA re-enrollment

Status	Criteria
Green	Dark web monitoring active and continuous; exposed credentials actioned within 24 hours of detection; executive names and brand monitoring active
Amber	Monitoring active but response SLA >48 hours; or periodic rather than continuous monitoring
Red	No dark web monitoring; or monitoring active but no response workflow; or credentials found in breach data with no notification process

4. Vulnerability intelligence integration rate

What to measure. Percentage of critical vulnerabilities published by CISA (KEV), major vendors (Microsoft Patch Tuesday, Oracle CPU, Adobe), and threat intelligence feeds that are cross-referenced against your asset inventory within 24 hours of disclosure, producing a prioritized impact assessment before the SOC is fielding questions.

Why it matters. Vulnerability disclosure is a race. Attackers scan for newly disclosed critical vulnerabilities within hours of publication. Organizations that can assess their exposure in minutes rather than days have a meaningful defensive advantage. Intelligence-driven vulnerability prioritization, using threat context (is this being exploited?) not just CVSS scores, is the difference between triage and noise.

• CISA KEV feed: automated polling or webhook subscription
• Vendor security advisories: subscription to vendor security notification lists (Microsoft MSRC, Oracle, Adobe, Cisco PSIRT)
• Threat intelligence platform: vulnerability intelligence module (Recorded Future Vulnerability Intelligence, Tenable One, Vulncheck)
• Vulnerability management platform: integration with TI for exploitation context, Tenable, Qualys, and Rapid7 all integrate exploitation intelligence
• SOAR: automated playbook triggered on KEV addition → query asset inventory → produce impact summary

How to calculate. (Critical vulnerability disclosures with asset inventory cross-reference completed within 24 hours) ÷ (total critical vulnerability disclosures in period) × 100

Status	Criteria
Green	>95% of KEV additions with automated impact assessment within 24 hours; SOAR playbook for KEV triage active
Amber	70–94%; or manual cross-reference process taking 24–72 hours
Red	<70%; or no systematic vulnerability intelligence integration; or impact assessments reactive rather than proactive

5. Intelligence reporting relevance score

What to measure. Percentage of intelligence reports produced or distributed to leadership and business stakeholders that result in a documented action or decision, not reports opened and filed, but reports that changed a decision, initiated an investigation, or informed a risk acceptance.

Why it matters. Intelligence reports that inform no decisions are expensive wallpaper. This KRI measures whether your intelligence production function is connected to the decision-making functions it exists to serve. Low relevance scores indicate either intelligence that isn't targeted at the right audience, or a consumption problem where decision-makers aren't engaging with what's produced.

• Intelligence report distribution system: report tracking with recipient engagement data
• CISO/leadership feedback: documented decisions or actions referencing intelligence reports
• SOC: incidents where intelligence reports contributed to detection or investigation, tracked in incident records
• GRC platform: risk register updates triggered by intelligence reporting

How to calculate. This requires tracking report outcomes, a process investment. Options:

• Formal: brief follow-up survey to report recipients 30 days after distribution
• Informal: monthly review of whether distributed reports led to documented actions
• Proxy: percentage of SOC investigations with TI report cited in incident record

Status	Criteria
Green	>50% of reports resulting in documented action or decision; feedback loop between intelligence and SOC/risk functions established
Amber	25–49% actionability; or no systematic tracking of report outcomes
Red	<25% actionable; or reports produced without audience targeting; or no connection between intelligence production and SOC investigation

6. Brand and executive threat monitoring coverage

What to measure. Whether continuous monitoring is active for brand impersonation (look-alike domains, social media impersonation, fake app stores), executive digital footprint exposure, and targeted phishing infrastructure identified before campaigns are launched against your organization.

Why it matters. Pre-attack infrastructure, phishing domains registered, spoofing infrastructure stood up, executive social media impersonation accounts created, is visible before it's used. Threat intelligence monitoring that catches this infrastructure during setup rather than after deployment converts reactive incident response into proactive takedown. Brand monitoring is also a legal and reputational protection function, not only a security one.

• Brand protection platforms (BrandShield, Bolster, PhishLabs, Recorded Future Brand Intelligence): look-alike domain monitoring, social media impersonation detection, dark web brand mention monitoring
• Certificate transparency (crt.sh, Cert Spotter): newly issued certificates for brand-keyword domains
• Domain registration monitoring (DomainTools): newly registered domains containing your brand name or executive names
• Social media APIs: impersonation account monitoring on LinkedIn, X/Twitter, Facebook
• App store monitoring: unofficial apps using your brand in title or description

KRI values.

• Look-alike domains detected per month: trend metric, rising volume signals targeted campaign preparation
• Mean time to takedown: hours from identification to successful takedown of phishing infrastructure or impersonation accounts
• Phishing campaigns targeting your users proactively identified: count per quarter

Status	Criteria
Green	Continuous monitoring active; new look-alike domains reviewed within 24 hours; mean time to takedown <48 hours for high-risk infrastructure
Amber	Monitoring active but review latency 24–72 hours; or takedown process >5 days
Red	No brand monitoring; or reactive discovery only (user reports, not proactive monitoring); or no takedown capability

7. Intelligence sharing and community participation

What to measure. Active membership in sector-specific ISACs and threat intelligence sharing communities, and the contribution rate, how often your organization contributes intelligence versus only consuming it.

Why it matters. Threat intelligence communities work because members share what they know. Organizations that only consume from ISACs without contributing undermine the collective defense model and miss the reciprocal benefits of contribution, faster, more contextual intelligence from peers who face the same threats. Active participation is also a regulatory expectation in some industries (CISA encourages it; FFIEC and other regulators acknowledge it).

• ISAC membership records: FS-ISAC, H-ISAC, E-ISAC, IT-ISAC, or sector-appropriate ISAC
• Contribution records: incident reports submitted, indicators shared, advisories contributed to ISAC community
• MISP / OpenCTI instance: if running a sharing platform, contribution metrics (events created vs. events consumed)
• Government partnerships: CISA partnerships, FBI InfraGard membership, sector-specific coordination mechanisms

KRI values.

• ISAC membership active: yes/no for sector-appropriate ISAC
• Contribution-to-consumption ratio: (Intelligence artifacts contributed) ÷ (intelligence artifacts consumed), track quarterly
• Collaborative exercises participation: sector-specific tabletop or red team exercises per year

Status	Criteria
Green	Active ISAC membership; contribution-to-consumption ratio >0.1 (contributing at least 10% as much as consuming); participation in at least one sector exercise per year
Amber	Passive ISAC membership (consuming only); or membership lapsed
Red	No ISAC membership; or no active engagement with government or peer threat intelligence sharing

Deriving these KRIs by source type

From Threat Intelligence Platforms (Recorded Future, Intel 471, MISP, Anomali)

• Feed inventory and integration status: List active feeds; check each for configured export to SIEM/EDR/firewall, integration flag per feed
• IOC freshness: Timestamp of most recently ingested indicator per feed, flag feeds with indicators >48 hours old
• Actor tracking: Profile list filtered by industry vertical tag; cross-reference with ATT&CK Groups for coverage assessment
• MISP event API: GET /events/index for contribution count; GET /feeds for consumer feed count, calculate ratio

From SIEM (Splunk, Sentinel, Elastic)

• TI match rate: index=* [| inputlookup threat_intel_iocs | fields src_ip, dest_ip, url, hash] | stats count, adapt to your SIEM and lookup table name
• IOC blocklist hits: Firewall or proxy logs filtered for blocked connections matching TI IOC blocklist, signals TI is actively preventing connections
• Threat actor TTP detection: Alert rules tagged with ATT&CK technique IDs from tracked actor profiles, coverage percentage

From Dark Web Monitoring Services (SpyCloud, Flare, Digital Shadows)

• Credential exposure API: Most services offer API access to breach data queries for your email domain; automate daily query and compare to previous day's results
• New exposure alert → SOAR: Webhook to SOAR playbook on new credential exposure alert → identity provider lookup → account risk flagging → password reset workflow trigger
• Executive monitoring: Named monitoring for C-suite and board members, separate alert queue with elevated SLA

From DNS and Domain Monitoring (DomainTools, crt.sh)

• Look-alike domain detection: DomainTools Iris API → query for domains containing brand name registered in last 7 days; or crt.sh API for certificate issuance monitoring
• DMARC aggregate reports: Source IPs sending email claiming to be from your domain, overlap with brand impersonation detection
• Passive DNS: Historical resolution data for newly registered brand-similar domains, early warning of phishing infrastructure staging

From Vulnerability Intelligence (Vulncheck, Tenable, CISA)

• KEV polling: curl https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq '.vulnerabilities | sort_by(.dateAdded) | reverse | .[0:5]', newest five additions
• Exploitation context from TI: Recorded Future vulnerability intelligence or Vulncheck API, exploitation activity data per CVE, enriching CVSS scores with actual threat context
• SOAR integration: Trigger playbook on new KEV addition → query Qualys/Tenable for open findings with that CVE ID → create priority remediation ticket