I recently reviewed a security team’s quarterly report to their board. Twelve pages of charts. Vulnerabilities remediated (trending up, great!). Phishing simulations conducted (four this quarter!). Security awareness training completion (97%!). Mean time to detect (reduced by 3 hours!).

The board nodded politely. The CISO felt good about the presentation. Two months later, a phishing email led to a credential compromise that cost the company $2 million in incident response and customer notification.

None of those metrics predicted—or would have prevented—the breach.

Most security metrics measure activity, not outcomes. They tell you the security team is busy. They don’t tell you whether the organization is actually more secure.

The Problem With Common Metrics

Let’s autopsy the usual suspects:

“Vulnerabilities remediated” counts effort, not risk reduction. Remediating 500 low-severity findings while 5 critical CVEs age in production makes the number go up while security goes down. Without severity weighting and context, this metric is misleading at best.

“Mean time to detect” (MTTD) sounds important but usually measures noise. If your SIEM fires 10,000 alerts and 9,900 are false positives, a fast MTTD means you’re quickly looking at garbage. And what gets detected matters more than how fast—detecting failed logins quickly is less valuable than detecting lateral movement slowly.

“Phishing simulation click rates” measure performance on simulated phishing, which users learn to recognize. Sophisticated phishing doesn’t look like training examples. A 2% click rate on obvious simulations says nothing about resilience to targeted attacks.

“Training completion rate” measures compliance with mandatory training, not behavioral change. I’ve seen 100% training completion at organizations where employees still shared passwords and clicked suspicious links daily.

“Security incidents” as a standalone metric is perverse. Does a rising count mean better detection or worse security? Does a falling count mean improved defenses or blind spots? Without context, the number is meaningless.

What “Good” Actually Looks Like

Useful security metrics share three characteristics:

1. They tie to business outcomes. What does the business actually care about? Availability. Customer trust. Regulatory standing. Cost. Metrics should connect to these, even if indirectly.

2. They measure capability, not activity. Not “we did security things” but “we can stop/detect/recover from specific threats.”

3. They’re actionable. A metric that can’t drive a decision is a vanity metric. Every measurement should answer “what would we do differently if this number changed?”

Here’s a framework that works.

Tier 1: Coverage Metrics

Coverage answers: “For each control we claim to have, what percentage of our environment actually has it?”

This sounds basic. It isn’t. Most organizations can’t accurately answer this question for any control.

Example: EDR Coverage

• Numerator: Endpoints with EDR agent installed and reporting
• Denominator: Total endpoints in asset inventory
• Target: 98%+ (some exceptions are legitimate, most aren’t)

To calculate this, you need accurate asset inventory (already hard) and EDR deployment reports that match reality (also hard). The gap between “we have EDR” and “we have EDR deployed with 98% coverage” is where attackers live.

Example: MFA Coverage

• Numerator: User accounts with MFA enforced
• Denominator: Total user accounts
• Target: 100% for employees, defined threshold for contractors/vendors

Calculate separately for different account types. Service accounts and break-glass accounts complicate the math—exclude them with explicit documentation, don’t let them silently drag down coverage.

Example: Vulnerability Remediation Coverage

• Numerator: Critical/high vulnerabilities remediated within SLA
• Denominator: Total critical/high vulnerabilities discovered
• Target: 95%+ within SLA

This is different from raw counts. A team that remediates ⁵⁰⁄₅₀ criticals within SLA is outperforming a team that remediates 500 lows while criticals age.

Coverage metrics tell you whether your security investments are actually deployed. They expose the gap between “we bought it” and “it’s protecting us.”

Tier 2: Efficacy Metrics

Coverage tells you controls exist. Efficacy tells you they work.

Example: Detection Efficacy

Run regular atomic tests—scripted simulations of specific attack techniques. Track:

• Total techniques tested
• Techniques detected with alert generated
• Techniques detected with correct severity
• Techniques that reached SOC (vs. auto-suppressed)

If you simulate Kerberoasting and no alert fires, you know your detection gap. If alerts fire but are auto-suppressed or deprioritized, you know your tuning is wrong.

This requires ongoing testing, not annual pentests. Monthly or quarterly runs of automated attack simulation give you trend data. Did last month’s detection rule changes actually improve detection?

Example: Response Efficacy

Time metrics matter here, but specific ones:

• Time from alert to human triage
• Time from confirmed incident to containment action
• Time from containment to full remediation

Don’t average across all incidents—segment by severity. Response time for a low-priority alert doesn’t matter. Response time for a confirmed ransomware deployment matters a lot.

Example: Recovery Efficacy

Test backup restoration. Actually test it. Track:

• Percentage of critical systems with tested recovery procedures
• Time to restore each critical system from cold start
• Data loss window (RPO gap between backup frequency and reality)

Most organizations claim they can recover. Few have tested it. The ones who have often discover their “4-hour RTO” is actually 72 hours once they account for real conditions.

Tier 3: Exposure Metrics

Exposure metrics quantify your attack surface—how much opportunity exists for attackers?

Example: External Attack Surface

• Internet-facing assets (tracked over time—is it growing or shrinking?)
• Internet-facing assets with known vulnerabilities
• Expired certificates on external services
• Shadow IT services discovered

Continuous attack surface monitoring is now table stakes for organizations with any complexity. Track what’s exposed, trend it monthly, hold teams accountable when exposure grows without justification.

Example: Credential Exposure

• Number of corporate credentials in breach databases
• Age of oldest unrotated password
• Service accounts with non-expiring credentials
• Privileged accounts without MFA

Credential exposure predicts breaches better than almost any other metric. Track it obsessively.

Example: Third-Party Exposure

• Number of third-party integrations with production data access
• Third-party vendors without security assessments
• Time since last security review per vendor tier

Your security posture includes your vendors’ security. A supply chain compromise bypasses your controls entirely.

Tier 4: Business Outcome Metrics

These connect security to what executives actually care about.

Example: Security’s Impact on Sales

• Average time to complete customer security questionnaires
• Win/loss rate on deals with security requirements
• Number of deals blocked or delayed by security concerns

If security enables faster sales cycles and more deal wins, that’s quantifiable business value.

Example: Regulatory Standing

• Open audit findings (by severity and age)
• Time to close audit findings
• Compliance certification status and expiration

Regulatory failure has direct business impact—fines, lost business, operational restrictions.

Example: Cost Metrics

• Security spend as percentage of IT spend (benchmark against peers)
• Cost per protected endpoint/user
• Incident response costs (internal and external)

These aren’t “less is better” metrics. Underspending on security creates false savings. But understanding cost structure helps with budgeting and comparison.

Putting It Together: An Executive Dashboard

Most executives don’t want twelve pages of charts. They want to understand:

1. Are we protected? (Coverage metrics)
2. Do our protections work? (Efficacy metrics)
3. Where are we exposed? (Exposure metrics)
4. What’s the business impact? (Outcome metrics)

Build a one-page dashboard with the top metric from each category, plus trends. Color code red/yellow/green if your executives need that simplification, but be honest about thresholds. A 94% when target is 98% is yellow, not green.

Reserve the detailed metrics for security team operations. Executives don’t need to know your atomic test results by MITRE ATT&CK technique. They need to know whether detection is improving or degrading.

What Changes When You Measure Correctly

Meaningful metrics change behavior.

When you track coverage accurately, you find the gaps. That server nobody owns with no EDR, no patching, and an admin account from 2019. The coverage metric forces uncomfortable conversations about asset management and accountability.

When you track efficacy, you stop assuming controls work. Most organizations have never tested whether their SIEM detects common attack patterns. Testing reveals the answer is usually “not reliably.”

When you track exposure, you quantify risk in terms executives understand. “We have 47 internet-facing assets with critical vulnerabilities” is more compelling than “we need to prioritize patching.”

When you track business outcomes, security becomes a business function instead of a cost center. Revenue impact gets attention that vulnerability counts never will.

The Metric You’re Probably Missing

Here’s one that’s rarely tracked but highly predictive:

Security decision velocity. How long does it take to make and implement a security decision?

Track time from “we identified a problem” to “the fix is deployed.” When this number is high—weeks or months—your security program is bureaucratically constrained regardless of what other metrics say. When it’s low—days or hours for non-critical issues, hours or less for critical ones—you can actually respond to threats.

Fast is secure. Slow is vulnerable. Most organizations are slow.