DORA Is Not an IT Problem. It's an Operation Risk Problem.

The Digital Operational Resilience Act entered into application in January 2025. In the months that followed, many financial entities handed DORA compliance to their technology departments and moved on. This is the wrong response — and regulators are beginning to notice.

DORA is not an IT regulation dressed in financial services language. It is a governance regulation that uses ICT risk as its subject matter. The distinction is not semantic. It determines who is accountable, what they are accountable for, and what the consequences of non-compliance look like.

Article 5 of DORA is unambiguous. The management body of a financial entity shall define, approve, oversee, and be accountable for the implementation of all arrangements related to the ICT risk management framework. Not the CTO. Not the CISO. The management body.

This means that senior management must approve the ICT risk management framework, receive regular reporting on its effectiveness, and demonstrate active oversight of digital operational resilience. The regulation explicitly requires that management body members maintain sufficient knowledge and skills to understand and assess ICT risk — and keep those skills current.

For organisations that have treated technology governance as a delegated function, this represents a significant change. The regulator's expectation is that senior management understands ICT risk in substantive terms, not just that they have signed a policy document.

DORA requires financial entities to have a comprehensive ICT risk management framework that addresses the full lifecycle of ICT risk — identification, classification, protection, detection, response, recovery, and learning. This is not materially different from existing frameworks like ISO 27001, but DORA is more prescriptive about what must be documented and maintained.

Critically, the framework must be reviewed at least annually and after major incidents. The review must be documented, findings must be addressed, and the management body must be informed of the outcomes. This is an active governance requirement, not a static compliance exercise.

Organisations that have existing ISMS frameworks under ISO 27001 or NIST will find significant overlap with DORA requirements. However, the overlap is not complete, and the key difference is the explicit placement of accountability. ISO 27001 requires top management commitment. DORA requires management body accountability — a meaningfully higher standard.

DORA's incident reporting requirements are among its most operationally demanding elements. Financial entities must classify ICT-related incidents against defined criteria and report major incidents to their competent authority within specified timeframes — an initial notification within four hours of classification, an intermediate report within 72 hours, and a final report within one month.

The classification criteria are detailed. Organisations must assess incidents against thresholds covering duration, data affected, economic impact, reputational damage, and geographic spread. Getting this wrong — misclassifying a major incident as minor — is itself a compliance failure.

This means incident response processes must be explicitly DORA-aware. Classification decisions must be documented. Reporting timelines must be tracked. And the management body must be informed of major incidents, not just the technical team.

DORA's requirements for third-party ICT providers are extensive and represent the area where many organisations are furthest from compliance. Financial entities must maintain a complete register of all contractual arrangements with ICT third-party service providers, classified by criticality.

Critical ICT third-party providers — those where disruption could have systemic impact — face direct regulatory oversight under DORA, including inspections and binding recommendations from supervisory authorities. Financial entities must ensure that their contracts with critical providers meet DORA's specific requirements, including provisions for audit rights, exit strategies, and subcontracting controls.

For organisations with complex supplier ecosystems, achieving full visibility into ICT dependencies is itself a significant undertaking. Many have contractual arrangements with dozens of ICT providers that have never been formally assessed against DORA's criticality criteria.

DORA requires all financial entities to have a digital operational resilience testing programme. For most entities, this means annual testing of ICT tools and systems. For significant entities — those that meet defined thresholds of size and systemic importance — this means Threat-Led Penetration Testing (TLPT) every three years, conducted by qualified external testers against live production systems.

TLPT under DORA is not a standard penetration test. It is a structured exercise based on current threat intelligence, targeting the entity's critical functions, conducted with the management body's explicit approval. The results, including identified vulnerabilities and remediation timelines, must be shared with the competent authority.

Organisations that have been conducting annual penetration tests will find that TLPT requires a more rigorous programme than they currently operate. Those that have not been testing systematically will find themselves significantly behind.

Regulatory enforcement of DORA is early-stage, but the direction is clear. Supervisory authorities across the EU are developing their examination approaches, and the emphasis is consistently on governance — can the management body demonstrate that it understands and actively oversees digital operational resilience?

The organisations that will be in a defensible position are not necessarily those with the most sophisticated technical controls. They are the ones where senior management can demonstrate informed decision-making: where the ICT risk framework reflects genuine risk assessment rather than checkbox compliance, where incident classification is rigorous and documented, where third-party dependencies are mapped and managed, and where testing results drive remediation rather than sit in a report.

DORA's scope is broad and its requirements are detailed, but the underlying principle is straightforward: operational resilience is a management responsibility, and regulators will hold management accountable for it. Treating it as an IT problem is not just a governance failure — it is the wrong answer when the regulator comes to ask.