The EU’s Digital Operational Resilience Act (DORA) has fundamentally changed how financial institutions – and the technology partners supporting them – must think about system performance. Availability is no longer measured solely by customer satisfaction or operational excellence. It has become a regulatory expectation. For IT organizations, software vendors, and testing partners, this elevates performance testing from a quality assurance activity to a key component of regulatory compliance.
As of 17 January 2025, DORA requires financial entities to demonstrate that critical digital services remain resilient during disruptions, cyber incidents, infrastructure failures, and periods of exceptional demand. While the regulation does not prescribe specific performance testing tools or metrics, it clearly requires organizations to validate the resilience of ICT systems supporting critical business functions through structured testing and continuous risk management.
For many years, performance testing was viewed primarily as an engineering discipline. Organizations executed load tests before major releases, measured response times under expected traffic, and used the results to improve application scalability. While these activities remain important, the Digital Operational Resilience Act (DORA) has fundamentally changed their business significance.
Today, performance is no longer only about user experience or system efficiency. In regulated financial services, it has become part of operational resilience – and, increasingly, a matter of compliance.
A payment platform that slows dramatically during peak transaction periods may not be “down” in the traditional sense, but from a customer’s perspective, delayed or failed transactions represent a service disruption. Under DORA, such disruptions are no longer viewed solely as technical incidents. They are operational risks that financial institutions are expected to identify, test, monitor, and mitigate.
This marks a significant shift for software engineering teams. Performance testing is evolving from an optional pre-release activity into a continuous engineering practice that provides evidence of operational resilience.
The question is no longer:
“Can our application handle the expected load?”
The more relevant question is:
“Can we prove that our critical digital services remain available and resilient under realistic operating conditions?”
Historically, financial institutions invested heavily in cybersecurity controls designed to prevent attacks. DORA broadens this perspective by asking a more important question:
Can your critical services continue operating when something inevitably goes wrong?
The regulation introduces a comprehensive framework covering:
Rather than focusing exclusively on preventing failures, DORA requires organizations to demonstrate their ability to withstand, recover from, and adapt to operational disruptions.
This means resilience must be demonstrated – not assumed.
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) establishes a comprehensive framework for managing ICT risks across the European financial sector. Its primary objective is to ensure that financial entities can continue delivering critical services even when faced with cyberattacks, infrastructure failures, software defects, or operational disruptions. The regulation emphasizes governance, ICT risk management, incident reporting, digital operational resilience testing, third-party ICT risk management, and continuous improvement.
One of the most significant implications for engineering teams is that DORA explicitly requires organizations to establish a digital operational resilience testing programme. The regulation lists several appropriate testing activities, including vulnerability assessments, scenario-based testing, end-to-end testing, penetration testing, source-code reviews, and performance testing, depending on the organization’s ICT landscape and risk profile. This is an important change in perspective.
Historically, software availability was often treated as an operational KPI measured by uptime percentages or service-level agreements. Under DORA, availability becomes part of the organization’s ability to demonstrate resilience. In other words, resilience is no longer assumed. It must be verified.
Many organizations equate availability with infrastructure uptime. However, customers experience availability differently.
A banking application may technically remain online while still failing to deliver acceptable service if:
From a business perspective, these scenarios all reduce service availability.
Modern digital services depend on many interconnected components:
Performance degradation in any one of these components can affect the customer experience without causing a complete outage. This is precisely why resilience testing should go beyond simple uptime monitoring. Organizations must understand how systems behave under realistic operating conditions – including peak traffic, infrastructure failures, dependency latency, and unexpected demand.
One of DORA’s underlying principles is that resilience should be designed into systems rather than verified only after incidents occur. Performance testing supports this objective by allowing organizations to identify operational weaknesses before customers experience them.
Instead of asking:
“Did the system fail?”
engineering teams should ask:
These questions move performance testing beyond technical benchmarking. They become business resilience questions.
Research consistently demonstrates that users have little tolerance for slow digital services. Google has reported that as mobile page load time increases from one second to three seconds, the probability of a user leaving the page rises significantly, with abandonment increasing sharply as delays grow. While banking applications differ from public websites, the underlying principle remains relevant: slower systems reduce customer satisfaction and increase operational friction.
In financial services, the consequences extend beyond user frustration. Performance degradation may lead to:
These outcomes directly affect operational resilience. For this reason, performance engineering should no longer be viewed purely as a technical optimization exercise. It is an important mechanism for reducing business risk.
Many software projects achieve excellent functional test coverage. Regression suites execute thousands of automated tests. Business workflows pass. Integration scenarios succeed. Yet the system may still fail under realistic operational conditions.
Consider an online banking platform preparing for salary payment day. Every functional test passes. Authentication works. Transfers complete successfully. Account balances are correct.
However, once transaction volume increases by 300%, response times exceed acceptable limits, API latency grows, background processing queues become saturated, and customers experience repeated failures. From a functional perspective, the application is correct. From an operational perspective, it is not resilient. Performance testing addresses this gap.
It validates not only whether software behaves correctly but whether it continues behaving correctly when real-world conditions become challenging.
Traditional performance testing often occurred only before major releases. A dedicated testing environment was prepared. Engineers executed several load scenarios. Reports were generated. The project moved into production. Modern software delivery no longer supports this model.
Organizations deploy software weekly, daily, or even multiple times per day. Cloud infrastructure changes dynamically. APIs evolve continuously. Third-party dependencies update frequently.
As a result, performance validation must also become continuous. Leading organizations increasingly integrate performance testing into CI/CD pipelines, allowing critical performance regressions to be detected shortly after code changes rather than shortly before production. This approach aligns closely with DORA’s emphasis on continuous operational resilience rather than periodic verification.
Performance testing under DORA requires more than running a load generation tool. DORA is encouraging organizations to strengthen governance, improve resilience testing, automate monitoring, and integrate operational resilience into day-to-day technology management rather than treating compliance as an isolated audit activity.
Organizations should seek partners capable of:
Experience with regulated industries is particularly valuable, where testing must balance technical depth with compliance expectations.
Availability is no longer measured solely by uptime percentages or SLA reports. It has become evidence of operational resilience. Organizations that invest in structured performance testing, continuous monitoring, realistic resilience validation, and performance engineering will be better positioned not only for regulatory compliance but also for delivering reliable digital services in increasingly complex technology environments. Ultimately, resilience is no longer something organizations declare.
It is something they must demonstrate. Delivering reliable performance in regulated environments requires deep technical expertise and experience with mission-critical systems.
ProofIT has extensive references in automated testing and performance testing of complex, business-critical systems, supporting organizations operating in highly regulated sectors including banking, telecommunications, and aerospace. Whether validating scalability, resilience, availability, or end-to-end system performance, ProofIT helps organizations build confidence that their critical digital services can perform when it matters most.
If your organization is preparing for DORA compliance or strengthening its operational resilience strategy, our experts are ready to help.
