Cybersecurity Metrics for the Board: Five Numbers That Actually Communicate Risk
Boards cannot make investment decisions from vulnerability counts. They need five numbers that translate technical activity into business risk — and they need them on one page.
Security teams are good at producing data. They are bad at producing the specific data that a board needs to make investment decisions. The result is a quarterly slide deck with forty metrics, none of which answer the question the board is actually asking: are we safer than last quarter, and is our investment working?
The five metrics that communicate risk
| Metric | What it tells the board | Why it matters |
|---|---|---|
| Mean Time to Detect and Respond (MTTD/MTTR) | How quickly we find and contain incidents | The single best indicator of incident response capability |
| MFA coverage on critical systems | Percentage of privileged and remote access protected by MFA | Directly correlates with reduced breach likelihood |
| Patch SLA compliance | Percentage of critical vulnerabilities patched within the target timeframe | Measures operational discipline, not just vulnerability count |
| Phishing simulation failure rate | Percentage of employees who click in simulated phishing tests | Indicates human risk layer and training effectiveness |
| Tested Recovery Time Objective | Time to restore critical systems, proven by exercise | The number that matters most during a ransomware event |
Why vulnerability counts do not belong on the board slide
'1,400 vulnerabilities remediated this quarter' sounds impressive. It tells the board nothing. Were those 1,400 out of 1,500 (good) or 1,400 out of 15,000 (concerning)? Were they critical or low? Did fixing them reduce risk or just reduce a number? Vulnerability counts measure activity, not capability, and they cannot be used to make investment decisions.
Replace them with patch SLA compliance: '92% of critical vulnerabilities patched within 14 days, up from 78% last quarter.' That is a trend, a target, and a measure of operational discipline — all in one number.
How to present them
One page. Six numbers. Current value, target, and trend arrow. No jargon, no CVSS scores, no framework references. The board's job is not to understand cybersecurity; it is to approve investment and hold the function accountable. Give them the numbers that enable that, and leave the technical detail for the appendix.
The metrics that do not work
- Number of alerts processed. Measures noise, not security. A team that processes 50,000 alerts is not twice as secure as one that processes 25,000; it may just have worse detection tuning.
- Security spend as percentage of IT budget. A ratio, not a result. Spending more does not mean risking less.
- Number of training sessions delivered. Activity, not outcome. The phishing simulation failure rate is the outcome that matters.
- Number of policies published. Documentation is not a control. Controls are what people do, not what they are told.
Reporting that enables decisions, not just documents activity
The board does not need forty metrics. It needs five, on one page, with trends. We help security teams build the reporting that enables investment decisions rather than filling slide decks.
Kinematic Digital designs and operates security programmes for mid-market and enterprise organisations. See our cybersecurity services and preemptive security programme, or book a security review.
Frequently Asked Questions
What are the most useful cybersecurity metrics for a board?
The five that consistently communicate risk: mean time to detect and respond to incidents, percentage of critical assets with MFA, percentage of systems patched within SLA, number of phishing simulations failed, and recovery time objective tested in the last exercise. These translate technical activity into business risk.
Why should vulnerability counts not be reported to the board?
Vulnerability counts measure activity, not capability. A board cannot make investment decisions from '1,400 vulnerabilities remediated this quarter' because it does not indicate whether the organisation is safer. Report risk reduction and capability maturity instead.
How often should security metrics be reported to the board?
Quarterly as a minimum, with a concise one-page scorecard. Annual reporting is too infrequent for a function that can change its risk profile in a week. Monthly reporting is appropriate for high-risk organisations or during active transformation.
What is MTTR and why does it matter?
Mean Time To Respond — the average time from incident detection to containment. It is the single best indicator of incident response capability. A low MTTR means the organisation detects and contains threats quickly; a high MTTR means exposure during incidents is prolonged.
Should we benchmark our metrics against other organisations?
Benchmark selectively. Comparison data is useful for context but dangerous as a target — every organisation has a different risk profile. Use benchmarks to understand whether your metrics are reasonable, not to set goals.