Table of Contents
The following sections walk through what DORA requires, why the 2024 dry-run results were so poor, and what a credible preparation program looks like in practice.
- A Number That Should Alarm Every Chief Risk Officer
- What DORA Actually Is
- The Five Pillars of DORA, in Detail
- The Real Cost of a DORA Failure
- The Special Case of Threat-Led Penetration Testing (TLPT)
- The 2024 Dry-Run: What Was Actually Measured
- The 116 Quality Checks, Unpacked
- Why So Many Firms Failed
- The Register of Information, Root of the Problem
- Why 2026 Changes Everything
- Who Is Affected, Precisely
- The Governance Model That Actually Works
- The Complete 2025-2026 Timeline
- How to Prepare Now
- Case Study: A Regional Bank Facing the Dry-Run
- The Mistakes That Sink a DORA Program
- First Diagnostic Checklist
- FAQ
- Regard d’Expert
- Références
A Number That Should Alarm Every Chief Risk Officer
In 2024, the European Supervisory Authorities ran a dry-run exercise to test financial institutions’ readiness against the requirements of the Digital Operational Resilience Act (DORA). The result should surprise even the best-prepared organizations: only 6.5% of firms passed the full set of 116 data quality checks applied to their submissions. In other words, more than 93% of tested institutions showed at least one non-conformity, on an exercise that carried no direct regulatory consequence.
That number deserves to be taken seriously for a simple reason: DORA is no longer, in 2026, a text in a tolerance phase. The regulation has been fully applicable since January 17, 2025, and 2026 marks the shift to active enforcement by national competent authorities. Firms still failing this dry-run in 2024 no longer have the same room to maneuver today, the same gaps, if they persist, now expose the organization to real scrutiny, not a pedagogical exercise.
What DORA Actually Is
The Digital Operational Resilience Act is an EU Regulation, not a Directive, requiring financial entities to demonstrate their ability to withstand, respond to, and recover from disruptions and threats related to information and communication technology (ICT). Unlike a directive, which requires transposition into each member state’s national law, an EU regulation applies directly and uniformly across all 27 countries, with no national margin for interpreting the substance of the text.
This legal distinction isn’t a technicality: it explains why DORA could take effect so quickly and uniformly compared to other recent EU texts like CSRD or the EAA, which saw uneven national transposition timelines. For DORA, there’s no country-to-country waiting game, the obligation is the same everywhere, since January 17, 2025.
DORA applies to banks, insurance and reinsurance companies, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third-party providers, including non-EU companies, as soon as they operate in Europe or serve European clients. This extension to third-party providers is one of the text’s major innovations, and one of the most poorly anticipated by affected organizations.
The Five Pillars of DORA, in Detail
DORA structures its requirements around five pillars that together cover the entire lifecycle of digital operational resilience. Understanding these five pillars is essential before addressing why the 2024 dry-run revealed so many gaps.
First pillar, ICT risk management governance. DORA explicitly requires that the financial entity’s management body be responsible for ICT risk management, this is no longer a topic that can be fully delegated to IT. The board must approve the ICT risk management framework, oversee its implementation, and be accountable for failures.
Second pillar, ICT incident management, classification, and reporting. Entities must detect, classify, and report major ICT incidents according to strict deadlines and standardized formats defined by supervisory authorities. This pillar requires internal processes capable of quickly qualifying incident severity and producing a compliant notification within timeframes often measured in hours, not days.
Third pillar, digital operational resilience testing. DORA mandates regular testing, including, for the most significant entities, threat-led penetration testing (TLPT), a particularly demanding form of penetration test simulating realistic attacks on critical systems.
Fourth pillar, managing ICT third-party risk. This is the pillar introducing the Register of Information, an exhaustive, structured mapping of all ICT third-party providers and their contracts, with particular attention to providers deemed critical by the authorities.
Fifth pillar, information sharing on cyber threats. DORA encourages, and in some cases structures, the sharing of cyber threat information and intelligence between financial entities, to collectively strengthen sector-wide resilience.
These five pillars don’t function independently. An entity that neglects governance (first pillar) will mechanically produce slower, less structured incident management (second pillar), less rigorous resilience testing (third pillar), and a less reliable Register of Information (fourth pillar), which largely explains why the 2024 dry-run failure rate was so massive: the weakness observed on the Register of Information was often just the visible symptom of insufficiently mature ICT risk governance upstream.
DORA’s five pillars cover the entire lifecycle of digital operational resilience.
The Real Cost of a DORA Failure
Penalties under DORA vary by member state and entity type, but they share one common trait: they’re never limited to a simple administrative fine. Competent authorities hold broad powers including requiring corrective measures under penalty, temporarily suspending certain activities, and in the most severe cases, withdrawing authorization, an existential sanction for a regulated financial institution.
Beyond direct sanctions, the indirect cost of a DORA failure discovered during a real inspection far exceeds that of proactive remediation. An entity discovering its gaps during a supervisory inspection must produce a remediation plan under a regulator-imposed timeline, with heightened scrutiny on subsequent cycles, a structurally less favorable position than an internal audit conducted upstream, at its own pace, with the ability to quietly correct issues before any official submission.
The Special Case of Threat-Led Penetration Testing (TLPT)
For entities designated as significant by competent authorities, DORA requires threat-led penetration testing, commonly known by its acronym TLPT. These tests differ markedly from a standard penetration test: they simulate realistic attack scenarios built from actual threat intelligence observed against the financial sector, executed by specialized red teams and overseen by an independent controller throughout the exercise.
Preparing for a TLPT isn’t limited to a one-off technical exercise. It requires precise mapping of the critical systems involved, coordination with ICT third-party providers potentially implicated in the tested scope, and governance capable of drawing structured lessons from results, not just fixing discovered vulnerabilities in isolation. Entities that approach TLPT as a mere compliance exercise, without integrating results into continuous security posture improvement, get significantly less value from it than those treating it as a genuine risk-steering tool.
Preparation also demands close coordination between the internal security team, the business lines whose systems are being tested, and often external specialized providers who conduct the actual simulated attack. This coordination itself becomes a test of organizational maturity, an entity unable to coordinate a TLPT smoothly is often revealing the same governance gaps that would surface during a real incident.
Beyond the technical execution, the true value of a TLPT lies in what happens afterward: how findings are triaged, prioritized, and fed into a genuine remediation roadmap with executive visibility. Organizations that treat the post-test report as a formality to file away, rather than as a live input into governance discussions, forfeit most of the exercise’s actual benefit.
A TLPT tests organizational coordination as much as it tests technical defenses.
The 2024 Dry-Run: What Was Actually Measured
Before looking at the specific failure patterns, it helps to understand exactly what the exercise tested and why the ESAs chose this particular focus over other possible starting points.
The dry-run exercise conducted by the European Supervisory Authorities (ESAs) in 2024 specifically focused on the quality and completeness of the data entities would need to submit for the Register of Information, one of DORA’s most structurally demanding and technical deliverables. The test didn’t evaluate operational resilience itself, but rather entities’ ability to reliably and consistently produce the structured data required by the regulation.
This methodological choice is revealing: authorities rightly anticipated that the main difficulty wouldn’t be conceptual but operational, the real capacity of financial institutions’ information systems to produce a reliable mapping of their ICT providers, structured according to a standardized format, free of errors and inconsistencies.
The 116 Quality Checks, Unpacked
The 116 quality checks applied during the dry-run covered several dimensions: internal consistency of submitted data (the same provider identified consistently across all declared contracts), completeness of mandatory fields, compliance with taxonomies and reference data defined by the ESAs, and consistency between entity-level and consolidated group-level data for multi-entity organizations.
The result is a form of institutional erosion: capability that technically exists on paper but cannot be reliably produced, verified, or defended when a supervisor actually asks for it, which is precisely the gap the 2024 dry-run was designed to expose, and precisely the gap it found in 93.5% of participating institutions.
Why So Many Firms Failed
Several structural causes explain this massive failure rate, and they overlap substantially with difficulties observed on other data-intensive compliance programs like CSRD.
Contract data scattered across multiple functions. The information needed for the Register of Information, provider identity, service nature, criticality, contractual termination and portability clauses, typically lives in legal systems, procurement systems, and technical inventories managed by different teams, rarely connected to each other.
The absence of a single provider reference source. Many organizations, particularly multi-entity groups, discover while building their Register of Information that they never had a consolidated, reliable view of all their ICT providers group-wide, each subsidiary managing its own contracts with no central visibility.
Underestimating the complexity of criticality classification. Determining whether a provider is \u201ccritical\u201d under DORA requires a rigorous, documented methodology, not an informal judgment call, and many organizations simply didn’t have that methodology in place at test time.
A lack of data governance skill applied to this specific scope. As with CSRD, DORA’s real complexity on this pillar is a data structuring and governance complexity, not just a legal or cybersecurity complexity.
The Register of Information, Root of the Problem
The Register of Information deserves particular attention because it’s precisely what was tested, and it’s also what structures the entity’s relationship with its entire ICT provider ecosystem. This register must cover, for 2026, all contractual arrangements with ICT third-party providers in force as of December 31, 2025, a point-in-time snapshot requiring retrospective collection if not anticipated in advance.
National submission deadlines for this register vary by country despite DORA’s regulation status, an important nuance: while the substantive requirements are harmonized, practical submission arrangements (portals, precise deadlines) sometimes remain nationally managed. In the Netherlands, the supervisory authority (AFM) set a submission deadline of March 31, 2026. In Luxembourg, the CSSF portal opened February 11, 2026. At the consolidated European level, the ESAs set a deadline of April 30, 2026.
Why 2026 Changes Everything
DORA has been in force since January 2025, but the initial period was marked by what several legal experts describe as implicit tolerance, authorities giving entities time to structure their frameworks without immediately launching heavy enforcement actions. That period is ending. Competent national authorities, alongside the European Supervisory Authorities, are now conducting active supervisory reviews, and enforcement actions are real.
A PwC legal expert sums up this shift well: boards must now prepare for a new cadence of supervisory engagement centered on operational resilience, distinct from the traditional prudential metrics financial institutions are used to. This is no longer a secondary IT topic in a board meeting, it has become a governance topic in its own right.
Who Is Affected, Precisely
DORA applies to a deliberately broad scope: banks, insurance and reinsurance companies, investment firms, payment institutions, e-money institutions, crypto-asset service providers, fund managers, and many other categories of regulated financial entities. Requirements are applied proportionately, smaller entities aren’t held to exactly the same standard as large systemic institutions, but proportionality doesn’t mean exemption.
An often underestimated point: ICT third-party providers themselves, including those based outside the EU, fall within the supervisory scope as soon as they’re designated critical to the European financial sector. Many IT services and outsourcing companies based in India or elsewhere, serving European financial clients, must now themselves prepare for direct DORA compliance obligations.
This extension of scope to non-EU third-party providers deserves serious attention from non-EU digital services companies, including North American ones, that derive a significant share of revenue from European financial clients. Designation as a critical provider doesn’t depend on headquarters location, but on the real importance of the service provided to the operational stability of the European financial sector, a functional criterion, not a geographic one.
The proportionality principle running through DORA also deserves a closer look, since it’s frequently misunderstood as a broad exemption rather than what it actually is: a graduated scale of expectations. A small payment institution and a systemic cross-border bank are both squarely within scope, but the depth of documentation, the frequency of testing, and the intensity of supervisory engagement expected from each differ substantially. Confusing proportionality with exemption is itself a common source of the compliance gaps revealed by the 2024 dry-run, smaller entities sometimes assume a lighter touch extends to the Register of Information itself, when in practice that specific deliverable is expected from nearly the entire scope regardless of size.
The Governance Model That Actually Works
Organizations that move efficiently on DORA compliance share a common pattern: they don’t treat the Register of Information as a standalone deliverable owned by a single function, but as the visible output of a broader ICT risk governance structure spanning legal, procurement, IT, and risk management. A dedicated DORA steering committee, meeting monthly, with named data owners for each major provider category and explicit escalation paths for classification disagreements, consistently outperforms ad hoc coordination between departments that only interact when a deadline forces them to.
This governance model also needs a genuine executive sponsor, someone with the authority to resolve disputes between, for example, a procurement team wanting to classify a provider as non-critical to avoid additional contractual obligations, and a risk function insisting on a stricter classification. Without that arbitration authority sitting above both functions, criticality classification tends to drift toward whichever answer is organizationally convenient rather than whichever answer is factually correct, exactly the kind of drift that produces exactly the inconsistencies the ESAs’ 116 checks are designed to catch.
The Complete 2025-2026 Timeline
Tracking DORA deadlines requires distinguishing substantive obligations, harmonized at EU level, from practical submission arrangements, sometimes nationally managed. January 17, 2025 marks the regulation’s full entry into effect, not a transition start date, but the point from which substantive obligations are fully enforceable.
December 31, 2025 is the reference date for the snapshot of contractual arrangements with ICT third-party providers to appear in the 2026 Register of Information, every organization must therefore be able to reconstruct a reliable view of its contractual situation at that precise date, even retrospectively if collection wasn’t conducted continuously.
February 11, 2026 corresponds to the opening of Luxembourg’s CSSF submission portal, one of the first national timelines to actually activate. March 31, 2026 is the deadline set by the Dutch authority AFM for Register of Information submission. April 30, 2026 is the consolidated deadline set by the European Supervisory Authorities themselves, a reference date for the whole sector even where earlier national deadlines exist.
Beyond these documentary deadlines, 2026 also sees intensifying threat-led penetration testing campaigns for entities designated as significant, along with the first in-depth supervisory reviews of the real robustness of ICT incident management setups, two workstreams that, unlike the Register of Information, aren’t limited to a one-off documentary submission but require continuous demonstration of operational capability.
How to Prepare Now
Given this, the immediate priority for any financial institution that hasn’t yet validated the robustness of its Register of Information is to conduct an internal audit modeled on the ESAs’ 116 quality checks methodology, not to wait for a real inspection to discover the same gaps that tripped up 93% of entities tested in 2024.
Concretely, this approach usefully breaks down into four phases. The first is appointing a single DORA program owner within the organization, with a clear mandate covering both ICT risk governance and Register of Information coordination, a role that, in many organizations, simply doesn’t exist yet in formalized form. The second phase builds the exhaustive provider inventory group-wide, systematically querying every subsidiary, every procurement function, and every existing contract management system, rather than trusting an assumed-complete list.
The third phase applies the criticality classification methodology to this consolidated inventory, explicitly documenting the criteria used for each decision, a provider hosting sensitive customer data isn’t classified the same way as a provider supplying an expense report tool, and this differentiation must be traceable and defensible under inspection. The fourth phase, finally, sets up the continuous update rhythm for the register, with a process triggered automatically at every new contract signed or terminated, rather than a full rebuild at every submission deadline.
Case Study: A Regional Bank Facing the Dry-Run
A European regional bank, with roughly 1,800 employees operating across three countries, participates in the 2024 dry-run with reasonable initial confidence: the institution already maintains an IT provider inventory kept by IT, updated semi-regularly for several years. The dry-run result reveals a pass rate of only 22% across the 116 quality checks, notably above the sector average, but far from full compliance.
The post-test diagnosis reveals that IT’s inventory, while real, only covered providers directly contracted by that function, it systematically missed providers engaged directly by local subsidiaries, as well as several cascading subcontracting arrangements where a designated primary provider itself used ICT subcontractors not identified in the initial register. This gap, very common, illustrates why a single-function-owned inventory, however rigorous, almost never covers the full reality of a multi-entity group.
The bank then launches a six-month program combining a newly created data governance function, a systematic contract review involving each subsidiary’s legal teams, and methodological clarification of criticality classification validated by the risk committee. The rebuilt register reaches a 94% internal compliance rate at a second, internally-run dry-run ahead of the real 2026 submission, a result that wouldn’t have been achieved without the structural overhaul of underlying data governance, not just extra collection effort.
Rebuilding a reliable register requires real coordination across functions, not just a collection push.
The Mistakes That Sink a DORA Program
Beyond the specific gaps already discussed, a handful of recurring organizational mistakes show up across nearly every troubled DORA program observed in the market.
Treating the Register of Information as a one-off collection exercise rather than a continuous data governance program. A register built once and never updated quickly becomes stale as new contracts are signed and old ones terminated.
Letting each subsidiary or function manage its own provider list with no central reference source. This is precisely the gap that drove down the 2024 dry-run pass rate, and the one observed in the case study above.
Underestimating the complexity of the provider criticality classification methodology. An informal, undocumented classification doesn’t hold up under a regulator asking to justify each classification decision.
Discovering data inconsistencies at submission time rather than through a prior internal audit. An internal audit modeled on the ESAs’ 116 checks, conducted months ahead of the real deadline, leaves time to correct without direct regulatory pressure.
Assigning this program solely to legal or solely to IT, without cross-functional data governance skill. Neither function alone covers the full skill set needed to build a reliable, durable register.
First Diagnostic Checklist
This checklist gathers the points of vigilance identified throughout this article, to use as the basis for a first internal diagnostic before any more formal audit is commissioned.
- Does a single, central reference source of all group ICT providers exist, covering every subsidiary without exception?
- Is a documented provider criticality classification methodology in place and applied consistently?
- Has an internal audit modeled on the ESAs’ 116 quality checks been run on a representative contract sample?
- Are national submission deadlines relevant to each country of operation known and tracked in a shared calendar?
- Is a data governance function formally involved in the program, alongside legal and IT?
- Is a continuous update process triggered automatically at every new contract or termination?
FAQ
Does DORA apply to non-financial companies?
Not directly, but ICT providers serving European financial clients can be designated critical and find themselves subject to direct obligations, even without being a regulated financial entity themselves.
Did the 2024 dry-run carry direct regulatory consequences?
No, it was a pedagogical exercise with no attached sanction, but the same checks now apply to real 2026 submissions, where the consequences of failure are no longer symbolic.
How long does it take to build a reliable Register of Information?
Variable depending on how scattered existing systems are, but building a reliable central reference source typically takes several months for a multi-entity group, not a few weeks.
Are DORA and NIS2 related?
Yes, DORA is explicitly treated as the sector-specific law for financial services relative to the more general NIS2 directive, avoiding contradictory dual requirements for financial entities.
Can a DORA-compliant company still fail a future check?
Yes, DORA compliance isn’t a fixed state validated once and for all, it requires continuous updating of the Register of Information as contracts and providers evolve.
Is a dedicated software tool needed to manage the Register of Information?
Not necessarily in the first cycle, rigorous governance with clear definitions and a continuous update process can work on properly structured existing tools, spreadsheets included, provided organizational discipline is genuinely real, backed by named accountability, not just documented on paper as a policy nobody actually follows day to day.
Should a small financial firm worry as much as a large bank?
DORA’s proportionality principle reduces certain requirements for smaller entities, notably on threat-led penetration testing, but the Register of Information is still expected from nearly the entire covered scope, with no significant size-based exemption.
What happens if a provider disputes its criticality classification?
A well-governed program documents the classification methodology clearly enough that disagreements can be resolved by reference to defined, written criteria rather than negotiation between departments with competing incentives, but disputes do arise in practice, particularly with providers reluctant to accept the additional contractual obligations that come with a critical designation, and having a clear escalation path to risk governance resolves this faster and more consistently than leaving it to informal discussion between account managers.
How does DORA interact with existing outsourcing guidelines already in place at many institutions?
Most financial institutions already had outsourcing risk policies before DORA, often derived from earlier EBA or EIOPA guidelines, DORA does not replace these but significantly raises the bar on documentation, granularity, and the breadth of providers covered, meaning existing policies usually need substantial extension rather than wholesale replacement. Institutions that map their existing outsourcing policy against DORA’s specific requirements early tend to find the gap smaller and more manageable than those who assume, without checking, that prior compliance work already covers the new regulation.
Regard d’Expert
Having coordinated compliance audits and structured data dictionaries across multi-country contexts, I recognize in this 93.5% failure rate a pattern I consistently observe on this type of regulatory program: the difficulty is almost never understanding the regulatory text itself, it’s the absence of upstream data governance capable of producing reliable, consistent, auditable data across an entire group, an organizational challenge far more than a purely technical or legal one, requiring real coordination between legal, procurement, IT, and risk management functions. That coordination challenge, more than any single technical gap, is what separates the small minority of firms that passed the 2024 dry-run from the vast majority that did not.
Written by Steeve Vignissy, Senior Digital Transformation Consultant at Notoriti, with experience coordinating cybersecurity and compliance programs across multi-country financial and retail contexts, including audit and governance committee work.
👉 Contact Notoriti to audit your DORA Register of Information before the next deadline.
Références
- Orbiq, DORA Compliance Guide 2026: Requirements & Deadlines, March 2026
- Mitratech, What Is DORA? What Financial Institutions Need to Know in 2026, June 2026
- IBM, What Is the Digital Operational Resilience Act (DORA)?, June 2026
- PwC Legal, cited by IBM, analysis of the DORA 2026 maturity phase
