DORA Regulation: What the Digital Operational Resilience Act requires of financial companies as of January 17, 2025

Regulation (EU) 2022/2554 on the operational stability of digital systems in the financial sector (Digital Operational Resilience Act, DORA) has been directly applicable in all member states since January 17, 2025. It addresses banks, investment firms, insurers, payment and e-money institutions, crypto service providers, management companies, trading venues, central counterparties and their third-party ICT service providers. Those subject to the scope of application must demonstrate five sets of obligations: ICT risk management, serious incident reporting, regular resilience testing, third-party management and information exchange.

This article organises DORA from the officer's perspective. Where in the company are decisions made operationally, where documented, where checked. We show which interfaces exist with ISO/IEC 27001:2022, BAIT and KAIT, when an incident is reported to the national supervisory authority and how critical ICT third-party service providers fall under the direct supervision of the European Supervisory Authorities (ESAs). The conclusion is a 90-day timetable that brings the obligations into effect.

Art. 2 DORA lists 20 categories of financial companies, from credit institutions to insurance intermediaries to crypto asset service providers, crowdfunding providers and central securities depository. Third-party ICT service providers also come into play as soon as they provide ICT services for a covered financial company. The regulation is therefore noticeably broader than the previous regulations BAIT, VAIT, KAIT and ZAIT, but national supervisory practice remains applicable to the extent that DORA leaves room.

For small and non-interconnected investment firms, micro-insurers and similar actors, Article 16 DORA provides for a simplified ICT risk management regime. However, the full obligation for incident reporting and third-party management remains. National implementation in Germany takes place through the Financial Market Digitization Act (FinmadiG), which adapts the KWG, VAG, WpHG and ZAG and anchors supervision at BaFin and the Deutsche Bundesbank. Anyone who works as an information security officer in a financial company takes on central tasks in DORA implementation, from risk inventory to reporting to the board.

ICT risk management according to Art. 6 ff. DORA requires a documented, regularly reviewed framework. It includes strategy, policies, procedures, protocols, tools and human resources. The management body is responsible and must have express approval, regular reviews and training obligations (Article 5 DORA). Operational layers are the identification of critical functions and information assets, the detection of anomalies, the response with containment and eradication, the recovery and learning from incidents.

The interface to ISO/IEC 27001:2022 is tight. 93 controls in Appendix A of the standard cover parts of Articles 8 to 15 DORA, but do not replace them. DORA requires specifics, such as backup locations, alternative processing facilities, restart times for each critical function and the separation of productive and backup data. The technical regulatory standards package (RTS, EBA/EIOPA/ESMA mandates) published jointly with ESAs further specifies the requirements. Anyone who already has an ISMS in accordance with ISO 27001:2022 can add DORA as an additional requirement bracket to the existing portfolio instead of building parallel structures. The obligation to report to the management body is at least annually, and in the event of significant changes on an event-related basis.

Art. 17 DORA requires an incident management process with classification, escalation, root cause analysis and lessons learned. Article 18 DORA sets out the classification criteria, including number of affected customers, data loss, duration of impairment, geographical spread, economic impact and reputational effects. The associated Delegated Regulation (EU) 2024/1772 defines the threshold values ​​for “serious” incidents and “significant” cyber threats.

According to Art. 19 DORA, serious ICT incidents must be reported in three stages: initial report within four hours of being classified as serious, but no later than 24 hours after becoming known; Interim report within 72 hours; Final report within one month. The initial report contains contact details, a description of the incident and affected functions. The interim report quantifies the effects, the final report classifies causes and measures. Deadline begins as soon as we become aware of it. The report is made to the national supervisory authority, and in Germany regularly to BaFin. At the same time, if personal data is affected, there is also an obligation to report within 72 hours in accordance with Article 33 of the GDPR. A double but independent reporting chain is standard. The NIS 2 reporting deadlines are similar in structure, but are legally separate.

Art. 24 to 27 DORA require a test program. The basic catalogue includes vulnerability assessments, open source analysis, network security and penetration testing, source code reviews and scenario-based testing. Frequency and depth depend on the risk profile, at least annually for critical ICT systems. The tests must be carried out independently, and the reports are sent to the management body and the supervisory authority upon request.

For significant institutions, Threat-Led Penetration Tests (TLPT) in accordance with Article 26 f. DORA are added at least every three years. The TLPT methodology closely follows the ECB's TIBER-EU framework: Threat Intelligence, Red Team, Closed Loop Reporting. Which institutions are subject to TLPT results from quantitative and qualitative criteria that the EBA has defined in coordination with the other ESAs (RTS under Art. 26 Para. 11). The tests address real production systems including selected third-party ICT service providers; Requirements for confidentiality, preparation and escalation plans are correspondingly high. The national TLPT authority in Germany is the Bundesbank together with BaFin. Tests that are successfully completed under the TIBER-DE framework can be credited towards DORA obligations, provided the methodology and reporting status meet RTS requirements. The auditor calls, the evidence is ready.

Art. 28 to 30 DORA structure the contractual relationships with third-party ICT service providers. An information register of all contracts with third-party service providers is mandatory, which must be submitted to the supervisory authority annually (Art. 28 Para. 3). Contracts must contain minimum clauses: description of functions, locations of data processing, availability and security levels, cooperation with supervisory authorities, audit rights, exit and transition plans, reporting obligations in the event of incidents.

Before conclusion of the contract, Art. 28 DORA requires a risk assessment and an examination of whether the function is critical or essential. Subcontractor chains must be transparent and contractually permitted in advance, with the financial company's right of consent (Art. 30 para. 2 letter a). Concentration risks must be actively managed; An accumulation of critical functions at a single provider, a region or a platform must be documented with justification. For ICT third-party service providers that are classified as critical, the supervisory regime of Article 31 ff. DORA applies: One of the ESAs assumes direct supervision, can make recommendations, order audits and impose penalty payments. The list of critical service providers is updated annually. The person responsible for the ISMS who manages the suppliers interlinks the register, risk analyses and contract controlling in one inventory so that supervision and internal auditing see a single source.

DORA overrides national supervisory practices where the regulation regulates them. BAIT, VAIT, KAIT and ZAIT remain relevant as supplementary supervisory communications provided they do not conflict with DORA. The interface to the GDPR remains strict: Art. 33 GDPR requires an independent report of violations of the protection of personal data within 72 hours of becoming aware of it. The DORA report to BaFin does not replace it. The external data protection officer remains responsible for the data protection assessment; the ICT security function remains responsible for DORA.

The relationship with the NIS-2 Directive is legally unbundled: Art. 1 Para. 2 NIS-2 classifies financial companies as “lex specialis” as soon as DORA applies. NIS-2 therefore does not have any independent cyber obligation effect for banks, insurers and investment firms; it only remains relevant where group companies operate outside the financial sector. To the extent that AI systems become relevant in the financial sector, the EU AI Act layers are also linked to DORA, for example in the risk classification of internal algorithms. In everyday operations, this means a consolidated reporting map: DORA to BaFin, GDPR to state data protection, NIS-2 to BSI for non-financial parts, AI Act according to the responsible authority.

Art. 50 DORA requires Member States to provide for “effective, proportionate and dissuasive” sanctions. Germany implements this in the technical laws. The KWG, VAG, WpHG and ZAG have updated the fines in the KWG, VAG, WpHG and ZAG since the FinmadiG came into force, allowing fines of up to seven figures and a percentage of the annual turnover, depending on the sector. In addition, there are supervisory orders, management prohibitions and publication obligations.

Critical ICT third-party service providers can be subject to penalty payments according to Art. 35 DORA, which can amount to 1 percent of the average global daily turnover, per day of the violation, for a maximum of six months. This sanction specifically targets cloud providers, data centre operators and similar heavyweights. From a regulatory perspective, the lead overseer function of the EBA, EIOPA or ESMA drives the process, coordinated with the national authorities. In practice, the actual level of sanctions depends heavily on the classification of the violation, the duration and the level of cooperation. Experience from GDPR proceedings suggests that the first fines can be expected from 2026 in high-profile areas, for example if reporting requirements or third-party registers are demonstrably inadequate. Audit-proof, documented, § ...-proof.

Day 1 to 14: Applicability analysis. Clarify which group companies fall under Article 2 DORA, which special regulations apply (Article 16 simplified regime) and which ICT service providers are relevant. Take an initial inventory of critical functions and associated ICT assets.

Day 15 to 45: Risk management framework. Bring the governance requirements into the board's rules of procedure and into the reporting line of the information security officer. Supplement the existing ISMS with the DORA-specific elements: restart times per function, detection tools, backup concept, alternative processing facilities, RTS-compliant classification. Day 46 to 75: Third Parties. Record all ICT contracts in the register, check them against Art. 30 DORA, make addenda if clauses are missing, and clarify subcontractor chains. Day 76 to 90: Tests and Incidents. Define classification and reporting paths according to Articles 17 to 19 DORA with clear deadlines (four, 24, 72 hours, one month). Plan the 2026 testing program, including TLPT requirements. CIVAC accompanies this roadmap in the workspace, with audit templates for the register, the classification matrix and the three-stage reporting path, and supports the reporting line to the management body.

CIVAC is a compliance platform and officer-as-a-service. Licence the workspace for your internal representatives so that ICT risk inventory, incident classification, third-party registers and reporting paths run in a traceable inventory. Or have our representatives order, with an appointment certificate, signed, filed and verifiable. The ISO 27001:2022 basis, the 93 controls and 490 audit templates as well as the EU data residency form the technical foundation on which DORA is based.

Anyone who is relevant to DORA knows the reporting paths to BaFin and the Bundesbank. The actual effort arises in day-to-day business: assigning each asset to a responsible person, assigning each contract to a clause, assigning each incident to a deadline. CIVAC maintains this assignment in the workspace, with reminders, audit traces and escalation paths. If you want to know which steps your house should specifically cover in the first 30 days, write to info@civac.de or use the contact form on civac.de. Turn reading into an assignment.