ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Every security team is asked the same question by its board sooner or later: are we getting safer? Answering it means reporting numbers — and that is where cybersecurity KRIs and KPIs get muddled. They are not the same thing, they answer different questions, and mixing them produces reports that look thorough but say very little. This guide explains the difference, what a usable indicator looks like, and how many you actually need.
If you are still choosing a control framework to measure against, start with our guide to the NIST Cybersecurity Framework, or read NIST’s own Cybersecurity Framework overview.
| KPI | KRI | |
|---|---|---|
| Question it answers | Is the control working? | Is our exposure growing? |
| Direction | Backward-looking — performance to date | Forward-looking — early warning |
| Typical example | 98% of servers patched within SLA | Number of internet-facing assets with no named owner |
| What it triggers | Process correction | Risk review or escalation |
| Usual audience | Security and IT management | Risk committee and board |
A key performance indicator measures whether a control is doing its job. Patch compliance, mean time to detect, percentage of staff who completed awareness training, backup success rate — each describes something that has already happened, and each has an obvious target.
KPIs are operational. They tell you whether the machinery you built is running. They rarely tell you whether it is the right machinery, or whether the threat it was built for has changed.
A key risk indicator measures conditions that make a loss more likely, before the loss happens. Unowned assets, privileged accounts without multi-factor authentication, third parties with expired security attestations, systems past end-of-support — none of these are incidents. All of them make incidents more likely.
The practical test: if the number gets worse, does your risk increase even though nothing has failed yet? If yes, it is a KRI.
Most indicator programmes fail not because the metrics are wrong but because nobody can act on them. A reportable indicator needs five things attached to it:
Thresholds agreed in advance matter most. An indicator that turns red only when someone decides it should be red is not an indicator, it is an opinion.
Fewer than most teams start with. A board pack needs somewhere between eight and fifteen indicators; anything more and attention scatters. The larger library sits underneath, reviewed by the security function, with only the exceptions escalating upward.
Building that library from scratch is the slow part. Our Critical IT and Cybersecurity Indicators pack provides 153 ready indicators in two Excel templates — roughly 100 KPIs mapped to NIST CSF sub-controls with red thresholds already set, plus a consolidated list of technology KRIs with owner, frequency, RAG calculation and required evidence per line. It is a starting library to cut down, not a blank sheet to fill.
Boards do not want a dashboard, they want a judgement. Lead with what changed since the last report, what it means for the risk position, and what decision you need from them. Indicators are the evidence for that narrative, not a replacement for it.
Trend beats snapshot. A single red number invites debate about the number; three quarters of steady deterioration invites a decision.
Indicators picked in isolation drift toward whatever is easiest to instrument. Mapping each cybersecurity KRI to a specific control makes two things visible at once: which parts of your programme you are measuring, and which parts you are not measuring at all.
The NIST Cybersecurity Framework works well as the spine because its functions already divide the ground sensibly — identify, protect, detect, respond, recover. If every function has at least one cybersecurity KRI against it and one is conspicuously empty, that gap is the finding, before any number is even reported.
The same mapping pays for itself at audit. An indicator already tied to a control, with its evidence requirement written down, answers an auditor’s question without a separate evidence-gathering exercise.
A KPI measures whether a control is performing — patch rates, training completion, detection times. A KRI measures conditions that increase the likelihood of loss before anything fails, such as unowned assets or privileged accounts without MFA. KPIs look backward at performance; KRIs look forward at exposure.
Between eight and fifteen for a board pack. Keep the wider indicator library at management level and escalate only exceptions and trends, otherwise the signal is lost in volume.
They do not have to be, but mapping them to NIST CSF or ISO 27001 controls makes coverage gaps visible and makes the same evidence reusable for audits. Unmapped indicators tend to cluster around whatever is easiest to measure.
August 12, 2026
August 12, 2026
