On 26 August 2026 the European Banking Authority (EBA) opened a consultation on draft Regulatory Technical Standards (RTS) specifying how institutions must manage operational risk under the Capital Requirements Regulation. For anyone who has spent two years building a Digital Operational Resilience Act (DORA) programme, one clause matters more than the rest: Article 2 of the draft says you may rely on what you have already built. This article sets out the mapping, article by article, the five things DORA does not give you, and what changes at the EUR 750 million line.
What was published
The paper is EBA/CP/2026/18, dated 26 August 2026. It carries a mandate from Article 323(2) of Regulation (EU) No 575/2013, the Capital Requirements Regulation (CRR), as amended by Regulation (EU) 2024/1623, to specify the obligations institutions have to meet under Article 323(1), points (a) to (h). Fifteen articles, sixteen consultation questions.
| Item | Detail |
|---|---|
| Reference | EBA/CP/2026/18, published 26 August 2026 |
| Legal basis | Article 323(1) and (2) CRR, as amended by Regulation (EU) 2024/1623 |
| Consultation closes | 31 December 2026 at 23:59 |
| Public hearing | Virtual, 29 September 2026, 10:00 to 12:00 CET |
| Hearing registration closes | 25 September 2026 at 16:00 |
| Next step | Final draft RTS submitted to the European Commission for adoption under Article 10 of Regulation (EU) No 1093/2010 |
Note. This is a consultation paper, not law. The text can change, and the draft carries no application date: that will be settled when the Commission adopts the final standard. Nothing below describes an obligation that binds you today. It describes the direction of travel, which is worth knowing while your DORA evidence is still fresh.
Who it reaches, and who it does not
The scope line is worth settling before you read further, because DORA and this draft do not cover the same population.
| DORA (Regulation (EU) 2022/2554) | Draft OpRisk RTS (CRR3) | |
|---|---|---|
| Population | Financial entities across some twenty categories, from credit institutions to crypto-asset service providers | Institutions subject to the CRR: credit institutions and investment firms |
| Insurance undertakings | In scope | Not in scope, they sit under Solvency II |
| Risk covered | ICT risk | Operational risk in full, of which ICT risk is one driver |
| Basis of application | Individual entity | Individual and, where applicable, consolidated and sub-consolidated |
If you are a bank or an investment firm, both apply to you and the overlap is the subject of this article. If you are an insurance undertaking, this draft is not yours, though the direction it sets for ICT-risk integration is worth watching.
Article 2, the clause worth reading twice
The draft opens, before it even reaches its definitions, with a provision on ICT risk. Article 2(1) requires ICT risk management under DORA and Directive (EU) 2022/2556 to form an integral part of the overall risk management framework. Article 2(2) then states that where the RTS requires policies, procedures, controls or tools that are already specified in detail under DORA, institutions may rely on those arrangements to fulfil the requirements of the RTS.
That is a reuse clause, and it is deliberate. Recital 5 explains the reasoning: ICT risk, including ICT third-party risk, is a material component of operational risk, so the two frameworks have to be consistent and duplication has to be avoided. Question 1 of the consultation asks whether the approach works and what further clarification would help, which tells you the EBA expects institutions to test it against their own estate.
The practical consequence: a DORA programme that produced approved, dated, owned artefacts is an asset here. One that produced a compliance narrative is not.
The three components, and where your DORA evidence lands
The draft frames the operational risk management framework in three parts: governance, the operational risk management process, and the operational risk assessment system. The table below maps each requirement to the DORA artefact that speaks to it, and to what the artefact does not reach.
| Draft RTS requirement | What your DORA programme already produces | What it does not cover |
|---|---|---|
| Art. 4(2) The framework reinforces operational resilience, supporting delivery of critical or important functions through disruption | The critical or important function (CIF) inventory under Article 3(22) DORA, with the impact analysis and the response and recovery plans behind it | Disruption from non-ICT sources: process failures, people, legal and misconduct events, physical events |
| Art. 4(3) Management body approves the framework and defines the risk appetite at least annually | Management body accountability for the ICT risk management framework under Article 5(2) DORA, with the annual review under Article 6(5) | An operational risk appetite covering the whole institution, translated by senior management into quantitative limits with escalation on breach |
| Art. 5 Documentation standards: author, version, approving body, dates of development and approval | The document control discipline you built for the ICT risk framework, its policies and its board approvals | Extension of the same discipline to the operational risk framework as a whole, including the three-lines-of-defence description |
| Art. 6(5) Preventive, detective and corrective control activities | Protection and prevention, detection, and response and recovery under the ICT risk pillar | The same control logic applied to conduct, legal, process and people risk |
| Art. 7(3) Business process mapping, risk and control assessments, scenario analysis and stress testing | The asset and dependency mapping under Article 8 DORA, and the testing programme under Articles 24 to 27 | Scenario analysis feeding the internal capital adequacy assessment, and stress testing calibrated on severe but plausible conditions |
| Art. 9(1) Collect, record, store, aggregate, analyse and monitor operational risk data | The ICT-related incident management process under Article 17 DORA, the classification under Article 18, the major-incident reports under Article 19 | Loss amounts, the EUR 20,000 threshold, external loss data, and reconciliation with the accounting records |
| Art. 9(5) An operational risk taxonomy, governed, with ownership and change control | Incident classification by impact under Article 18 DORA | Classification of losses by event type, consistent with the applicable technical standards on loss data classification |
| Art. 10 An independent operational risk management function in the second line | The control function you named for ICT risk, and its independence arrangements | An institution-wide view across every operational risk, with the ability to evidence that view where other functions oversee particular risk types |
| Art. 11 Reporting on the operational risk profile through ordinary reporting lines | The ICT risk reporting cadence to the management body | Reporting to the management body in its supervisory function at least quarterly, or at least annually below EUR 750 million |
| Art. 13 Audit reviews of the process and the assessment system | The internal audit coverage of the ICT risk management framework | Audit of the quality, accuracy and completeness of the data used for the business indicator component |
| Art. 15 Traceable data flows from capture to retention, with ownership and audit trails | Data governance, logging and traceability built for the ICT estate | Reconciliation procedures between accounting data on operational risk losses and the loss data set |
Where DORA stops: five things you still have to build
The reuse clause is generous on process and governance. It is silent on the prudential machinery, because DORA has no equivalent to it.
1. The loss data set. DORA makes you record and report incidents. It never asks what they cost. The draft RTS works in euros: losses above EUR 20,000 under the CRR regime, plus losses below that threshold where they are relevant, with the criteria for relevance written into your own internal documents. An incident register with no financial dimension does not answer Article 9.
2. The business indicator. Article 7(1) of the draft requires the calculation of the business indicator component, and the annual operational risk loss for institutions at or above EUR 750 million. That is CRR machinery, defined in Article 314 CRR, and it comes from the finance function rather than from resilience. Article 9(2)(i) goes further and asks for the input and output data behind it, including how losses, expenses, provisions and financial impacts are allocated to profit and loss items.
3. The operational risk taxonomy. DORA classifies incidents by impact: confidentiality, integrity, availability, and the criteria that decide whether an incident is major. The draft RTS wants events classified by type for loss aggregation, governed with named ownership and change control, and, above the threshold, consistent with the applicable standards on loss data classification. These are different classification systems answering different questions, and mapping between them is work nobody has done yet.
4. Boundary cases. Article 9(2)(b) asks for events where operational risk contributes to losses classified under other risk types. Question 11 of the consultation sets out the EBA reading: boundary cases with Pillar 1 risks mean credit, counterparty and CVA risk, market risk being already inside the operational risk perimeter by Article 317(6) CRR, while boundary cases with Pillar 2 risks such as strategic, business and liquidity risk should always be treated as operational risk. This is a question for your credit and finance colleagues, not for your ICT team.
5. Everything that is not ICT. The obvious one, and the one most likely to be underestimated by a team arriving from a DORA programme. Operational risk in the draft includes legal risk events, misconduct events and failures in third-party arrangements that have nothing to do with technology. Your DORA controls cover one driver of operational risk well. They cover the others not at all.
The EUR 750 million line
Proportionality in the draft runs almost entirely through one number: the business indicator, calculated under Article 314 CRR. Establish which side of it you sit on before anything else, because it changes five separate obligations.
| Requirement | Business indicator at or above EUR 750 million | Below EUR 750 million |
|---|---|---|
| Framework effectiveness review (Art. 4(4)) | At least annually | At least every two years |
| Reporting to the management body in its supervisory function (Art. 11(1)(b)) | At least quarterly | At least annually |
| Operational risk appetite (Art. 4(7)) | Set on its own terms | The business indicator, or its relevant components, may serve as the only proxy, unless the competent authority requires more |
| Data set (Art. 9(2) and 9(3)) | The full list, from sub-threshold losses to key risk and key control indicators and contingent liabilities | A defined subset, plus losses above EUR 20,000 and relevant, material losses below it |
| Taxonomy (Art. 9(7)) | Consistency with the applicable loss data classification standards is required | Recommended, not required |
| Annual operational risk loss (Art. 7(1)) | Calculated | Not required |
Question 16 asks whether this single threshold is the right dividing line at all, and Question 9 asks smaller institutions what loss thresholds they use internally. If your answer to either is anything other than comfortable agreement, the consultation is the place to say so.
The integration nobody has staffed
If you read only one thing in the draft beyond Article 2, read Recital 5. It says that ICT-related incidents falling within the scope of operational risk should be identified and treated as operational risk events inside the operational risk management framework, drawing on the information already produced by the DORA incident management and reporting arrangements.
Read that as an instruction and it becomes concrete. The incident your ICT team classified under Article 18 DORA, notified under Article 19 and closed with a final report has to arrive in the operational risk event register with a loss amount attached, a taxonomy category, a link to the business process where it materialised, and, eventually, a reconciliation against what the accounting records say it cost.
In most banks those are two systems owned by two functions that speak to each other quarterly at best. The draft also asks, at Article 9(2)(b), for incidents and near misses with no loss impact, which is a category DORA already makes you record but which rarely travels beyond the resilience team.
The useful test. Take one ICT-related incident from the last twelve months. Follow it from detection, through classification, through the notification you filed, into the operational risk event register, into the loss data set, and into the profit and loss line where its cost landed. Wherever the trail goes cold is the gap this draft will find.
Six moves before 31 December
None of this requires a programme. It requires half a dozen decisions taken while the consultation is open.
1. Settle which side of the threshold you are on. Get the business indicator from finance, under Article 314 CRR, and write the answer down. Five obligations follow from it.
2. Run the reuse test. Take the fifteen articles of the draft and, for each one, name the DORA artefact that answers it in whole, in part, or not at all. The output is a one-page table, and the free OpRisk RTS readiness check walks the same ground in eight questions. Article 2 gives you the right to rely on those arrangements, but only you can show which ones qualify.
3. Trace one incident end to end. The test above. It takes an afternoon and produces a better gap list than any questionnaire.
4. Check the near-miss question. Do you record ICT-related incidents that caused no loss, and could you produce them by business process? If the answer lives only in a ticketing system, that is a data problem worth naming now.
5. Read Questions 8, 9, 11 and 16 first. Our free guide to the sixteen questions sets out what each one is asking and why. They are the ones that decide what this costs you: the meaning of relevance below EUR 20,000, the threshold for smaller institutions, the treatment of boundary cases, and whether the EUR 750 million line is the right one.
6. Decide whether to respond. Responses are due by 31 December 2026 at 23:59. The virtual public hearing is on 29 September 2026 from 10:00 to 12:00 CET, and registration closes on 25 September 2026 at 16:00. Both are on the EBA consultation page, and both are free.
Why this matters beyond the consultation
Two years of DORA work has produced, in most institutions, a body of evidence held by the resilience and ICT functions: a CIF inventory, an incident process that runs, a Register of Information, tested recovery plans, a testing programme. Article 2 of this draft is the first supervisory text to say plainly that this body of work counts somewhere else.
The institutions that benefit will be the ones that can produce it in a form another function can use: approved, dated, owned, and mapped to a requirement. That is the same discipline DORA rewarded. It is now worth twice.
For the wider banking picture, our DORA compliance guide for banks covers the pillar-by-pillar obligations this framework will sit alongside, and the regulatory watch tracks each step of this consultation.
