DORA Is Here: What Financial Entities in the DACH Region Must Do Now

The Digital Operational Resilience Act became applicable on January 17, 2025, and it represents the most significant overhaul of ICT risk management regulation for the European financial sector in a generation. For financial entities in Germany and Austria, the compliance deadline has passed, and supervisory scrutiny is now intensifying; Swiss firms with EU business and the ICT third-party service providers that financial entities depend on are affected indirectly.

The Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA) establishes a uniform set of requirements for the security of network and information systems supporting business processes of financial entities. For the first time, the EU has articulated a single, directly applicable framework for ICT risk management, incident reporting, operational resilience testing, third-party risk management, and information sharing across the whole of the regulated financial sector. DORA replaces a fragmented landscape of sector-specific and national rules with a consolidated regulation and a set of European-level technical standards that apply uniformly across member states.

This article provides a comprehensive walkthrough of DORA for financial entities in the DACH region: its scope and objectives, the five substantive pillars, the Level 2 measures published by the European Supervisory Authorities, the specific implications for Germany, Austria, and Switzerland, the relationship with existing frameworks such as BAIT, and the practical compliance roadmap that entities should now be executing. The objective is to equip boards, compliance functions, and senior leadership with the understanding they need to assess their current state against DORA’s expectations and to plan the remediation activities that supervisory engagement will increasingly demand.

DORA in Context: Why It Was Adopted

The rationale for DORA rests on a simple observation: the European financial sector has become critically dependent on information and communication technology, and yet the regulatory framework for ICT risk management was fragmented, inconsistent, and increasingly inadequate to the nature of the threats the sector faces. Individual supervisors had articulated sector-specific expectations — BAIT in Germany for banks, equivalent circulars for insurers and capital management companies — but these expectations varied across jurisdictions, across sectors, and in their depth of coverage. The result was a patchwork that left material gaps and imposed inconsistent burdens on cross-border institutions.

DORA's response is to harmonise. By establishing a single regulation that applies directly in all member states, DORA creates a common baseline for ICT risk management, incident reporting, testing, third-party oversight, and information sharing. The regulation is supplemented by regulatory technical standards (RTS) and implementing technical standards (ITS) developed by the European Supervisory Authorities, which provide the operational detail that entities need to design their compliance programmes.

Who Is in Scope?

DORA applies to a broad range of financial entities defined by reference to their existing authorisation categories under EU financial services legislation. The in-scope entities include the following:

• Credit institutions authorised under the Capital Requirements Directive.
• Payment institutions authorised under PSD2 (including account information service providers).
• Electronic money institutions authorised under EMD2.
• Investment firms authorised under MiFID II.
• Crypto-asset service providers (CASPs) authorised under MiCA.
• Insurance and reinsurance undertakings authorised under Solvency II, together with insurance intermediaries.
• Institutions for occupational retirement provision (IORPs).
• Central counterparties (CCPs), central securities depositories (CSDs), trading venues, and trade repositories.
• Managers of alternative investment funds (AIFMs) and UCITS management companies.
• Credit rating agencies, administrators of benchmarks, crowdfunding service providers, and several other categories of specialised financial entities.

The scope is deliberately broad, reflecting the regulation’s ambition to cover the entire European financial sector. For a closed list of small entity types, a simplified ICT risk management framework under Article 16 of DORA applies in place of Articles 5 to 15: small and non-interconnected investment firms, payment and electronic money institutions exempted under EU payment services and e-money law, institutions exempted under the Capital Requirements Directive, and small institutions for occupational retirement provision. The duty to report major incidents continues to apply to them. All other entities can rely only on the general proportionality principle in Article 4.

Crucially, DORA also establishes an oversight framework for ICT third-party service providers that are designated as critical ICT third-party providers (CTPPs) by the European Supervisory Authorities. Once designated, a CTPP becomes subject to direct oversight by the ESAs, including the possibility of on-site inspections, recommendations and, where the provider refuses information or inspections, periodic penalty payments. This extension of supervisory reach to non-financial ICT providers is one of DORA’s most novel features.

Pillar One: ICT Risk Management (Articles 5–16)

The first pillar of DORA establishes the foundational expectations for ICT risk management. Articles 5 through 16 require financial entities to establish and maintain a sound, comprehensive, and well-documented ICT risk management framework that enables them to identify, protect, detect, respond to, and recover from ICT risks in a coordinated manner.

The governance dimension of this pillar is central. DORA explicitly places responsibility for ICT risk with the management body of the financial entity. The management body must approve the ICT strategy, the ICT risk management framework, the business continuity policy, and the information security policy. It must allocate adequate budget to ICT risk management, ensure appropriate staffing, and maintain active oversight. Board members are expected to possess sufficient knowledge and skills to understand ICT risks, and the regulation imposes training expectations on members of the management body.

Substantively, the ICT risk management framework must include the following elements: an ICT strategy aligned with the entity’s overall business strategy; a mapping of all ICT-supported business functions and their dependencies on specific systems and processes; a business impact analysis identifying which functions are critical and what the recovery objectives should be for each; protection measures covering information security, access controls, encryption, and network security; detection measures capable of identifying anomalous activity; response and recovery procedures including backup, business continuity, and disaster recovery arrangements; and a learning process through which incidents and near-misses inform the evolution of the framework.

For German institutions that used to be subject to BaFin's BAIT circular (Circular 10/2017, most recently in the version of 16 December 2024), DORA takes its place and is more specific in several areas: ICT asset management expectations are more granular, encryption requirements are more prescriptive, and network segmentation obligations are more explicit. BaFin repealed the sector-specific circulars KAIT, VAIT, and ZAIT with effect from the end of 16 January 2025 in order to avoid double regulation. Since DORA became applicable, BAIT has applied only to institutions that do not have to run ICT risk management under DORA; it will be repealed in full at the end of 31 December 2026.

Pillar Two: ICT-Related Incident Reporting (Articles 17–23)

The second pillar introduces a harmonised framework for the classification and reporting of ICT-related incidents. Under DORA, financial entities must classify ICT-related incidents against criteria defined in the regulatory technical standards published by the European Supervisory Authorities. Incidents that meet the thresholds for classification as major must be reported to the competent authority — BaFin in Germany, the FMA in Austria — using standardised templates. Voluntary reporting of significant cyber threats is also supported by the regulation.

The time limits set out in Delegated Regulation (EU) 2025/301 are demanding. The initial notification must be made within 4 hours from the moment the entity classifies the incident as major, and in any event no later than 24 hours from the moment it became aware of the incident. An intermediate report must follow within 72 hours of the initial notification and must be updated, at the latest once regular activities have been recovered. The final report is due no later than one month after the intermediate report or, where there was one, after the latest updated intermediate report.

Meeting these timelines in practice requires operational readiness that many institutions have historically lacked. Incident detection must be fast enough to enable classification within hours. Internal governance must be structured to allow the classification decision to be taken quickly, with clear delegation of authority. Reporting templates must be pre-populated and reviewable within the available window. External communications to customers, counterparties, and the public must be coordinated with the regulatory notification.

In addition, financial entities may notify significant cyber threats to the competent authority on a voluntary basis (Article 19(2) DORA); only major ICT-related incidents must be reported. The regulation thereby supports a broader ecosystem of information sharing aimed at improving sector-wide resilience.

Pillar Three: Digital Operational Resilience Testing (Articles 24–27)

The third pillar requires financial entities to test the resilience of their ICT systems on a regular basis. The testing regime is stratified by size and importance: all in-scope entities must conduct a baseline level of testing, while entities identified as significant must additionally conduct advanced threat-led penetration testing (TLPT).

The baseline testing obligation requires entities to conduct a comprehensive testing programme covering their critical ICT systems and applications. This includes vulnerability assessments, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. The programme must be implemented on a risk-based basis, with the depth and frequency of testing calibrated to the criticality of the systems involved.

For significant entities, DORA introduces mandatory threat-led penetration testing. TLPT is an advanced form of testing in which a red team, equipped with bespoke threat intelligence, attempts to compromise the entity’s critical functions in a realistic simulation of an attacker’s behaviour. The methodology is closely aligned with the TIBER-EU framework developed by the European Central Bank and national central banks, which was published in May 2018 and which has been implemented nationally in Germany as TIBER-DE by the Deutsche Bundesbank.

TLPT under DORA must be conducted at least every three years for entities subject to the requirement. It must cover the entity’s critical functions, be performed by qualified and independent testers, follow a structured methodology covering threat intelligence, red-teaming, and a closure phase, and conclude with a remediation plan for any weaknesses identified. The cost and operational impact of a full TLPT exercise are substantial, and entities subject to the requirement should plan their testing cycles carefully to manage both the cost and the disruption to normal operations.

Pillar Four: ICT Third-Party Risk Management (Articles 28–44)

The fourth pillar has generated the most operational complexity for financial entities, and it is where many institutions are still working through the implementation. Articles 28 through 44 of DORA establish a comprehensive framework for managing the risks associated with reliance on ICT third-party service providers, including cloud service providers, managed service providers, software vendors, and data hosting providers.

The foundational obligation is the register of information (RoI), which each in-scope financial entity must maintain and submit to its competent authority. The register must contain detailed information about all ICT third-party service arrangements, including the nature of the services, the counterparty identity, the geographic location of service provision and data storage, the identification of any sub-outsourcing, and the classification of the arrangement as supporting a critical or important function. The information required for the RoI is specified in the implementing technical standards published by the ESAs.

DORA also establishes mandatory contractual provisions for ICT third-party arrangements. Article 30 sets out the minimum contractual clauses that must be included in agreements with ICT providers, covering areas such as service descriptions, service levels, data protection, location of data processing, audit rights, incident notification, business continuity arrangements, termination rights, assistance with supervisory inquiries, and cooperation with supervisory authorities. For arrangements supporting critical or important functions, additional requirements apply, including exit strategy provisions and enhanced audit rights.

The practical challenge has been renegotiating existing contracts to meet these requirements. Many financial entities rely heavily on standardised terms from major cloud service providers, and the negotiating leverage of individual financial entities over these providers is limited. The hyperscale cloud providers have responded by developing DORA-specific contractual amendments, but the process of rolling these out across the estate of existing contracts has absorbed significant resources across the sector.

The designation of critical ICT third-party providers (CTPPs) by the European Supervisory Authorities introduces a new layer of direct supervisory oversight. Once designated as critical, an ICT third-party provider becomes subject to oversight by a Lead Overseer from among the ESAs, which can request information, conduct investigations and inspections, and issue recommendations; it can enforce its information requests and inspections with periodic penalty payments. This is a genuinely novel extension of supervisory reach into non-financial entities and marks a significant development in EU regulatory policy.

Pillar Five: Information Sharing (Article 45)

The fifth pillar of DORA encourages — but does not mandate — the sharing of cyber threat intelligence among financial entities. Article 45 establishes a legal basis for voluntary information-sharing arrangements between financial entities, allowing them to exchange indicators of compromise, tactics techniques and procedures (TTPs), cyber security alerts, and configuration tools. Such sharing must comply with data protection requirements and must not disclose commercially sensitive information.

In practice, this pillar has been welcomed by the industry, which has long recognised the value of collective intelligence in defending against increasingly sophisticated cyber threats. Financial sector information sharing and analysis centres (ISACs), trusted communities, and sector-specific threat intelligence platforms provide the operational vehicles through which Article 45 arrangements are implemented. The pillar does not in itself create new compliance burdens; rather, it removes legal uncertainty that previously discouraged some firms from participating in information-sharing arrangements.

The Level 2 Measures: RTS and ITS

DORA establishes the high-level framework, but much of the operational detail is contained in Level 2 measures — regulatory technical standards (RTS) and implementing technical standards (ITS) developed by the European Supervisory Authorities (EBA, ESMA, EIOPA, collectively the ESAs) and adopted by the European Commission. These technical standards cover areas such as the criteria for classifying incidents as major, the content and format of incident reports, the content of the register of information, the methodology for threat-led penetration testing, the criteria for designating critical ICT third-party providers, and the detailed content of ICT risk management frameworks.

The ESAs delivered the technical standards in two batches. The first batch, of January 2024, covered ICT risk management, the criteria for classifying incidents, the policy on ICT services supporting critical or important functions, and the register of information. The second batch, of July 2024, covered the content, format and time limits of incident reports (now Delegated Regulation (EU) 2025/301), threat-led penetration testing, and the oversight of critical ICT third-party providers. Financial entities should ensure that their compliance programmes reference the most current adopted versions of these standards, and compliance functions should maintain awareness of the ongoing work of the ESAs in this area.

Proportionality: How DORA Scales

One of the policy challenges in drafting DORA was calibrating the regulation to apply proportionately across a sector that ranges from the largest globally systemic institutions to small investment firms and crowdfunding platforms. DORA addresses this through the general proportionality principle in Article 4 and through Article 16, which establishes a simplified regime for certain small entity types.

The simplified regime replaces Articles 5 to 15 with a leaner ICT risk management framework; it is open only to the entity types named in Article 16, not to every small institution. Entities subject to the simplified regime still must implement an ICT risk management framework, report major incidents, and maintain the register of information, but the level of detail expected is calibrated to their scale. How strictly the simplified framework is examined in practice is an area where national supervisory practice will shape the burden over time.

Beyond Article 16, proportionality is woven through the regulation's operational provisions. The frequency and depth of testing, the granularity of risk assessments, the sophistication of incident response arrangements, and the formality of governance structures can all be calibrated to the size and complexity of the entity. This proportionality is a genuine feature of the regulation, not a loophole, and entities should engage with it substantively rather than assuming that full adoption of the most demanding expectations is always required.

Relationship with Existing Frameworks: BAIT and NIS2

For German financial entities, DORA has largely replaced BaFin's IT circulars. KAIT, VAIT, and ZAIT were repealed with effect from the end of 16 January 2025. All institutions that have to run ICT risk management under DORA are excluded from the scope of BAIT; BAIT continues to apply only on a transitional basis to institutions outside DORA and will be repealed in full at the end of 31 December 2026. The practical consequence is that institutions within the scope of DORA do not have to satisfy two frameworks at once; DORA and its technical standards are what counts.

DORA also interacts with the NIS2 Directive (Directive (EU) 2022/2555), which establishes cybersecurity requirements for a broader range of sectors beyond financial services. For financial entities within the scope of DORA, the NIS2 provisions on risk management, reporting obligations and supervision do not apply (Article 4 NIS2); DORA takes their place. Entities that are part of broader corporate groups including non-financial activities may nevertheless need to manage both regimes across their group. The interaction is mediated through the concept of lex specialis, under which the more specific financial sector regulation (DORA) takes precedence for financial entities over the general cybersecurity directive (NIS2).

DORA in Germany: BaFin's Approach

BaFin has approached DORA implementation as a consolidation and intensification of its existing supervisory focus on ICT risk management. German institutions that had already invested heavily in BAIT compliance found that DORA extended rather than displaced their existing arrangements, though the new requirements around incident reporting timelines, third-party risk management, and testing have required genuine incremental effort.

BaFin's supervisory engagement with DORA has emphasised the importance of genuine operational capability rather than documentary compliance. Institutions are expected to be able to demonstrate that their incident response procedures work in practice, that their third-party arrangements are actively managed, and that their testing programmes are substantive. Thematic supervisory reviews, on-site examinations, and targeted information requests have all been deployed by BaFin as tools for assessing DORA readiness across the German financial sector.

For newly licensed institutions, showing how the DORA requirements will be met has become a regular part of BaFin's review of the licence application. Payment institutions, e-money institutions, and investment firms filing applications today must set out in the application file how they will comply with DORA, and BaFin examines these submissions in substance. Founders who assume that DORA compliance can be caught up on after authorisation face follow-up requests that prolong the procedure and can delay the grant of the licence.

DORA in Austria: FMA Engagement

The Austrian FMA has published guidance on its expectations for DORA implementation and has integrated DORA supervision into its ongoing engagement with supervised entities. Austrian institutions benefit from the general accessibility of the FMA and the authority's willingness to engage substantively on interpretive questions. The FMA's supervisory approach to DORA mirrors its broader philosophy: rigorous application of EU standards combined with practical dialogue on implementation questions.

For smaller Austrian institutions, the proportionality principle in Article 4 of DORA is particularly important; the simplified regime of Article 16 is open only to the entity types named there. The FMA has signalled willingness to work with entities on the practical calibration of compliance programmes to their size and risk profile, though this does not reduce the core expectations around incident reporting, governance, and third-party risk management.

The interplay between DORA and existing FMA expectations on IT governance and outsourcing also deserves attention. Austrian institutions that already complied with the FMA's circulars and guidance in these areas find that DORA extends rather than replaces their existing arrangements, although the new requirements on reporting time limits and third-party contracts have required genuine incremental effort. Compliance functions should carry out a gap analysis between their current state and the DORA expectations and turn the results into a prioritised implementation programme.

DORA and Switzerland: Indirect Exposure

Switzerland presents a distinctive case. As a non-EU and non-EEA jurisdiction, DORA does not directly apply to Swiss financial institutions. However, Swiss firms that serve EU clients through branches or subsidiaries, Swiss firms whose ICT providers are also providing services to EU financial entities, and Swiss firms participating in EU financial market infrastructures all face indirect compliance exposure.

FINMA's own framework for ICT risk management and operational resilience is articulated primarily through FINMA Circular 2023/1 “Operational risks and resilience – banks”, alongside other guidance on outsourcing and cyber risk. The Swiss framework shares conceptual similarities with DORA — emphasising governance, risk management, and resilience — but differs in specific terminology, incident reporting timelines, and third-party provisions. Swiss firms building EU-facing businesses should plan for a harmonised framework that satisfies both Swiss and DORA expectations, rather than treating them as independent compliance streams.

The practical consequence for Swiss groups with EU subsidiaries is that they need a group-wide ICT risk management model in which the EU subsidiary complies with DORA and the Swiss parent meets FINMA's expectations, while intra-group services and dependencies are documented in a way that satisfies both supervisory perspectives. This integration involves additional effort, but it is also an opportunity to create a single resilience operating model that is regarded as mature in both jurisdictions.

DORA for CASPs: A New Compliance Layer

Crypto-asset service providers authorised under MiCA are subject to DORA from the moment their MiCA authorisation takes effect. This creates an interesting compliance interaction: CASPs must simultaneously build their governance and operational frameworks to meet MiCA requirements and to satisfy DORA expectations around ICT risk management, incident reporting, testing, and third-party risk management. For new entrants building greenfield CASP operations, this creates an opportunity to design a unified compliance framework from the outset; for existing crypto firms adapting to the new regulatory environment, it can represent a significant uplift in operational expectations.

The DORA requirements have particular salience for CASPs because crypto operations typically involve heavy reliance on cloud infrastructure, specialised third-party services (custody, blockchain analytics, node operations), and complex technology estates. The register of information, the contractual clause requirements, and the incident reporting obligations all apply with full force, and CASPs should plan to meet these expectations from the moment they commence regulated activity.

For founders preparing a CASP application, this means that the DORA documentation must be part of the initial application file. Supervisors expect new CASPs to be DORA-compliant when they start operating, and the authorisation review often covers elements such as the ICT risk management framework, the incident response procedures, and the third-party register. Building MiCA and DORA compliance as parallel workstreams, rather than as sequential projects, is the practicable route for most new CASPs.

The Critical ICT Third-Party Provider Designation

The designation of critical ICT third-party providers is one of DORA's most consequential innovations. Under the regulation, the European Supervisory Authorities designate certain ICT providers as critical based on criteria including the systemic impact on financial stability if the provider were to fail, the number and significance of the financial entities that depend on the provider, the substitutability of the provider, and the concentration of service provision within the provider.

Once designated, a CTPP becomes subject to direct oversight by a Lead Overseer, which is one of the ESAs acting on behalf of all supervisory authorities. The Lead Overseer can request information, conduct general investigations and on-site inspections, and issue recommendations. If a provider does not comply with a request for information, an investigation or an inspection, the Lead Overseer can impose a daily penalty payment of up to 1 percent of the provider's average daily worldwide turnover, for no more than six months (Article 35(6) to (8) DORA). If a provider does not declare within 60 calendar days that it will follow a recommendation and gives no sufficient explanation, the Lead Overseer discloses this publicly; as a last resort, the competent authorities can require financial entities to suspend their use of the service or to terminate the contract (Article 42 DORA). The oversight is intended to give supervisors visibility and leverage over providers whose failure would have systemic consequences, even though the providers themselves are not financial entities.

On 18 November 2025 the European Supervisory Authorities designated critical ICT third-party providers for the first time and published the list; under Article 31(9) of DORA it is updated every year. Financial entities should check whether their key ICT providers are on the list and understand that designated providers are subject to direct supervisory oversight even if the financial entity itself remains the primary regulatory counterpart.

The Register of Information: A Detailed Look

The register of information is one of the most tangible compliance obligations of DORA, and it has absorbed substantial effort at many financial entities. The register must contain structured information about every ICT third-party service arrangement, with a higher level of detail for arrangements supporting critical or important functions. The ESAs have published implementing technical standards specifying the exact data fields, codes, and formatting expected in the register.

The practical challenge for most institutions is not understanding what the register requires but rather assembling the underlying data from fragmented sources. Information about ICT providers is typically spread across procurement systems, contract repositories, financial systems, and informal vendor relationships, and consolidating it into a single register that meets the ITS format requires coordinated effort across multiple internal functions. Entities that began this work early in 2024 have generally been better positioned for the January 2025 effective date than those that waited.

The register must be kept up to date, reflecting changes in the ICT provider landscape, new or terminated services, and updates to the criticality classification of specific arrangements. It must be provided to the competent authority on request and, in practice, is submitted annually as part of routine supervisory reporting. Competent authorities use the register as an input to their own supervisory assessment of concentration risk and third-party dependency.

The quality of the register is itself a supervisory signal. A carefully maintained, complete, and plausible register suggests that the institution genuinely has its third-party relationships under control. A patchy or inconsistent register, conversely, casts doubt on the soundness of ICT governance as a whole and typically attracts detailed follow-up questions from the supervisor. Financial entities should therefore allocate resources to the continuous maintenance of the register and treat its updating not as a one-off exercise but as a recurring process built into the ongoing operating model.

Practical Compliance Roadmap

For entities still working toward full DORA compliance, or for entities seeking to mature their compliance programmes beyond the initial January 2025 baseline, a structured roadmap is essential. Priority actions typically include the following:

• Governance uplift: Ensuring that the management body has formally approved the ICT risk management framework, the ICT strategy, and the business continuity policy, and that board-level reporting on ICT risk is established.
• Risk management framework review: Conducting a gap analysis between the existing ICT risk management framework and DORA’s specific requirements, identifying areas where documentation or operational practice needs to be strengthened.
• Register of information completion: Finalising and maintaining the register of information, including all ICT third-party service arrangements and classification as supporting critical or important functions.
• Contract remediation: Reviewing ICT third-party contracts against the mandatory clause requirements of Article 30, negotiating amendments where needed, and prioritising arrangements that support critical functions.
• Incident response readiness: Updating incident classification and reporting procedures to meet DORA’s harmonised timelines, with particular attention to the 4-hour initial notification window for major incidents.
• Testing programme alignment: Designing or updating the digital operational resilience testing programme to meet the baseline requirements, and assessing whether threat-led penetration testing obligations apply.
• TLPT planning (where applicable): For entities subject to the TLPT requirement, planning the three-year testing cycle, procuring qualified testers, and engaging with the national central bank or competent authority on methodology alignment.
• Information sharing participation: Joining or formalising participation in sector information sharing arrangements to benefit from collective intelligence on threats.

Common Pitfalls in DORA Implementation

Across the population of in-scope entities, several recurring failure modes can be observed. Common pitfalls include the following:

• Documentation without operational capability: Producing documentation that describes sophisticated compliance arrangements that do not reflect actual operational reality on the ground.
• Incomplete register of information: Registers that omit material providers, that misclassify the criticality of arrangements, or that fail to capture sub-outsourcing chains.
• Unremediated third-party contracts: Reliance on providers whose contracts do not yet contain the mandatory DORA clauses, creating compliance gaps and supervisory exposure.
• Incident response not tested under time pressure: Incident procedures that look good on paper but that have never been exercised under the 4-hour initial notification constraint.
• Fragmented governance: ICT risk management that sits with the technology function without adequate involvement from compliance, risk management, and the management body.
• Underestimation of testing costs: Failure to plan for the substantial costs associated with threat-led penetration testing for significant entities subject to the requirement.

Cost Expectations

The cost of DORA compliance varies widely across the sector. For large banks and insurers with mature ICT risk management functions, the incremental cost of DORA compliance may be moderate relative to their existing investment in resilience. For smaller institutions, the cost can represent a more significant share of the operating budget, particularly where substantial gaps exist in existing frameworks. The ongoing cost of compliance includes compliance staffing, third-party advisory support, testing costs (especially TLPT for significant entities), contract management, register maintenance, incident response readiness, and supervisory reporting. Entities should budget realistically for the full-cycle cost rather than treating DORA as a one-off project.

Ongoing Programme Management

DORA is not a one-time compliance event but an ongoing programme. The regulation anticipates that the ICT risk environment will continue to evolve, that threats will become more sophisticated, and that supervisory expectations will continue to mature. Financial entities should plan for continuous programme management: regular updates to the ICT risk management framework, periodic review of the third-party register and contracts, testing on a rolling basis, continuous monitoring of the Level 2 measures and their revisions, and regular engagement with competent authorities and supervisors.

Entities that treat DORA as a project to be completed will find that compliance decays rapidly as their technology environment, third-party relationships, and threat landscape change. Entities that establish durable programme management arrangements — including clear ownership, periodic review cycles, and integration with broader enterprise risk management — will be better positioned to sustain compliance over time.

Conclusion

DORA marks a genuine shift in how ICT risk is regulated in the European financial sector. It imposes substantial new obligations, it raises the bar for operational resilience across the sector, and it extends supervisory reach into the ICT third-party ecosystem in unprecedented ways. For financial entities in the DACH region, the immediate work is to ensure that the January 2025 baseline is genuinely met and that the compliance programme is configured for sustained operation. The firms that approach DORA as an opportunity to build genuinely more resilient operations — rather than as a compliance burden to minimise — will be best positioned for the supervisory environment that DORA has created. Aegiron Capital Group supports fintechs and software vendors entering the DACH market in preparing for the DORA requirements of their bank customers and partners; legal advice and security assessments come from the law firm and specialists you engage.