Board Cyber Metrics (KPI/KRI) Dashboard Template
A curated, board-grade set of cyber metrics for the quarterly board or risk-committee update. Every metric here earns its place by mapping to a decision the board makes and tying to the risk appetite the board set — not by being an impressive number. Adapt the targets and owners to your own organisation.
01Principles — what makes a metric board-grade
A board metric is not an operational metric scaled up. It exists to inform a decision the board actually makes: where to spend, what risk to accept, when to escalate, and whether the company is inside its stated risk appetite. Apply these principles before any number reaches the deck.
- Maps to a decision. If no board decision changes with the number, it does not belong on the board deck — it is operational detail.
- Tied to risk appetite. The most important metrics are KRIs tracked against the thresholds the board itself set; an appetite breach is the highest-signal thing on the slide.
- Leading and lagging together. Leading indicators (control coverage, patch-SLA, training) predict future risk; lagging indicators (incidents, MTTD/MTTR, audit findings) confirm outcomes. The board needs both.
- Trend, not a snapshot. Show several periods so the board reacts to the direction of travel, not a single frame that could be a recovery or a slide.
- Owner and target. Every metric names who is accountable and what "good" is, or the board cannot judge performance against a commitment.
- Few, not comprehensive. The board gets one slide and a few minutes. Curate ~6–8 decision-linked metrics; a full dashboard belongs to management.
The single test for every candidate: does this number change a board decision? If not, cut it — however good it looks.
02The board metric set
A curated set of ~7 metrics that spans risk posture against appetite, a leading and a lagging view, and the major exposures. Replace the targets and owners with your own; keep each one mapped to a decision.
| Metric | Type | Why it is board-grade | Target | Owner |
|---|---|---|---|---|
| Risk posture vs appetite (open risks above tolerance) | KRI | Tells the board directly whether the company is inside the risk appetite it set; each breach forces a decision to accept, fund or escalate | 0 breaches of appetite | CISO / CRO |
| Critical / internet-facing vulns open past SLA | KRI | A concrete, high-signal appetite threshold on the exposure most likely to be exploited | ≤ threshold set by board | Head of Vuln Mgmt |
| Mean time to detect / respond (MTTD / MTTR) | Lagging | Confirms whether detection and response are inside tolerance when something does happen | MTTD / MTTR targets | Head of SOC |
| Patch-SLA attainment for critical systems | Leading | Predicts future exposure; a leading indicator the board can fund to improve | ≥ 95% | IT Ops |
| % of critical assets covered by EDR | Leading | Measures control coverage on the assets that matter; a gap is a fundable decision | ≥ 98% | Security Engineering |
| Third-party / vendor risk (critical vendors within tolerance) | KRI | Concentrated dependence on critical vendors is the company’s risk regardless of whose systems it sits on | % critical vendors assessed & in tolerance | TPRM Lead |
| Security-awareness training completion | Leading | A leading human-risk indicator; useful context, but not to be featured merely because it is reliably green | ≥ 95% | Security Awareness |
| Major incidents (count & severity, with trend) | Lagging | The outcome measure the board ultimately cares about, shown as a trend with severity — never a bare count | 0 major | CISO |
Show each row with RAG status against its target and the multi-period trend beside the current number. Colour triages attention; the number and trend support the decision.
03Metrics to AVOID (vanity — leave off the board deck)
These numbers look busy and reassuring but map to no board decision. A bigger figure is not a safer company — most of them rise with threat volume, not with security. Keep them in operational dashboards, not on the board slide.
- Malicious / blocked emails and attacks "repelled" — rises with threat volume, not with safety; maps to no decision.
- Total alerts or events generated — an operational workload measure, not a risk measure.
- Patches applied (raw count) — effort, not coverage; patch-SLA attainment on critical systems is the board version.
- Firewall rules, signatures or tools deployed — activity and spend inputs, not outcomes or risk.
- A single undecomposable "security score" — collapses signal; only defensible if the board can drill into what moved it.
- Operational SOC metrics (queue depth, alerts per analyst, false-positive rates) — for running the team, not governing risk.
- Any metric chosen because it is reliably green — flattering selection is itself a vanity trap that displaces higher-signal numbers.
The subtle trap is not just showing vanity metrics — it is choosing which metrics to feature because they flatter you. Select for decision-relevance, not for comfort.
04Presentation guidance
- Show the trend over several periods, not a single point-in-time number — direction of travel drives the board reaction.
- Use red/amber/green against each metric’s agreed threshold, with the actual number and trend alongside. Colour alone hides magnitude; numbers alone force the board to recall every threshold.
- Lead with appetite breaches (KRIs over threshold); do not bury them under green vanity tiles.
- If you use a composite score, make it decomposable — show which component moved and why.
- Benchmark against peers only as cautious context, never as the target; "better than average" can still be outside your own appetite.
Reporting period
Quarter / month covered
RAG thresholds reviewed with
Who agreed the thresholds — board / risk committee
Appetite breaches this period
List each KRI over threshold and the proposed board action
05Cadence & ownership
Metrics without a cadence and an accountable owner drift into trivia. Fix who reports what, to whom, and how often.
Board / risk-committee cadence
e.g. quarterly to the board, monthly to the risk committee
Metric owner (per row)
Each metric names a single accountable owner — see the set above
Threshold review cadence
When appetite thresholds are re-set with the board
Data source & refresh
System of record and how often each metric is refreshed
Escalation path
What happens, and who is told, when a KRI breaches appetite
Review the metric set itself periodically: as the business and threat landscape change, a metric that once mapped to a live decision can become routine, and a new exposure may need a new KRI.