The Digital Operational Resilience Act came into force on 17 January 2025, yet six months into enforcement, EU banks are discovering that their compliance posture covers only the visible surface of what DORA actually demands. The critical gap is not in written policy—it is in the real-time visibility of ICT dependencies that regulators are now actively stress-testing, and most banks lack the operational tooling to answer the most basic question: where does your firm’s digital infrastructure actually fail?
DORA compliance gaps have shifted from a theoretical risk to a live operational problem. The European Banking Authority, alongside national regulators like the ECB’s SSM and individual financial conduct authorities, has moved from guidance into active examination. Banks that treated DORA as a document-filing exercise rather than a capability transformation are now exposed. This article maps the specific, avoidable failures still visible in bank compliance programmes and explains why generic framework implementations are failing the regulatory test.
What Is DORA Compliance and Why Does It Matter Right Now?
The Digital Operational Resilience Act is the EU’s binding regulation on ICT risk management, third-party service dependency, incident reporting, and testing of digital infrastructure resilience. It applied to all credit institutions, payment service providers, and digital finance firms from 17 January 2025. DORA compliance gaps emerge when banks have the formal structures but lack the concrete operational capability to map, monitor, and respond to ICT failures in real time. The regulation requires banks to identify material ICT service providers, measure their concentration risk, conduct annual incident scenario testing, and report outages to regulators within specified timeframes. Most critically, DORA demands that banks understand and document the failure modes of their own infrastructure and the single points of dependency that could cascade into systemic outages.
The Three Biggest DORA Compliance Gaps Most Banks Still Have Not Closed
1. Absence of True End-to-End ICT Dependency Mapping
The first and most pervasive gap is the lack of genuine visibility into the full dependency chain of critical digital services. Many banks have documented their “material ICT service providers”—the major cloud vendors, payment networks, and core banking platforms—but have failed to map the transitive dependencies: the API providers that support those vendors, the DNS resolution services, the disaster recovery facilities that are themselves dependent on third-party connectivity.
A bank that relies on a European cloud provider for real-time settlement data but has not documented that the provider’s data centre failover is routed through a single telecommunications carrier, or that the provider’s encryption key management is outsourced to a US-based subsidiary, has not actually closed the dependency map. DORA Article 15 requires institutions to “identify and assess the criticality of their ICT services”, and this cannot be done without understanding the full supply chain. In our observation, banks that have passed this audit did so by building software-defined service discovery tools that continuously scan their infrastructure logs and API call graphs to identify undocumented dependencies—a capability that most banks still lack.
The operational consequence is that when regulators ask, “If this provider fails, which customer-facing service actually goes dark?”, many banks cannot answer with precision. They guess, or they provide diagrams that are 18 months out of date because no automated process is refreshing them.
2. Incident Reporting Thresholds That Do Not Match Regulatory Intent
DORA Article 19 requires institutions to report “major incidents” to their national competent authority within 15 business days. The regulation defines a major incident as one that has a “significant impact” on the institution’s operations or on the financial markets. What constitutes “significant” is left deliberately vague in the text, and this ambiguity has created a dangerous compliance gap.
Many banks have operationalised DORA incident reporting by setting narrow technical thresholds: “report if availability falls below 95% for more than 30 minutes” or “report if customer data is accessed by unauthorised users for more than 10 records.” These rules are easy to code into incident management systems. But they do not match the regulatory intent, which is concerned with financial impact and market confidence, not technical uptime percentages.
The firms getting this right are those that have built incident classification systems that ask three questions in sequence: (1) How many customer transactions were actually failed or delayed by the incident? (2) What was the revenue or settlement impact over the duration? (3) Did the incident affect a critical service within the meaning of the EBA’s Guidelines on ICT Security? Only if the answer to question 1 or 2 meets a financial threshold—typically €1 million of transaction value or settlement delays exceeding 2 hours—does the incident enter the DORA reporting queue. A purely technical incident that did not touch customer transactions does not get reported, even if it was serious operationally.
The gap persists because integrating incident management systems with transaction ledgers and settlement systems is technically complex and requires real-time data streaming that many banks have not invested in. The result is over-reporting of technical noise and under-reporting of actual business impact, which erodes regulator trust and creates false compliance signals.
3. Testing Scenarios That Do Not Stress the Actual Failure Modes That Matter
DORA Article 18 requires institutions to test their digital resilience through “advanced testing methodologies” including “threat-led penetration testing” and “scenario-based testing”. Many banks have discharged this obligation by running annual penetration tests against their web application firewalls and conducting desk-top exercises where teams describe what they would do if a cloud provider went offline.
The specific gap is this: most testing does not replicate the kind of failures that actually cause customer harm. Banks test “What if AWS fails?” but they do not test “What if the API latency between our transaction processing system and our funds transfer service increases by 500 milliseconds?”—a realistic scenario that degrades transaction throughput without a clean on/off failure. They do not test “What if our identity provider is reachable but returns 10% false rejections?”—a scenario that affects real customer login attempts. They do not test the correlated failure of backup systems that happens when a data centre becomes overheated and multiple vendor systems in that facility reach thermal throttling limits.
The uncomfortable truth is that the testing frameworks most banks use (industry-standard chaos engineering platforms) are designed to break systems intentionally and measure recovery time. They are not designed to create the kind of partial, cascading, and asymmetric failures that regulators are now stress-testing through their own ICT risk examinations. A bank that has never tested what happens when a core banking system can process transactions but cannot update customer ledger balances has a significant DORA compliance gap that no passing penetration test report can hide.
Why Standard DORA Compliance Frameworks Are Insufficient
Most banks have implemented DORA compliance through a standardised approach: map the legal requirements to a control framework (often ISO 27001 or the ECB’s TIBER-EU standard), build a policy repository, assign ownership, and conduct annual audits. This is sufficient for the “tone at the top” and governance elements of DORA. It is entirely insufficient for the operational resilience elements.
The difference is this: governance and policy frameworks are static and periodic. They are audited once a year. Operational resilience is dynamic and continuous. It requires real-time visibility into infrastructure state, automated dependency discovery, live incident severity classification, and testing methodologies that evolve as the attack surface changes.
A bank can have a board-approved DORA policy, a designated Chief Information Security Officer, and a three-page incident response plan and still fail a regulatory stress test because the bank cannot demonstrate that it actually has the capability to detect and respond to a partial cloud provider outage in real time. The policy exists; the capability does not.
The regulatory examination findings support this. Institutions that have reported examination feedback from ECB SSM teams or national competent authorities have received common findings: “The institution’s ICT risk assessment does not identify all material service providers,” “The institution’s incident classification process does not align with materiality guidance,” and “The institution’s testing programme does not include scenario-based testing of critical services under degraded conditions.” These are not policy failures; they are capability gaps.
The Role of Third-Party ICT Service Providers and Concentration Risk
DORA’s concentration risk framework (Articles 28–30) requires institutions to identify which service providers are so critical that their failure would prevent the institution from continuing to carry out essential functions. Banks must set contractual limits on the proportion of critical infrastructure that can be concentrated in a single provider, and they must have termination and exit arrangements documented.
The gap here is not conceptual but operational. Many banks have identified their concentration risks—typically discovering that cloud compute is concentrated in one or two providers, that DNS resolution is concentrated, that payment gateway access is concentrated—but have not implemented the technical and contractual mechanisms to actually reduce that concentration.
The challenge is genuine: if a bank’s entire trading book is in one cloud environment because that environment has the lowest latency connectivity to the relevant trading venues, switching to a second cloud provider necessarily increases latency and therefore operational risk. The bank has not solved the concentration risk; it has merely documented it and asked for regulatory forbearance.
Regulators are not granting forbearance. Instead, they are requiring banks to implement controls that accept some operational performance loss in exchange for reduced concentration. This might mean routing 5% of trading traffic through a secondary cloud provider, even if that introduces 2-3 milliseconds of additional latency. It means testing that the secondary path actually works under real load at least quarterly. Most banks have not implemented these controls because the performance cost is visible (measurable latency increase) while the benefit (reduced systemic risk) is invisible and theoretical.
Incident Response and the 15-Day Reporting Clock
One of DORA’s most operationally demanding requirements is Article 19: the obligation to report major incidents to the competent authority within 15 business days of detection. This is substantially faster than many banks’ existing incident response processes, particularly for incidents that require forensic investigation or involve third parties.
A typical bank’s incident response timeline looks like this: incident detected (T+0), incident classified (T+2 hours), incident contained (T+4 hours), root cause analysis initiated (T+8 hours), root cause established (T+3–7 days), remediation implemented (T+5–15 days), post-incident review completed (T+20 days), regulatory report filed (T+30 days). The DORA requirement compresses the reporting timeline to 15 business days—which is 21 calendar days—without compressing the investigation timeline.
The specific gap is process and resource. Banks need to establish a parallel reporting process that can file a preliminary incident report to the regulator at T+15 days based on available information, even if root cause analysis is incomplete. The report must include what happened, what the impact was, what immediate containment actions were taken, and what further investigation is underway. This requires segregating the investigation process from the reporting process, a discipline that most bank security teams have not developed.
Additionally, banks need to establish pre-approved templates and decision trees so that incident severity classification and materiality assessment can be done in hours, not days. A bank that requires three layers of management approval before filing a regulatory incident report will miss the 15-day deadline. The firms getting this right have delegated the decision-making authority to a real-time incident severity officer who can classify and approve reporting without escalation.
Third-Party Audit and Assurance Under DORA
DORA Article 26 permits institutions to rely on assurance reports from ICT service providers’ external auditors (SOC 2 Type II reports, etc.) to partially satisfy the institution’s own oversight obligations. However, DORA also requires institutions to verify that the assurance reports actually cover the relevant risks and to conduct their own assessment of the service provider’s ICT risk profile.
The compliance gap is the false assumption that a current SOC 2 Type II report is equivalent to DORA compliance assurance. SOC 2 audits typically cover availability, security, and confidentiality controls, but they do not specifically address the DORA criteria: the provider’s capacity to absorb potential losses, the provider’s incident notification timeline, the provider’s testing methodologies, or the provider’s own concentration risks. A bank that accepts a SOC 2 report as discharge of its DORA obligation without reviewing it against the DORA-specific criteria has not actually closed the compliance gap.
Additionally, SOC 2 audits are typically annual. DORA implicitly requires more frequent assurance that ICT risks have not degraded. A bank using a 12-month-old SOC 2 report to justify reliance on a service provider for real-time payment processing has a visibility gap of up to one year.
The Algoy Perspective
The most critical gap that compliance frameworks and regulatory guidance do not address is the absence of a unified, real-time operating model for ICT risk. Most banks still have siloed ICT risk capabilities: security teams manage vulnerability and access controls, operations teams manage availability and disaster recovery, enterprise architecture teams manage dependencies, and business continuity teams manage scenario testing. No single function has visibility into whether the bank’s actual ICT operations conform to its DORA obligations at any given moment.
The strategic implication is this: DORA compliance cannot be achieved through policies and annual audits alone. It requires the operational equivalent of a real-time risk dashboard that shows whether each critical service has redundancy, whether all material service providers are within approved concentration limits, whether all testing is current, and whether the institution can actually survive the failure modes it claims to have tested. Banks that are still operating DORA compliance as a compliance function (checklist-driven, policy-focused, once-annual) will continue to fail regulatory examinations. Banks that are operationalising DORA as a continuous operational capability (monitoring-driven, scenario-based, real-time) are moving through examination cycles with minimal findings.
The uncomfortable fact is that most large EU banks still lack this operational integration. The compliance function knows about DORA requirements; the technology function knows about ICT risks; the business continuity function knows about testing. But no single team owns the proof that the institution is actually resilient according to DORA’s criteria. This is the gap that will generate the next wave of regulatory enforcement findings.
Frequently Asked Questions
What is the difference between DORA’s “major incident” and my bank’s existing incident severity definitions?
DORA defines a major incident by financial impact and system materiality, not by technical severity. A partial outage affecting 2% of transactions is likely material under DORA even if your incident management system classifies it as “high severity” rather than “critical”. Map your existing severity levels to DORA’s materiality criteria (significant impact on operations or markets) rather than to your technical definitions, and you will align your reporting process with regulatory intent.
Does a SOC 2 Type II report from a cloud provider fully satisfy DORA’s third-party oversight requirements?
No. SOC 2 reports are useful but not sufficient. DORA requires you to independently verify that the provider’s controls cover the specific risks material to your institution, that the provider meets your contractual service levels, and that concentration risk is managed. You must review the SOC 2 report against DORA-specific criteria and conduct your own periodic risk assessment of the provider, typically at least annually.
Our bank has passed ISO 27001 certification. Does that mean we are DORA compliant?
ISO 27001 addresses information security controls and governance, which overlap with DORA’s security requirements. However, DORA also mandates specific obligations around ICT dependency mapping, concentration risk limits, incident reporting timelines, and scenario-based testing that ISO 27001 does not cover. Certification against one does not substitute for compliance with the other; they are complementary but not equivalent frameworks.
What should we prioritise if our bank has not yet closed all DORA compliance gaps?
Prioritise end-to-end dependency mapping of critical services first (which informs all other controls), then align your incident classification process with DORA’s materiality definition and implement the parallel reporting workflow to meet the 15-day deadline. These three operational capabilities generate the most examination findings when they are absent. Generic policy improvements are less urgent than fixing the operational visibility and incident response process gaps.
