DORA for financial entities: duties and implementation

DORA governs the digital operational resilience of the financial entities within its scope. It has applied since 17 January 2025. Implementation requires institutions to connect ICT risk management with actual operations and include externally supplied services in those controls.

What is the DORA Regulation?

The DORA Regulation is Regulation (EU) 2022/2554 of 14 December 2022, which sets uniform requirements for the digital operational resilience of financial entities in the EU financial sector (EUR-Lex); “DORA” stands for Digital Operational Resilience Act. Its legal basis is Art. 114 TFEU (internal market). The core topics are ICT risk management, the management of ICT third-party risk, the reporting of major ICT-related incidents, digital resilience testing including threat-led penetration testing (TLPT), the oversight framework for critical ICT third-party service providers (CTPPs) and the sharing of cyber threat information.

DORA harmonises requirements for managing ICT risks in the financial sector. It covers internal operations and dependence on external services. Even where a service is sourced externally, the financial entity remains responsible for its duties. Regulation (EU) 2022/2554, DORA

How current this systemic-risk rationale is became evident in July 2026: In its warning ESRB/2026/3, officially published in the EU Official Journal C/2026/3795 of 16 July 2026, the European Systemic Risk Board (ESRB) classifies frontier AI models as a source of systemic cyber risk for the EU financial system (ESRB press release of 7 July 2026). For DORA implementation the ESRB warning is relevant in two ways: it concerns ICT risk management under Chapter II of the DORA Regulation (threat landscape, vulnerability management) and ICT concentration risk under Art. 29 DORA, because AI and cloud capacity is concentrated among a few providers.

Since when does DORA apply, and to whom?

The DORA Regulation (EU) 2022/2554 has applied directly to financial entities in the EU since 17 January 2025; no national transposition act was needed, since DORA, as an EU regulation, is directly applicable in all Member States (EUR-Lex). Entry into force and date of application must be distinguished: the Regulation was adopted on 14 December 2022 and published in the EU Official Journal L 333 of 27 December 2022; it entered into force on the twentieth day following that publication (which works out to 16 January 2023), but has only been mandatory to apply since 17 January 2025. Art. 64 DORA settles both in two sentences:

DORA applicability depends on the entity category and the exclusions in Article 2. National provisions may subject additional entities to corresponding requirements. Describing an organisation as a financial company is not sufficient to determine its scope. Article 16 provides a simplified ICT risk-management framework for specified covered entities. Regulation (EU) 2022/2554, DORA

What does DORA regulate? The 9 chapters at a glance

The DORA Regulation is structured into 9 chapters with 64 articles and 106 recitals (EUR-Lex). The chapter map shows the article range and the core obligation for each chapter:

Duties of the management body under DORA: ICT risk management is a non-delegable governance duty of the management body (Art. 5–15 DORA). The management body is responsible for setting and approving the digital operational resilience strategy (Art. 5(2)(d) DORA); senior ICT staff report to it at least once a year (Art. 13(5) DORA); resilience training is mandatory for all employees and for the management body (Art. 13(6) DORA). Even where the compliance review is outsourced, the financial entity remains fully responsible (Art. 6(10) DORA).

How far this responsibility reaches is made clear by Chapter V of the DORA Regulation on ICT third-party risk. Art. 28(1)(a) DORA states verbatim:

Under DORA, then, the service can be outsourced, but never the responsibility: the financial entity remains the addressee of all obligations, even where an ICT third-party service provider runs the operations.

Which DORA deadlines and key dates currently apply?

DORA has applied since 17 January 2025. The following dates identify particular duties and supervisory steps. A new register submission follows the competent supervisor’s current request. Regulation (EU) 2022/2554, DORA BaFin: Informationsregister und Anzeigepflichten

The European Supervisory Authorities reported 3,383 major ICT-related incidents under DORA for 2025. Around one third involved third-party providers. These figures come from their first annual report, published on 3 June 2026. ESAs: first DORA report on major ICT-related incidents

DORA vs. BAIT: What has applied to IT since 2025?

Institutions that implement their ICT risk management under the DORA Regulation have been exempt from the scope of the BAIT since 17 January 2025; the BAIT will only be fully repealed as of 31 December 2026 (BaFin, announcement “DORA kommt” of 9 January 2025). The two dates must be distinguished: for DORA institutions the BAIT has not been applicable since 17 January 2025; the formal repeal, as a transition for the remaining supervised entities, only takes effect as of 31 December 2026.

For the question “Which BAIT requirements continue to apply after 31 December 2026?” this means: none. BaFin is repealing the BAIT in full as of 31 December 2026 (BaFin announcement of 9 January 2025); supervised entities without a DORA ICT obligation continue to apply the BAIT on a transitional basis until that date. The background to the cut-off date: through the German Financial Market Digitalisation Act (FinmadiG), further institutions become subject to DORA from 1 January 2027; Section 1a (2a) KWG extends the DORA requirements “accordingly” to, among others, leasing and factoring institutions. The parallel circulars KAIT, VAIT and ZAIT had already been repealed by BaFin as of 16 January 2025 (BaFin announcement of 9 January 2025).

DORA vs. MaRisk AT 9: What goes where?

Outsourced or externally procured ICT services that are subject to ICT third-party risk management under Art. 28–30 DORA have, since the 9th MaRisk amendment, no longer fallen within the scope of MaRisk AT 9; the explanatory note on AT 9 para. 1 of Circular 06/2026 (BA) of 30 June 2026 makes this clear verbatim:

For outsourcing outside this ICT context, MaRisk AT 9 remains authoritative. The 9th MaRisk amendment entered into force with its publication on 30 June 2026; where additional requirements arise from it in individual cases, BaFin grants a transition period until 1 January 2027 (cover letter to Circular 06/2026 (BA), ref. BA 54-FR 2210/00067#00005, of 30 June 2026; BaFin announcement of 30 June 2026). The MaRisk perspective of the AT 9 restructuring is covered in the overview MaRisk: current version Circular 06/2026, structure and amendments.

DORA vs. NIS2: When is DORA lex specialis?

For the covered financial entities, DORA is a sector-specific Union legal act within Article 4 NIS2. The express designation is in Article 1(2) DORA. This does not establish a blanket answer for every national duty of a financial entity; each duty must be mapped individually. Regulation (EU) 2022/2554, DORA Directive (EU) 2022/2555, Article 4

Which RTS, ITS and guidelines belong to DORA?

DORA is supplemented by delegated acts, implementing acts and guidelines. Each implementation task should use the relevant current instrument, such as the register templates or incident-reporting requirements. Regulation (EU) 2022/2554, DORA Implementing Regulation (EU) 2024/2956, register templates Delegated Regulation (EU) 2025/301, Article 5

Central level 2 acts of DORA include the Delegated Regulations (EU) 2024/1772 (incident classification), 2024/1773 (contractual arrangements policy), 2024/1774 (ICT risk management plus simplified framework), 2025/301 (incident reporting), 2025/532 (subcontracting) and 2025/1190 (TLPT) as well as the Implementing Regulations (EU) 2024/2956 (register templates) and 2025/302 (reporting forms). Based on the CTPP criteria (Delegated Regulation (EU) 2024/1502), the ESAs designated 19 critical ICT third-party service providers for the first time on 18 November 2025 (ESAs press release).

Delegated Regulation (EU) 2024/1774 specifies technical controls, including vulnerability management and access rights. Intervals must be connected to their applicable system and risk scope. A general checklist without that mapping does not fully reflect the instrument. Delegated Regulation (EU) 2024/1774

What is the DORA register of information?

For ICT third-party providers that are legal persons established in the EU, the register permits an LEI or EUID. Equivalent providers outside the EU must use an LEI. Separate template rules govern identifiers for natural persons acting in a business capacity. The register must be maintained and updated continuously. Article 28(3) DORA distinguishes this from annual information on new arrangements and from providing the register when requested by the supervisor. A BaFin submission follows the applicable collection request and format instructions. Implementing Regulation (EU) 2024/2956, register templates Corrigendum to Implementing Regulation (EU) 2024/2956 Regulation (EU) 2022/2554, DORA BaFin: Informationsregister und Anzeigepflichten

Submission must use the technical format and current template version required by BaFin. A self-designed Excel workbook does not meet those requirements merely because BaFin provides an Excel template for a collection. BaFin: Ausfüllhinweise für die RoI-Excel-Vorlage BaFin: Informationsregister und Anzeigepflichten

What do institutions need to do now? Five first steps

The following checks structure implementation in ongoing operation. They need to be related to the financial entity’s scope and risk profile.

1. 01Determine critical or important functions

   Take existing business impact analyses and the protection needs assessment as the starting point (definitions in Art. 3 DORA). The classification drives register content, testing obligations and audit focus areas.

2. 02Consolidate register data

   Bring contracts, ICT service providers, supported functions and provider identifiers together in a shared data model; the target structure is the 15 templates of ITS 2024/2956 (EUR-Lex).

3. 03Run the gap analysis article by article

   Check existing BAIT/ISMS documentation against DORA and RTS 2024/1774. Article 10(2) requires automated vulnerability scanning and assessments at least weekly for ICT assets supporting critical or important functions. Frequency for other assets follows their classification and risk profile (Art. 10).

4. 04Make incident management production-ready

   Test classification and reporting under Art. 17–23 DORA against the deadlines of Delegated Regulation (EU) 2025/301; details: incident reporting under DORA .

5. 05Clarify governance and responsibilities

   Explicitly assign management body responsibility (Art. 5 DORA), annual ICT reporting (Art. 13(5) DORA), training (Art. 13(6) DORA) and the separation of the regulatory circuits DORA Art. 28–30 vs. MaRisk AT 9.

Test business continuity from outage to business recovery

A recovery test should establish whether an important task can be performed reliably again after disruption. Current MaRisk AT 7.3 addresses impact analysis, coordinated continuity arrangements and documented testing, among other matters. The sequence below is a self-developed working example connecting business process, technology and provider; it does not replace the entire DORA testing programme.

1. 01Define the question and boundary

   Example: following an outage of its reporting application, a business team can produce and approve a priority report again. Record the affected function, permitted test environment and authority to abort before starting.

2. 02Record dependencies and targets

   Include data, sign-in, interfaces, workstations, staff and involved providers. Derive maximum tolerable disruption, recovery target and tolerable data loss from the actual process; the template does not prescribe generic hourly targets.

3. 03Prepare the sequence and evidence

   Assign distinct tasks to the test lead, business acceptance owner, technical operator and observer. Agree data, fallback, communication and time measurement beforehand. An exercise notification must not be mistaken for an actual incident.

4. 04Trigger the scenario in a controlled way

   Record the trigger and timestamp. Check alerting, activation of continuity arrangements, restoration and backlog handling. A discussion workshop alone does not demonstrate technical recovery; identify the two test types separately.

5. 05Verify business recovery

   Starting the application is insufficient. Complete a defined business transaction, reconcile its data and have the accountable role assess the result. Compare measured times and lost or reconstructed data against the agreed criteria.

6. 06Close deviations and retest

   Assign each deviation an owner, deadline, interim measure and retest evidence. Distinguish passed, partially passed, failed and not tested. The responsible management role decides on residual risks and follow-up actions.

The downloadable template connects scenario, acceptance criteria and results in one record. It can support a facilitated walkthrough and a subsequent technical test. Dependencies deliberately left untested must remain visible in the outcome.

Legal and professional sources: BaFin: MaRisk, Rundschreiben 06/2026 (BA), 30.06.2026, amtlicher Volltext bei der Bundesbank; Verordnung (EU) 2022/2554: DORA, insbesondere Artikel 11, 24 und 28–30.

Download the test record (Markdown)

Classify ICT incidents: when is a disruption major?

Start with an incident record containing occurrence, awareness, affected services, initial impact and responsible people. Recovery and assessment run in parallel. Update classification as new evidence emerges; an initially low estimate does not end the assessment. The steps below connect DORA Articles 17–19 with Delegated Regulation (EU) 2024/1772.

1. 01Assess criticality under Article 6

   The service criterion is relevant, in particular, where ICT supporting critical or important functions is affected, financial services requiring authorisation, registration or supervision are affected, or successful malicious unauthorised access to network and information systems occurs. This entry condition is broader than an outage of an application marked as critical.

2. 02Assess Article 9 thresholds

   For each criteria group below, record the measure, source, denominator, assessment time and outcome. Where actual figures are unavailable, document the estimates required under the RTS and their basis. An unknown value is not evidence that a threshold has not been met.

3. 03Apply the Article 8 decision rule

   Where critical services under Article 6 are affected, an incident is major if the specific access condition in Article 9(5)(b) is met, or at least two of the other criteria groups meet their materiality thresholds. That access condition concerns successful malicious unauthorised access which may cause data losses and is not already covered by point (a).

4. 04Assign the decision and escalate

   The designated function records classification, time and reasoning, activates reporting and informs senior management. The management body receives information on impact, response and additional controls. Waiting for a perfect root-cause analysis must not delay the initial notification deadline.

Count each group only once. Two exceeded client thresholds are not two groups. Incident duration and service downtime also form one group. Under Article 8(2), assess recurring incidents with the same apparent root cause monthly for aggregation: at least twice within six months and collectively meeting the major-incident conditions. Apply the specified exceptions for microenterprises and entities under the simplified framework.

Move from classification to initial, intermediate and final reporting

1. 01Notify using the available information

   The reporting function submits the available core information as early as possible. Article 5 of Regulation 2025/301 sets a deadline of four hours after classification and generally no later than 24 hours after awareness. Where classification occurs after those 24 hours, the specific four-hour rule runs from classification. Awareness and classification need separate timestamps.

2. 02Update the intermediate report and recovery status

   Submit an intermediate report no later than 72 hours after the initial notification, even if the incident’s status has not changed. Update without undue delay and, in any event, when regular activities have recovered. The reporting function takes revised impacts and treatment information from the incident response lead.

3. 03Close with root cause and actual impact

   Submit the final report no later than one month after the intermediate report or the latest updated intermediate report. It consolidates root-cause analysis, actual impact and implemented measures. Outstanding improvements continue to have internal owners and deadlines.

For credit institutions, the weekend and bank-holiday extension in Article 5(4) does not apply to initial or intermediate reports. If a submission cannot be made within its applicable deadline, inform the competent authority without undue delay and no later than that deadline, explaining why. Coordinate DORA reporting with any separately required data-protection notification while assessing both obligations independently.

Illustrative sequence only: an outage becomes known at 09:00. The service supports a critical function. At 11:05, evidence shows downtime exceeding two hours and 12% of that service’s clients affected. Two groups are therefore met. If classification occurs at 11:05, initial notification is due as early as possible and no later than 15:05. If submitted at 12:00, the 72-hour intermediate-report clock starts at 12:00. The example assumes major classification was not required earlier.

Legal and professional sources: Delegierte Verordnung (EU) 2024/1772, Artikel 1–9: Klassifizierung und Wesentlichkeit; Delegierte Verordnung (EU) 2025/301, Artikel 5: Meldestufen, Fristen und Ausnahmen; DORA, Artikel 17–19: Vorfallmanagement und Meldung.

Where can I find the DORA full text and the official sources?

The official DORA full text is available on EUR-Lex: Regulation (EU) 2022/2554, ELI, published in the EU Official Journal L 333 of 27 December 2022, available as HTML and PDF. The BaFin DORA overview page bundles the German supervisory and procedural information; the level 2 acts carry their own ELI addresses, for example Delegated Regulation (EU) 2024/1774.

Related topics

• DORA register of information: deadline & template
• MaRisk: current version Circular 06/2026, AT/BT structure and amendments: incl. the AT 9 delineation from DORA.
• All DORA deadlines in the banking regulation roadmap: annual tables 2026 to 2028+ with references.

Frequently asked questions about the DORA Regulation

An offer from T-NEX GmbH

Discuss the project with T-NEX

Define the business and technical scope of a DORA project. Consulting supports that assessment; operations and evidence pages explain the questions to resolve for the actual deployment.