Most cyber dashboards mix key performance indicators (KPIs) and key risk indicators (KRIs) in one list, so a board reading "98 per cent of critical patches applied" cannot tell whether the organisation is safe or merely busy. A KPI tells you whether a control or programme is delivering what it promised. A KRI tells you whether exposure to a named risk is approaching the level the organisation agreed to tolerate. The two often use the same data, which is exactly why they get confused. This guide is for CISOs, risk managers and security metrics owners who need to decide which indicator belongs in which report, how to convert one into the other, and who must act when a threshold is crossed. It goes deeper on the distinction than the Key Risk Indicators for Cyber Risk Guide, which covers KRI design and catalogues in full.
Key takeaways
- A KPI measures delivery, a KRI measures exposure. The test is the question each answers: "are we doing what we said?" versus "are we still inside our risk tolerance?"
- The same data can feed both. Percentage of critical vulnerabilities patched is a KPI; the count of mission-critical systems still unpatched at day 10 of a 14-day tolerance is a KRI built from the same feed.
- KRIs need a tolerance and an owner, or they are just numbers. A threshold nobody is obliged to act on is a KPI with a red colour applied.
- Audience follows type. Boards and risk committees need KRIs tied to appetite plus a few outcome KPIs; operational teams need KPIs to run their work and leading KRIs to prioritise it.
- Identity is where the gap shows first. Programmes report high coverage percentages for human MFA or secrets rotation while a handful of exposed machine credentials carry most of the risk.
Definitions that hold up under audit
NIST SP 800-55 Vol. 1 (December 2024), the measurement guide for information security, treats KPIs and KRIs as kinds of metric rather than everything an organisation measures. It describes KPIs as metrics of progress toward intended results and KRIs as metrics used to measure risk. It also defines leading indicators as predictive metrics that come before incidents and lagging indicators as metrics that track the outcomes of events. NIST IR 8286C Rev 1, which covers staging cybersecurity risks for enterprise risk management, puts the distinction in terms of purpose: KPIs show whether a programme is succeeding and how controls perform against tolerance, while KRIs are the measures particularly valuable for predicting risk, showing whether likelihood or impact is rising, a new risk has appeared or controls are failing.
| Attribute | KPI | KRI |
|---|---|---|
| Question answered | Is the control or programme delivering as designed? | Is exposure to a named risk moving towards or beyond tolerance? |
| Anchored to | A target, service level or plan milestone | A risk tolerance statement derived from appetite |
| Typical owner | Control or programme owner (security operations, IAM, vulnerability management) | Risk owner, usually a business executive, with the CISO advising |
| Typical form | Percentages, rates, cycle times, coverage | Counts of high-impact exposures, ages against deadlines, estimated loss bands |
| Time orientation | Mostly lagging (what was delivered last period) | Leading by design, with a paired lagging KRI showing tolerance breach |
| What a breach of threshold triggers | Operational correction: resource, process or tooling change | A risk decision: accept with a dated plan, add controls, transfer or escalate |
| Primary audience | Management and operational teams | Executive risk forums, risk committee, board |
| Good example | Median days to remediate critical vulnerabilities | Internet-facing systems with known exploited vulnerabilities open past the amber point |
One further class sits between them. A key control indicator shows whether a specific control is operating across its population, such as the share of servers reporting to endpoint detection. Many organisations fold these into KPIs; what matters is that nobody presents them as risk measures without linking them to a tolerance.
How the two connect: one feed, two indicators
NIST IR 8286C Rev 1 Section 5 describes risk tolerance statements being translated into security controls, KPIs and KRIs, with tolerance always more specific than appetite. Its notional patching example shows the relationship cleanly.
| Element | NIST IR 8286C Rev 1 example (patching) | What it tells you |
|---|---|---|
| Tolerance | CVSS 10 vulnerabilities on mission-critical systems patched within 14 days of discovery | The line the organisation has agreed not to cross |
| KPI | Percentage of critical vulnerabilities patched | Whether the patching process is performing |
| Leading KRI | Mission-critical systems with unpatched CVSS 10 vulnerabilities at 10 days | Tolerance is at risk and there are four days left to act |
| Lagging KRI | The same count at 15 days | Tolerance has been exceeded and governance must be told |
Notice what the KPI cannot show. A 97 per cent patch rate looks healthy, but if the missing 3 per cent are the internet-facing payment servers, exposure is outside tolerance. The KRI narrows the population to what the tolerance protects and counts the items that matter. Conversely, the KRI alone does not tell the vulnerability team whether its process is improving; the KPI does.
Converting a KPI into a KRI takes four changes:
- Narrow the population to the assets, identities or data the tolerance statement covers.
- Switch from rate to count or age where each item is serious on its own.
- Set the threshold from the tolerance, with the leading point early enough to act.
- Name a risk owner who must decide, not just a team that must work harder.
Decision criteria: which indicator for which purpose
Audience
The UK Cyber Governance Code of Practice (April 2025) asks boards to define and communicate the organisation's cyber security risk appetite (action A3) and to require formal reporting at least quarterly, with suitable metrics tracked and tolerances agreed for each (action E2). That structure points to KRIs: a metric with a tolerance is a risk indicator. Boards still need a small number of KPIs to judge whether the strategy is being delivered (action B4), but they should be outcome KPIs, not activity counts. The Board Cyber Risk Reporting Guide covers report design.
| Audience | Mostly KRIs | Mostly KPIs | Typical cadence |
|---|---|---|---|
| Board or risk committee | Top risks against tolerance, trend and breaches since last report | Three to five outcome KPIs on strategy delivery | Quarterly, plus out-of-cycle on lagging breach |
| Executive risk forum | All top-risk KRIs, amber and red items with owners and dates | Programme delivery against plan | Monthly |
| CISO leadership team | Leading KRIs to prioritise effort | Control and service performance by function | Monthly or fortnightly |
| Operational teams | Leading KRIs for their area, as work queues | Throughput, cycle time, backlog, coverage | Weekly or daily |
Leading or lagging
Both types can be leading or lagging, but the mix differs. Most KPIs report the past period. A useful KRI set pairs one leading indicator, which warns while there is still time inside the tolerance, with one lagging indicator, which records that tolerance was exceeded. If a top risk has only lagging indicators (incidents, audit findings), the board learns about exposure after the damage.
Link to risk appetite
If there is no approved tolerance, there cannot be a true KRI. NIST IR 8286C Rev 1 also names risk capacity, the maximum risk an organisation can endure, as something to watch closely. Where appetite has not been set, start with the Cyber Risk Appetite Statement Template and report KPIs honestly as KPIs until tolerances exist.
Small and large organisations
- Small organisations: five to eight KRIs covering the top risks, each with an owner, plus a handful of KPIs the IT lead already tracks. Avoid building a metrics platform before the tolerances exist.
- Large and regulated organisations: KRIs cascade from enterprise risk categories to cyber scenarios to business units, with aggregation rules agreed with enterprise risk management and internal audit testing definitions.
Paired examples: KPI and KRI side by side
Each row shows how a delivery measure and an exposure measure differ for the same domain. Thresholds must come from your own tolerances.
| Domain | KPI (delivery) | KRI (exposure) |
|---|---|---|
| Vulnerability management | Median days to remediate critical findings | Known exploited vulnerabilities on internet-facing systems open beyond the amber point |
| Workforce authentication | Percentage of users enrolled in MFA | Privileged and remote-access accounts without phishing-resistant MFA |
| Secrets and machine credentials | Percentage of secrets rotated on schedule | Production credentials known or suspected exposed and not rotated within the agreed window |
| NHI ownership | Percentage of non-human identities with an owner recorded | Non-human identities with production write access and no active owner |
| Access governance | Access review campaigns completed on time | Standing privileged entitlements above the agreed ceiling |
| Detection | Mean time to acknowledge alerts | Critical log sources silent for longer than the agreed window |
| Backup and recovery | Backup job success rate | Critical services without a successful isolated restore test this quarter |
| Third parties | Supplier assessments completed against plan | Critical suppliers with broad API or OAuth access and no review in the last year |
| Awareness | Training completion rate | Users who submitted credentials in simulations and hold privileged roles |
For deeper identity sets, see the Identity Security Metrics Guide and the NHI Programme Metrics guide.
Where identity fits
Identity metrics expose the KPI and KRI gap more clearly than any other domain, because the populations are large and the risk is concentrated. A secrets rotation KPI can read 99.9 per cent while the remaining 0.1 per cent includes the credentials an attacker already holds. The Cloudflare Thanksgiving Breach shows this: after the October 2023 Okta support system compromise, Cloudflare reported that it failed to rotate one service token and three service accounts out of thousands, and an attacker used them in November 2023 to reach its Atlassian systems and source code. Any rotation KPI would have looked excellent. A KRI defined as "credentials exposed in a known third-party incident and not rotated" would have shown four open items on critical systems, each one a decision for a risk owner.
Good NHI and identity KRIs share three traits: they count items rather than report ratios, they restrict the population to identities with access to what the tolerance protects, and they include age against a deadline. The Board Briefing: NHI Risk shows how to present them.
Controls: making the indicators trustworthy
Metric definitions
NIST SP 800-55 Vol. 1 says meaningful measures take organisational security goals and objectives into account and includes a goal field in its measure template, linking each measure to a strategic or security goal. It also warns that an accurate measure unrelated to stated priorities may not be useful. Write a one-page definition for every KPI and KRI before it reaches a dashboard.
| Field | KPI definition | KRI definition (additional or different) |
|---|---|---|
| Goal or risk link | Programme objective or service level | Risk register entry and the tolerance statement |
| Formula and population | Numerator, denominator, inclusion rules | Restricted population; count or age rather than rate where possible |
| Data source | System of record and extraction method | Same, plus a coverage measure so a shrinking inventory cannot hide exposure |
| Target or threshold | Target and trend direction | Green, amber and red points derived from tolerance, with lead time to act |
| Owner | Control owner | Risk owner who decides, plus the control owner who acts |
| Escalation | Management review if target missed | Named route and timescale for amber and red |
Thresholds and escalation
NIST IR 8286C Rev 1 describes two reporting routes: when a leading KRI is exceeded, normal periodic reporting may be enough; when a lagging KRI is exceeded, an intermediate communication is needed so relevant parties know tolerance has been exceeded. Build those two routes into your process and add a third, local to your governance, for any threat to risk capacity. KPI misses go to management review; they do not escalate to the board unless they move a KRI.
Implementation: separating KPIs from KRIs in an existing dashboard
- List every metric currently reported to any audience above team level.
- Classify each as activity count, KPI, key control indicator or KRI, using the question it answers. Expect most to be activity counts or KPIs.
- Map top risks from the risk register and check which have an approved tolerance. Those without one go back to the risk owner before any KRI is built.
- Convert one KPI per top risk into a leading and lagging KRI pair, using the four changes above.
- Baseline for one or two cycles without thresholds, then set thresholds with the risk owner. This is the audit mode for indicators.
- Split the reports: board and executive packs lead with KRIs; KPIs move to management packs except for a few outcome measures.
- Roll back any KRI that proves noisy or unreliable to a KPI until its data source is fixed, and record why.
- Review yearly and after major incidents, acquisitions or tolerance changes.
Detection and measurement: is the indicator set working?
- KRI coverage: percentage of top cyber risks with at least one leading and one lagging KRI tied to an approved tolerance.
- Ownership: percentage of KRIs with a named risk owner who has acknowledged the threshold in the last 12 months.
- Escalation timeliness: percentage of lagging KRI breaches communicated to the risk owner within the agreed timescale.
- Decision rate: percentage of red KRIs with a recorded decision (accept with date, treat, transfer) within one reporting cycle.
- Predictive value: share of incidents in the year preceded by an amber or red leading KRI in the affected area.
- Board mix: ratio of KRIs to activity counts in the board pack, trending towards KRIs.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-02 | Appetite and tolerance statements, the anchor for every KRI |
| NIST CSF 2.0 | GV.RM-03; GV.RR-01 | Cyber risk in enterprise risk management; leadership accountability and ownership |
| NIST CSF 2.0 | GV.OV-03; ID.IM-01 | Evaluating risk management performance; improvements from evaluations (KPIs) |
| NIST SP 800-53 Rev 5 | PM-6 Measures of Performance | Programme KPIs |
| NIST SP 800-53 Rev 5 | PM-9 Risk Management Strategy; RA-3 Risk Assessment; RA-7 Risk Response | Tolerance, assessment and the decisions KRIs trigger |
| NIST SP 800-53 Rev 5 | CA-7 Continuous Monitoring | Data feeds and monitoring frequency behind both indicator types |
| ISO/IEC 27001:2022 | Clause 6.1 (risk assessment and treatment); Clause 9.1 (monitoring, measurement, analysis and evaluation) | Risk criteria and measurement of ISMS performance |
| UK Cyber Governance Code of Practice | A2, A3, B4, E1, E2 | Ownership, appetite, strategy delivery, governance roles, quarterly reporting with tolerances |
Common failure patterns
- KPIs dressed as risk: "patch compliance 96 per cent" on a slide titled "cyber risk". It measures effort, not exposure. Rename it or convert it.
- Thresholds without owners: red, amber and green set by the security team, with no business owner obliged to decide. Every KRI threshold needs a named risk owner who has agreed it.
- Ratios that hide the few items that matter: high coverage percentages over large identity populations, as the Cloudflare case shows. Count the high-impact residue.
- Same metric, two names: one number reported as a KPI to operations and a KRI to the board, with different definitions. Keep one definition per indicator and state its type.
- KRIs with no tolerance behind them: thresholds invented because a dashboard needed colours. Get the tolerance approved first.
- Green for ever: indicators that have not changed state in two years are either badly calibrated or measuring a solved problem.
Practitioner checklist
- Classify every reported metric as activity count, KPI, key control indicator or KRI.
- Confirm each top risk has an approved tolerance before building its KRIs.
- Pair one leading and one lagging KRI per top risk.
- Restrict KRI populations to what the tolerance protects and count high-impact items.
- Name a risk owner and a control owner for every KRI.
- Define escalation routes for leading and lagging breaches, with timescales.
- Include machine credentials and non-human identities in identity KRIs.
- Lead board packs with KRIs and limit KPIs to a few outcome measures.
- Report inventory coverage next to every ratio-based indicator.
Standards and references
- NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures
- NIST: IR 8286C Rev 1, Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight
- NIST: IR 8286 Rev 1, Integrating Cybersecurity and Enterprise Risk Management
- UK Government: Cyber Governance Code of Practice
- Financial Stability Board: Principles for an Effective Risk Appetite Framework
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
Related NHI Mgmt Group resources: Security Metrics and KPIs Programme Guide · Cyber Risk Quantification Guide · Board Cyber Report Template · IGA KPIs and KRIs to Report to the Board