ServiceNow Threat Intelligence KPIs and Metrics That Matter

Threat Intelligence as Risk Measurement

Threat Intelligence KPIs measure how effectively your organization detects, analyzes, and responds to security threats. These metrics differ from other operational metrics because they measure risk reduction, not efficiency. A fast but inaccurate threat detection process is worse than slower but high-accuracy detection: false positives waste security team time, while false negatives miss real threats. The fundamental KPI strategy should emphasize detection accuracy and response effectiveness over speed, though timeliness still matters. Most security teams struggle with alert fatigue (too many alerts, many of them false positives) rather than insufficient detection. Your KPI mix should include accuracy metrics (false positive rate, false negative rate) alongside speed and throughput metrics.

Threat Detection and Alert Accuracy

Threat alert generation rate is the number of threats detected per week or month by your threat intelligence system, from the sn_threat table. Most organizations receive threat intelligence from multiple sources: endpoint detection and response (EDR) tools, SIEM systems, network monitoring, and external threat feeds. Track detection sources: which detection mechanisms generate most alerts? Which are most accurate? This helps prioritize: if EDR generates accurate threats but SIEM generates mostly false positives, invest more in EDR and tune SIEM detection rules. False positive rate is critical: percentage of threat alerts that, after investigation, are determined to be benign or misclassified. Most security organizations track and reduce false positive rates significantly. Rates that remain high indicate detection rules are too loose and security team time is wasted on investigation of non-threats.

Also measure false negative rate (threats missed entirely), though this is harder to quantify. One approach: monitor external threat intelligence feeds to see if threats you missed were publicly disclosed. Another: rely on breach incident post-mortems to identify detection gaps. False negative rate is typically unknown; organizations often discover it only after a breach. Prioritize reducing false negatives through continuous monitoring improvement and rule tuning rather than trying to measure false negatives directly.

Threat Analysis and Classification

Threat classification accuracy is the percentage of detected threats correctly classified by severity and category. Most organizations use severity levels: Critical (active ongoing compromise, requires immediate response), High (advanced persistent threat indicators, investigation urgently needed), Medium (suspicious activity, slower investigation), Low (interesting but low-risk, log for trend analysis). Classification errors (marking medium threats as critical) waste resources, while underclassifying real threats (marking critical threats as medium) delays response. Measure this by sampling threats regularly and verifying the assigned classification against actual threat characteristics. Track your accuracy for Critical/High classification separately from overall accuracy; both should improve over time as classification rules are tuned.

Threat Response and Remediation

Measure time-to-detect (TTD): average time from when a threat first occurred to when you detected it. Different threat types require different detection speed: endpoint threats may take hours to surface, while active intrusions require detection within minutes. Longer TTD means threats have more time to propagate and steal data. Time-to-respond (TTR): average time from detection to when the security team begins investigation and remediation. Faster TTR for critical threats is essential. Time-to-remediate (TTRem): time from detection to when the threat is fully resolved (malware removed, credentials rotated, vulnerable systems patched). TTRem depends on threat complexity: simple malware resolves faster than sophisticated attacks requiring extensive investigation and remediation.

Also measure remediation success rate: percentage of remediated threats that don’t recur after resolution. Recurrence suggests remediation was incomplete (malware cleaned but back-door left open, credentials reset but vulnerability not patched). High recurrence rates indicate the security team isn’t addressing root cause thoroughly. Most security organizations build a SOAR (Security Orchestration, Automation and Response) playbook for common threats to automate response and reduce TTR.

Threat Intelligence Utilization

Measure threat intelligence coverage: what percentage of your IT infrastructure, applications, and users are monitored for threats? Coverage should be highest for production systems, moderate for staging systems, and lower for development environments. Gaps in coverage represent blind spots where threats might go undetected. Also measure threat intelligence data quality: percentage of threat alerts with sufficient information for analysts to investigate (source of threat, type of threat, affected resources, severity indicators). Alerts with missing information slow investigation significantly. Most organizations prioritize improving alert completeness so investigators have context for each alert.

Risk Reduction and Trend Analysis

Track threat trend month-over-month: are threats increasing, stable, or declining? Increasing threat counts might indicate either better detection (good) or new threats in your environment (bad—requires root cause analysis). Also track threat source distribution: are threats coming from specific geographic regions, threat groups, or attack vectors? This intelligence helps prioritize defense: if most threats are phishing emails, invest in email security; if most are vulnerable network services, invest in patching and network hardening. Most organizations build a quarterly threat assessment: consolidate threat data from the quarter, identify top threats and trends, and use that to inform security roadmap priorities.

Defining each metric tightly enough that two teams would calculate it the same way

Many threat intelligence dashboards fail on definitions before they fail on data. Two analysts can report the same month and reach different totals because one counts a grouped alert as a single detection and the other counts every indicator inside it. A metric that cannot be recalculated by someone else has little value in a review, and it becomes a tool for winning arguments rather than making decisions. A scorecard owner needs each number to hold up under challenge, and this section is about that.

Draft a definition card for each metric before it is shown anywhere. The card has a question the metric answers, a numerator, a denominator, a start event, an end event, and a named owner. The table shows the parts that often drift.

Procedure for building a scorecard the review can trust

1. Choose no more than a handful of metrics for the first review, and make each one answer a decision someone actually takes.
2. Write the definition card for each, and have the analyst who closes the alerts and the lead who reviews them both read it.
3. Back-calculate the metric for a sample of past alerts by hand, and compare your hand calculation with the dashboard result.
4. Only publish the metric once the two calculations agree on that sample.
5. Re-check definitions whenever the closure categories or the alert grouping logic change, because those changes move the numbers without any change in the threat.

When a good-looking metric hides a bad outcome

A falling false positive share can mean the program is improving. It can also mean analysts have started closing ambiguous alerts as benign because the queue is too long to investigate them. The number is identical in both cases. The difference shows up in the sample review, where a closed alert later turns out to have been part of a real incident. Build that check into the scorecard rather than trusting the trend.

The same caution applies to time measures. Faster closure can reflect better tooling, or it can reflect an alert type being closed without investigation. Pair every speed measure with an outcome measure, such as how many closed alerts were reopened within the agreed review window.

When measurement is premature

If the source has been live for a few weeks, most trend lines are noise. A reasonable early position is to report outcomes for individual alerts and keep the aggregate metrics out of leadership material until there is enough history to read a trend. Presenting an early curve as a result sets expectations the program cannot yet meet.

Which single metric should a security lead track first?

The confirmed share for each source. It tells you whether a source earns its place, and it is simple enough that every analyst can check it. Add the others once that figure is trusted.

How should an alert counted in two metrics be handled?

Decide once, in the definition card, which metric owns it. Counting the same alert in two places can make the dashboard appear to contain more threats than the queue ever held.

Should the scorecard include the number of blocks applied?

Only alongside the number of those blocks that were later reversed by a business owner. Blocks are an action, not an outcome, and a high block count with many reversals can signal a source that needs tighter scoring.

Who approves edits to a metric definition?

The metric owner, after the change is recorded with its date and the reason. A silent edit to a definition means the figures on either side of it cannot be compared, which can defeat the purpose of the scorecard.

For the reporting side of the same problem, the operational intelligence review article covers reviewing the decision path, and the common mistakes guide covers definition errors among others.