Good Security Metrics in the AI Era: What to Measure (and What to Ignore)

Every security program measures something. The hard part is measuring the few things that change a decision — and, in 2026, noticing that the list of things worth measuring has grown an entire AI-shaped section that most dashboards still ignore. This is a practical guide to what a good security metric looks like, the classic core set that still earns its place, and the AI-era metrics your program is probably missing.

What makes a metric good (and worth keeping)

Before you add a metric, make it pass four tests. If it fails any one of them, it is almost certainly a vanity metric and you should drop it:

• Actionable. A bad reading points to a specific thing someone can do about it. "Number of alerts" on its own is not actionable; "percentage of critical alerts triaged within the SLA" is.
• Owned. A named person or team is accountable for the number and for moving it. A metric nobody owns drifts, gets argued about, and eventually gets ignored.
• Tied to a decision. Some real choice depends on it — fund this, accept that risk, escalate here, staff there. If no decision changes regardless of the value, the metric is decoration.
• Hard to game. You cannot satisfy the number without the underlying reality improving. "Tickets closed" is easy to game; "critical vulnerabilities confirmed remediated and re-scanned" is not.

A handful of metrics that pass all four beats a wall of charts that look impressive and mean nothing. More dials do not make a program more controlled — they make it harder to see what matters.

KPIs, KRIs and KCIs — three questions, not three synonyms

These acronyms get used interchangeably, which hides the fact that they answer different questions:

• KPI — key performance indicator: Are we performing well? Mean time to respond, percentage of critical vulnerabilities patched within SLA, training completion rate.
• KRI — key risk indicator: Is our risk rising? A forward-looking warning signal — unpatched internet-facing systems, volume of shadow-AI detections, number of privileged accounts without MFA. KRIs are meant to move before an incident does.
• KCI — key control indicator: Are our controls actually working? MFA coverage, EDR coverage, backup restore-test success rate, logging coverage.

A balanced program uses all three. KCIs prove your controls exist and function, KRIs warn you when exposure is growing, and KPIs show whether the team is hitting its objectives.

Leading vs lagging: steer by one, confirm with the other

Lagging metrics measure outcomes that already happened — incidents this quarter, mean time to recover, breaches reported. They hold people accountable but they describe the past. Leading metrics are predictive: patch latency, control coverage, phishing report rate, AI inventory coverage. They measure the conditions that drive future outcomes, so you still have time to act. Pair them deliberately: a leading indicator to steer by, and a lagging indicator to confirm the steering worked. A program that reports only lagging numbers is always explaining last quarter instead of improving next one.

Report to the audience, not to yourself

The same underlying data should roll up three different ways, because three different audiences make three different decisions:

• The board makes funding and risk-acceptance decisions. Give them a small set of risk-and-trend indicators in business terms: overall posture, trend over time, top risks and roughly what they would cost, coverage of critical controls, and progress against the roadmap they are funding. A few meaningful numbers, tied to money and decisions.
• The CISO and security leadership track the program-health KPIs across the whole set — the connective tissue between board narrative and ground truth.
• The SOC lives in operational numbers: MTTD, MTTR, alert volume, false-positive rate, detection coverage. These drive daily tuning and staffing.

The classic mistake is showing the board a SOC dashboard, or asking the SOC to act on a board-level trend line. Same data, different altitude.

The classic core set that still earns its place

None of these are new, and that is the point — they are durable because they tie to real decisions:

• MTTD (mean time to detect) and MTTR (mean time to respond/recover) — how fast you see and handle an incident.
• Patch latency — time from a fix being available to it being deployed.
• Percentage of critical vulnerabilities inside SLA — not just "how many," but how many are being handled in time.
• Phishing report rate — a leading behavioral signal; report rate is more useful than click rate because it measures the defense you want to build.
• MFA coverage and EDR coverage — the two control-coverage KCIs that quietly prevent the most incidents.
• Backup restore-test success rate — backups you have never restored are a hope, not a control.
• Control coverage — how much of your chosen framework (such as NIST CSF or ISO 27001) is actually implemented and evidenced, not just documented.

The AI-era metrics most programs are missing

Here is where 2026 programs fall down. They measure patching, coverage and response well, and have almost no visibility into their AI surface. If you cannot answer these, you are flying blind on the fastest-growing part of your attack surface:

• AI and model inventory coverage — do you know every model, API and AI service in use across the business? This is the AI equivalent of asset inventory, and it is usually near zero to start.
• Shadow-AI detections — unsanctioned AI tools employees adopt on their own. A KRI: rising detections mean rising ungoverned risk.
• Prompt-injection test pass rate — of your AI-facing applications, how many pass a prompt-injection test suite?
• AIBOM and model-provenance coverage — can you produce an AI Bill of Materials for your systems: which models, weights, datasets and components, from where?
• AI red-team finding closure rate — findings from adversarial testing of your AI features, and how quickly they close.
• Agent autonomy level — how much your AI agents are permitted to do without a human in the loop. Rising autonomy without rising controls is a risk you want on a chart.
• RAG grounding / citation rate — for retrieval-augmented systems, how often answers are actually grounded in and cite retrieved sources, as a proxy for hallucination risk.
• AI data-leakage incidents — sensitive data exposed through an AI tool, prompt or integration.

You cannot buy credible targets for these off a slide, so do not try.

Set your own targets — do not copy an "industry average"

The single most common request is "what's a good number for MTTR / patch latency / coverage?" There is no honest universal answer, and quoting one off a vendor slide is how programs end up chasing a figure that has nothing to do with their risk. Do this instead: baseline your current number, decide where your risk tolerance says it needs to be, and set a target that closes the gap on a realistic timeline. For most of the AI-era metrics above, the honest first target is simply "measure it at all," then "get coverage above X%," then tighten from there. Methods like FAIR can help you translate a risk into a dollar range when the board asks "so what?"; frameworks like NIST CSF and ISO 27001 give you a control set to measure coverage against. None of them hand you a universal target — they give you a structure for setting your own.

Common anti-patterns to kill on sight

• Vanity metrics — big numbers that go up and to the right (alerts handled, trainings delivered) but change no decision.
• Metrics nobody owns — a chart with no accountable owner is a chart that will be argued about and then quietly dropped.
• Gameable definitions — any metric you can satisfy without improving reality will eventually be satisfied that way.
• Dashboard sprawl — one more panel is not one more insight. Retire metrics as deliberately as you add them.

Put it into practice

If you want a structured starting point rather than a blank spreadsheet, browse the full metrics library and build a weighted risk score — pick the metrics that fit your program, set your own targets, and weight them into a single posture score you can trend. From there, our free tools line up with the measures above:

• AI Security Risk Mapper — map the AI risks you now need metrics for.
• CSPM Readiness Scorecard — score your cloud-posture control coverage.
• AI security tools — the full set for the AI layer of your program.
• All PlayCISO tools — scanners, scorecards and builders across the program.

This article is educational, vendor-neutral guidance for security leaders, not an audit, certification, or legal advice. Framework names (NIST CSF, FAIR, ISO 27001) are referenced for orientation only.