By Cyber Defense Technologies October 21, 2026 4 min read
Security teams are often asked for metrics, and the easiest numbers to produce are counts: emails blocked, alerts generated, vulnerabilities found, training modules completed. Those numbers can grow or shrink for reasons that have nothing to do with risk. A rising count of blocked attacks might mean better filtering, more attacks or a change in how the tool counts.
Leaders need measures that answer a simpler question: if something goes wrong, how exposed are we, and how quickly can we respond?
What makes a metric useful
A good security metric is:
- Tied to an outcome, such as reduced exposure or faster containment.
- Actionable, so a change in the number points to a decision or task.
- Measured consistently, with a written definition that does not change quietly between reports.
- Hard to game, so improving the number means improving security.
NIST CSF 2.0 can help organize metrics across its functions (Govern, Identify, Protect, Detect, Respond and Recover), so leaders see a balanced picture rather than only what is easiest to measure.
Detection and response
Time to detect. How long between an attacker's first meaningful activity and the moment someone notices. This is often established only after an investigation, but tracking it across incidents and exercises shows whether detection is improving.
Time to contain. How long between detection and the point where the attacker can no longer act, such as an isolated host or a disabled account. This reflects tooling, staffing, authority and process.
Alert handling time. How long high-severity alerts wait before someone reviews them, including nights and weekends.
Red team exercises and purple team testing provide useful data points for these measures without waiting for a real incident.
Exposure
- Patch latency for known exploited vulnerabilities. Measure the time from publication in CISA's Known Exploited Vulnerabilities catalog, or from vendor disclosure, to remediation on affected systems. Report internet-facing systems separately.
- MFA coverage. The proportion of accounts protected by MFA, broken out for privileged accounts, remote access and email, and the proportion using phishing-resistant methods.
- EDR and logging coverage. The proportion of assets in your inventory that report to EDR and send logs to central monitoring.
- Privileged accounts. The number of accounts with administrative rights and how that number changes over time.
- Unsupported systems. Assets running software that no longer receives security updates.
Each of these depends on an accurate asset inventory. If the inventory is incomplete, coverage numbers will look better than reality.
Resilience
Restore test success. The proportion of scheduled restore tests that succeeded, and the measured recovery time for critical systems compared with the recovery time objective.
Exercise findings closed. Whether actions identified in tabletop exercises and post-incident reviews are completed on schedule.
Metrics to treat with caution
- Total attacks blocked, which mostly reflects internet background noise.
- Total vulnerabilities found, which rises with better scanning and says little about exploitable risk.
- Training completion rates, which show compliance rather than behavior change.
- Phishing simulation click rates in isolation, which vary with the difficulty of each test. Reporting rates and time to report are often more meaningful.
These numbers are not useless, but they belong in operational reports rather than leadership dashboards.
Set your own targets
Be cautious with industry benchmark figures, which often come from vendor surveys with unclear methods. Set targets based on your own risk, mission and contractual obligations, and focus on trends. A steady reduction in patch latency for exploited vulnerabilities is more meaningful than any single comparison with another organization.
Present metrics as decisions
Pair each metric with context: what it shows, why it changed and what decision or resource would improve it. A chart showing that MFA coverage for remote access stalled because of one legacy system gives leaders something to act on.
How CDT can help
CDT's control assessments establish an evidence-based baseline for these measures, and our managed security team reports on detection and response performance in terms leaders can use.
