ComplianceDORA Six-Month Review — Financial Institutions Report 847 Major ICT Incidents as Operational Resilience Testing Reveals Third-Party Concentration Risk
Six months after the Digital Operational Resilience Act went into effect across EU financial institutions, supervisory authorities report 847 major ICT incidents classified under Article 19 reporting obligations, with cloud-service outages, cyber-attacks, and software-deployment failures representing 76% of incidents. More significantly, mandated operational-resilience testing under Chapter IV has revealed severe third-party concentration risk: 83% of tested financial institutions rely on fewer than five critical ICT service providers, and 47% have single points of failure where a single vendor outage would disrupt critical business functions. The findings validate DORA's premise that financial-sector digital resilience requires systematic third-party risk management and operational continuity planning beyond traditional business continuity frameworks.
Editorially reviewed for factual accuracy
DORA's first six months have transformed ICT risk management from a compliance checkbox to a supervisory priority. The incident-reporting requirements have created unprecedented visibility into the frequency and severity of technology failures affecting financial services, while resilience-testing obligations have exposed dependencies that institutions previously underestimated or misunderstood. The third-party concentration findings are particularly concerning: financial institutions have outsourced critical functions to cloud providers, payment processors, and core-banking vendors without maintaining the operational independence that DORA requires. Addressing the concentration risk will require multi-year efforts to diversify providers, develop exit strategies, and build internal capabilities for critical functions currently outsourced.
Major ICT incident reporting and supervisory response
Article 19 of DORA requires financial institutions to report major ICT-related incidents to their competent authority within strict timelines: initial notification within 4 hours of detection, intermediate report within 72 hours with impact assessment, and final report providing root-cause analysis and remediation measures. The 847 major incidents reported in the first six months represent incidents meeting the classification thresholds in Article 18: incidents causing significant operational or financial impact, affecting a large number of clients, or having potential systemic implications.
Cloud-service outages accounted for 287 incidents (34%), making cloud resilience the single largest incident category. The incidents include regional availability-zone failures affecting AWS, Azure, and Google Cloud customers; network-routing errors causing cross-region connectivity loss; and API rate-limiting failures during peak-load events. The incidents demonstrate that cloud-provider SLA commitments of 99.9% or 99.99% availability translate to multiple hours of downtime annually and that financial institutions relying on cloud services without multi-cloud or hybrid-cloud failover face unacceptable operational-continuity risk.
Cyber-attacks represented 218 incidents (26%), with DDoS attacks, ransomware, and business-email-compromise attempts dominating the category. The incidents reveal that despite significant cybersecurity investment, financial institutions remain attractive and vulnerable targets. Notably, several incidents involved attacks on third-party service providers that cascaded to financial institutions — validating DORA's focus on third-party cyber resilience as a systemic risk.
Software-deployment failures caused 142 incidents (17%), including failed software updates that disrupted core banking systems, database-migration errors causing data-corruption events, and configuration-change errors that disabled critical transaction-processing functions. The incidents highlight operational-change-management weaknesses: institutions are deploying software changes without sufficient testing, rollback procedures, or impact analysis, exposing customers to service disruptions that should be preventable.
Supervisory authorities have issued formal findings to 34 institutions based on incident-reporting analysis, citing inadequate incident-response procedures, insufficient root-cause analysis, and delayed remediation. The findings signal that regulators are using incident reports as a supervisory tool rather than simply as a data-collection mechanism, with enforcement actions likely for institutions demonstrating persistent operational-resilience weaknesses.
Operational resilience testing and third-party dependency mapping
Chapter IV of DORA requires financial institutions to conduct advanced testing of ICT systems, including threat-led penetration testing for significant institutions and scenario-based resilience testing for all institutions. The resilience testing must assess the institution's ability to continue critical business functions under adverse scenarios including cyberattacks, third-party failures, and multiple simultaneous incidents. The testing conducted in the first six months has revealed dependency structures that institutions themselves did not fully understand.
The most significant finding is third-party concentration risk. DORA requires institutions to identify and document dependencies on critical ICT third-party service providers under Article 28. The dependency-mapping exercises have revealed that 83% of institutions rely on fewer than five providers for functions classified as critical — including payment processing, customer authentication, regulatory reporting, and transaction clearing. More concerning, 47% of institutions have identified single points of failure where a single vendor's service disruption would prevent the institution from providing critical services to customers or meeting regulatory obligations.
Cloud-provider concentration is particularly acute. Among institutions using public cloud services, 68% use a single cloud provider for production workloads, and 89% of those using a single provider have not implemented automated failover to an alternative provider or on-premises infrastructure. The absence of multi-cloud architecture or hybrid-cloud failover means that institutions are operationally dependent on the continuous availability of a single vendor's services — a dependency that conflicts with DORA's requirement that institutions be able to exit from or replace third-party services without unacceptable disruption.
Payment-processing dependencies create systemic risk. The testing revealed that European payment-card processing is concentrated among three major vendors, with 76% of tested institutions using one of these vendors for card-authorization services. A disruption affecting any of the three vendors would simultaneously impact hundreds of financial institutions and millions of customers. The concentration has emerged organically as institutions outsource non-differentiated functions to achieve economies of scale, but the systemic-risk implications were not apparent until DORA's dependency-mapping requirements forced thorough analysis.
Legacy-system dependencies persist despite digital-transformation initiatives. Resilience testing revealed that 42% of institutions depend on core-banking systems that are more than 15 years old, operated by vendors that have been acquired or merged multiple times, with diminishing technical support and limited integration capabilities. The legacy dependencies create operational risk — the systems are fragile and difficult to update — and strategic risk — the institutions lack viable migration paths away from the legacy platforms without accepting multi-year disruption to critical functions.
Exit strategies and contractual remediation
Article 30 of DORA requires financial institutions to maintain exit strategies for contracts with critical ICT third-party providers. The exit strategy must enable the institution to terminate the contract and transition to an alternative provider or in-house solution without unacceptable disruption to critical business functions. The exit-strategy requirement has proven challenging to implement: institutions have contractual arrangements with third-party providers that lack exit-enabling terms, and the institutions lack the technical capabilities or alternative providers needed to execute an exit.
Supervisory authorities have identified exit-strategy deficiencies in 61% of reviewed contracts with critical providers. Common deficiencies include contractual terms that do not guarantee data portability in machine-readable formats, absence of contractual commitments for transition assistance from the provider, lack of escrow arrangements for source code or configuration data, and exit fees or notice periods that would make rapid exit economically or operationally infeasible. Institutions are now engaged in contract renegotiation with critical providers to incorporate DORA-compliant exit terms, but providers with significant market power have limited incentive to agree to terms that facilitate customer exit.
The exit-strategy challenges are most acute for cloud services and SaaS applications. Cloud providers offer proprietary APIs, data-storage formats, and integration architectures that create lock-in: migrating from one cloud provider to another requires application refactoring, data transformation, and infrastructure reconfiguration that can take months or years. SaaS vendors similarly use proprietary data models and integration protocols that make switching costly. Institutions are responding by adopting cloud-agnostic architectures using Kubernetes, container orchestration, and API gateways that reduce dependence on provider-specific services, but the architectural transformation is multi-year effort requiring significant engineering investment.
Some institutions are developing internal capabilities for critical functions currently outsourced, creating operational independence that enables credible exit threats. For example, institutions are building in-house payment-processing capabilities as a backup to third-party processors, maintaining the third-party relationship for operational efficiency but retaining the ability to internalize the function if the third-party relationship becomes untenable. The dual-capability approach addresses DORA's exit-strategy requirement but increases operational cost and complexity.
Critical third-party provider oversight framework
Article 31 of DORA establishes an Oversight Framework for critical ICT third-party service providers, enabling supervisory authorities to conduct direct oversight of providers serving multiple financial institutions. The framework addresses the structural challenge that financial institutions have limited use over systemically important providers: supervisors can now examine providers directly and impose requirements on providers rather than relying solely on contractual arrangements between institutions and providers.
The European Supervisory Authorities (ESAs) designated 12 ICT service providers as critical in the first designation round, including the three major cloud providers (AWS, Microsoft Azure, Google Cloud), two payment processors (Worldline, Nexi), three core-banking software vendors (FIS, Temenos, Finastra), and four specialized service providers (cybersecurity, communication, data centers). The designation subjects these providers to direct supervisory oversight including on-site inspections, audit rights, and enforceable recommendations.
The designated providers have responded with mixed cooperation. Cloud providers, already subject to regulatory oversight in multiple jurisdictions, have established dedicated regulatory-affairs teams and are engaging constructively with supervisors. Smaller specialized providers, facing regulatory oversight for the first time, have expressed concerns about the compliance burden and the potential disclosure of competitive information to regulators who also oversee their competitors. The ESAs have provided guidance clarifying that oversight will focus on operational resilience, security controls, and incident-response capabilities rather than commercial terms or pricing, but provider concerns about regulatory overreach persist.
Operational resilience program maturity and governance
DORA Article 6 requires financial institutions to establish an ICT risk-management framework covering risk identification, protection, detection, response, recovery, and learning. The framework must be thorough, documented, and regularly tested. The six-month review reveals significant maturity variation: large international institutions generally have sophisticated operational-resilience programs predating DORA, while smaller institutions are building programs from foundational elements.
Governance structures are evolving to integrate ICT resilience into board oversight. DORA Article 5 requires management bodies to approve and periodically review the ICT risk-management framework, and to receive regular reports on ICT risk exposure and incidents. Institutions are establishing board-level technology-risk committees or expanding existing risk committees' mandates to include ICT resilience as a standing agenda item. The governance formalization elevates ICT risk from an operational concern managed by IT departments to a strategic risk requiring board-level attention.
Resilience metrics and monitoring are maturing. Institutions are defining key risk indicators for ICT resilience including system availability, incident frequency and severity, recovery-time objectives, and third-party performance. The metrics are integrated into enterprise-risk dashboards and are reviewed in regular risk-management committee meetings. The metrics-driven approach enables institutions to track resilience improvements over time and to identify emerging risks before they escalate to major incidents.
Coordination with existing frameworks including ISO 22301 (business continuity), NIST Cybersecurity Framework, and ISO 27001 (information security) has been necessary to avoid duplicative requirements. Institutions are mapping DORA requirements to existing control frameworks and are treating DORA as an integrative framework that consolidates ICT risk management, cyber resilience, and third-party risk into a single coherent program rather than a separate compliance overlay.
Recommended actions for financial institutions and ICT risk leaders
Conduct a thorough third-party dependency assessment that identifies all critical ICT service providers and maps the specific business functions that depend on each provider. Classify dependencies by criticality, identifying single points of failure and concentration risks where multiple critical functions depend on a single provider.
Develop exit strategies for relationships with critical providers, starting with the highest-risk dependencies. Negotiate contract amendments to incorporate data-portability guarantees, transition-assistance commitments, and reasonable exit terms. For relationships where contract amendments are not achievable, develop alternative-provider relationships or in-house capabilities that reduce dependence on the incumbent provider.
Implement multi-cloud or hybrid-cloud architecture for critical workloads currently deployed on a single cloud provider. The architecture should enable automated failover to an alternative provider or on-premises infrastructure if the primary provider experiences a prolonged outage. Test the failover procedures regularly to verify that they function as designed.
Enhance incident-response procedures to satisfy DORA's reporting timelines and content requirements. Ensure that incident-detection systems can identify major incidents within hours of occurrence, that incident-classification procedures apply Article 18 thresholds consistently, and that incident reports include the root-cause analysis and remediation commitments that supervisors expect.
Establish board-level ICT resilience oversight that provides the management body with regular visibility into ICT risk exposure, major incidents, resilience-testing results, and third-party dependencies. The oversight should enable the board to assess whether the institution's ICT resilience is commensurate with its risk profile and business model.
What to expect
DORA's six-month record demonstrates that the regulation is achieving its objective: financial institutions are investing in operational resilience, supervisors have unprecedented visibility into ICT incidents and dependencies, and critical third-party providers are subject to regulatory oversight. The incident data and resilience-testing findings validate DORA's premise that financial-sector digital resilience requires systematic risk management and that third-party concentration risk poses systemic threats. The concentration findings will drive multi-year efforts to diversify providers, develop exit capabilities, and build resilience into critical dependencies. Institutions that treat DORA as a compliance exercise rather than a strategic operational-resilience program will face increasing supervisory scrutiny and will remain vulnerable to the ICT disruptions that the regulation seeks to prevent.
Continue in the Compliance pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Third-Party Risk Oversight Playbook
Operationalize OCC, Federal Reserve, EBA, and MAS outsourcing expectations with lifecycle controls, continuous monitoring, and board reporting.
-
SOX Modernization Control Playbook
Modernize Sarbanes-Oxley (SOX) compliance by aligning PCAOB AS 2201, SEC management guidance, and COSO 2013 controls with data-driven testing, automation, and board reporting.
-
ESG Assurance Operating Guide
Deploy credible ESG assurance across CSRD, SEC climate disclosure, and ISSA 5000 requirements with regulator-aligned controls, data governance, and audit-ready evidence.
Documentation
- Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — eur-lex.europa.eu
- EBA DORA Implementation Report — eba.europa.eu
- Financial Sector ICT Incident Analysis Q4 2025 - Q1 2026 — esma.europa.eu
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.