Learn
Your risk register tells you what could go wrong. Your KRIs tell you whether the wrong thing is getting more likely right now.
If you've ever sat across from an auditor and been asked "How would you know if your ICT risk environment changed materially since your last assessment?" - and you didn't have a quantitative answer - you needed KRIs. This guide is the working-document version of that answer. It explains what a Key Risk Indicator is, how it differs from a Key Performance Indicator (KPI), why every modern compliance framework expects you to have them, and what concrete KRIs to seed on day one for DORA, NIS2, ISO 27001:2022, AMLD6 and the EU AI Act.
Whether you're searching for "what are KRIs", "KRI examples for risk management", "DORA KRI metrics", "key risk indicators ISO 27001" or "KRI vs KPI" - this is your one-stop reference. By the end you'll have a 14-KRI starter pack, the regulatory citations for each, and the threshold logic to drive a board-ready traffic-light dashboard.
What is a Key Risk Indicator?
A Key Risk Indicator is a quantitative metric chosen to forecast or detect changes in a defined risk's likelihood, impact or velocity. Unlike a Key Performance Indicator (KPI), which measures whether you're achieving a goal, a KRI measures whether a risk you've already identified is becoming more or less acute.
KPI vs KRI - the practical distinction:
- KPI: Percentage of releases shipped on time. Answers "are we hitting our delivery target?"
- KRI: Percentage of releases that triggered a security incident within 7 days of deployment. Answers "is our change-management process degrading our risk posture?"
Same numerator can serve as either, depending on whether you're managing performance or watching risk.
A good KRI has six properties:
- Quantitative. Counts, percentages, days, currency. Not "high / medium / low" - that's the register.
- Predictive or contemporaneous, not lagging. "Number of breaches in the last quarter" is a lagging KPI. "Number of high-severity vulnerabilities open more than 30 days" is a leading KRI.
- Tied to a specific risk in the register. An unanchored metric is just a vanity number.
- Direction-explicit. Lower-is-better (e.g. # open critical incidents) or higher-is-better (e.g. % MFA coverage). The threshold logic depends on it.
- Threshold-bound. A green/amber/red band the value falls into. Without thresholds you have data, not signal.
- Owned. A named accountable role (CISO, CRO, DPO, Compliance Lead).
Why every modern compliance framework requires KRIs
The word "KRI" is not always written into the regulation, but the obligation is. Regulators want evidence that you are continuously monitoring risk levels and that there is a mechanism to escalate when they drift out of tolerance. Quantitative indicators with thresholds are the universal answer.
| Framework | Article / clause | What it requires |
|---|---|---|
| DORA (EU 2022/2554) | Art. 6, Art. 16 | ICT risk-management framework with documented strategy, policies, procedures and protocols, including continuous identification, assessment and monitoring of all ICT risks. Article 31 adds concentration-risk monitoring. |
| NIS2 (EU 2022/2555) | Art. 21(2)(f) | "Policies and procedures to assess the effectiveness of cybersecurity risk-management measures." The only credible way to assess effectiveness is to measure it. |
| ISO 27001:2022 | Clause 6.1.3, 9.1 | Risk treatment plan with monitoring of effectiveness. Clause 9.1 explicitly requires the organisation to determine what needs to be monitored and measured, when, and by whom. |
| NIST CSF 2.0 | GV.RM-04, ID.IM-03 | Risk appetite and tolerance statements include criteria and measurements. Continuous monitoring informs improvement. |
| AMLD6 (EU 2018/1673) | Art. 13, Art. 30 | Risk-based AML/CFT measures with effectiveness monitoring. SAR / alert disposition timeliness is one of the canonical AML KRIs. |
| EU AI Act (EU 2024/1689) | Art. 9, Art. 72 | Risk-management system across the AI system lifecycle. Article 72 introduces post-market monitoring of high-risk AI systems with metrics on performance and incidents. |
In plain language: every supervisory regime that has emerged in the last five years has converged on the same supervisory expectation - show your metrics, show your thresholds, show the trend. KRIs are the answer to all three.
The 14 KRIs every risk manager should track in 2026
Below is a working starter pack spread across the ten enterprise risk domains. Each entry includes the direction, suggested thresholds for a typical mid-market financial-services or B2B SaaS organisation, and the regulatory citations the KRI satisfies.
Regulatory & compliance
1. % of policies past review date
Direction: lower is better · Green: ≤ 5% · Amber: ≤ 15% · Red: > 15% · Frequency: monthly
Maps to: ISO 27001 A.5.1, A.5.5 · DORA Art. 9 · NIS2 Art. 21(2)(a)
2. Regulatory updates unacknowledged > 30 days
Direction: lower is better · Green: 0 · Amber: ≤ 3 · Red: > 3 · Frequency: weekly
Maps to: ISO 27001 4.2 · DORA Art. 13
Operational
3. Critical risks above tolerance
Direction: lower is better · Green: 0 · Amber: ≤ 2 · Red: > 2 · Frequency: monthly
Maps to: DORA Art. 6, Art. 16 · ISO 27001 6.1.2, 6.1.3 · NIS2 Art. 21(2)(a)
4. Risks with overdue review
Direction: lower is better · Green: ≤ 2 · Amber: ≤ 10 · Red: > 10 · Frequency: monthly
Maps to: ISO 27001 6.1.3, 9.1 · DORA Art. 6
5. Average control effectiveness
Direction: higher is better · Green: ≥ 85% · Amber: ≥ 70% · Red: < 70% · Frequency: quarterly
Maps to: ISO 27001 6.1.3, 8.1 · DORA Art. 9
Cyber & ICT
6. Open major incidents
Direction: lower is better · Green: 0 · Amber: ≤ 2 · Red: > 2 · Frequency: daily
Maps to: DORA Art. 17, Art. 19 · NIS2 Art. 23 · ISO 27001 A.5.24
7. Incidents with missed regulator deadline (last 90 days)
Direction: lower is better · Green: 0 · Amber: ≤ 1 · Red: > 1 · Frequency: monthly
Maps to: DORA Art. 19 (4h/24h/72h timelines) · NIS2 Art. 23 (24h/72h/1m) · GDPR Art. 33 (72h)
8. Open vulnerabilities > 30 days (high / critical)
Direction: lower is better · Green: ≤ 5 · Amber: ≤ 20 · Red: > 20 · Frequency: weekly
Maps to: ISO 27001 A.8.8 · DORA Art. 9 · NIS2 Art. 21(2)(e)
9. Mean time to remediate (MTTR) - critical risks
Direction: lower is better · Green: ≤ 45 d · Amber: ≤ 90 d · Red: > 90 d · Frequency: quarterly
Maps to: ISO 27001 8.1, 10.1 · DORA Art. 6, Art. 9
Third-party
10. % of critical vendors with overdue assessments
Direction: lower is better · Green: ≤ 5% · Amber: ≤ 15% · Red: > 15% · Frequency: monthly
Maps to: DORA Art. 28, Art. 29 · ISO 27001 A.5.19, A.5.20 · NIS2 Art. 21(2)(d)
11. Vendor spend Herfindahl-Hirschman Index (HHI)
Direction: lower is better · Green: < 1,500 · Amber: < 2,500 · Red: ≥ 2,500 · Frequency: quarterly
Maps to: DORA Art. 31 (concentration risk)
12. Critical functions on a single provider
Direction: lower is better · Green: ≤ 1 · Amber: ≤ 3 · Red: > 3 · Frequency: quarterly
Maps to: DORA Art. 31
People & awareness
13. % of staff completed annual security training
Direction: higher is better · Green: ≥ 95% · Amber: ≥ 80% · Red: < 80% · Frequency: quarterly
Maps to: NIS2 Art. 21(2)(g) · ISO 27001 A.6.3, A.7.2.2 · DORA Art. 13
14. Phishing simulation click-rate
Direction: lower is better · Green: ≤ 10% · Amber: ≤ 20% · Red: > 20% · Frequency: quarterly
Maps to: ISO 27001 A.6.3 · NIS2 Art. 21(2)(g)
How to actually run a KRI programme - five practical steps
The fastest way to fail at KRIs is to design a beautiful catalogue and then never collect a measurement. The fastest way to succeed is to wire as many KRIs as possible to system data your platform already has, then commit one human owner per remaining manual KRI to a single page where they enter a number once a month.
- Anchor every KRI to a risk and a regulation. "Unattached" KRIs become orphans no one updates. Tag the framework articles or controls the metric satisfies - when a regulator asks why you track it, the answer is on the screen.
- Set thresholds before you measure. Otherwise the first reading becomes the new "normal" and you lose objectivity. Use regulator-grounded defaults where they exist (e.g. HHI 1500/2500 for DORA Art. 31 concentration, or PCI DSS-style 30-day patch SLAs).
- Automate every KRI you can. If the data lives in your platform (risk register, controls library, vendor inventory, incidents table, integration findings) it should be a one-click auto-compute, not a quarterly spreadsheet. Manual is the exception, not the default.
- Show the trend, not just today's number. A green KRI that has been worsening every month for the last quarter is more important than a red one that just flipped. Sparkline plus a regression-alerting rule (three consecutive measurements moving in the bad direction) catches both.
- Couple breach to escalation. When a KRI crosses red, something has to happen automatically - at minimum a notification with a named owner. For regulated entities, the breach should also start the statutory clock (DORA Art. 19 4-hour notification window; NIS2 Art. 23 24-hour early warning). KRIs without escalation are decoration.
How Venvera implements KRIs
Venvera ships a KRI module as part of the standard risk-management workspace. Twenty KRIs come pre-seeded across all ten enterprise risk domains, each one anchored to specific DORA / NIS2 / ISO 27001 / AMLD6 articles. A dozen are auto-computed from the risk register, controls library, incidents table and TPRM vendor data - no manual collection required. The remaining manual KRIs (AML alert backlog, phishing click-rate, RTO/RPO compliance, internal-fraud events) have a single page where the named owner records the value and adds context.
What no other GRC tool produces at the same depth:
- Regulatory-clock-coupled breach. Toggle "auto-create regulatory incident on breach" on any KRI; when it crosses red, Venvera opens an incident with the right statutory clock (DORA Art. 19 4h/24h/72h or NIS2 Art. 23 24h/72h/1m), notifies the right people, and the incident-clock worker monitors due-dates every five minutes.
- Snapshot-based regression alerts. The dashboard surfaces KRIs whose trajectory is worsening across the last three snapshots - even when the current status is still green. This is the early-warning signal regulators expect you to monitor.
- Composite domain-health scores. Each of the ten enterprise risk domains gets a 0-100 health score, weighted by regulatory anchoring (KRIs tagged to more articles weigh more). Surfaces straight onto board packs.
- Control-failure propagation. Link any KRI to the controls whose effectiveness materially affects it. When a control fails, the KRI is flagged as at-risk before the next measurement is even recorded.
- Board-pack PDF export. One click produces a board-ready PDF combining overall health, per-domain composites, regression alerts, open breaches with clock status, and regulatory-readiness scores per framework - anchored to article-level citations.
Try it in your tenant
Open Risk Management → KRIs and click Seed catalogue. Twenty KRIs with the full framework anchoring appear in under a second. Click Auto-compute and the dashboard populates from your live data.
Frequently asked questions about Key Risk Indicators
What is the difference between a KRI and a KPI?
A KPI measures whether you are achieving a performance goal. A KRI measures whether a risk you have identified is increasing or decreasing. The same raw number can serve as either - what matters is the framing. "Time to deploy" is a KPI; "Time to patch a critical vulnerability after disclosure" is a KRI. The threshold logic and ownership chain differ accordingly.
How many KRIs should an organisation track?
For mid-market financial-services, B2B SaaS and healthcare entities operating under DORA, NIS2, ISO 27001 and adjacent regimes, 15-30 active KRIs is a healthy range. Below 15 you are almost certainly missing critical signals; above 40 the cost of monthly collection starts to outweigh the marginal insight. Venvera's seed catalogue lands at 20, which most regulated mid-market entities can run with no adjustment.
Do small organisations need KRIs to be NIS2 or DORA compliant?
NIS2 Art. 21(2)(f) requires "policies and procedures to assess the effectiveness of cybersecurity risk-management measures." Without quantitative indicators the assessment becomes subjective and impossible to defend in a competent-authority inspection. DORA is more explicit - Art. 6 requires a documented framework with continuous monitoring of all ICT risks. Small entities can get away with fewer KRIs, but the obligation to have them does not depend on size.
What is the relationship between KRIs and risk appetite?
Risk appetite is the qualitative statement of the level of risk an organisation is willing to accept. KRIs are the quantitative instruments that tell the board whether the organisation is operating within appetite. A KRI threshold (the green/amber boundary) is the operationalisation of the appetite. When a KRI moves into red, the organisation is operating outside its declared appetite and escalation is required.
Should KRIs be reported to the board?
Yes - and most modern board packs include a single-page KRI dashboard with a green/amber/red status, a sparkline showing the trend, and a flag for any KRI breaches that occurred in the period. DORA Art. 5 in particular places the management body in personal accountability for the ICT risk-management framework, including monitoring. A KRI dashboard is the primary evidence that the board is exercising that oversight.
Where can I find KRI templates I can adapt?
Venvera ships a reference catalogue of 20 KRIs - covering DORA, NIS2, ISO 27001, AMLD6, NIST CSF and EU AI Act - that you can seed into any tenant in one click. Documentation here. AuditBoard publishes a smaller KRI library focused on internal-audit programmes. Drata and Vanta do not ship dedicated KRI primitives at the time of writing - they require you to build the equivalent from their risk-scenario module.
Ready to move from spreadsheet to programme?
Spin up a Venvera tenant, seed the 20-KRI catalogue, and run auto-compute. In under five minutes you'll have a board-ready dashboard with the regulatory citations already attached. Start a free trial →
