The difference from a KPI is the direction of view: a KPI measures in hindsight whether a goal was met; a KRI shows ahead of time whether a risk is getting worse. A KRI becomes useful only with three additions: the named risk it refers to, thresholds derived from the risk appetite, and a rule for who does what when a threshold is crossed.
Key takeaways
- A KRI shows whether a risk is rising; a KPI measures whether a goal is met; a KCI measures whether a control works.
- Every KRI needs a named risk, a warning and an escalation threshold derived from the risk appetite, and an escalation rule.
- DORA requires financial entities in Article 6(8)(c) to set key risk metrics as part of their information security objectives.
- ISO/IEC 27001 does not require KRIs; clause 9.1 requires you to decide yourself what is measured, how, when and by whom.
- Thresholds cannot be copied from other sources, because they depend on your own risk appetite.
What is a KRI, and which 4 conditions must it meet?
A KRI is a leading metric tied to a named risk. It is a tool of risk management and assumes that the risks have already been identified and assessed; the methods for doing so are compared in the guide to risk analysis methods. A metric becomes a KRI if it meets four conditions:
- Linked to a named risk. The KRI belongs to an entry in the risk register, such as the risk of known vulnerabilities being exploited.
- Lead time. It changes before the event occurs and leaves time to act.
- Thresholds. At least a warning threshold and an escalation threshold, derived from the defined risk appetite.
- Escalation rule. When a threshold is crossed, it is defined who is informed and which decision is due, for example with the risk owner.
KRI, KPI and KCI compared
A KRI shows whether a risk is rising; a KPI measures whether a goal is being met; a KCI (key control indicator) measures whether a specific control works.
| Indicator type | Guiding question | Direction | Example from patch management |
|---|---|---|---|
| KPI (key performance indicator) | Are we meeting our goal? | backward-looking, performance | Share of patches applied within the agreed period |
| KCI (key control indicator) | Does the control work? | state of a control | Share of systems actually covered by the patching tool |
| KRI (key risk indicator) | Is the risk rising? | forward-looking, exposure | Number of critical vulnerabilities on internet-facing systems open beyond the deadline |
A KPI can be green while the related KRI rises, for example when the team patches faster but new systems push up the number of open critical vulnerabilities. Performance metrics for information security are covered in the entry on security metrics and KPIs; how to report them to the board is the subject of the article security metrics the board understands.
Which 8 KRIs suit information security?
Eight KRIs for information security are shown in the table below, each with the risk it refers to. Thresholds are left out on purpose, because they depend on your risk appetite, system landscape and deadlines.
| KRI | Related risk | Data source | Threshold logic | Escalates to |
|---|---|---|---|---|
| Critical vulnerabilities on internet-facing systems open beyond the remediation deadline | Exploitation of known vulnerabilities | Vulnerability scanner, asset inventory | Count, rising trend over two measurements | Owners of the affected systems, then CISO |
| Share of systems without vendor support (end of life) | Vulnerabilities that can no longer be fixed | Asset inventory | Share of all production systems | IT management, budget decision |
| Privileged accounts with an overdue access review | Misuse of administrator rights | Identity and access management | Number and age of overdue reviews | Risk owner of the system concerned |
| Open exceptions to security requirements | Gradual erosion of the requirements | Exception register | Number and share of expired exceptions | Information security officer, executive management if they accumulate |
| Click rate in phishing simulations, over time | Compromised credentials | Simulation platform | Increase compared with previous campaigns | Awareness owners |
| Systems without active endpoint protection | Undetected malware | EDR console, asset inventory | Count, any deviation on servers | IT operations |
| Recovery tests exceeding the agreed recovery time | Longer outage after an incident | Test records | Any overrun on critical systems | BCM owners |
| Critical service providers without a current security assessment | Incident in the supply chain | Service provider register | Count, age of the last assessment | Procurement and risk owner |
A single value says little; only the trend over several measurements shows whether a risk is shifting.
How do you develop KRIs in 6 steps?
You develop KRIs in six steps, from the risk register to a review of predictive power:
- Start from the risk register, not from the data you happen to have. Pick the material risks and ask which observable quantity changes before they materialize.
- Measure cause, not effect. A good KRI measures a cause or precondition, such as unpatched systems, not the incident itself.
- Define the population and the data source. Without a reference base a value cannot be interpreted; without an automatic source it has to be compiled by hand for every report.
- Derive thresholds from the risk appetite. Set a warning threshold and an escalation threshold, and record the baseline.
- Assign the escalation rule and the recipient. Each threshold is mapped to who is informed and which decision is due.
- Review predictive power regularly. If a risk materialized without any KRI firing, the indicator is unsuitable or the threshold too high.
A COSO-commissioned paper by Mark S. Beasley, Bruce C. Branson and Bonnie V. Hancock, “Developing Key Risk Indicators to Strengthen Enterprise Risk Management”, published in 2010, describes KRIs for enterprise risk management as leading indicators tied to strategic objectives and material risks.
Few KRIs with a clear consequence
For executive management, a few KRIs on the material risks that stay comparable over years are enough; more can be tracked operationally below that. A KRI whose breach would not make anyone act differently should be dropped. Tracking too many indicators risks turning breaches into routine that no longer triggers any response.
Do ISO 27001 or DORA require KRIs?
ISO/IEC 27001 does not require KRIs; DORA expressly requires risk metrics.
ISO/IEC 27001: measurement without a prescribed indicator type
Clause 9.1 of ISO/IEC 27001 requires you to decide for yourself what you monitor and measure, by which methods, when and by whom, and when and by whom the results are evaluated; the standard does not prescribe a particular type of indicator. KRIs are one way to keep watch on the risks from the risk assessment under clause 6.1.2, and under clause 9.3 trends in monitoring and measurement results are an input to the management review.
DORA: key risk metrics in the resilience strategy
DORA, Regulation (EU) 2022/2554, goes further. Under Article 6(8)(c), the digital operational resilience strategy must set out clear information security objectives, including key performance indicators and key risk metrics. The strategy is part of the ICT risk management framework; financial entities under the simplified framework of Article 16 are exempt from Article 6.
Four mistakes that make KRIs ineffective
Four mistakes strip KRIs of their warning function:
- Treating outcome measures as KRIs. The number of incidents reports a risk after it has materialized.
- KRIs without a risk. An indicator not linked to any risk has no owner and no threshold.
- Borrowed thresholds. Thresholds from other sources are not derived from your own risk appetite.
- Traffic lights without consequence. If a red light is merely noted across several reports, the escalation rule is not being lived.
Where Rizzqo takes the values for KRIs from
A KRI is only as good as its data source: if it is compiled for the report, it is out of date by the next meeting. In Rizzqo the values from which KRIs can be derived arise from the work on the assets. A supporting asset's coverage is the share of its requirements finalized as fulfilled; the gap spread shows on how many supporting assets the same requirement is still open. For assets and categories with open gaps, the CISO board shows risk exposure in euros from the linked risk assessments, split into inherent, current and residual. A daily snapshot turns this into a trend.