The Digital Operational Resilience Act has applied across the EU since 17 January 20254. For most banks the first year was about compliance plumbing: building the register of information on ICT contracts, rewriting incident classification and repapering supplier agreements. The regime has now produced data of its own, and that data changes how bank leaders should think about resilience.
Three lessons stand out. Operational resilience is mostly about ordinary failures in complex systems, not rare cyber events. Concentration in a few technology providers is now a supervisory matter, not just a procurement one. And AI is adding a new layer of dependency just as supervisors have mapped the old one.
What 3,383 incidents tell us
In June 2026 the European Supervisory Authorities published their first report on major ICT-related incidents under DORA. Financial entities reported 3,383 major incidents in 2025, an average of 0.18 per entity. More than 60% occurred in the credit sector, which averaged 0.57 major incidents per entity, and a further 16% in payments1. By type, 51% were system failures, 27% external events, 18% payment-related and 10% cybersecurity-related1.
The root causes are even more telling. Half of major incidents were caused by a system failure or malfunction, 32% by external events, 19% by process failures and 12% by human error. Almost a third, 29%, originated from a failure attributable to a third-party provider1. Around a third had a cross-border impact. On the positive side, two-thirds of incidents caused no or only minor disruption to clients and transactions, which suggests detection and response are working1.
Most major incidents start with systems, not attackers
High-level root causes of major ICT-related incidents, EU financial sector, 2025, % of incidents (%)
Note: Entities can select more than one root cause, so shares do not sum to 100. System failure is reported as 'half'. Third-party share is a separate measure of origin.
The cost of failure is also rising. The EBA reports that losses from newly reported ICT risk events at EU/EEA banks rose to about €0.73 billion in 2025 from about €0.65 billion in 2024, even as the number of new events fell sharply. Banks name dependencies on ICT service providers as their biggest challenge related to non-EU/EEA providers, cited by around 80%9.
Concentration, now supervised directly
DORA's most novel feature is direct oversight of the technology providers themselves. The registers of information that banks struggled to build fed straight into it. In the ESAs' 2024 dry run, only 6.5% of registers from almost 1,000 financial entities passed all data quality checks4. By November 2025 the data were good enough for the ESAs to designate 19 critical ICT third-party providers. The list includes hyperscale cloud providers, data centre operators, network providers and financial-services technology firms23. The ESAs can issue recommendations and, as a last resort, require financial entities to suspend or terminate the relevant services. The list is updated each year3.
The UK has followed. HM Treasury made its first designations under the critical third parties regime on 10 July 2026, naming the EMEA or UK entities of four major cloud providers. Joint oversight by the Bank of England, PRA and FCA began on 13 July 20265. Separately, the UK's operational resilience rules required firms to be able to stay within impact tolerances for their important business services by 31 March 2025. That is now an ongoing obligation with annual mapping, testing and self-assessment7. New PRA and FCA rules on operational incident and third-party reporting, published in March 2026, apply from 18 March 2027 and require a register of material third-party arrangements6.
AI makes the dependency map deeper
AI adds another layer of dependency. In the Bank of England and FCA's 2024 survey, a third of AI use cases were third-party implementations, up from 17% in 2022. The top three providers accounted for 73% of reported cloud providers, 44% of model providers and 33% of data providers8. The EBA is explicit that DORA's requirements on third-party oversight, ICT risk management, incident reporting and resilience testing apply to banks' use of AI systems9.
For banks, this means the questions asked of a cloud provider now apply to a model provider too. What happens to a customer-facing agent if the model endpoint is unavailable for four hours? Can a critical workflow fall back to a rules-based path or a human queue? Is there a tested route to a second model if the first is withdrawn or changes behaviour after an update? Few AI business cases we review answer these questions, and under DORA they are no longer optional.
AI concentrates on a handful of providers
Share of reported providers accounted for by the top three, AI use cases in UK financial services, 2024, % (%)
From compliance to resilience engineering
- Treat the register as a live dependency graph. Link contracts to services, systems, data flows and important business services so that the register answers ‘what breaks if this provider fails?’
- Invest where incidents start. With half of major incidents rooted in system failures, change management, observability and release discipline do more for resilience than another security tool1.
- Test exits and substitutes. For each critical provider, including AI model providers, document and rehearse a degraded mode and an exit path.
- Automate incident classification. DORA and the forthcoming UK regime reward fast, consistent classification and reporting, and both depend on clean data about services, clients and transactions affected.
The regimes will keep tightening. The ESAs' list of critical providers is refreshed annually, the UK's incident and third-party reporting rules arrive in March 2027, and supervisors now have a year of comparable incident data to benchmark banks against136. Banks that treat the next 12 months as a chance to engineer resilience into their data and operating model, rather than to polish submissions, will find each new requirement cheaper to meet.