How to Build a Security Metrics Program (Step by Step)

Most security metrics programs fail the same way: someone exports every number a tool will produce, puts them on a dashboard, and six months later nobody looks at it because none of the numbers ever changed a decision. A program that works is built in the opposite direction — from decisions back to data — and it is built in a deliberate order. Here are the seven steps, plus how to fold in the AI-era metrics a 2026 program needs.

Step 1 — Tie metrics to decisions and objectives

Start with the decisions, not the data. Write down the choices your leadership and security team actually make: what to fund next quarter, which risks to formally accept, where to add headcount, when to escalate, what to tell the board. Then work backward: for each decision, which one or two numbers would genuinely inform it? That is your candidate list. Anything that does not feed a decision does not enter the program — no matter how easy it is to measure. This single discipline prevents most dashboard sprawl before it starts.

Step 2 — Pick a small core set per audience

You are not building one list; you are building three views of one program for three audiences:

• Board: a handful of risk-and-trend indicators in business terms — posture, trend, top risks and roughly their cost, coverage of critical controls, roadmap progress.
• CISO / security leadership: the program-health KPIs across the whole set.
• SOC: operational numbers — MTTD, MTTR, alert volume, false-positive rate, detection coverage.

Keep each view short. A few trusted numbers people act on beats a wall of charts nobody reads. If you are unsure which metrics belong in the core set, our companion guide on good security metrics in the AI era walks through the classic core set and the AI additions.

Step 3 — Define each metric precisely

This is the step teams skip, and it is the one that saves you from the "three decks, three numbers" argument. Give every metric a one-page definition with five parts:

• Formula / definition — exactly what is counted, over what period, with explicit inclusions and exclusions.
• Source — the system the data comes from.
• Owner — the named person or team accountable for the number and for moving it.
• Cadence — how often it is measured and reported.
• Target — what good looks like, and the reasoning behind it.

Ambiguity is how one metric quietly becomes several. If three teams each count "incidents" their own way, you will get three incident counts and a meeting about which is right. A written definition ends that.

Step 4 — Baseline first, then set targets

Do not set a target before you know where you stand. Measure the metric as it actually is today — that is your baseline. Then decide where your risk tolerance says it needs to be, and set a target that closes the gap on a realistic timeline. Resist the urge to import an "industry average" off a vendor slide: those figures are rarely comparable to your scope, definitions and maturity, and chasing them steers you toward a number disconnected from your real risk. When the board asks "so what does this risk cost us?", a quantification method like FAIR helps translate a risk into a dollar range; for control-coverage targets, anchor to a framework such as NIST CSF or ISO 27001. Re-baseline periodically so targets stay honest as the program matures.

Step 5 — Automate collection

A metric that depends on someone hand-filling a spreadsheet once a quarter will be late, inconsistent, and eventually abandoned. Wire each metric to its source system so the number is produced the same way every time, on its cadence, without heroics. Automation also makes the definition honest: if you cannot automate the collection, it is often a sign the definition is too fuzzy to compute reliably. Start with the metrics whose data already lives in a queryable system (your vulnerability scanner, EDR console, identity provider, ticketing system) and expand from there.

Step 6 — Report to the board and the SOC differently

Same data, three altitudes. The board gets risk and trend tied to money and the decisions you are asking them to make — not a SOC console. The CISO view carries the program-health KPIs that connect board narrative to ground truth. The SOC gets the operational detail that drives daily tuning and staffing. The recurring mistake is handing the board a dashboard built for analysts, or asking analysts to act on a board-level trend line. Build the roll-ups once, deliberately, so the same underlying numbers can tell three audiences what each of them needs.

Step 7 — Review on a cadence and retire vanity metrics

A metrics program that only ever grows becomes noise. Put a recurring review on the calendar and, at each one, ask of every metric: does this still drive a decision, does it still have an owner, is it still hard to game? Retire the ones that have gone stale as deliberately as you added them. Watch specifically for vanity metrics — numbers that climb reassuringly (alerts handled, trainings delivered) but change nothing — and metrics that have quietly lost their owner. Pruning is not a sign the program failed; it is a sign it is being run.

Adding AI metrics to the program

Once the discipline above is in place, extend it to the AI layer — defining each AI metric the same way (formula, source, owner, cadence, target) rather than bolting them on. Start with the one that gates all the others:

• AI and model inventory coverage — you cannot measure or defend AI you cannot see, so coverage comes first.
• Shadow-AI detections — a risk indicator for ungoverned tool adoption.
• Prompt-injection test pass rate — of AI-facing apps, how many pass a prompt-injection suite.
• AIBOM and model-provenance coverage — can you produce a bill of materials for your AI components.
• AI red-team finding closure rate and agent autonomy level — adversarial findings and how much your agents do without a human in the loop.
• AI data-leakage incidents — sensitive data exposed through an AI tool or integration.

For most of these, the honest first target is "measure it at all," then "reach X% coverage," then tighten. Baseline each one; do not import a target from elsewhere.

Start here

You do not have to build the metric catalog from a blank page. Browse the full metrics library and build a weighted risk score — select the metrics that fit each audience, define and baseline them, set your own targets, and weight them into a single posture score you can trend over time. From there, these free tools support the steps above:

• SOC Maturity Assessment — baseline your detection-and-response operation before you set operational targets.
• NIST CSF Toolkit — anchor your control-coverage metrics to a recognized framework.
• 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, ISO 27001, FAIR) are referenced for orientation only; set your own targets against your own risk tolerance.