Cybersecurity Metrics: KPIs Every CISO Should Track

Cybersecurity metrics KPIs are the measurements a security leader uses to show whether controls work, whether risk is falling, and whether the money spent is buying real protection.

Done well, they replace opinion with evidence in conversations with the board, the CFO and auditors.

Done badly, they become a wall of green dashboards that hides the one number that matters.

People use "metric" and "KPI" interchangeably, but the difference matters when you decide what to put in front of executives. A metric is any measurement. A KPI is a metric tied to a target and a business objective, so it tells you whether you are winning or losing. Other terms you will meet are key risk indicators, which warn that exposure is rising, and outcome-driven metrics, which connect security performance to business results.

• Boards and regulators expect evidence. For U.S. public companies, SEC rules require disclosure of material cybersecurity incidents on Form 8-K Item 1.05 within four business days of a materiality determination, plus annual disclosure of cybersecurity risk management, strategy and governance. Both depend on numbers you can defend.
• Budgets are tight. The IANS 2026 benchmark found a median security budget growth of 0%, so every request needs measurable justification. See Corporate Cybersecurity Budget Planning.
• Attackers move faster. M-Trends 2026 reports that the median time from initial access to handoff to a second threat group fell from over 8 hours in 2022 to 22 seconds in 2025, so slow internal metrics matter.
• Guidance exists. NIST finalized SP 800-55 Volume 2, Developing an Information Security Measurement Program, in December 2024, replacing a 2008 revision. It describes how to plan, develop and run a measurement program.

A metric earns its place on the scorecard only if someone would act differently depending on its value. Before adding any number, run it through five questions.

No security team can track everything. Group your KPIs into six categories, collect widely, and report a short list upward. The table below is the working map used in the rest of this guide. Targets are illustrative starting points; set yours from risk appetite, history and peer data.

Speed is the most intuitive security metric, and the data shows why it matters. Mandiant's M-Trends 2026 reports a global median dwell time of 14 days for 2025 investigations, up from 11 days in 2024. When an intrusion is first spotted by an outside party such as law enforcement or a notified victim, dwell time is much longer than when the organization finds it itself, so the share of internally detected incidents is itself a useful KPI. IBM's 2026 Cost of a Data Breach summaries put the average lifecycle from breach to containment at roughly 247 days, so treat any figure below that as a start, not a finish line.

Use medians because incident times are heavily skewed: a few long investigations will distort a mean. If you want to model the cost side of slow response, see the insider-case numbers in Insider Threat Detection, where faster containment changes the average cost materially.

Vulnerability counts are the classic vanity metric. What matters is how fast the exploitable ones are fixed. The Verizon 2026 DBIR, as reported by Help Net Security, found that exploitation of vulnerabilities became the top initial access vector, the median time to fully patch known-exploited vulnerabilities rose from 32 to 43 days, and only 26% of CISA KEV entries were fully remediated, down from 38%. Those numbers set a modest bar: if you can fix known-exploited flaws in 14 days, you are well ahead of the reported median.

Credentials and recovery are where many serious incidents are decided, so measure both explicitly. Count phishing-resistant authentication separately from any-factor MFA, because one-time codes and push approvals can still be phished or fatigued, while passkeys and hardware keys are bound to the legitimate site.

NIST CSF 2.0, released in February 2024, added a Govern function alongside Identify, Protect, Detect, Respond and Recover. That makes governance measurable in its own right. Useful KPIs include the number of risks outside appetite without an approved plan, share of risks with a named owner, policy exceptions past review, and the percent of tier-1 systems with a completed risk assessment in the last year. Where possible, express risk in money: expected annual loss before and after a control gives the board a number it can compare with the cost of the control.

Vendors are part of your attack surface. The 2026 DBIR, as reported by Help Net Security, found that third-party involvement in breaches doubled to 48% and that only 23% of third parties had MFA in place in the sampled data. Track critical-vendor assessment coverage, time to close vendor findings, vendors with access to sensitive data and no current assessment, and the number of vendors with MFA enforced on access to your data.

Measure what you can inventory. Start with the percent of AI systems and AI-enabled SaaS tools that are inventoried and owned, high-risk AI use cases assessed before launch, and models with provenance and integrity checks. The frameworks behind these are in AI Governance and Security Policy and AI Model Supply Chain Risks.

Completion rates show attendance. Behavior shows learning, so prefer phishing report rate, median time from delivery to first report, repeat-clicker trend, and the share of staff who know how to report an incident. For insider risk, the program-level measures in Insider Threat Detection apply here too: time to detect and time to contain.

Executives fund what they can compare. Translate security into the language of cost, loss and value. The IANS 2026 benchmark reports security spending at about 9.9% of the IT budget at the median, a useful reference when someone asks "are we spending too much or too little?" Your own financial KPIs should show what that money bought. For budget structure and justification, see Corporate Cybersecurity Budget Planning.

A board does not need fifty charts. It needs a one-page view, a trend, a plain-language "so what", and a clear ask. Use three layers: an executive page of 6 to 8 KPIs, a management layer of 20 to 30 operational KPIs, and a detailed layer in your tools for analysts. The sample below shows the executive page; every value is illustrative.

1. Lead with the answer. Open with whether risk is up, flat or down, and why.
2. Show trends, not snapshots. Twelve months of history beats a single colored tile.
3. Pair every red with a plan. Name the owner, date and the resource needed.
4. Add benchmarks carefully. Industry medians help, but label the source and population.
5. Keep definitions stable. If you change a formula, restate the history.
6. End with decisions. Ask for approval, funding or acceptance of a named risk.

NIST SP 800-55 Volume 2 describes measurement as a program with a lifecycle: identify what decisions need data, define measures, collect and analyze, then use the results to improve. Follow the same loop in practice.

The script below calculates the core KPIs from raw records and rates each against a target. It uses synthetic data for illustration; replace the generator functions with exports from your own tools. It was run with a fixed random seed, and the output beneath it is the real output.

# kpi_scorecard.py: compute core CISO KPIs from raw records and rate them against targets.
# Synthetic data for illustration. Standard library only.
import random
import statistics as st
from datetime import datetime, timedelta

random.seed(21)
NOW = datetime(2026, 11, 1)
SLA_DAYS = {"critical": 7, "high": 30, "medium": 90, "low": 180}   # remediation targets
KEV_SLA_DAYS = 14                                                 # known-exploited vulnerabilities

# ---------- synthetic raw data (replace with exports from your SIEM, ticketing, scanners) ----------
def make_incidents(n=40):
    rows = []
    for _ in range(n):
        occurred = NOW - timedelta(days=random.randint(5, 180), hours=random.randint(0, 23))
        detect_h = random.lognormvariate(2.2, 1.0)        # hours from occurrence to detection
        contain_h = random.lognormvariate(2.0, 0.9)       # hours from detection to containment
        rows.append({"occurred": occurred,
                     "detected": occurred + timedelta(hours=detect_h),
                     "contained": occurred + timedelta(hours=detect_h + contain_h)})
    return rows

def make_vulns(n=300):
    rows = []
    for _ in range(n):
        sev = random.choices(list(SLA_DAYS), [0.08, 0.22, 0.45, 0.25])[0]
        found = NOW - timedelta(days=random.randint(1, 120))
        kev = sev in ("critical", "high") and random.random() < 0.15
        fixed = None
        if random.random() < 0.93:                         # 93% eventually fixed
            fixed = found + timedelta(days=random.expovariate(1 / (SLA_DAYS[sev] * 0.4)))
            if fixed > NOW:
                fixed = None
        rows.append({"sev": sev, "found": found, "fixed": fixed, "kev": kev})
    return rows

incidents, vulns = make_incidents(), make_vulns()

# ---------- KPI calculations ----------
hours = lambda a, b: (b - a).total_seconds() / 3600
mttd = st.median(hours(i["occurred"], i["detected"]) for i in incidents)     # median hours to detect
mttc = st.median(hours(i["detected"], i["contained"]) for i in incidents)    # median hours to contain

def due_and_met(v):
    sla = KEV_SLA_DAYS if v["kev"] else SLA_DAYS[v["sev"]]
    due = v["found"] + timedelta(days=sla)
    if due > NOW:
        return None                                        # not yet due, exclude from SLA rate
    return v["fixed"] is not None and v["fixed"] <= due

results = [r for r in map(due_and_met, vulns) if r is not None]
sla_rate = 100 * sum(results) / len(results)
kev = [v for v in vulns if v["kev"]]
kev_fixed = 100 * sum(1 for v in kev if v["fixed"]) / len(kev)
open_crit_over_30 = sum(1 for v in vulns if v["sev"] == "critical" and not v["fixed"] and (NOW - v["found"]).days > 30)

users, mfa_any, mfa_pr = 1200, 1190, 410               # from your identity provider
assets, edr, scanned = 5000, 4930, 4400                 # from CMDB, EDR and scanner
restore_tests, restore_ok = 12, 11                      # last 12 months of restore drills
trained, reported = 94.0, 38.0                          # % trained; % of simulated phish reported

def status(value, target, higher_better=True):
    ratio = value / target if higher_better else target / max(value, 1e-9)
    return "GREEN" if ratio >= 1 else ("AMBER" if ratio >= 0.8 else "RED")

rows = [  # (KPI, value, unit, target, higher_is_better)
    ("Median time to detect",              mttd,                 "h",  8,    False),
    ("Median time to contain",             mttc,                 "h",  8,    False),
    ("Vuln SLA compliance",                sla_rate,             "%",  90,   True),
    ("KEV vulns remediated",               kev_fixed,            "%",  95,   True),
    ("Phishing-resistant MFA coverage",    100 * mfa_pr / users, "%",  60,   True),
    ("Any-factor MFA coverage",            100 * mfa_any / users,"%",  99,   True),
    ("EDR coverage of assets",             100 * edr / assets,   "%",  98,   True),
    ("Assets scanned in last 30 days",     100 * scanned / assets,"%", 95,   True),
    ("Restore tests passed",               100 * restore_ok / restore_tests, "%", 95, True),
    ("Phishing reported by recipients",    reported,             "%",  50,   True),
]

if __name__ == "__main__":
    print(f"{'KPI':36}{'Value':>9}  {'Target':>7}  Status")
    for name, val, unit, target, hib in rows:
        print(f"{name:36}{val:8.1f}{unit}  {target:6}{unit}  {status(val, target, hib)}")
    print(f"\nOpen critical vulns older than 30 days: {open_crit_over_30}")

Output:

KPI                                     Value   Target  Status
Median time to detect                    9.5h       8h  AMBER
Median time to contain                   8.2h       8h  AMBER
Vuln SLA compliance                     85.7%      90%  AMBER
KEV vulns remediated                    62.5%      95%  RED
Phishing-resistant MFA coverage         34.2%      60%  RED
Any-factor MFA coverage                 99.2%      99%  GREEN
EDR coverage of assets                  98.6%      98%  GREEN
Assets scanned in last 30 days          88.0%      95%  AMBER
Restore tests passed                    91.7%      95%  AMBER
Phishing reported by recipients         38.0%      50%  RED

Open critical vulns older than 30 days: 3

Notice two design choices. Time metrics use the median so a few long incidents do not distort results. The SLA rate excludes vulnerabilities not yet due, so a freshly discovered backlog does not inflate performance. Rating logic treats within 80% of target as amber; adjust the thresholds to your risk appetite.