The number is 50 percent.
That is the share of European financial institutions fully compliant with DORA as active enforcement begins. Automated cross-checking of Register of Information filings running, first compulsion payments issued, national competent authorities empowered to impose fines up to 2% of global annual turnover, suspend operating licenses, and hold individuals personally liable up to €1 million.
Half. After two years of preparation.
The temptation is to read this as a capacity problem. Too many requirements, too little time, too complex a framework. That reading is wrong, and the institutions that accept it will fail the next regulatory cycle the same way they failed this one.
The 50 percent figure is not a measurement of compliance effort. It is a measurement of organizational design. The institutions that are non-compliant didn’t run out of time. They ran into something their organizations weren’t structured to produce.
What Compliance Programs Can’t Do
When a significant regulation arrives, large institutions build compliance programs. This is rational. Compliance programs are how organizations manage regulatory requirements defined workstreams, executive sponsors, working groups, evidence packages, timeline dashboards. They are effective tools for producing documentation that demonstrates awareness of and response to a regulatory framework.They are not effective tools for changing how an organization operates.
DORA requires both. The regulation was designed to address a specific operational problem: financial institutions had accumulated deep dependencies on ICT providers they couldn’t adequately govern, using infrastructure they didn’t fully understand, under contracts that didn’t give them the rights they’d need if something went wrong. The framework’s requirements such as incident classification, third-party contract provisions, operational resilience testing, Register of Information are attempts to force that dependency structure into visibility and governance.
You cannot make a dependency structure visible through a compliance program. You can document it. You can produce a Register of Information that describes it. But documentation of a dependency structure and governance of a dependency structure are different things, and enforcement tests for the latter.
This is the design failure behind the 50 percent figure. The institutions that missed compliance built programs to address DORA’s requirements. The institutions that made it built governance that DORA’s requirements reflect. The compliance documentation followed from something that already existed. For the others, the documentation was the product and enforcement is now checking whether the product matches the production.
The Three Places It Breaks
Enforcement concentrates at the points where the gap between documentation and operational reality is most measurable. There are three.
The first is incident classification. DORA requires consistent, risk-calibrated categorization of operational incidents across the institution. In practice, incident classification in large financial institutions is a negotiation. When a trading system degrades, or a payment rail runs slow, or a third-party data feed goes dark, someone has to determine the severity. That determination triggers escalation requirements, reporting timelines, and regulatory notification obligations. The people closest to the problem know what different severity levels will cost them in terms of scrutiny, process, and accountability. Classification gets managed accordingly.
This isn’t negligence. It is a rational response to an incentive structure that treats incident classification as a high-stakes organizational decision rather than an operational signal. The problem is that DORA requires the latter, and the compliance program that mapped existing incident categories to DORA’s framework didn’t change the incentive structure. It just relabeled the categories. Automated cross-checking of incident patterns against regulatory filings will find the cases where what was classified and what should have been classified diverge.
The second is third-party contract provisions. DORA requires specific contractual rights with ICT vendors: exit provisions, audit access, sub-outsourcing controls, service continuity guarantees. Most contracts with major providers – cloud platforms, core banking vendors, market data services were written before these requirements existed and don’t contain them. Renegotiating at scale requires leverage the institution may not have, timeline the compliance program didn’t build in, and counterparty cooperation that wasn’t guaranteed. The compliance path most institutions took was documentation: mapping existing contract language to DORA’s requirements and treating gaps as low materiality or in process. Enforcement applies a different materiality standard than the compliance program did.
The third is the Register of Information itself. Assembling an accurate Register required knowing every material ICT third party, every service they provide to each business function, and every criticality designation, as those relationships actually operate in production, not as they were originally contracted. For institutions that had never mapped their actual operational dependency structure, building the Register was the first time anyone had tried. What most submitted reflects how the institution intended its dependencies to work, assembled from procurement records, vendor lists, and org charts. Automated regulatory cross-checking compares that against incident reports, outage disclosures, and third-party filings. The institutions that built their Register from production reality will look different from the ones that built it from procurement records.
The Governance That Enforcement Finds
When enforcement identifies a gap in any of these three areas, it is not finding a compliance failure. It is finding a governance structure.
An institution that cannot classify incidents consistently does not have a classification problem. It has an authority problem: somewhere in the organizational design, the decision about how bad something is was left to the people most interested in the answer. That is a governance design choice, usually invisible until enforcement makes it legible.
An institution whose contracts don’t contain required provisions has a vendor management problem that predates DORA. The contracts were acceptable before DORA because nobody required what DORA requires. The question enforcement surfaces is why the remediation program didn’t treat renegotiation as the primary task rather than documentation of existing terms.
An institution whose Register doesn’t reflect production reality has a self-knowledge problem. It does not accurately know its own operational dependency structure. That is a significant finding for an institution whose stability regulators are responsible for. It will inform supervisory assessments of operational risk for as long as the finding is on record which is substantially longer than the enforcement cycle that produced it.
The Individual Liability Question
DORA’s individual liability provisions, senior management and governing body members personally liable, not institutionally, up to €1 million are the mechanism that changes the governance conversation most directly.
For the previous generation of operational resilience regulation, the governance response was to add oversight at the institutional level. More committee review. More sign-off layers. More documentation of who approved what. Individual liability asks a different question: does the person attesting to the Register of Information actually know what it contains? Not whether they signed the document, but whether they have the organizational intelligence to know whether it is accurate.
That is not a compliance program question. It is an operating model question.
The institutions that treated DORA as a compliance program built programs that attest to things. The institutions that treated it as an operating model upgrade built systems that know things. The enforcement record will show which is which.
What the Number Actually Measures
50 percent of European financial institutions are fully DORA-compliant.
That number will be updated over the course of the enforcement cycle. Some of the non-compliant institutions will close their gaps quickly. Some will dispute findings. Some will pay fines and remediate. The number will change.
What won’t change is what the number revealed: that across the institutions in scope, half lacked the organizational structure to know their own operational dependency landscape well enough to represent it accurately under a framework they had two years to prepare for. That is useful information. It describes something real about how governance capability is and is not built inside large financial institutions.
The next regulatory cycle will ask similar questions of similar institutions. The ones that treat the current enforcement moment as a compliance problem to close will be non-compliant again. The ones that read the 50 percent figure as an organizational diagnosis and act accordingly are the ones that will have built something different by then.