Learn
DORA never uses the phrase "key risk indicator". It does, however, require you to define thresholds and act on them, and that is the same job under a different name.
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It has 64 articles. Search "DORA KRIs" and you will find lists of indicators asserting that this or that article demands them; a surprising number of those lists cite articles that do not say what they are claimed to say, or in a few cases do not exist. So the point of this guide is narrow and checkable: fourteen indicators, each one attached to the article it actually helps you evidence, with the article text quoted where it matters.
Two honesty notes up front, because they determine how you should read everything below. First, the thresholds are ours, not the regulator's. DORA sets no numeric KRI thresholds anywhere. Every percentage and count in this article is an illustrative starting point that you are expected to tune to your own risk appetite. Anyone presenting a threshold to you as a DORA requirement or an industry benchmark is inventing it. Second, the closest thing to a textual hook for thresholds is Article 10(2), which requires detection mechanisms that "define alert thresholds and criteria to trigger and initiate ICT-related incident response processes". That is the obligation KRIs serve.
| Does DORA require KRIs? | Not by name. The term does not appear in the regulation. Article 6(1) requires continuous monitoring of ICT risk, and Article 10(2) requires alert thresholds that trigger incident response. KRIs are the standard instrument for both. |
| Does DORA set KRI thresholds? | No. Not one numeric threshold for any indicator. Every number in this article is our illustrative default. |
| Where the numbers do come from the law | The incident reporting clock. Those hours are fixed, and they are set by Commission Delegated Regulation (EU) 2025/301, not by DORA itself. |
Article 5: Governance and organisation
Article 5(2) puts the management body in the loop personally: it must "define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework". Article 5(2)(i) then requires it to put in place reporting channels so it is duly informed about third-party arrangements, material changes and at least major incidents.
The supervisory question this creates is not "do you have indicators?" but "what does the board actually see, and what does it do about a red one?" A single indicator does not answer that. A roll-up does.
KRI 1: Composite domain health score
A single 0 to 100 score per risk domain, built from the constituent indicators underneath it, so the board sees posture across the whole estate rather than fourteen disconnected numbers. This is the roll-up that makes Article 5(2)(i) reporting channels usable at board level.
Direction: higher is better. Example thresholds: our default bands are green at 80 and above, amber at 60 to 79, red below 60. Set your own.
Article 6: ICT risk management framework
Article 6(1) requires a sound, comprehensive and well-documented ICT risk management framework that enables you to "address ICT risk quickly, efficiently and comprehensively". Article 6(5) requires the framework to be documented and reviewed at least once a year, and after major incidents, supervisory instructions, or conclusions from testing and audit. Article 6(8) requires it to contain a digital operational resilience strategy, including, at point (b), the ICT risk tolerance level.
That risk tolerance level is the hook. Once you have written down a tolerance, "are we outside it?" becomes a measurable question, and a documented tolerance with nothing measuring it is the weakest thing in the whole framework.
KRI 2: Critical risks above tolerance
Count of critical-level ICT risks whose residual rating exceeds the documented ICT risk tolerance level set under Article 6(8)(b). If this is above zero and nobody is escalating, the tolerance statement is decorative.
Direction: lower is better. Example thresholds: green 0, amber up to 2, red above 2.
KRI 3: Policies past their review date
Share of approved policies whose next review date has lapsed. Article 6(5) makes the annual review of the framework an obligation, and a framework whose constituent policies have quietly expired does not survive contact with an auditor.
Direction: lower is better. Example thresholds: green at or below 5 percent, amber up to 15 percent, red above 15 percent.
KRI 4: Risks with an overdue review
Count of risks whose next review date has passed with no updated review recorded. The companion to the indicator above, on the risk register rather than the policy set.
Direction: lower is better. Example thresholds: green up to 2, amber up to 10, red above 10.
Articles 9 and 10: Protection, prevention and detection
Article 9 requires protection and prevention measures. Article 10 is the one that matters most for indicator design, and it is the article most commonly misattributed in KRI guides, which tend to credit its content to Article 6(8). To be precise: Article 6(8) is the digital operational resilience strategy. Anomaly detection is Article 10.
Article 10(1): "Financial entities shall have in place mechanisms to promptly detect anomalous activities, in accordance with Article 17, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure."
Article 10(2): detection mechanisms shall "enable multiple layers of control, define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for relevant staff in charge of ICT-related incident response."
"Define alert thresholds and criteria to trigger and initiate ICT-related incident response processes" is as close as DORA comes to describing a KRI programme. It also tells you what a threshold is for: not a colour on a slide, but a trigger that starts a response.
KRI 5: Average control effectiveness
Share of implemented controls rated effective at their last test. Article 9 asks whether protective measures exist; this asks whether they work, which is the harder and more useful question.
Direction: higher is better. Example thresholds: green at or above 85 percent, amber at or above 70 percent, red below 70 percent.
KRI 6: Open high or critical vulnerabilities older than 30 days
Count of high-severity vulnerabilities discovered more than 30 days ago and still open. A direct read on whether detection is feeding remediation or just filling a queue.
Direction: lower is better. Example thresholds: green up to 5, amber up to 20, red above 20.
Articles 17 to 19: Incident management and the reporting clock
Article 17 requires an ICT-related incident management process. Article 18 sets the criteria for classifying an incident as major. Article 19(4) requires three submissions, an initial notification, an intermediate report and a final report, but it sets no deadlines at all: it defers the time limits to a technical standard.
This matters because the clock is quoted incorrectly almost everywhere, including in guides that are otherwise careful. The deadlines are in Article 5(1) of Commission Delegated Regulation (EU) 2025/301:
| Submission | Deadline, quoted from RTS 2025/301 Article 5(1) |
| Initial notification | "within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident" |
| Intermediate report | "at the latest within 72 hours from the submission of the initial notification" |
| Final report | "no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report" |
The error to check for in your own runbook. 72 hours is the intermediate report. It is very widely reported as the deadline for the final report, with 24 hours misdescribed as the intermediate one. The 24-hour figure is the outer limit on the initial notification, measured from awareness rather than from classification. If your incident procedure has these swapped, your escalation timings are wrong in a way that only shows up when it is too late to fix.
KRI 7: Open major incidents
Count of incidents classified major under Article 18 that are still open or in progress. The number the board asks for first.
Direction: lower is better. Example thresholds: green 0, amber up to 2, red above 2.
KRI 8: Incidents that missed a regulatory reporting deadline, rolling 90 days
Count of incidents in the last 90 days where a statutory reporting deadline was breached. This is the indicator that should never be amber. A missed deadline is itself a reportable failure, so this measures a compliance breach, not a risk.
Direction: lower is better. Example thresholds: green 0, amber 1, red above 1. There is a good argument for having no amber band here at all.
KRI 9: Mean time to remediate critical ICT risks
Average days from identification to closure for critical ICT risks. Article 6(1) requires ICT risk to be addressed "quickly, efficiently and comprehensively"; this is the only word in that phrase you can put a number on.
Direction: lower is better. Example thresholds: green at or below 45 days, amber at or below 90 days, red above 90 days.
Articles 24 to 27: Resilience testing
Article 24(1) requires a testing programme, for financial entities other than microenterprises, as an integral part of the ICT risk management framework. Article 24(6) is the one with a number in it: at least yearly, appropriate tests must be conducted on all ICT systems and applications supporting critical or important functions. Article 25(1) lists the kinds of test available.
On threat-led penetration testing, one correction worth making because it is repeated constantly: TLPT under Article 26(1) is required at least every three years, but not of "the largest entities" or "significant institutions". It is required of entities that their competent authority has identified under Article 26(8). Size correlates, but the trigger is designation, not size, and it is the competent authority that decides.
KRI 10: Resilience tests completed on schedule
Share of planned resilience tests, including recovery drills and scenario tests, completed inside their planned window. The programme in Article 24 is an obligation to test, and a plan nobody executes is the most common way to fail it quietly.
Direction: higher is better. Example thresholds: green at or above 90 percent, amber at or above 75 percent, red below 75 percent.
Articles 28 to 30: ICT third-party risk
Article 28 requires ongoing management of ICT third-party risk, and Article 28(3) requires the register of information. Article 28(8) requires exit strategies for services supporting critical or important functions. Article 29 requires a preliminary assessment of ICT concentration risk, including whether a provider is "not easily substitutable". Article 30(2) sets out the nine contractual elements every ICT arrangement must contain, at points (a) to (i), with Article 30(3) adding more for critical or important functions.
KRI 11: Critical vendors with an overdue risk assessment
Share of critical or important ICT providers whose most recent risk assessment is more than a year old. Ongoing monitoring under Article 28 is a continuous duty, not an onboarding gate.
Direction: lower is better. Example thresholds: green at or below 5 percent, amber at or below 15 percent, red above 15 percent.
KRI 12: Top-5 vendor spend concentration
Share of annual ICT spend going to the five largest providers. A blunt instrument, but it is the one that most cheaply surfaces the Article 29 question of substitutability.
Direction: lower is better. Example thresholds: green below 50 percent, amber below 70 percent, red at or above 70 percent.
Article 31: Critical ICT third-party providers and concentration
Article 31 gives the ESAs the power to designate critical ICT third-party service providers and bring them under the Oversight Framework. The whole design of that chapter reflects a systemic worry: a small number of providers serving a large share of the EU financial sector. Your entity-level counterpart of that worry is measured with concentration indicators.
KRI 13: Vendor spend HHI
The Herfindahl-Hirschman Index of ICT vendor spend, that is, the sum of the squared percentage shares. It captures something a top-5 share cannot: whether concentration sits in one provider or is spread across several.
Direction: lower is better. Example thresholds: below 1,500, 1,500 to 2,500, above 2,500. See the caveat immediately below, because these numbers are borrowed, not regulatory.
KRI 14: Critical functions served by a single provider
Count of critical or important functions with exactly one provider behind them. Each one is a single point of failure, and Article 10(1) explicitly requires you to identify potential material single points of failure.
Direction: lower is better. Example thresholds: green up to 1, amber up to 3, red above 3.
Where the HHI bands actually come from. DORA prescribes no HHI thresholds, and the ESAs have not published any. The 1,500 and 2,500 bands are lifted from competition policy: they are the concentration thresholds in the 2010 US Horizontal Merger Guidelines issued by the Department of Justice and the Federal Trade Commission, which treat a market below 1,500 as unconcentrated, 1,500 to 2,500 as moderately concentrated, and above 2,500 as highly concentrated. They are a reasonable borrowed yardstick and nothing more. They are not an EU standard, they are not a DORA standard, and the European Commission's own merger guidelines use different bands entirely. Use them as a starting scale, not as a compliance target.
What happens after an indicator turns red
An indicator that goes red and produces an email is a dashboard. An indicator that goes red and starts a process is a control. The difference is what supervisors are probing when they ask about the thresholds you act on, and Article 10(2) is explicit that thresholds exist to "trigger and initiate ICT-related incident response processes".
The design principle is straightforward. When an indicator crosses into red, three things should happen without anyone deciding to make them happen: the breach is recorded with the value that triggered it and the owner responsible; if the breach implies a reportable event, an incident is opened immediately rather than after a meeting; and the reporting deadlines are computed from the moment of detection, not from the moment somebody remembers them.
That last point is where the clock in the section above stops being trivia. If your tooling computes the wrong deadline, it will tell you that you are comfortably inside a window you have in fact already missed. Whatever you use, including anything described below, check the deadline arithmetic it produces against Article 5(1) of RTS 2025/301 yourself.
Frequently Asked Questions
Does DORA explicitly require key risk indicators?
No. The term "key risk indicator" does not appear in Regulation (EU) 2022/2554. What the regulation requires is the underlying function: Article 6(1) requires an ICT risk management framework enabling you to address ICT risk quickly, efficiently and comprehensively, and Article 10(2) requires detection mechanisms that define alert thresholds and criteria to trigger and initiate incident response processes. KRIs are the conventional instrument for discharging that. So the honest formulation is that DORA requires the job, not the tool, and anyone telling you the regulation mandates KRIs by name has not read it.
Are the thresholds in this article regulatory requirements or industry benchmarks?
Neither. Every number in this article, the 70 percent, the 85 percent, the 90 percent, the counts, the HHI bands, is an illustrative default we chose so the indicators are concrete enough to argue with. DORA sets no numeric KRI thresholds anywhere, and there is no published EU benchmark dataset for these measures. Tune them to your own risk appetite and the scale of your estate. If a vendor or consultant presents a threshold to you as "the DORA requirement" or "the industry standard", ask them for the citation, and expect not to get one.
What are the real DORA incident reporting deadlines?
Four hours, 72 hours, one month. Precisely: the initial notification within four hours of classifying the incident as major, and in any case no later than 24 hours from becoming aware of it; the intermediate report at the latest within 72 hours of the initial notification; and the final report no later than one month after the intermediate report, or after the latest updated intermediate report where applicable. These are set by Article 5(1) of Commission Delegated Regulation (EU) 2025/301, not by DORA itself, because Article 19(4) of DORA names the three submissions and defers the time limits to the technical standard. The common error is to describe 24 hours as the intermediate report and 72 hours as the final one. Both halves of that are wrong.
Which article requires anomaly detection: Article 6(8) or Article 10?
Article 10. This is worth stating flatly because the misattribution is common in KRI guidance, and an earlier version of this article made the same mistake. Article 10(1) requires mechanisms to promptly detect anomalous activities and to identify potential material single points of failure, and Article 10(2) requires those mechanisms to define alert thresholds. Article 6(8) is a different thing entirely: it requires the ICT risk management framework to include a digital operational resilience strategy, and at point (b) to establish the ICT risk tolerance level.
Are the HHI bands of 1,500 and 2,500 official DORA values?
No. DORA prescribes no HHI thresholds and the ESAs have published none. Those bands come from the 2010 US Horizontal Merger Guidelines issued by the Department of Justice and the Federal Trade Commission, where a market below 1,500 is unconcentrated, 1,500 to 2,500 is moderately concentrated and above 2,500 is highly concentrated. They are a borrowed yardstick from competition policy, not an EU regulatory standard, and the European Commission uses different bands in its own merger guidelines. Use them as a scale to reason with, and do not represent them internally as a compliance threshold.
Who does threat-led penetration testing actually apply to?
Entities that their competent authority has identified under Article 26(8), on an assessment of impact, systemic character and ICT risk profile and maturity. It is not "the largest entities" or "significant institutions" as a class, and it is not something you self-assess into. Article 26(1) then requires those identified entities to carry out TLPT at least every three years. Entities that are not identified still run the general testing programme under Articles 24 and 25, including the at-least-yearly testing of systems supporting critical or important functions required by Article 24(6).
Primary sources
Every article number in this guide was checked against the text of the regulation. The article count, the deadlines and the threshold provenance all come from the sources below.
- Regulation (EU) 2022/2554 (DORA) - Articles 5, 6, 9, 10, 13, 17 to 19, 24 to 27, 28 to 31. It contains 64 articles and applies from 17 January 2025.
- Commission Delegated Regulation (EU) 2025/301 - Article 5(1) sets the four-hour, 72-hour and one-month reporting deadlines.
- Commission Delegated Regulation (EU) 2024/1774 - the RTS on ICT risk management tools, methods, processes and policies.
- 2010 Horizontal Merger Guidelines (US DOJ and FTC) - the actual origin of the 1,500 and 2,500 HHI concentration bands.
How this works in Venvera
Thirteen of the fourteen indicators above ship as seeded entries in Venvera's KRI catalogue. The fourteenth, the composite domain health score, is not a catalogue entry at all: it is the roll-up the board pack computes across ten risk domains from whatever indicators sit underneath them. Worth being exact about the rest, too, because the catalogue is not a DORA catalogue. It ships 23 indicators tagged across several regimes, DORA and ISO 27001 among them, which is why the mapping in this article is presented as ours: we have attached each indicator to the DORA article it helps evidence, rather than pretending the product stamps a DORA article on every one.
Each indicator carries a direction, so the system knows whether up is good or bad, an amber and a green threshold, an owner, a measurement frequency and a history. Fourteen of them compute themselves on a schedule from data already in the platform, pulling from the risk register, the incident records, the controls library and the third-party data, so the number is not somebody's recollection typed into a form once a quarter.
Each indicator also has a setting to open a linked incident automatically when it crosses into red, which records the breach with the triggering value and the responsible owner, and puts the reporting deadlines onto a worker that re-checks them every five minutes rather than waiting for someone to notice. The board pack is generated from the same data: domain health across ten risk domains, the indicators that have regressed since the last snapshot, and the breaches still open.
What we will not tell you is that this removes your obligation to check the arithmetic. Deadline logic is exactly the kind of thing that is wrong quietly, in tooling and in runbooks alike, so validate whatever you use against Article 5(1) of RTS 2025/301 rather than trusting a label.
DORA is one of several regimes most financial entities carry at once, and indicators are among the most reusable artefacts across them. The crosswalk engine is there so the evidence behind an indicator can serve NIS2 or ISO 27001 without being rebuilt. If you want a quick read on where you stand, run a free compliance check.
Indicators that start a process, not just a colour
A seeded KRI catalogue with thresholds, owners and auto-computed measurements, and a board pack generated from the same data.
Book a demo →Last updated: July 2026. General information, not legal advice. All thresholds in this article are illustrative defaults chosen by Venvera, not regulatory requirements or industry benchmarks. Confirm article references against the current text and your competent authority's guidance.
