Learn
DORA went live on 17 January 2025. The supervisory expectation has shifted from "do you have an ICT risk-management framework?" to "show me the indicators you watch and the thresholds you act on."
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) does not list a fixed set of Key Risk Indicators - but every article that touches risk management, incident management, third-party risk and resilience testing imposes a monitoring obligation. This article walks through DORA article by article and lists the specific KRIs that satisfy each one. If you've been searching for "DORA KRIs", "DORA Article 6 risk indicators", "DORA Article 31 concentration risk metrics" or "DORA operational resilience metrics", this is the practitioner's reference.
Every KRI below is one Venvera ships seeded out of the box, with the regulator-grounded thresholds documented in the platform. The article identifies why the supervisor will ask for it.
Article 5 - Governance and organisation
Article 5 places the management body in personal accountability for the ICT risk-management framework. The supervisory question: how does the board demonstrate oversight? A board-level KRI dashboard with green/amber/red status per domain is the standard answer.
Suggested KRI: Composite domain-health score (operational, cyber, third-party, conduct, financial-crime, fraud, ESG, strategic, regulatory, resilience)
Single 0-100 score per domain, weighted by the regulatory anchoring of constituent KRIs. Reviewed by the management body at every board meeting per Art. 5(2).
Article 6 - ICT risk-management framework
Article 6 is the article supervisors will probe most. It requires a documented framework with policies, procedures and protocols for identification, assessment, treatment and monitoring of ICT risks. The continuous-monitoring expectation is explicit in Art. 6(8): mechanisms to detect anomalous activities and a corresponding response.
KRI 1: Critical risks above tolerance
Count of critical-level ICT risks whose residual rating exceeds the documented risk tolerance. Direction: lower is better. Green 0, amber ≤ 2, red > 2.
KRI 2: % of policies past review date
Share of approved policies whose next-review date has lapsed. Direction: lower is better. Green ≤ 5%, amber ≤ 15%, red > 15%.
KRI 3: ICT risks with overdue review
Count of risks whose next-review date has passed without an updated review. Direction: lower is better. Green ≤ 2, amber ≤ 10, red > 10.
Article 9 - Protection and prevention
Article 9 requires effective protection and prevention controls. Auditors translate this to two questions: are the controls implemented, and are they actually working?
KRI 4: Average control effectiveness
Share of implemented controls rated "effective". Direction: higher is better. Green ≥ 85%, amber ≥ 70%, red < 70%.
KRI 5: Open vulnerabilities > 30 days (high / critical)
Number of high-severity vulnerabilities discovered more than 30 days ago and still open. Direction: lower is better. Green ≤ 5, amber ≤ 20, red > 20.
Articles 17-19 - ICT-related incident management
Articles 17-19 prescribe the major-incident classification and reporting timelines: 4-hour initial notification, 24-hour intermediate, 72-hour final and a 1-month root-cause analysis. Missing any of these is a supervisory event in its own right.
KRI 6: Open major incidents
Count of incidents classified "major" with status open or in-progress. Direction: lower is better. Green 0, amber ≤ 2, red > 2.
KRI 7: Incidents with missed regulator deadline (90-day rolling)
Number of incidents over the last 90 days where the 4h / 24h / 72h DORA clock was breached. Direction: lower is better. Green 0, amber ≤ 1, red > 1.
KRI 8: Mean time to remediate critical ICT risks (days)
Average days from identification to closure for critical-level ICT risks. Direction: lower is better. Green ≤ 45, amber ≤ 90, red > 90.
Articles 24-27 - Digital operational resilience testing
Articles 24-27 require a documented testing programme covering vulnerability assessments, scenario-based testing, source-code reviews, end-to-end tests and threat-led penetration testing (TLPT) at least every three years for the largest entities. The supervisor wants evidence the schedule is being kept.
KRI 9: % of mandated resilience tests completed on schedule
Share of resilience tests (TLPT, scenario, recovery drills) completed within their planned window. Direction: higher is better. Green ≥ 90%, amber ≥ 75%, red < 75%.
Articles 28-30 - ICT third-party risk
Articles 28-30 prescribe the periodic assessment of ICT third-party providers, the contractual provisions required and the Register of Information. Two KRIs are non-negotiable:
KRI 10: % of critical vendors with overdue assessment
Share of critical or important third-party providers whose most recent risk assessment is more than 365 days old. Direction: lower is better. Green ≤ 5%, amber ≤ 15%, red > 15%.
KRI 11: Top-5 vendor spend concentration
Share of annual ICT spend allocated to the five largest providers. Direction: lower is better. Green < 50%, amber < 70%, red ≥ 70%.
Article 31 - Critical ICT third-party providers (concentration risk)
Article 31 introduces concentration risk on critical ICT third-party providers (CTPPs) - explicitly anticipating systemic risk from a small number of providers serving many EU financial entities. The Herfindahl-Hirschman Index (HHI) is the canonical concentration measure regulators borrow from competition policy.
KRI 12: Vendor spend HHI
Sum of squared market shares of vendor spend. Direction: lower is better. Green < 1,500 (competitive), amber < 2,500 (moderately concentrated), red ≥ 2,500 (highly concentrated).
KRI 13: Critical functions on a single provider
Count of critical business functions served by exactly one provider - each is a single point of failure under Art. 31. Direction: lower is better. Green ≤ 1, amber ≤ 3, red > 3.
Article 13 - ICT-related awareness, training and learning
Article 13 requires staff training on operational resilience. The supervisor wants coverage, not certificates.
KRI 14: % of staff with completed annual security training
Share of active staff who completed mandatory cyber-security awareness training in the last 12 months. Direction: higher is better. Green ≥ 95%, amber ≥ 80%, red < 80%.
Coupling KRI breaches to the DORA statutory clock
One feature that distinguishes a mature DORA programme from a checkbox programme is what happens after a KRI crosses red. The minimum-viable answer is "fire a notification and call a meeting." The supervisor-ready answer is "open an incident with the statutory clock already running."
Venvera's KRI module includes an "auto-create regulatory incident on breach" toggle per KRI. When the indicator crosses into red, Venvera:
- Records a breach event with the previous and new status, the triggering value and the responsible owner.
- If the KRI is anchored to DORA, opens an incident with the appropriate clock: 4-hour initial, 24-hour intermediate, 72-hour final, 1-month root-cause analysis (Art. 19).
- If also anchored to NIS2, populates the 24h early warning / 72h notification / 1m final clocks (Art. 23) in the same incident.
- The incident-clock worker (running every 5 minutes) escalates as deadlines approach, then again on breach.
Result: the gap between "a KRI crossed red" and "the board pack reflects a regulator-grade incident in flight" closes from days to seconds. This is what Article 5's accountability provisions actually demand.
FAQ - DORA KRIs
Does DORA explicitly require KRIs?
The text of Regulation (EU) 2022/2554 does not use the term "Key Risk Indicator". But Article 6 requires continuous identification, assessment and monitoring of ICT risks, with documented mechanisms to detect anomalies. The ESA technical standards (RTS on ICT risk management) operationalise this with thresholds and metrics. KRIs are the universally accepted instrument for satisfying the obligation.
Are HHI thresholds at 1,500 / 2,500 official DORA values?
DORA does not prescribe HHI thresholds explicitly. The 1,500 / 2,500 bands are the canonical thresholds used in competition-policy concentration analysis (US Department of Justice / European Commission Horizontal Merger Guidelines). The ESA technical standards on subcontracting and ICT third-party risk are evolving - current practice anchors to the competition-policy precedent until ESA-specific guidance lands.
Should the board see all 14 KRIs every meeting?
A composite per-domain score (10 domains) plus the list of any red or amber KRIs is the standard board view. The full 14 KRIs sit underneath in an appendix or drill-down. Daily/weekly KRIs (open major incidents, vulnerability backlog) are operational; quarterly KRIs (MTTR, concentration, resilience testing schedule) belong in the board pack.
How is DORA different from NIS2 for KRI purposes?
DORA is sector-specific (EU financial entities) and prescriptive on ICT operational resilience, including the 4h/24h/72h reporting timeline and concentration risk under Art. 31. NIS2 is sector-agnostic and prescribes "policies and procedures to assess the effectiveness of cybersecurity risk-management measures" - including continuous monitoring of effectiveness. The 14 KRIs above satisfy both. See our DORA vs NIS2 comparison →
Where does Venvera fit?
Venvera ships all 14 KRIs pre-seeded in the standard catalogue, each one anchored to the specific DORA article it satisfies. A dozen are auto-computed from the risk register, incidents table, controls library and TPRM data. Breach-to-statutory-clock coupling is built in. Open the KRI module in your tenant →
Building your DORA programme from scratch?
Start with our DORA framework overview, our Register of Information guide, and seed the KRI catalogue from inside the app on day one.
