More than a year after the EU Digital Operational Resilience Act became applicable, the banking sector is moving into a harder phase. The policies exist. Management responsibilities have been assigned. The challenge is proving that the controls work when systems, suppliers and recovery processes are under pressure.
QA Financial reported on August 21, 2026 on a study of 23 banks conducted by risk and treasury consultancy Zanders. Almost all participating banks had assigned management responsibility for digital operational resilience and documented a strategy. The results became less consistent when the study looked at how those strategies were communicated, tested and translated into daily risk controls. Only 12 of the 23 banks reported a comprehensive stakeholder communication plan, and fewer than half had a formal ICT risk appetite statement approved by senior management.
This gap between documented control and operational evidence is directly relevant to infrastructure teams. Sensaka's guide to compliance software and infrastructure evidence examines the same problem from the technology layer: governance systems can record requirements, but organizations still need reliable evidence from the assets, configurations and operational systems those controls are meant to govern.
Testing maturity is still uneven
The Zanders study found that regular ICT resilience testing was generally established, but advanced methods were less consistently adopted. QA Financial specifically highlighted limited use of threat led penetration testing among institutions required to perform it. The report also described variation in how issues discovered during testing were escalated and how results were validated.
That matters because a test has little value if its findings do not create an accountable remediation process. A bank needs to know which service was tested, which dependencies were included, what failed, who owns the corrective action and whether the fix was retested. Evidence has to connect the scenario to the outcome.
The European Central Bank has been making a similar point. Its 2026 supervisory priorities emphasize ICT security, third party risk, incident response, change management and preparedness for disruption involving major cloud providers. DORA is therefore becoming less about showing that a testing program exists and more about showing that the program can expose and reduce real service risk.
Recovery plans need to cover complete business services
QA Financial reported that only 16 of the 23 banks said their business continuity and disaster recovery plans comprehensively covered all critical business functions. That is a significant distinction because recovery cannot be demonstrated by restarting a single server or application in isolation.
A critical banking service may depend on identity, networking, databases, middleware, payment systems, customer channels, storage, cloud services and external providers. Any one of those dependencies can prevent the business function from recovering even if the core application is technically online.
This is where operational resilience becomes an infrastructure mapping problem. Teams need to understand which physical and digital components support each critical service, what the acceptable recovery target is and how the service behaves when a dependency fails. Recovery exercises should prove that users can resume the function with correct data and acceptable performance, not merely that individual systems can boot.
Third party risk is becoming a system level problem
The study also found uneven maturity in technology supplier oversight. Most banks had third party risk frameworks, yet fewer than half had robust exit strategies or adequately accounted for geopolitical risks. Concentration and interconnectedness risks were also not consistently incorporated into assessments.
That weakness becomes more important as financial institutions rely on a smaller number of major cloud, SaaS and infrastructure providers. A supplier failure can affect several business services at once. A bank therefore needs to understand not only the risk of an individual vendor, but also how many critical processes depend on the same provider, region, identity platform or network path.
DORA has changed the standard of proof. It is no longer enough to show that the organization has a policy for resilience. The practical question is whether the bank can demonstrate that critical services can withstand disruption, that issues are escalated, that suppliers can participate in recovery and that remediation is verified.
That is a much more demanding test, but it is also a more useful one. A compliance document cannot restore a payment service. Operational evidence can show whether the organization has a realistic chance of doing so.
Originally published on the Sensaka blog.
Top comments (0)