Security Metrics That Survive a Board Meeting

Security programmes are asked to prove their value with numbers, and most of the numbers reported are the wrong ones. The test for any metric is simple and rarely applied: if this number moved, would anyone do anything differently? A number that cannot change a decision is decoration.

Vanity metrics

These get reported constantly because they are easy to produce and they look impressive.

Attacks blocked, emails filtered, and alerts generated are volume counts driven almost entirely by the internet's background noise. They rise and fall with attacker activity you do not control, and a large number proves only that you have a perimeter, not that it is effective.

Training completion percentage measures attendance, not behaviour. Total vulnerabilities is a count without context — a thousand low-severity findings on isolated systems matters less than three critical findings on an internet-facing one. Patch counts have the same problem.

None of these are useless as operational telemetry. They are useless as evidence of security posture, and presenting them as such invites a reasonable executive to ask what they are supposed to conclude.

Metrics that inform decisions

Time-based measures are the most durable. Time to detect, time to contain, and time to remediate by severity all track capability rather than activity, and they improve or degrade for reasons you control. Report medians alongside worst cases, because an average hides the incident that ran for three weeks — the family discussed under mean time to detect.

Coverage measures answer how much of the estate a control actually protects: the percentage of endpoints with working detection agents reporting in the last week, the percentage of accounts with multi-factor authentication enforced, the percentage of critical assets with tested backups. These expose gaps that binary "we have EDR" statements hide, and they depend on knowing what you own — which is why an accurate CMDB is upstream of honest metrics.

Effectiveness measures test whether controls work rather than whether they exist. The proportion of simulated attack techniques that produced an alert, the phishing simulation reporting rate rather than the click rate, and the proportion of incidents found internally rather than reported by an outsider. That last one is unglamorous and telling.

Exposure measures — internet-facing services with known-exploited vulnerabilities, privileged accounts without MFA, systems past end of support — state risk in terms a business audience can act on, especially when paired with exploitability data such as EPSS rather than raw severity counts.

KPIs and KRIs

A key performance indicator measures how well the function is doing its job — detection time, patch compliance, coverage. It looks at performance.

A key risk indicator is a leading signal that risk is increasing — a rising count of exceptions to policy, unpatched critical systems trending upward, privileged accounts growing, failed access reviews. It looks ahead.

The distinction matters because KPIs tell you how you are doing and KRIs tell you what is about to go wrong. A programme reporting only KPIs is describing the past.

Reporting to leadership

Different audiences need different things, and sending the same dashboard to all of them is why security reporting gets ignored.

The board wants risk in business terms: what could materially hurt the organization, whether it is getting better or worse, whether the investment is producing a result, and how the organization compares to its obligations. A handful of measures with a trend line and a plain statement of what they mean.

Executives want the same with more operational detail and the decisions they need to make. Operational teams want the full set.

Three rules that improve any security report. Show trends, because a single value means nothing without direction. Give context — a target, a peer comparison, or a regulatory requirement — so the audience knows whether the number is good. And say what you will do about anything moving the wrong way, since a metric presented without an action reads as a complaint.

Be honest about bad numbers. Metrics that only ever improve are not being measured; they are being managed, and the credibility cost when that becomes obvious is severe.

Where they connect to operations

Metrics should fall out of the work rather than being assembled by hand each quarter. Detection and response times come from the incident process and the playbooks that record it; coverage comes from the asset inventory; effectiveness comes from control validation such as adversary emulation. Where a metric requires a manual spreadsheet, it will be late, wrong, and eventually abandoned.

Exam angles

Distinguish KPIs (performance) from KRIs (leading risk signals). Recognize activity and volume counts as poor indicators of security effectiveness, and time-based, coverage, effectiveness and exposure measures as meaningful ones. Know that metrics should support decisions, be reported with trend and context, and be tailored to the audience — business risk language for the board, operational detail for the team.