Security metrics and KPIs worth reporting
Eight metrics is enough. The test for each is whether a number moving would change a decision someone in the room can make. Metrics that only go up, or that measure activity rather than exposure, take up space and teach a board that security reporting is theatre.
A security metrics pack for an executive audience should be about eight measures, each with a target, a trend and a sentence saying what it means. The useful ones share a property: they measure exposure or speed, both of which can get worse, so the number carries information. Counts of things done, blocked or trained cannot get worse and therefore say nothing.
The structure of the meeting itself and what a board should ask for is on CISO board reporting, and the full quarterly document is on the board report template.
The test a metric has to pass
- Can it get worse? Blocked attacks and training completions only rise. They are activity, not condition.
- Would a change alter a decision? If a number doubles and the response is "noted", it is not a KPI and it belongs in an appendix.
- Does it survive gaming? Any metric a team is measured on will be optimised. Ask how you would cheat it, and whether cheating it would also make the company safer. Mean time to patch improves if you stop scanning the hard systems.
- Is it comparable over time? A metric whose definition moves each quarter is a story, not a measure. Write the definition down and change it deliberately, in public, when you change it.
Eight metrics and what to target
| Metric | Definition | Reasonable target | What it tells you |
|---|---|---|---|
| Time to remediate critical findings | Median days from discovery to fix, criticals only, all sources | Under 14 days | Whether the organisation can actually act. The single best indicator of program health |
| Overdue critical and high findings | Count past their own due date, with the oldest named | Zero critical, single digit high | Whether commitments mean anything. The trend matters more than the count |
| Coverage of critical controls | Percentage of production assets with endpoint detection, logging and MFA | Above 98% | The gap is where incidents start. Report the absolute number of uncovered assets alongside the percentage |
| Privileged accounts, and how many are stale | Count of admin accounts, plus those unused for 90 days | Stale at zero | Access sprawl, which is invisible until it is exploited |
| Phishing report rate and time to report | Percentage of simulated phish reported, and median minutes to first report | Above 30%, under 10 minutes | Whether people help. Far better than click rate, and see awareness training |
| Recovery testing | Date of the last successful restore test of a critical system, and how long it took | Within 90 days | The only backup metric that means anything |
| Third-party exposure | Count of critical vendors, how many reviewed in the last year, and how many hold customer data | 100% of critical reviewed | See vendor risk management |
| Security-driven deal friction | Deals delayed or lost on a security review, and days added to the sales cycle | Trending down | The metric that puts security in revenue terms, and the only one the sales leader will defend at budget time |
The eighth one changes the meeting
Deal friction is the metric almost nobody reports and the one that most changes how a security program is funded. It reframes the program from a cost centre into something with a revenue effect that the chief revenue officer will corroborate. Collecting it means asking sales operations to tag opportunities where a security review added time. The number is usually available within a quarter, and your ROI argument rests on it. The ROI calculator uses the same reasoning and deliberately refuses to convert it into a breach probability nobody can support.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Metrics that mislead, and what to use instead
| Commonly reported | Problem | Report instead |
|---|---|---|
| Attacks blocked | Measures internet background noise. Cannot get worse. Rises when you add a sensor | Incidents that reached a human, and how long they took to close |
| Training completion at 100 per cent | Measures clicking through slides, not behaviour | Phishing report rate and time to report |
| Total vulnerabilities | Dominated by low severity noise and by how many scanners you run | Overdue criticals, and median time to remediate |
| Security maturity score | Moves when the assessor changes. Not comparable across assessments | One score with a published method, trended, plus the weakest domain named. Use the maturity assessment |
| Percentage of controls implemented | Treats a password policy and network segmentation as equal units | Coverage of the small set of controls that actually stop incidents |
| Mean time to detect | Sound in principle and unstable at small volumes, where two incidents set the mean | The individual timeline of each real incident, in prose |
Who sees what, and how often
| Audience | Cadence | What they get |
|---|---|---|
| Security and engineering | Weekly | Everything, including the vulnerability backlog |
| Executive team | Monthly | The eight metrics, one page, plus what changed |
| Board or audit committee | Quarterly | Four or five of the eight, trended over a year, with the risk register and the roadmap |
| Customers and prospects | On request | Certification status and a trust page. Never raw metrics |
Trend over four quarters, not month over month, in board material. A single month is noise at this scale, and presenting it invites a conversation about a number that will have moved back by the next meeting.
Setting targets you can defend
The targets in the table above are defensible starting points, not industry benchmarks. There is no reliable published Canadian benchmark set for most of these at mid-market scale, so a target presented as an industry standard invites a question you cannot answer. Present them as commitments the company is making. A commitment can be argued about and adjusted; a benchmark can only be doubted.
Two habits make targets stick. Set them with the executive who owns the work, not for them. And when a target is missed three quarters running, change the target or change the funding, because a target nobody has ever met is a slow lesson that these numbers do not matter. Where the funding argument goes is covered on security budget benchmarks.
Get a metrics pack built
Defining eight metrics, wiring the data and producing the first pack is a fixed-scope piece of work. Tell us your size and we will get it quoted by Canadian providers.
Get matchedCommon questions
What security metrics should we report to the board?
Four or five, trended over a year: time to remediate critical findings, overdue criticals and highs, coverage of critical controls, recovery testing recency, and security-driven deal friction. Each with a target and a sentence of interpretation. Blocked attacks, training completion and total vulnerability counts should not be in board material, because none of them can get worse in a way that means anything.
How many security KPIs is the right number?
Around eight for an executive team and four or five for a board. The limit is not what you can measure, it is what a room can hold in mind well enough to notice a change. A pack of twenty metrics gets skimmed, and skimming is how a genuinely alarming number gets past a board that would have acted on it.
Is mean time to detect a good metric?
It is sound in principle and unstable in practice at mid-market volumes, where two incidents in a quarter set the mean and a single unusual case swamps the trend. At that scale, walk through the timeline of each real incident in prose instead. Mean time to detect starts earning its place once you have enough incidents a quarter for an average to mean something, which is not a milestone to look forward to.
Should we report a security maturity score?
Only if the method is published and stays the same, because a score that moves when the assessor changes is worse than no score. Used consistently it is a reasonable way to show direction over years and to name the weakest domain, which is the actionable part. Never present a proprietary score you cannot explain the method for, since the first question will be how it is calculated and "the vendor computes it" ends the conversation badly.
Who should produce the metrics pack?
Whoever owns the program, which for a fractional arrangement is the vCISO, at roughly three to six hours a month once the data is wired up. The important constraint is that the numbers come from systems rather than from the person writing the pack, so they are reproducible if someone asks. A pack that only the author can reproduce is a pack the next person will quietly restart from scratch.