A KPI measures whether a control or process is performing. A KRI signals that risk exposure is changing. The difference sounds academic until you notice that most security dashboards are entirely KPIs - which means they tell you how busy you have been, not whether you are more likely to be breached next quarter.
The distinction
- KPI - key performance indicator. How well are we executing? "94% of privileged access reviews completed on time." Backward-looking, about effectiveness of delivery.
- KRI - key risk indicator. Is exposure increasing? "Number of internet-facing systems with unpatched critical vulnerabilities, trending up three periods." Forward-looking, about likelihood of harm.
The same underlying data often feeds both. Patch compliance percentage is a KPI. The count of critical unpatched externally-reachable systems is a KRI, because it maps to a plausible attack path rather than to team throughput.
Leading vs lagging
- Lagging indicators report what already happened: incidents this quarter, audit findings, breach count. Reliable, but they only confirm outcomes.
- Leading indicators suggest what is coming: unremediated critical vulnerabilities, overdue access reviews, staff phishing report rate, control coverage gaps.
Boards receive almost entirely lagging metrics, which is why security reporting so often feels like history rather than governance. One good leading indicator is worth several lagging ones.
Metrics worth reporting
Genuinely useful KPIs
- Percentage of recurring controls completed on schedule.
- Mean time to remediate, by severity, against your SLA.
- Training completion within deadline, including new joiners.
- Evidence coverage - controls with current, in-period evidence.
- Vendor assessments completed against those due.
Genuinely useful KRIs
- Critical vulnerabilities on internet-facing systems, and their age.
- Accounts with standing privileged access.
- Leaver accounts still active beyond the target window.
- Critical suppliers without current assessment or with no exit plan.
- Systems outside the supported-software baseline.
- Phishing report rate - falling report rate is an early cultural warning.
- Overdue high-risk treatment items.
Measure controls, not activity
GRC Copilot tracks control coverage, evidence currency and remediation against your SLAs - the measurement layer that maturity frameworks require.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Metrics that waste everyone's time
- Attacks blocked. Impressive, uninformative, and driven by internet background noise rather than your posture.
- Total vulnerability count with no exposure or exploitability context.
- Emails scanned, alerts generated - volume of activity, not effectiveness.
- Training completion at 100% forever - true and inert; the report rate is the behavioural measure.
- Any number without a target, trend or consequence.
Thresholds are what make a metric operational
A metric without a threshold is trivia. Each should carry:
- A target - what good looks like.
- A threshold that triggers action, tied to your risk tolerance.
- An owner who acts when it is breached.
- A trend - direction usually matters more than the current value.
Why measurement unlocks maturity
This is the practical payoff. Maturity models - SAMA CSF's levels, HITRUST's scoring, CMMI-style scales - typically place "implemented" below "measured" and "managed". An organisation can operate a control perfectly and still be capped at the middle of the scale because nothing is measured or reported.
If you are pursuing SAMA CSF level 4 or a certifiable HITRUST score, defining KPIs and reporting them periodically is the remaining work. It is a governance activity, not a technical one, and it is usually the cheapest maturity increment available.
Building a small set
- Start with five to seven metrics, not thirty.
- Cover both performance and risk - at least two leading indicators.
- Automate collection; hand-assembled metrics stop being produced.
- Set targets and thresholds before the first report, not after seeing the numbers.
- Report trends, and say what changed as a result.
- Retire metrics nobody acts on.
Frequently asked questions
How many metrics should we report to the board?
Five to seven, with trends. Boards act on direction and exceptions, not on dashboards.
Can one metric be both a KPI and a KRI?
The same data often serves both, framed differently. Patch completion rate is performance; unpatched internet-facing criticals is risk.
What if our metrics always look good?
You are probably measuring what is easy. Add a leading indicator tied to a real attack path and see whether it stays comfortable.
Do frameworks require metrics?
ISO 27001 requires monitoring, measurement, analysis and evaluation. Maturity-scored frameworks like SAMA CSF effectively require them to progress beyond the middle levels.
Key takeaways
- KPIs measure execution; KRIs warn that exposure is rising.
- Most dashboards are lagging - add at least two leading indicators.
- Every metric needs a target, threshold, owner and trend.
- Measurement is usually the cheapest step from "implemented" to a higher maturity level.