DORA Readiness Gaps: What Supervisors Will Examine First

The Supervisory Clock Is Ticking

DORA — Regulation (EU) 2022/2554 on digital operational resilience for the financial sector — was published in the Official Journal of the European Union on December 27, 2022. Its application date, per Article 64, was January 17, 2025. The regulation comprises 64 articles across 9 chapters, establishing five operational pillars (Chapters II through VI) that collectively define the most comprehensive ICT resilience framework ever imposed on the European financial sector.

Per Recital 3 of DORA, approximately 22,000 financial entities fall within scope. Article 2(1) defines 20 categories of in-scope entities, ranging from credit institutions and investment firms to crypto-asset service providers and crowdfunding service providers. The European Supervisory Authorities (ESAs) published their first batch of Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) consultation papers in June 2023, followed by a second batch in December 2023, with final standards published in the Official Journal by January 2025.

The early supervisory signals are instructive.

The ECB conducted its first cyber resilience stress test in 2024, covering 109 directly supervised banks. According to the ECB's press release of July 26, 2024, the exercise found that while banks generally have incident response and business continuity frameworks in place, recovery capabilities need improvement. The test specifically assessed banks' ability to respond to and recover from a severe but plausible cyber incident — and the results highlighted gaps that map directly to the five areas supervisors will scrutinize under DORA.

Many institutions face significant readiness gaps, as highlighted by these stress test findings. This is not surprising when you understand what auditors are actually looking for and how most institutions are actually managing compliance.

Gap #1: Incomplete ICT Asset Inventories

DORA Article 8 requires a comprehensive identification and classification of all ICT assets supporting business functions. Article 8(1) specifically mandates that financial entities "identify, classify and adequately document all ICT supported business functions, roles and responsibilities," and that this inventory "be updated on a regular basis and at least once a year, as well as upon occurrence of major changes." Auditors will not accept a spreadsheet that was last updated six months ago. They want a living, dependency-mapped inventory that reflects the current state of the technology landscape.

What auditors expect: A complete register of ICT assets (as defined in Art. 3(6)) with ownership, criticality classification derived from business impact analysis (Art. 11), dependency mapping showing upstream and downstream relationships, and lifecycle status tracking. They want to click on a critical business function and see every application, database, infrastructure component, and third-party service that supports it.

What they typically find: ICT asset identification remains one of the most common gaps cited by supervisory authorities. Institutions frequently maintain collections of Excel workbooks across different teams with inconsistent naming conventions, no dependency mapping, stale entries for decommissioned systems, and shadow IT that nobody has catalogued. The asset register may list one number of applications while cloud consoles and procurement systems tell a different story.

The challenge of manual asset management is not just incompleteness. It is the impossibility of maintaining accuracy over time. Every new deployment, every cloud migration, every vendor substitution creates drift between the register and reality. By the time an auditor arrives, the gap between documented state and actual state has widened to the point where the register is more fiction than fact.

Automated asset discovery and dependency mapping tools can close this gap, but only if they feed into a governance platform that enforces ownership, triggers reviews on change events, and maintains the regulatory metadata (criticality, data classification, RTO/RPO) that auditors actually examine. See our analysis of Article 8 requirements for the full scope of asset identification obligations.

Gap #2: Untested Recovery Capabilities

Article 11 requires ICT business continuity plans with defined recovery time and recovery point objectives (RTO/RPO). Article 25 mandates testing programmes proportionate to risk. Together, they create an expectation that recovery capabilities are not just documented but validated through realistic testing — and that the testing produces measurable evidence.

The ECB's 2024 stress test across 109 banks specifically assessed recovery capabilities and found this to be the area requiring the most improvement. This finding is consistent with broader supervisory observations: many institutions have business continuity documentation, but far fewer can demonstrate that their recovery plans have been operationally validated.

What auditors expect: Evidence that recovery plans have been tested against production-realistic scenarios, with measured recovery times compared against stated RTO/RPO targets, documented deviations, and tracked remediation of gaps discovered during testing. Art. 11(6) specifically requires that testing cover "ICT business continuity plans and ICT response and recovery plans" and validate that they "can be effectively implemented."

What they typically find: Business continuity plans that were written years ago and never tested. Or testing evidence that consists of a meeting invitation, an agenda, and a sign-off form with no actual recovery metrics. Or tabletop exercises counted as "testing" when the regulation explicitly requires operational testing of ICT tools and systems.

The fundamental problem is orchestration. A meaningful resilience test involves coordinating across multiple teams, collecting evidence at each step, measuring recovery times, documenting deviations, assigning corrective actions, and tracking remediation to closure. When this entire lifecycle is managed through email threads and shared drives, the evidence trail is fragmented, unverifiable, and incomplete. Auditors do not accept "we tested it, trust us." They want the evidence chain: test plan, execution log, measurements, findings, corrective actions, retest results.

Gap #3: Missing Third-Party Risk Assessment

Pillar IV is the most demanding section of DORA, spanning Articles 28 through 44. It requires not just vendor management but systematic concentration risk analysis (Art. 29), contractual compliance verification (Art. 30), exit strategy documentation for critical arrangements (Art. 30(2)(f)), and a formal register of information (Art. 28(3)) that must be available to competent authorities on request.

What auditors expect: A register of all ICT third-party contractual arrangements with criticality classification, concentration risk analysis (including substitutability assessment per Art. 29), evidence of contractual compliance with DORA-mandated provisions (Art. 30 — audit rights, data location, subcontracting notification, exit clauses), and documented exit strategies for critical arrangements.

What they typically find: A vendor list in procurement with contract values and renewal dates but no criticality classification. No concentration risk analysis whatsoever. Contracts signed before DORA that lack mandatory clauses. Exit strategies that say "migrate to alternative provider" with no specifics on data portability, transition timelines, or resource requirements.

The concentration risk gap is particularly dangerous because it is invisible until you measure it. A bank might have multiple "vendors" for cloud infrastructure and believe its risk is diversified. But if the majority run on the same hyperscaler, the actual concentration is extreme. The CrowdStrike outage of July 19, 2024 — which affected 8.5 million Windows devices according to Microsoft's blog post — demonstrated how a single vendor dependency can cascade across the financial sector in hours. The ION Trading ransomware incident of January 2023, as reported by Reuters and the Financial Times, disrupted derivatives trading for approximately 42 clients and illustrated how third-party ICT failures can propagate through financial markets. These are precisely the systemic risks that DORA's Pillar IV was designed to address, and institutions that have not assessed their specific exposure will face pointed questions from supervisors.

Gap #4: Inadequate Incident Classification and Reporting

Articles 17 through 23 establish harmonized incident classification criteria (Art. 18) and a three-phase reporting framework (Art. 19). The classification thresholds are specific and measurable: number of clients affected, duration, geographic spread, data losses, economic impact. The reporting timelines are strict: initial notification within four hours of classification, intermediate report within 72 hours, final report with root cause analysis within one month.

What auditors expect: An incident management process that correctly classifies incidents against DORA materiality thresholds (Art. 18), triggers regulatory reporting within mandated timelines (Art. 19), and produces post-incident reviews (Art. 13) with root cause analysis that feeds back into the risk management framework.

What they typically find: ITSM-oriented incident processes that track service disruptions but do not assess regulatory materiality. Classification criteria that do not align with DORA thresholds. No structured process for determining whether an incident must be reported to the competent authority. Post-incident reviews that focus on technical fixes without the root cause analysis and lessons learned that DORA requires.

The gap between an ITSM incident and a DORA-reportable incident is not just procedural. It requires real-time impact assessment: how many customers are affected, is data integrity compromised (Art. 3(3)), what is the financial impact, does this breach impact tolerance thresholds? Answering these questions under pressure, within the four-hour initial reporting window specified in Art. 19(4)(a), is nearly impossible without purpose-built tooling that links incidents to affected assets, business services, and customer segments.

Gap #5: No Continuous Assurance Mechanism

This is the gap that auditors are increasingly focused on. DORA does not use the phrase "continuous assurance," but Articles 5 through 16 collectively create an expectation that the ICT risk management framework is not a point-in-time exercise but a living, continuously validated capability. Art. 6(5) requires "continuous" identification of ICT risk sources. Art. 10 mandates ongoing anomaly detection. Art. 13 requires lessons learned to feed back into the framework between assessment cycles.

What auditors expect: Evidence that compliance is maintained between audits. That risk assessments reflect current threats. That control effectiveness is measured, not assumed. That deviations are tracked to closure. That the framework improves based on evidence, not just good intentions.

What they typically find: An annual compliance cycle. Risk assessments updated once a year. Controls tested during audit preparation. No ongoing measurement of control effectiveness. No automatic detection of compliance drift. A gap between the last assessment and the current examination that could be months wide.

This is where the spreadsheet-based compliance model fundamentally breaks down. A spreadsheet cannot continuously monitor whether controls are effective. It cannot alert when a risk assessment becomes stale. It cannot automatically create a deviation when an automated assertion fails. It cannot score compliance posture in real time. See our guide on building continuous compliance culture for practical steps to address this gap.

The Root Cause: Process, Not People

These five gaps share a common root cause. It is not that compliance teams are incompetent or underfunded — though many are under-resourced. The operational burden of manual compliance processes is substantial, though costs vary significantly by institution size and complexity. The core problem is that the tools most institutions use — spreadsheets, email, shared drives, and generic GRC platforms — were not designed for the level of traceability, evidence integrity, and continuous assurance that DORA demands.

DORA is not a checklist regulation. It requires deterministic workflows, immutable evidence chains, cryptographic integrity, real-time scoring, and board-level reporting (Art. 5 makes the management body personally accountable). Spreadsheets deliver none of these.

The institutions that recognize this distinction and invest in purpose-built operational resilience platforms will be better positioned for their first examination. Those that try to stretch their existing tools to meet requirements they were never designed for will face a difficult supervisory conversation.

The institutions that start now will be audit-ready. Those that wait will scramble.