More than a year after the EU’s Digital Operational Resilience Act became applicable, financial institutions are moving from regulatory preparation to the more difficult task of proving that resilience controls work in practice.
Governance structures, policies and documented strategies may satisfy DORA’s foundations, but they do not necessarily show that a bank can withstand, respond to and recover from a serious technology disruption.
For resilience teams, the real test lies in how effectively those requirements have been embedded across ICT testing, incident escalation, disaster recovery and third-party oversight. It is the difference between demonstrating that a control exists and producing credible evidence that it will protect critical banking services under pressure.
A study of 23 banks suggests that this transition remains incomplete. Almost all the institutions surveyed had assigned management responsibility for digital operational resilience and documented a strategy, but the findings were considerably less consistent when researchers examined how those strategies were communicated, tested and translated into everyday risk controls.
Only 12 of the 23 banks reported having a comprehensive stakeholder-communication plan, leaving 11 without one.
Fewer than half had a formal ICT risk-appetite statement approved by senior management, raising questions about whether technology risks are being measured against clearly defined organisational tolerance levels.
The findings come after DORA became applicable across the European Union on 17 January 2025. The legislation requires financial institutions to strengthen ICT risk management, resilience testing, incident reporting and oversight of third-party technology providers.
For QA, testing and resilience teams, the study highlights a central challenge in the post-DORA environment: documenting a strategy is not the same as demonstrating that systems, people and recovery processes will perform effectively during a real disruption.
“The survey indicates strong compliance with foundational DORA requirements,” stressed Martin Ruf, partner at risk and treasury consultancy Zanders, which conducted the study.
However, the results suggest that banks have made more progress in establishing high-level governance than in embedding resilience consistently across their operations.
Advanced testing remains limited
Most of the 23 banks had formal processes for identifying and documenting ICT risks. Only around half, however, systematically managed risks associated with emerging and innovative technologies.
Concentration and interconnectedness risks also appeared unevenly addressed. Just 12 banks incorporated these considerations into their risk assessments, despite DORA’s emphasis on understanding dependencies across systems, services and technology suppliers.
Those weaknesses are particularly relevant as banks expand their use of cloud services, AI tools and interconnected third-party platforms. A resilience assessment that looks at individual applications in isolation may fail to expose how disruption can spread across shared infrastructure, data flows and external providers.
The clearest QA concern emerged in ICT resilience testing. Regular testing was generally established, but the adoption of more advanced methodologies remained limited among institutions required to use them.
“While regular ICT resilience testing is generally practiced, the adoption of advanced testing methodologies, such as threat-led penetration testing, is limited among the institutes that are required to perform these tests,” Ruf said.
“The adoption of advanced testing methodologies, such as threat-led penetration testing, is limited.”
– Martin Ruf
The study also identified inconsistencies in how banks escalate problems discovered during testing and validate the resulting evidence.
“Variability also exists in the processes for escalating issues and validating results, signifying areas requiring further attention,” Ruf added.
That gap matters because DORA is not satisfied by the existence of a testing programme alone. Banks need repeatable processes for recording findings, assigning ownership, remediating weaknesses and confirming that corrective work has been effective.
For software-testing leaders, this increases the importance of traceability between test scenarios, defects, remediation actions and retesting. It also brings resilience testing closer to operational-risk governance, since unresolved findings may affect critical services far beyond the application originally tested.
Recovery plans lack coverage
Business continuity and disaster recovery presented another uneven picture. Although most participating banks reported having plans in place, only 16 said those plans comprehensively covered all critical business functions.
The study found that the testing and updating of business continuity and disaster-recovery plans had also remained largely stagnant. That could limit a bank’s ability to recover quickly if an outage affects systems or processes omitted from its existing scenarios.
The finding underlines the need to test complete business services rather than isolated technical components. A customer journey may depend on core banking, payments, identity services, customer channels, data platforms and external suppliers, meaning the failure of any one component can undermine the service as a whole.
Recovery testing must therefore establish not only whether technology can be restarted, but whether critical business functions can resume within acceptable timeframes and with accurate data.
The survey’s incident-reporting findings were more positive, with banks generally maintaining established documentation and reporting processes. Training was less uniform, however, creating a risk that teams may apply those procedures inconsistently during a live incident.
Under DORA, weaknesses in training and escalation can quickly become regulatory issues. Institutions must classify and report major ICT incidents within defined timelines, making clear responsibilities, rehearsed procedures and reliable information flows essential.
Third-party controls under pressure
The 23 banks also showed varying levels of maturity in their oversight of technology suppliers. Most maintained third-party-risk frameworks, but fewer than half had robust exit strategies or adequately accounted for geopolitical risks.
Contractual safeguards and incident-management arrangements were another area of concern. DORA makes financial institutions responsible for managing ICT risk even when important systems or services are provided by external companies.
For testing teams, that means resilience exercises increasingly need to incorporate vendors, cloud providers and other technology partners.
Banks must understand whether suppliers can provide relevant test evidence, participate in recovery exercises and support an orderly exit if a service becomes unavailable or the relationship ends.
The issue is particularly significant where multiple business services depend on the same provider. Without adequate concentration-risk analysis, banks may underestimate the scale of disruption that a single third-party failure could cause.
Moving beyond the checklist
The strongest area identified by the study was IT security. All 23 respondents had documented ICT security policies, while most reported having suitable controls in place.
Even there, however, Ruf’s analysis pointed to a need for continuing employee training and periodic evaluation. Documented policies offer limited protection if staff do not understand them or if controls are not reassessed as systems and threats change.
The overall findings indicate that banks have largely built the formal foundations of DORA compliance. The next phase will be harder: embedding those requirements in testing, delivery governance, supplier management, incident response and recovery planning.
“This survey highlights that while the foundations for DORA compliance are well-established within the banking sector, several areas still require strategic enhancements,” Ruf stressed.
For quality-engineering teams, the study is a warning against treating DORA as a documentation exercise. Banks may be able to show that management responsibilities, strategies and security policies exist, but regulators will increasingly expect evidence that resilience controls are comprehensive, repeatable and effective.
The divide exposed by the 23-bank survey is therefore not simply between compliant and non-compliant institutions. It is between banks that have established the required governance and those that can demonstrate operational resilience when their systems, suppliers and recovery processes are placed under genuine pressure.
NEXT MONTH
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
REGULATION & COMPLIANCE
Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.
READ MORE
- Goldman puts AI coding to the test
- How to test AI models that banks do not control
- OpenAI, Filigran and SunTec: the latest vendor and product news
- Sygnum: Testing AI is ‘a measurement problem’
- Banks’ ‘code for all’ push raises testing risks
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
