Performance Engineering as a Compliance Topic:
How DORA is Changing the Role of Testing
Published July, 2026 | 5 min read
With the introduction of the Digital Operational Resilience Act (DORA), financial institutions face the challenge of not only ensuring digital resilience but also demonstrating it. This regulatory requirement directly impacts the work of performance engineers, testers, and observability teams. DORA requires the stability, availability, and resilience of critical applications to be tested on a regular basis. As a result, testing and monitoring are evolving from traditional quality assurance activities into essential elements of regulatory compliance.
DORA requires risk-based testing of critical applications
Digital Operational Resilience Testing is the third of DORA’s five pillars. As part of this pillar, critical applications and services must be identified. However, DORA does not provide a universal list or predefined criteria for this process. Each organization must determine for itself which applications are considered critical.
In the event of an audit, these decisions must be clearly documented and justified.
Since DORA offers no specific guidance on how to identify critical applications, organizations face a significant challenge: they must determine which applications are critical and be able to justify their decisions during an audit. Even though the regulation does not explicitly define what makes an application critical.
To support organizations, the Austrian Federal Economic Chamber (WKO) refers to Document 32024R1772, Commission Delegated Regulation (EU) 2024/1772.
This regulation classifies ICT-related incidents according to their severity and impact. The consequences described in the regulation can serve as a useful starting point for assessing the criticality of applications.
Following this approach leads to the following conclusions:
It is not the application itself that is critical, but the impact that its failure would have on the organization, its customers, and the financial market.
The key questions are therefore:
What would be the consequences if this application were to fail?
Which tests need to be performed to minimize the risk of such a failure?
Since this document is published by the European Union itself, it provides a solid basis for making these decisions. In the event of an audit, organizations must be able to clearly justify at any time:
- Why was the application classified as critical or non-critical?
- Why were certain testing methods performed, while others were not?
Missing documentation can be just as problematic as insufficient testing.
Figure: Annual DORA Testing Cycle
Article 24: Critical applications must be tested regularly
Once an application has been identified as critical, Article 24 of DORA requires it to be tested at least once a year. A longer testing interval of three years applies to penetration testing.
These tests are designed to ensure that systems remain operational even under exceptional conditions and that potential vulnerabilities are identified at an early stage.
Article 25: Performance testing is explicitly mentioned
For performance engineers, Article 25 is of particular interest. It explicitly refers to performance testing. However, this does not mean that every application classified as critical must automatically undergo performance testing. Instead, a risk-based approach is required here as well.
Would the absence of performance testing, in the worst-case scenario, result in consequences such as those described in Commission Delegated Regulation (EU) 2024/1772 (see above)? If the answer is yes, performance testing is required. If not, it is not.
The following questions can help determine whether an application should undergo performance testing:
🛈 Questions to Help Classify Applications
Business Criticality
- Is the application directly involved in business-critical processes?
- Would an outage result in financial losses?
- Would core business operations come to a standstill?
- Is the application required to comply with regulatory requirements?
- Does the application support payment, trading, or settlement processes?
Customer Impact
- How many customers would be affected?
- Would customers be unable to carry out their business activities?
- Are there alternative ways to provide the service?
- Would customer satisfaction be significantly impacted?
Dependencies
- Do other critical systems depend on this application?
- Would an outage cause cascading effects?
- Is the application part of a critical business process?
- Would a failure affect other services?
Availability
- What is the maximum acceptable downtime (RTO)?
- How much data loss is acceptable (RPO)?
- Are Service Level Agreements (SLAs) defined?
- What availability requirements must be met?
Reputational Risks
- Would an outage attract public attention?
- Could customer or partner trust be significantly damaged?
- Could the incident receive media attention?
Regulatory Impact
- Would an outage trigger a reporting obligation?
- Would regulatory requirements be violated?
- Could the incident be classified as a major ICT-related incident?
In the event of an audit, organizations must be able to clearly justify:
Why was performance testing conducted, or why was it not performed?
Article 6: DORA as a continuous process
Once an application has been classified as critical or non-critical, the process does not end. Instead, Article 6 requires the ICT risk management framework to be reviewed and updated annually. As part of this process, the tools and testing methods in use are evaluated and, where necessary, replaced or enhanced. These assessments are based on insights gained from the operation and monitoring of applications.
In the event of major ICT-related incidents or following instructions from supervisory authorities, the ICT risk management framework must be reviewed immediately.
The consequences of an outage extend beyond technical issues
Should an incident occur despite these measures, Commission Delegated Regulation (EU) 2024/1772 describes how its severity is assessed. The relevant assessment criteria include:
- Number of affected customers
- Number of affected financial counterparties
- Number of affected transactions
- Impact on the organization’s reputation
- Duration of the incident and service downtime
- Geographical spread
- Occurrence of data loss
- Criticality of the affected services
- Economic impact
Since poor system performance is often the first warning sign of a larger outage, Performance Engineering becomes an important tool for minimizing operational risk.
Article 10: Continuous monitoring is mandatory
Monitoring is an integral part of Performance Engineering. DORA requires monitoring not only during performance testing but on a continuous basis. Its objectives include ensuring high availability, detecting potential disruptions at an early stage, and triggering alerts when unusual events occur.
Particular emphasis is placed on mechanisms for detecting:
- Network anomalies
- Network performance issues
- Risks to service availability
The required monitoring mechanisms include:
- Threshold-based alerts
- Automated warning and notification systems
- Defined criteria for triggering mitigation measures
As a result, observability is evolving from a technical best practice into a regulatory requirement.
Article 17: Monitoring does not end with dashboards
Even though dashboards are an effective way to gain an overview of a system, DORA goes a step further. Article 17 requires monitoring systems to be capable of:
- Identifying root causes
- Documenting the underlying causes
- Deriving and implementing corrective measures
The key requirement is the ability to establish relationships between infrastructure, networks, applications, and business processes..
| DORA Article | Requirement | Relevance for Performance Engineers |
|---|---|---|
| Article 6 | Continuous review and improvement of the ICT risk management framework | Regularly reassess application criticality and adapt testing strategies |
| Article 10 | Continuous monitoring | Observability, alerting |
| Article 17 | Root cause analysis | Tracing, correlation |
| Article 24 | Annual testing | Testing strategy |
| Article 25 | Performance testing | All types of performance testing |
Performance engineering and observability under DORA
Since Performance Engineering is inherently a non-functional discipline that rarely provides simple answers, monitoring has always been essential for producing meaningful results and enabling effective improvements. DORA changes the role of both activities.
Performance Engineering becomes a fundamental part of operational resilience, while monitoring extends to the continuous operation of all critical applications. As a result, the role of Performance Engineering in the financial sector is evolving. Before DORA, its primary objective was technical optimization. With DORA now in force, demonstrating digital operational resilience has become an equally important goal.
It can be summarized in one simple principle:
From a regulatory perspective, undocumented resilience does not exist.
A Note for Microenterprises
DORA is based on the principle of proportionality. As a result, microenterprises are exempt from the strict annual review and testing requirements. Instead, they are only required to perform these activities on a regular basis. The frequency is left to each organization to determine.
However, organizations must still be able to justify their chosen review interval in the event of an audit.