On 17 February 2026, the Digital Operational Resilience Act (DORA) — EU Regulation 2022/2554 — became fully applicable across the European financial sector. After two years of preparation, most institutions have produced policies, completed gap assessments and assigned project ownership. A smaller number have genuinely transformed their operating model to meet what DORA actually demands. The gap between those two groups is, in my experience, where the real risk now lives.
This article is written for board members, non-executive directors and senior executives at regulated financial institutions — not for the architects and security engineers implementing the technical controls. It focuses on the obligations that land directly on the management body under DORA, and on the scale of organisational and architectural change that compliance genuinely requires. Much of what follows is drawn from the practical experience of leading DORA compliance programmes at a regulated German bank.
DORA Is a Governance Regulation, Not an IT Regulation
The most important thing a board can understand about DORA is that it is not addressed to the IT department. Article 5 of the Regulation places explicit and non-delegable obligations on the management body — meaning the board of directors, supervisory board or equivalent — in respect of ICT risk. These are not obligations that can be fulfilled by receiving a quarterly dashboard from the CISO. They require active oversight, documented understanding, and personal accountability.
Specifically, Article 5 requires the management body to define, approve and oversee the ICT risk management framework; to set risk appetite and tolerance levels for ICT risk; to allocate adequate budget for ICT security and resilience; to approve major ICT investments; and to keep their individual knowledge of ICT risk sufficiently current to meaningfully discharge these responsibilities. That last point is striking. DORA effectively codifies a duty of competence on board members in relation to digital risk — something the NIS2 Directive had begun to signal, but that DORA makes explicit for financial entities.
"The board cannot delegate its DORA obligations to the technology function. It can delegate execution — it cannot delegate accountability."
This has practical consequences. Board members who have historically treated ICT risk as a specialist matter — something to be reassured about rather than understood — are now expected to engage with it substantively. Regulators including BaFin and the EBA have been clear that they will assess management body engagement as part of supervisory review. The days of the board receiving a traffic-light report and asking no further questions are numbered.
The Five Pillars — and Where Most Institutions Are Weakest
DORA's requirements are structured around five pillars. Most institutions have reasonable coverage of the first two and significant gaps in the remaining three.
In my experience working through DORA implementation, third-party risk management consistently represents the largest gap between what institutions think they have in place and what DORA actually requires. Article 28 mandates specific contractual provisions for all ICT service providers — not just critical ones — covering audit rights, data location, sub-contracting visibility, business continuity obligations, termination rights and much more. A systematic review of an institution's vendor estate typically reveals that the vast majority of existing contracts fail to meet these requirements. Renegotiating hundreds of supplier agreements is a multi-year programme, not a compliance checklist item.
What "Compliance" Rarely Means in Practice
One of the more uncomfortable conversations I have had with senior leadership teams concerns the difference between documented compliance and actual resilience. An institution can produce a DORA-compliant policy framework, appoint the right governance committees, and satisfy an initial supervisory review — whilst remaining operationally vulnerable in ways that would only become visible under real stress.
At regulated institutions I have worked with, the most revealing DORA exercise is not the gap assessment — it is asking a simple question: "If your three most critical ICT third-party providers each experienced a simultaneous outage of 48 hours, what would happen to your core business processes?" Most management teams cannot answer this question with confidence. DORA requires that they can — and that documented response plans exist, have been tested, and are known to work.
Genuine resilience requires that business continuity and disaster recovery plans are tested end-to-end, not just reviewed on paper. It requires that recovery time objectives (RTOs) and recovery point objectives (RPOs) are not just defined, but demonstrably achievable. It requires that the technology architecture itself — not just the processes around it — supports rapid detection, containment and recovery. This is where the architectural dimension of DORA becomes unavoidable.
The Architectural Dimension Boards Must Not Underestimate
DORA is not neutral with respect to technology architecture. An institution built on tightly coupled legacy systems, with limited network segmentation, opaque third-party dependencies and manual operational processes, cannot become DORA-compliant through governance changes alone. The architecture must change.
The specific architectural requirements that most commonly require significant investment are:
Network Segmentation and Isolation
DORA requires that ICT systems can be isolated to contain incidents without cascading failure. Many legacy architectures — particularly in banks that have grown through acquisition — have flat or insufficiently segmented network topologies. Achieving meaningful isolation requires not just firewall rules but architectural restructuring of how systems communicate.
Observability and Detection Capability
The incident reporting timelines in DORA (4 hours to initial notification) are only achievable if an institution has mature detection and monitoring capability. This means comprehensive logging, real-time alerting, Security Information and Event Management (SIEM) coverage across the entire ICT estate, and clear operational processes for incident classification. Many institutions have significant gaps in coverage — particularly across legacy applications and third-party hosted services.
Third-Party Dependency Mapping
Article 28 requires institutions to maintain a complete register of all ICT third-party service providers, with information on the functions supported, the criticality of each service, and the sub-contracting chain. Building this register is frequently a substantial discovery exercise in itself. Institutions are often surprised by how many critical processes run on undocumented or partially documented third-party infrastructure.
Business Continuity Architecture
DORA requires that continuity plans are not aspirational documents but tested, operational capabilities. This implies that backup systems exist, are maintained in a state ready to activate, and have been successfully tested under realistic conditions. For institutions that have historically treated DR as a one-time implementation exercise, bringing this to DORA standard requires sustained investment.
Questions Every Board Should Be Asking
Based on practical experience of DORA implementation, the following questions represent the minimum a management body should be able to answer — or require management to answer — with documented evidence:
- Has our ICT risk management framework been formally approved by the board, and is there documented evidence of that approval?
- Has the board explicitly set ICT risk appetite and tolerance levels, and are those levels reflected in operational limits?
- Can we demonstrate that all ICT third-party contracts have been reviewed against DORA's Article 28 requirements — and do we have a programme to remediate gaps?
- Have our Business Continuity and Disaster Recovery plans been tested end-to-end in the last twelve months, with documented results?
- Do we have a complete, accurate and current register of all ICT third-party providers, including sub-contractors?
- Have we identified whether we are classified as a significant institution subject to TLPT requirements, and if so, is our TLPT programme planned and resourced?
- Are our incident detection and reporting processes capable of meeting DORA's 4-hour initial notification requirement — in practice, not just in theory?
- Has the board received appropriate training or briefing to discharge its Article 5 responsibilities with the required level of understanding?
The Supervisory Reality
BaFin has been explicit that it will incorporate DORA into its supervisory framework and expects institutions to demonstrate not just policy compliance but operational capability. The EBA's Joint Examination Teams, which include EIOPA and ESMA representation, have indicated that supervisory assessments will include direct engagement with management body members — not just review of documentation submitted by the compliance function.
For institutions that have treated DORA as a compliance exercise to be managed by the second line of defence, this represents a meaningful change in supervisory approach. The first conversation a BaFin examiner has with a board member about DORA is not the moment to discover that the board's understanding of its obligations under Article 5 has not kept pace with implementation.
Conclusion
DORA is the most significant piece of technology-focused regulation the European financial sector has faced. Its distinguishing feature — compared with GDPR, NIS2 or the EBA's ICT Risk Guidelines — is the directness with which it places governance obligations on the management body rather than the technology function. This is not a detail. It is the central design choice of the regulation.
Institutions that understand this, and have built their DORA programmes accordingly — with the board as an active participant rather than a passive recipient of compliance updates — are significantly better positioned both for supervisory scrutiny and for the actual operational stress events that DORA is designed to prepare them for.
Those that have produced the documentation without transforming the underlying capability will find, sooner or later, that the gap becomes visible. Regulators have long memories, and ICT incidents do not respect the limits of a compliance programme.