DORA Regulation: A Practical Guide to the Digital Operational Resilience Act for Financial Entities

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has been applicable since 17 January 2025. It harmonises ICT risk management across approximately 22,000 financial entities in the European Union, supplemented by 13 Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) adopted by the European Supervisory Authorities (ESAs). DORA replaces a patchwork of national rules and ESA guidelines with a single binding framework that covers banks, insurers, investment firms, payment institutions, crypto-asset service providers, central counterparties, trading venues, credit rating agencies, and crowdfunding service providers. Critical ICT third-party providers fall under direct supervision by the ESAs.

This article explains the five pillars of DORA, the scope, the reporting framework, the third-party risk regime, and the testing requirements, including Threat-Led Penetration Testing (TLPT). We discuss the relationship between DORA and ISO/IEC 27001:2022, the role of the Information Security Officer (ISB), and the operational consequences for German Finanzdienstleister that already comply with BaFin guidance on bank-supervisory requirements for IT (BAIT, VAIT, ZAIT, KAIT). At the end you will understand which evidence supervisors will request and how the CIVAC platform structures the obligations into a defensible operating model. We also touch on the supervisory enforcement powers of BaFin, Bundesbank, and the ESAs, including fines of up to 1 percent of average daily worldwide turnover for critical third parties.

DORA applies to 20 categories of financial entities listed in Article 2 paragraph 1, ranging from credit institutions and insurers to crypto-asset service providers under MiCA. The scope is broader than most national supervisory regimes and includes entities that previously had no harmonised ICT obligations, such as crowdfunding service providers under Regulation (EU) 2020/1503 and account information service providers. National competent authorities (in Germany BaFin and Bundesbank) supervise compliance, while the ESAs handle the oversight of critical ICT third-party providers under Articles 31 to 44.

Proportionality is built into the regulation. Article 4 establishes that requirements shall be applied proportionately to the size, business profile, nature, scale, and complexity of services. Micro-enterprises (Article 16) benefit from a simplified ICT risk management framework. Small and non-interconnected investment firms, payment institutions exempted under Article 32 PSD2, and certain insurance intermediaries are excluded. Branches of third-country firms are included when they conduct activities subject to EU financial regulation.

For German entities already subject to BAIT, VAIT, ZAIT, or KAIT, DORA largely replaces and harmonises those frameworks. BaFin has confirmed in its consultation responses that DORA takes precedence and that the national circulars will be revised. Entities should map their existing controls against the DORA articles and the 13 RTS or ITS adopted in 2024. A formal gap analysis is the prerequisite for any remediation plan and is regularly requested during BaFin inspections. The CIVAC platform structures this mapping with 93 controls aligned to ISO/IEC 27001:2022 and the DORA articles, enabling a single source of truth for evidence and audit trails.

The first pillar requires every financial entity to establish a sound, comprehensive, and well-documented ICT risk management framework. Article 5 places direct responsibility on the management body: the board must approve the framework, oversee its implementation, and remain accountable for ICT risk. This is a substantive shift from prior practice, where ICT risk was often delegated to CIO or CISO without formal board engagement. Management body members must dedicate sufficient time to ICT matters and maintain knowledge through training.

The framework must include strategies, policies, procedures, ICT protocols, and tools necessary to protect all information and ICT assets. Article 8 requires identification and classification of ICT assets and dependencies, including those of third parties. Article 9 mandates protection and prevention measures aligned with the assessed risk. Article 10 requires detection mechanisms for anomalous activities and ICT-related incidents. Article 11 governs response and recovery, including ICT business continuity policy and a tested ICT Business Continuity Plan.

Article 12 addresses backup policies and restoration procedures, with the requirement to test recovery capabilities at least annually. Articles 13 and 14 cover learning and evolving, including the duty to monitor technological developments and to disseminate awareness across the entity. Article 16 provides the simplified framework for micro-enterprises and certain small entities. The CIVAC workspace operationalises this pillar with 490 ready-to-use audit templates, including ICT risk register, asset inventory, business impact analysis, and continuity test report. Other firms run compliance like a filing cabinet. We run it like software: signed, filed, defensible.

The second pillar harmonises incident reporting across financial entities. Article 17 requires entities to establish an ICT-related incident management process that detects, manages, and notifies ICT-related incidents and significant cyber threats. Article 18 mandates classification of incidents and cyber threats using criteria specified in the RTS on classification (Commission Delegated Regulation (EU) 2024/1772), including the number of clients and financial counterparts affected, the duration and service downtime, geographical spread, data losses, criticality of services, and economic impact.

Article 19 governs the reporting of major ICT-related incidents to the competent authority. The reporting cadence is structured into three stages: an initial notification within four hours of classification as major and no later than 24 hours from detection; an intermediate report within 72 hours; and a final report within one month. The RTS on reporting (Commission Implementing Regulation (EU) 2024/2956) specifies the templates and content. Significant cyber threats may also be reported voluntarily.

For German entities, BaFin acts as the competent authority and operates the reporting portal. Banks must additionally consider BAIT-derived obligations and, where applicable, the EZB SSM. The CIVAC workspace tracks classification, deadlines, and report submissions, with an automated escalation when the four-hour window approaches. The deadline runs from the moment of classification: classify late, miss the four-hour window. The auditor calls, the evidence is ready. Cross-references to the NIS-2 24/72 reporting path ensure consistency for entities subject to both regimes. The classification is documented with timestamp, decision rationale, and the natural person who made the determination, which is essential when supervisors later assess whether the four-hour clock started on time.

The third pillar requires a programme of digital operational resilience testing proportionate to the entity. Article 24 establishes the general testing requirement: appropriate tests on ICT tools and systems, including vulnerability assessments, scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

Article 26 introduces the requirement for Threat-Led Penetration Testing (TLPT) for entities identified by the competent authority based on size, risk profile, and systemic importance. TLPT must be conducted at least every three years on critical functions and live production systems, follow the TIBER-EU methodology or an equivalent national framework, and involve external testers certified under the RTS on TLPT. The scope and methodology must be approved by the competent authority before the test starts. Findings, remediation plans, and attestations are submitted to the authority.

Article 25 prescribes how tests are conducted and how findings are addressed: documented methodology, risk-based prioritisation of remediation, and integration into the ICT risk management framework. The CIVAC workspace manages the test cycle from scoping to attestation, with templates for the test plan, test report, and remediation tracking. Findings are linked to ICT assets and controls, enabling year-on-year trend analysis. Annual ICT continuity testing under Article 11 paragraph 6 is also tracked, with documented scenarios and lessons learned. License the workspace for your internal officers, or let our officers serve as your appointed ISB through our Officer-as-a-Service model.

The fourth pillar is the most far-reaching innovation of DORA. Articles 28 to 30 govern the entity-level management of ICT third-party risk. Financial entities must maintain a register of contractual arrangements, perform pre-contractual due diligence, ensure that contracts include mandatory clauses (Article 30), and monitor the performance of third parties on an ongoing basis. Contracts supporting critical or important functions must include enhanced provisions on subcontracting, audit rights, exit strategies, performance targets, and incident notification.

Articles 31 to 44 establish the direct oversight of critical ICT third-party providers (CTPPs) by the ESAs. The Commission designates CTPPs based on criteria in Article 31, including systemic impact, criticality of services, substitutability, and the number of financial entities relying on the provider. Designated CTPPs are assigned a Lead Overseer (EBA, EIOPA, or ESMA) and become subject to the Joint Oversight Network. The Lead Overseer can request information, conduct on-site and off-site investigations, issue recommendations, and impose periodic penalty payments of up to 1 percent of average daily worldwide turnover.

For German financial entities, the practical consequence is an immediate review of all third-party arrangements. The pre-DORA outsourcing register under BAIT MaRisk AT 9 needs to be enriched with DORA-specific data fields: criticality classification, EU contractual clauses, exit strategy, concentration risk, and subcontracting depth. The CIVAC platform mirrors the ESA reporting template and maintains the register in a format that can be submitted to BaFin without rework. The Information Security Officer typically owns this register, with input from procurement and legal.

The fifth pillar enables financial entities to exchange among themselves cyber threat information and intelligence, including indicators of compromise, tactics, techniques and procedures, cybersecurity alerts, and configuration tools. The exchange must take place within trusted communities of financial entities, through arrangements that protect the potentially sensitive nature of the information shared and that comply with applicable law, in particular Regulation (EU) 2016/679 (GDPR) and competition law.

Participation in such sharing is voluntary. Entities that engage in information sharing must notify their competent authority, both at the start and at termination. The notification ensures that supervisors maintain visibility over the sharing ecosystem without controlling it. The ESAs and ENISA may issue guidance and provide platforms for structured sharing, including the EU Cyber Crisis Liaison Organisation Network (EU-CyCLONe) for crisis coordination.

For German entities, the established Financial Sector Cyber Information Sharing initiatives, BSI CERT-Bund channels, and the BaFin BSI joint reporting arrangements remain relevant. DORA codifies and extends these practices. CIVAC supports the information sharing workflow with documented data classification, redaction templates, and a privacy review checklist. Subscribers to threat intelligence feeds can map indicators of compromise to their own asset inventory, supporting both detection (Pillar 1) and resilience testing (Pillar 3). The dual-model approach applies here as well: license the workspace for your internal officers, or let our officers be appointed as your designated contact. The information sharing dossier is documented, dated, defensible. Participation in trusted communities such as the Financial Services Information Sharing and Analysis Center (FS-ISAC) is increasingly expected, especially for larger entities and those with cross-border footprints.

Many financial entities are already certified to ISO/IEC 27001:2022 or operate an Information Security Management System aligned to the standard. The overlap with DORA is substantial: ISO/IEC 27001:2022 covers leadership engagement (clause 5), risk assessment (clause 6.1), competence (clause 7.2), operational planning (clause 8), and continual improvement (clause 10), all of which mirror DORA Pillar 1. The 93 Annex A controls of ISO/IEC 27001:2022 directly support DORA Articles 9 to 14.

However, ISO/IEC 27001:2022 does not impose the four-hour reporting window of DORA Article 19, the third-party register requirements of Article 28, or the TLPT obligations of Article 26. Entities that rely solely on their ISO certificate without a DORA mapping risk material gaps. The recommended approach is a layered control framework: ISO 27001 as the foundation, DORA-specific extensions for incident reporting, third-party register, and TLPT.

The CIVAC workspace maps 93 ISO/IEC 27001:2022 controls to the corresponding DORA articles and RTS, with evidence repositories that satisfy both auditors and supervisors. The annual surveillance audit under ISO 27001 can be combined with a DORA self-assessment, reducing redundancy. The October 2026 transition deadline for ISO/IEC 27001:2022 is the practical occasion to align both regimes. Other firms run compliance like a filing cabinet. We run it like software: a single workspace, two regulatory views, one defensible evidence base. Internal auditors and external assessors share a common evidence repository, eliminating duplicate document requests and reducing the friction during the surveillance audit cycle. The mapping is updated whenever ESAs publish new RTS or amend existing ones.

DORA itself does not harmonise administrative fines for financial entities. Article 50 leaves it to Member States to provide for effective, proportionate, and dissuasive penalties. In Germany, the BaFin gains supervisory powers under the implementing legislation (DORA-Begleitgesetz), with fines tied to the existing sectoral frameworks (KWG, VAG, WpHG, ZAG). Penalties range from low six-figure to seven-figure amounts depending on entity size and gravity. Personal liability of management body members under Section 25c paragraph 4 KWG and equivalent provisions remains relevant.

For critical ICT third-party providers, the ESA Lead Overseer can impose periodic penalty payments of up to 1 percent of average daily worldwide turnover (Article 35 paragraph 6), continued daily until compliance is achieved, for up to six months. This is a substantial tool that creates strong incentives for hyperscale cloud providers and major financial market infrastructure vendors to engage constructively with the oversight framework. Recommendations issued by the Lead Overseer must be addressed, even if not legally binding in the same sense as a decision.

Inspections by BaFin under DORA are typically risk-based and triggered by either supervisory priorities (cybersecurity, outsourcing) or specific events (major incidents, third-party failures, complaints). The inspection scope covers documentation, governance, technical controls, and interviews with key staff. The auditor calls, the evidence is ready. CIVAC structures the evidence in inspection-ready dossiers, with version control, change history, and a single export for the supervisory team. Preparation time before an inspection is reduced from weeks to days. The deadline runs from the moment of inspection notice, typically 14 days for the first document submission.

DORA is a structural regulation: it does not prescribe technologies, it prescribes outcomes and evidence. Entities that approach DORA as a checklist exercise miss the point. The regulation rewards entities that operate a coherent ICT risk management framework, integrate third-party risk into procurement, test resilience honestly, and report incidents with discipline. CIVAC is a compliance platform and Officer-as-a-Service that operationalises exactly these outcomes, with EU data residency for all client information and a workspace mapped to all 13 RTS and ITS adopted by the ESAs.

License the workspace for your internal officers, or let our officers be appointed as your designated ISB. The workspace covers the ICT asset inventory, the third-party register, the incident classification engine with the four-hour timer, the TLPT scoping templates, and the information sharing dossier. The official appointment certificate is issued within two working days, compared to the industry-standard two to six weeks. 25 officer roles are available, all live, including the Information Security Officer (ISB) most relevant for DORA-regulated entities. The deadline runs from the moment of awareness.

If you are unsure whether your firm meets the DORA threshold for TLPT, whether your third-party register is complete, or whether your incident management process can sustain the four-hour window, we conduct a focused gap analysis in the first meeting. From reading to action: write to info@civac.de or use the contact form on civac.de. We respond within one working day with a concrete assessment of your DORA posture, including a remediation roadmap and an estimate of annual operating costs. The first conversation is binding and at no cost risk to you.