Most cyber "KRIs" reported to boards are activity counts that move whether or not risk has changed, so the board learns nothing until an incident tells it. A key risk indicator (KRI) is a measure that shows whether exposure to a specific risk is approaching or exceeding the tolerance the organisation has agreed, early enough for someone to act. This guide covers how KRIs differ from KPIs, how to derive them from appetite and tolerance using the NIST IR 8286 series, the attributes every KRI needs, a starter catalogue for cyber risk including identity and non-human identities, threshold calibration, escalation and aggregation, and the failure patterns that make KRIs useless. It is written for cyber risk managers, CISOs and ERM teams. It assumes appetite and tolerance statements exist; to write those, see the Risk Appetite and Tolerance for Cyber Guide.
Key takeaways
- KRIs measure exposure, KPIs measure performance. NIST IR 8286C Rev 1 treats security controls, KPIs and KRIs as an interrelated triad that turns tolerance into measurable terms: KPIs show whether controls work, KRIs show whether that keeps risk acceptable.
- Every KRI needs a tolerance to measure against. Without an agreed tolerance a KRI is just a metric; with one, it has thresholds, an owner and an escalation route.
- Pair leading with lagging. NIST's notional examples set a leading KRI before the tolerance (critical vulnerabilities still unpatched at 10 days against a 14-day tolerance) and a lagging KRI after it (15 days).
- Breach type sets the reporting route. IR 8286C says leading KRI breaches can go through normal periodic reporting, while lagging breaches, where tolerance has already been exceeded, need intermediate communication.
- Fewer, owned, measured. A handful of KRIs per top risk, each with a fixed definition, data source and accountable owner, beats a dashboard of 80 untraceable numbers.
What a KRI is and is not
IR 8286 Rev 1 describes KRIs as the subset of metrics that indicate risk exposure and support oversight of tolerance, and says accepted risks must be measured too, to confirm they stay within tolerance. The test of a KRI is simple: if it crosses its threshold, does someone have to make a risk decision?
| Measure | Question it answers | Cyber example | Audience |
|---|---|---|---|
| Operational metric | How much activity happened? | Phishing emails blocked this month | Operations teams |
| Key performance indicator (KPI) | Is a control or programme performing as designed? | Percentage of critical vulnerabilities patched (NIST IR 8286C example) | Control owners, CISO |
| Key control indicator | Is a specific control operating and covering its population? | Share of production servers reporting to EDR | Control owners, internal audit |
| Key risk indicator (KRI) | Is exposure to a named risk approaching or beyond tolerance? | Critical vulnerabilities on mission-critical systems unpatched at 10 days | Risk owners, ERM, executive and board committees |
The same number can be a KPI at one level and feed a KRI at another. IR 8286C gives the example of a KPI counting business applications that are not adequately protected, which can trigger an organisation-level review of whether the backup tolerance gives adequate direction.
From appetite to KRI
NIST IR 8286C Rev 1 Section 5 sets out the chain: appetite gives direction, tolerance decomposes it into something specific ("tolerance is always more specific than appetite"), controls deliver it, KPIs measure the controls, and KRIs predict whether tolerance will hold. It adds risk capacity, the maximum risk the organisation can endure, as a criterion that must be monitored closely. The NIST notional examples show the chain end to end.
| Element | Vulnerability patching | Access control | Website availability |
|---|---|---|---|
| Appetite (paraphrased) | Mission-critical systems protected from known vulnerabilities | Health information accessible only to authorised parties | Minimal service disruption on customer-facing websites |
| Tolerance | Critical (CVSS 10) flaws on mission-critical systems patched within 14 days | Unique accounts; no more than 5 failed logins per user and 30 in total per hour | Outages of up to 2 hours affecting at most 5% of customers |
| Controls | Periodic vulnerability assessment, patch deployment | Unique accounts, authentication methods, audit logs, alerting | Generator, cooling, upstream provider, load balancers, web servers |
| KPI | Percentage of critical vulnerabilities patched | Unsuccessful logins in a 1-hour period | Outage time in hours; customer outage percentage |
| Leading KRI | Critical flaws still unpatched at 10 days | 4 failed logins for one user, or 25 across all users, within an hour | Outage of 1.5 hours affecting more than 5% of customers |
| Lagging KRI | Critical flaws still unpatched at 15 days | 6 failed logins for one user, or 35 across all users, within an hour | Outage of more than 2 hours affecting more than 5% of customers |
Source: NIST IR 8286C Rev 1, Table 5 (notional examples). NIST notes that where quantitative assessment is used, increases in estimated likelihood and financial impact can themselves be KRIs. See the Cyber Risk Quantification Guide.
Two design lessons follow. First, the leading threshold sits inside the tolerance with enough lead time to act: four days before the patching deadline, half an hour before the outage limit. Second, the lagging threshold is the evidence that tolerance was breached and is what governance must hear about promptly.
Designing a KRI: the attributes
Write each KRI as a one-page specification before it reaches a dashboard. These attributes make it auditable and stable across reporting periods.
| Attribute | What to define | Example |
|---|---|---|
| Linked risk and tolerance | Register ID of the risk and the tolerance statement it measures | CSRR-014 ransomware on core platforms; tolerance: KEV-listed flaws on internet-facing systems fixed within 7 days |
| Definition | Exact formula, unit and counting rule | Count of KEV-listed vulnerabilities open on internet-facing assets beyond 5 days |
| Population | Which assets or identities are in scope, and how the denominator is fixed | All assets tagged internet-facing in the CMDB; inventory coverage reported separately |
| Data source and lineage | System of record, extraction method, transformation | Vulnerability scanner joined to CISA KEV catalogue, daily |
| Direction and type | Leading or lagging; whether higher is worse | Leading; higher is worse |
| Thresholds | Green, amber and red values with the rationale for each | Green 0; amber 1 to 3; red more than 3 or any beyond 7 days |
| Frequency | Measurement and reporting cadence | Measured daily, reported monthly to risk committee |
| Owner | Named person accountable for the risk response, distinct from the data provider | Head of infrastructure (owner); vulnerability management lead (data) |
| Escalation | Who is told when amber and red are crossed, and how fast | Amber: risk owner within 1 working day; red: CISO and CRO within 24 hours |
| Data quality flag | How a failed or partial measurement is shown | "Not measured" displayed instead of zero |
The CISA Known Exploited Vulnerabilities (KEV) catalogue is a good example of a population filter that turns a noisy metric (all open vulnerabilities) into a risk-relevant one (vulnerabilities known to be exploited in the wild). See the Vulnerability Management Guide.
A starter KRI catalogue for cyber risk
Pick from this list only where you have an agreed tolerance and a reliable data source. Thresholds must come from your own tolerances, not from this table.
| Risk | Leading KRI | Lagging KRI |
|---|---|---|
| Exploitation of known vulnerabilities | KEV-listed or critical vulnerabilities on internet-facing assets open beyond the amber point of the tolerance | Vulnerabilities open beyond tolerance; incidents traced to a known, unpatched flaw |
| Account takeover (workforce) | Privileged and remote-access accounts without phishing-resistant MFA; corporate credentials found in infostealer logs and not reset within 24 hours | Confirmed account compromises per quarter |
| Non-human identity compromise | Production secrets and API keys older than the rotation policy; NHIs with no named owner; NHIs unused for 90 days but still enabled | Incidents involving leaked or abused machine credentials |
| Excess privilege | Standing privileged accounts above the agreed number; overdue access reviews for critical applications | Audit findings on inappropriate access |
| Ransomware and recovery | Critical systems without a tested, isolated backup in the last quarter; EDR coverage gaps on servers | Recovery time in the last test or incident against the recovery objective |
| Third-party compromise | Critical suppliers with overdue security assessments; third-party OAuth grants with broad scopes not reviewed | Incidents originating at suppliers |
| Data exposure | Publicly accessible storage buckets holding classified data; unencrypted sensitive data stores | Reportable data breaches per year |
| Detection failure | Critical log sources not reporting to the SIEM; rising external reconnaissance scanning (NIST IR 8286 Rev 1 example) | Mean time to detect confirmed incidents against target |
| Service disruption | Outage duration approaching the tolerance in the period | Severe customer disruptions in the last 90 days (NIST IR 8286 Rev 1 example) |
Where identity fits: NIST's own positive KRI example counts critical business systems protected by strong authentication. Extend that thinking to machine identities, which in most estates outnumber staff and rarely appear in access reviews. Owner coverage, credential age and dormant enabled NHIs are among the most predictive leading indicators available. See the Identity Security Metrics Guide and the NHI Risk Scoring Guide.
Setting and calibrating thresholds
- Derive, do not invent: the red threshold is the tolerance itself or its breach; the amber threshold is the point at which the owner can still recover inside the reporting period. If a tolerance is 14 days, an amber at 13 days gives no time to act.
- Count high-impact items: a percentage hides absolute exposure. Report "12 production API keys older than 365 days" rather than "99.4% compliant" when each item is serious on its own.
- Fix the denominator: if the population shrinks because discovery failed, a ratio KRI improves while risk grows. Report inventory coverage alongside.
- Baseline before you commit: run new KRIs for one or two cycles without thresholds, review the distribution with the risk owner, then set thresholds. Treat this as an audit mode for indicators.
- Recalibrate on change: IR 8286C says monitoring frequency should increase when impact or likelihood changes faster than the current interval, and that managers may change the KRIs monitored to gain better visibility. Review thresholds at least annually and after major incidents, acquisitions or regulatory change.
- Quantitative KRIs: where the organisation estimates loss in money, a rise in estimated annual loss for a top scenario beyond an agreed band is itself a KRI.
Reporting, escalation and aggregation
| Event | Reporting route (after NIST IR 8286C Rev 1) | Typical decision |
|---|---|---|
| Leading KRI crosses amber | Normal periodic reporting to the risk owner and management risk forum | Accelerate the response; confirm resources |
| Lagging KRI crosses red (tolerance exceeded) | Intermediate communication outside the normal cycle to the risk owner, CISO and ERM | Accept temporarily with a dated plan, add controls, or change priority |
| Risk capacity threatened | Immediate escalation to executive leadership and the board committee | Invoke incident or crisis governance; consider avoidance |
| KRI cannot be measured | Flag as a data quality exception in the same report | Fix the data source; treat the risk as unverified |
- Questions to ask on any KRI change: IR 8286C suggests asking whether likelihood is rising, severity is rising, a new risk has emerged, or controls are failing.
- Aggregation: NIST lists simple counts, weighted scores and summed exposure as ways to aggregate across registers, with the enterprise register's priority as a key input. Keep the underlying KRIs visible to the risk owner even when the board sees a composite.
- Cadence: IR 8286C says reporting cycles should match external disclosure obligations; if the enterprise reports quarterly, subordinate cycles must run at least quarterly. The UK Cyber Governance Code of Practice (8 April 2025), action E2, asks boards to require formal reporting at least quarterly, set suitable metrics and agree tolerances for each.
- Board view: show each top risk with its tolerance, current KRI value, trend over four periods and the owner's response, not a list of raw metrics. See the Board Cyber Risk Reporting Guide.
Implementing a KRI framework
- Start from the top risks: take the five to ten highest cyber risks on the enterprise risk register and their tolerance statements. If a top risk has no tolerance, fix that first.
- Draft one leading and one lagging KRI per risk: using the attribute specification above, with the risk owner in the room.
- Prove the data: for each KRI, extract the value manually once, then automate. Record lineage. Drop KRIs whose data cannot be trusted rather than reporting them.
- Run in shadow mode for one or two cycles: report values without thresholds, then set amber and red with the owner.
- Agree escalation: document who receives amber and red breaches and within what time, and test the route once.
- Go live with governance: table the KRI set at the risk committee and record approval of thresholds alongside appetite and tolerance.
- Review: quarterly for values and actions, annually for the set itself, retiring KRIs that never move or never trigger a decision. If a new KRI floods committees with false alarms, return it to shadow mode and recalibrate.
Small and large organisations: a small organisation might run eight to twelve KRIs from existing tools in a spreadsheet reviewed monthly by the leadership team. A large enterprise needs a KRI library with version control, automated feeds from security tooling into the GRC platform, and separate board, executive and management views drawn from one data set.
Measuring whether the KRIs work
- Share of top enterprise cyber risks with at least one approved leading and one lagging KRI.
- Share of KRIs fed automatically from a system of record with documented lineage.
- Median time from a red breach to a recorded risk decision.
- Number of incidents in the year that no KRI moved before (a sign of missing indicators).
- Share of KRIs reported as "not measured" in the period.
Framework mapping
| Framework | Reference | Relevance to KRIs |
|---|---|---|
| NIST CSF 2.0 | GV.RM-02 | Appetite and tolerance statements established, communicated and maintained: the anchor for every KRI |
| NIST CSF 2.0 | GV.RM-06 | Standardised method for calculating and prioritising risk, which KRI aggregation depends on |
| NIST CSF 2.0 | GV.OV-03 | Cybersecurity risk management performance evaluated and reviewed for adjustments |
| NIST CSF 2.0 | ID.RA-05, PR.AA-01, DE.CM-01 | Sources of KRI data: risk analysis, identity and credential management (users, services and hardware), network monitoring |
| NIST SP 800-53 Rev 5 | PM-6, PM-31, CA-7 | Measures of performance, continuous monitoring strategy and continuous monitoring |
| NIST SP 800-53 Rev 5 | RA-5, SI-2, AC-2 | Vulnerability monitoring, flaw remediation and account management: common KRI data sources |
| NIST IR 8286 Rev 1 and 8286C Rev 1 | Sections 3.6.2 and 5 | KRI and KPI definitions, leading and lagging indicators, notional examples, escalation |
| ISO/IEC 27001:2022 | Clause 9.1 | Monitoring, measurement, analysis and evaluation; see the ISO/IEC 27003 and 27004 Guide |
| UK Cyber Governance Code of Practice | Actions A3 and E2 | Board-defined cyber risk appetite; quarterly reporting with metrics and agreed tolerances |
| FSB Principles for an Effective Risk Appetite Framework (2013) | Risk capacity, appetite, limits and profile | The financial-sector model many ERM teams use for limit structures |
Common failure patterns
- Activity counts dressed as KRIs: "attacks blocked" rises with traffic and tells the board nothing about exposure. Replace with measures tied to a tolerance.
- No tolerance behind the KRI: thresholds set by the security team alone, with no approved tolerance, are opinions. Get the risk owner and ERM to agree them.
- Lagging only: incident counts and audit findings report damage after the fact; NIST favours leading indicators because they are actionable.
- Shrinking denominators: ratio KRIs improve when discovery fails. Report coverage of the population next to every ratio.
- Human identity only: MFA coverage for staff is reported while service accounts, API keys and tokens go unmeasured.
- Green forever: KRIs that have never changed colour in two years are either badly calibrated or measuring a solved risk. Retire or recalibrate them.
Lessons from incidents
The Snowflake Breach of 2024 is a clear case of exposure that leading KRIs could have shown. Attackers used credentials stolen by infostealer malware, some dating back to 2020, to log in to customer accounts that had no MFA, no credential rotation and no network restrictions; Mandiant found that at least 79.7% of the accounts used had prior credential exposure in infostealer logs. Three leading KRIs would each have moved well before data was taken: accounts on critical data platforms without MFA, credentials older than the rotation policy, and corporate credentials found in infostealer logs but not reset. The lesson for KRI design is that the most predictive indicators are often simple coverage and age measures over identities, human and non-human, on the systems that hold the most valuable data.
Practitioner checklist
- Confirm every top cyber risk has an approved tolerance before designing its KRIs.
- Define one leading and one lagging KRI per top risk, using a written attribute specification.
- Fix populations and report inventory coverage next to every ratio KRI.
- Set amber with enough lead time to recover inside the reporting period, and red at the tolerance breach.
- Run new KRIs in shadow mode for one or two cycles before thresholds go live.
- Document escalation: periodic reporting for leading breaches, out-of-cycle notice for lagging breaches.
- Include NHI indicators: owner coverage, credential age and dormant enabled machine identities.
- Align cadence with disclosure and board cycles, at least quarterly.
- Review the KRI set annually and retire indicators that never trigger a decision.
Standards and references
- 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 (ERM)
- NIST: Cybersecurity Framework
- CISA: Known Exploited Vulnerabilities Catalog
- UK Government and NCSC: Cyber Governance Code of Practice
- Financial Stability Board: Principles for an Effective Risk Appetite Framework
Related NHI Mgmt Group resources: Risk Appetite and Tolerance for Cyber Guide · NIST IR 8286 Cybersecurity and ERM Integration Guide · Security Metrics and KPIs Programme Guide · Board Cyber Risk Reporting Guide