DORA 2026: embedding digital resilience for the long term

Since 17 January 2025, financial entities within the scope of the Digital Operational Resilience Act, or DORA, have been required to comply with its provisions. The structures and processes introduced to meet DORA requirements must now become firmly established in day-to-day operations. This helps ensure that critical or important functions remain available during information and communication technology (ICT) disruptions and that affected systems and services can be restored promptly. DORA compliance therefore remains an ongoing responsibility for the management body, business units, and control functions. In 2026, having policies and procedures in place is no longer enough. Financial entities must also be able to demonstrate that their arrangements work reliably in practice.

The Digital Operational Resilience Act, formally Regulation (EU) 2022/2554, creates a harmonised European framework for the digital operational resilience of the financial sector.

Put simply, DORA requires financial entities to understand which processes, information assets, ICT systems, and third-party services support their critical or important functions. They must manage the associated risks, prepare for ICT disruptions, test their resilience, and provide evidence that their controls operate effectively.

The regulation applies to a wide range of regulated financial entities, including credit and payment institutions, insurance and reinsurance undertakings, investment firms, management companies, and crypto-asset service providers. The precise obligations depend on the type of organisation, applicable exemptions, and the principle of proportionality.

For practical implementation, the DORA requirements can be divided into five closely connected areas. A separate European framework governs the oversight of designated critical ICT third-party service providers.

• ICT risk management: Financial entities must identify, classify, document, and regularly review their ICT-supported business functions, the information assets and ICT assets supporting them, and the related risks and dependencies, with particular attention to critical or important functions.
• ICT incident management and reporting: ICT-related incidents must be detected, managed, and classified. Major incidents must be reported to the competent authority within the applicable deadlines.
• Digital operational resilience testing: Resilience testing must follow a risk-based approach. Identified weaknesses must be prioritised and addressed, and the effectiveness of the corrective measures must be validated internally.
• ICT third-party risk management: Providers, contracts, subcontracting chains, concentration risks, and options for an orderly provider transition must be considered throughout the contractual relationship.
• Information sharing: Financial entities may voluntarily exchange information and intelligence on cyber threats within trusted communities, while respecting data protection, confidentiality, and competition-law requirements.

In 2026, the management of ICT third-party risk continues to gain importance. Financial entities must maintain an accurate and up-to-date overview of the ICT services they obtain from external providers. They must report specified information to the competent authorities at least annually and make the full Register of Information, or sections of it, available upon request.

For the 2026 reporting cycle, entities supervised by BaFin were required to prepare and submit their Register of Information in accordance with BaFin’s applicable reporting instructions and validation requirements. Submissions that did not meet the validation rules had to be corrected and resubmitted.

The first reporting cycles have turned the Register of Information into a practical stress test for many financial entities. The required information about providers, contractual arrangements, ICT services, subcontractors, and the functions supported by these services is often spread across procurement systems, contract repositories, outsourcing registers, and spreadsheets. Bringing this information together in a complete and consistent register can therefore be challenging.

The requirements for the DORA Register of Information should not be treated solely as an annual reporting exercise. Financial entities need a reliable process for identifying and recording changes to providers, services, contracts, and supported functions throughout the year. Responsibilities for maintaining, reviewing, and approving the data must also be clearly assigned. The information contained in these registers is used for the European oversight of critical ICT third-party providers. It gives the European Supervisory Authorities insight into the systemic significance of providers, their role in supporting critical or important functions, and the substitutability of their services.

In November 2025, the European Supervisory Authorities published their first list of 19 critical ICT third-party providers. The DORA critical ICT third-party providers list includes specific legal entities associated with major ICT service groups such as Amazon Web Services, Microsoft, Google Cloud, IBM, SAP, and Oracle. These companies have since been subject to the European DORA Oversight Framework.

However, European oversight does not relieve financial entities of their own responsibilities. Before entering into a contractual arrangement, they must assess the relevant risks and perform appropriate due diligence on potential providers. During the relationship, they need to consider changes to services, subcontractors, dependencies, and concentration risks. Additional requirements apply to ICT services supporting critical or important functions. Where a provider is difficult to replace, the financial entity must be able to demonstrate which alternatives are available and how a transition or termination could be prepared without adversely affecting business operations. European oversight therefore complements the ICT third-party risk management of financial entities, but it does not replace it.

Digital operational resilience testing is intended to identify vulnerabilities, deficiencies, and gaps before they affect critical or important functions. Financial entities other than microenterprises must maintain a risk-based digital operational resilience testing programme and ensure that all ICT systems and applications supporting critical or important functions are tested appropriately at least once a year.

Completing a test is not enough. Identified issues must be prioritised, assigned to clear owners, and addressed within defined timeframes. Financial entities must track the resulting actions through to completion and validate internally that the weaknesses have been fully resolved. This can be challenging even for organisations with mature control environments based on ISO 27001 or previous national regulations. For DORA compliance, documentation remains necessary, but it must be supported by evidence that weaknesses are addressed, controls and procedures operate effectively, and the organisation continuously strengthens its digital operational resilience.

A DORA requirements checklist can help structure the regulatory provisions and identify potential gaps. Based on the findings, a DORA implementation plan can define how financial entities address any outstanding obligations and embed them permanently in their operations.
Six steps are particularly relevant:

1 Determine the scope

Financial entities should establish which legal entities and activities fall within the scope of DORA and whether exemptions or simplified requirements apply. The assessment of scope should be documented and reviewed when the organisation, its activities, or its regulatory status changes. 
This creates a reliable basis for determining which requirements apply and where the principle of proportionality can be considered.

2 Conduct a DORA gap analysis

The next step is to assess the extent to which existing structures for ICT risk management, the information security management system, business continuity management, incident management, resilience testing, and outsourcing governance already contribute to meeting the DORA requirements. A DORA gap analysis template can help financial entities systematically map existing controls to regulatory requirements, identify remaining gaps, and define the necessary implementation measures.
Existing structures should be reused where they genuinely meet the relevant requirements. However, organisations should not assume that compliance with ISO 27001, MaRisk, BAIT, or VAIT automatically establishes DORA compliance.

3 Make dependencies transparent

Financial entities need to identify the processes, information and ICT assets, applications, and ICT third-party providers that support their critical or important functions. The associated risks, controls, and contracts should also be documented. 
A connected view of these dependencies is particularly important for ICT risk management under DORA. If information is maintained separately by IT, procurement, legal teams, and risk management, the organisation may lack a consistent understanding of how its critical functions depend on individual services and providers.

4 Review controls and procedures

Controls, incident management processes, and recovery mechanisms should be reviewed and tested regularly to ensure they operate as intended. Any weaknesses identified must be prioritised, assigned to clear owners, and addressed within defined timeframes. Financial entities should then verify that the corrective measures have resolved the underlying issues and that the relevant controls remain effective.
Insights from these reviews should feed back into the ICT risk management framework, enabling financial entities to continuously improve their digital operational resilience.

5 Keep DORA evidence up to date

The Register of Information, risk assessments, test plans, remediation records, exit strategies, and other evidence should be reviewed and updated regularly and whenever relevant changes occur. The objective is not to produce as much documentation as possible. It is to maintain reliable and consistent evidence that reflects operational reality. Outdated registers, unresolved test findings, or exit strategies that no longer reflect the current provider landscape may create a false impression of compliance.
The documentation obligations under DORA should therefore be integrated into normal change, contract, and risk management processes rather than handled as a separate annual exercise.

6 Involve the management body

Material ICT risks, dependencies, incidents, and outstanding findings must be presented in a way that enables the management body to fulfil its direction and oversight responsibilities. Management reporting should provide reliable information on which critical or important functions are exposed, where material dependencies or concentration risks exist, and whether remediation is progressing as planned.
 

The six implementation steps show that DORA does not concern IT alone. It affects the organisation’s overall governance and operating model. Ultimate responsibility for managing ICT risk lies with the management body. Among other duties, it defines the appropriate risk tolerance for ICT risk, approves key arrangements, and oversees their implementation. To make informed decisions, management needs information from IT, information security, risk management, and other relevant functions. A reliable overall view helps identify critical dependencies, clarify responsibilities, and prepare targeted response and recovery measures.

However, the information required for management reporting is often distributed across different functions. Procurement may hold supplier information, legal teams may manage contracts, IT may maintain service documentation, and risk management may be responsible for reporting. If these functions use different data or definitions, financial entities cannot create a dependable picture of their digital operational resilience. Effective DORA implementation therefore requires cross-functional cooperation and a consistent information base. This approach supports regulatory compliance while also improving transparency across the ICT risks, systems, and providers on which critical or important functions depend.

Many financial entities already have information security and risk management structures on which they can build when implementing DORA. The decisive question is which DORA requirements are already covered and where adjustments are still needed. An information security management system based on ISO 27001, for example, supports the systematic management of information security risks. However, ISO 27001 certification does not confirm DORA compliance. DORA contains additional financial-sector-specific requirements concerning digital operational resilience, regulatory incident reporting, resilience testing, ICT third-party risk management, the Register of Information, and management body responsibilities.

DORA and NIS2 both aim to improve the management of ICT and cyber risks, but their scope differs. DORA establishes specific requirements for the financial sector, while NIS2 takes a broader approach and covers essential and important entities across a wide range of industries. For financial entities within the scope of DORA, DORA generally acts as the sector-specific framework for managing ICT risk and reporting major ICT-related incidents where the corresponding requirements overlap. Whether additional NIS2-related obligations apply depends on the individual entity and its activities.

MaRisk continues to specify supervisory requirements for risk management at German credit institutions and certain financial services institutions. DORA, by contrast, specifically regulates digital operational resilience in the financial sector. Existing MaRisk structures can support implementation, but they must be assessed against the detailed DORA requirements.

Many IT-related requirements previously addressed by BAIT and VAIT are now covered by DORA. BaFin repealed VAIT with effect from the end of 16 January 2025. It also exempted institutions subject to DORA’s ICT risk management requirements from BAIT as of 17 January 2025. BAIT remains applicable to a limited group of institutions until the end of 2026. From 1 January 2027, additional institutions covered by the relevant German transitional provisions will become subject to DORA. BaFin will fully repeal BAIT with effect from the end of 31 December 2026.

Existing frameworks can provide a valuable foundation for DORA implementation. They do not, however, remove the need for a structured gap analysis.

Effective DORA implementation goes beyond the formal fulfilment of individual requirements. It is reflected in how consistently the organisation applies them in day-to-day operations. The following characteristics indicate that DORA has been effectively embedded across the organisation:

• IT, information security, risk management, compliance, and other relevant functions coordinate their responsibilities and share the information needed to assess risks and dependencies.
• These functions work with current and consistent data, apply defined processes reliably, and maintain the necessary evidence on an ongoing basis.
• The organisation understands how its critical or important functions depend on processes, information assets, ICT systems, and third-party providers.
• Findings from incidents, resilience tests, and audits are assigned to clear owners, addressed within defined timeframes, and validated before they are considered closed.
• The management body receives the information it needs to monitor material ICT risks, dependencies, incidents, and outstanding findings and to make informed decisions.

These characteristics show that DORA has become an established part of operational practice rather than remaining a purely regulatory requirement.
 

DORA provides financial entities with a harmonised framework for systematically strengthening their digital operational resilience. As the requirements have applied since 17 January 2025, the priority in 2026 is to embed them permanently in governance and operational processes.

Effective implementation is not limited to meeting formal regulatory obligations. It creates greater transparency across ICT risks and dependencies, supports more targeted prioritisation of protective and improvement measures, and helps organisations prepare for ICT disruptions.

The central challenge is moving from documentation to demonstrable effectiveness. Financial entities must be able to show that controls operate reliably, incidents can be reported on time, findings from digital operational resilience testing are fully remediated, and ICT third-party risks are managed continuously.

This helps organisations protect their ability to act during a disruption and maintain or restore critical or important functions more reliably.