The regulatory deadlines may have passed, but operational resilience is entering a far more demanding phase for financial institutions.
Over the past two years, banks have invested heavily in meeting new resilience requirements. Critical business services have been identified, impact tolerances defined, governance frameworks established and extensive programmes launched to satisfy regulations such as the EU’s Digital Operational Resilience Act (DORA) and operational resilience regimes in the UK and elsewhere.
For many banks and finance firms, however, implementation was only the beginning. The real challenge is no longer designing resilience frameworks.
It is proving that those frameworks continue to work as software changes, cloud environments evolve, third-party suppliers introduce new risks and AI accelerates the pace of technology delivery. Operational resilience is becoming a continuous validation problem rather than a compliance exercise.
That conclusion is reinforced by a new analysis from Ernst & Young, which argues that while financial institutions have made significant progress in embedding operational resilience requirements under DORA and the UK’s operational resilience framework, they remain under growing pressure from increasingly interconnected technology, third-party dependencies and increasingly complex disruption scenarios.
Next phase
That marks an important shift. The first phase of operational resilience was largely about compliance. The next phase is about continuously proving that resilience survives every software release, infrastructure upgrade and supplier change.
It changes the role of quality assurance. Rather than simply supporting regulatory compliance through periodic testing exercises, QA increasingly becomes one of the mechanisms through which banks demonstrate that critical business services remain within their defined impact tolerances despite constant technological change.
EY argued that operational resilience should now be viewed as a “living framework” rather than a one-off programme.
Instead of treating compliance milestones as an end point, firms should continuously adapt their resilience capabilities, reassess risks and regularly validate that critical services can withstand disruption.
That philosophy is becoming increasingly familiar. Software delivery inside banks has accelerated dramatically over the past two years as institutions adopt cloud-native architectures, platform engineering and AI-assisted software development. Releases that once occurred quarterly may now happen weekly, daily or even continuously for some services.
Change inevitable
Every release introduces change. A software update may appear minor in isolation, yet interact with cloud infrastructure, APIs, security controls or third-party platforms in ways that affect an important business service.
A change that passes functional testing can still introduce resilience risks if dependencies fail, recovery processes no longer perform as expected or operational controls become ineffective.
Traditional software testing was designed to answer a relatively simple question: does the application work? Operational resilience asks a much broader one: can the entire business service continue operating within its defined tolerance when technology fails, suppliers are disrupted or cyber incidents occur?
That distinction is reshaping what financial institutions expect from software testing. Rather than validating only individual applications or releases, testing increasingly extends across end-to-end customer journeys, cloud infrastructure, identity services, external providers, operational processes and recovery capabilities.
Functional testing remains essential, but it is increasingly complemented by resilience testing, dependency validation, automated regression, synthetic monitoring and continuous observability.
Increasingly, the objective is not simply to detect defects before production but to provide confidence that critical business services continue operating safely as technology evolves.
The frequency of validation is changing as well. Historically, resilience exercises often took place annually or alongside major regulatory reviews.
Today’s operating environment leaves little room for that approach. Software changes too frequently, infrastructure evolves too quickly and third-party ecosystems are becoming too dynamic for resilience to be assessed only once or twice a year.
Instead, resilience is becoming a continuous operational capability. That mirrors the transformation already seen in software engineering.
Continuous integration and continuous delivery replaced large, infrequent releases with constant incremental change. Increasingly, operational resilience appears to be following the same path, replacing periodic validation with continuous assurance.
Automated testing pipelines
This creates a growing demand for automated testing pipelines, production-safe resilience exercises, chaos engineering, synthetic monitoring and richer validation of critical business services. Evidence is becoming just as important as execution.
Regulators increasingly want organisations to demonstrate not only that testing took place, but what was tested, what failed, how defects were resolved, whether operational controls remained effective and whether important business services continued performing within their defined impact tolerances throughout change.
Documentation is evolving from an audit requirement into part of the operational control framework itself. This trend extends well beyond DORA.
Across operational resilience frameworks in Europe, the UK and other major financial centres, supervisory expectations increasingly focus on demonstrating resilience rather than merely declaring compliance.
Firms must be able to show that important business services continue operating despite technology failures, cyber attacks, supplier disruption or unexpected operational events.
That naturally places greater emphasis on continuous validation, because third-party risk adds another layer of complexity.
As banks become increasingly dependent on cloud providers, fintech partners, software vendors and external platforms, validating resilience extends beyond internally developed applications.
Critical business services often rely on technology ecosystems that span multiple organisations, making end-to-end testing and dependency validation significantly more important than in traditional application-centric quality assurance.
Testing therefore becomes increasingly ecosystem-based rather than application-based. Rather than asking whether a single application performs correctly, resilience programmes must demonstrate that an entire chain of interconnected systems continues supporting customers under adverse conditions.
Tthat represents one of the most significant shifts in recent years. Operational resilience is no longer primarily a governance initiative or a regulatory project.
It is becoming an ongoing software quality challenge, requiring continuous validation that technology changes do not compromise the services on which customers and markets depend. The compliance programmes may have been completed, but the continuous testing era is only just beginning, and banks should take note.
THIS SEPTEMBER IN LONDON
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
- AI adoption strains JPMorgan testing
- Can banks ‘outsource’ AI accountability?
- HDFC Bank raises testing stakes
- Is observability banking QA’s next discipline?
- Barclays on AI testing, telemetry and kill switches
WATCH NOW
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
