Under DORA, load and performance testing evidence is part of the resilience review.
For compliance and engineering teams at EU financial entities who need to show their systems hold up under volume.
The EU’s Digital Operational Resilience Act (DORA) has applied to financial entities since 17 January 2025. It sets one rulebook for how banks, insurers, investment firms, and their critical ICT providers keep digital services running through disruption. Digital operational resilience testing is one of its five pillars (alongside ICT risk management, incident reporting, third-party risk, and information sharing), and that pillar reaches your load and performance testing directly.
One disambiguation first, because the acronym is overloaded. This article is about the EU regulation. It is not about the DevOps “DORA metrics” (deployment frequency, lead time, and the rest). Different DORA entirely.
Article 25 of the regulation lists the testing methods a resilience program should draw on. Performance testing and end-to-end testing sit on that list, alongside vulnerability assessments and penetration testing. So when an examiner reviews your resilience testing, load and stress testing evidence is fair game.
Most DORA coverage online centers on threat-led penetration testing. This piece covers the quieter obligation: showing your systems stay responsive under volume, producing the evidence an auditor will actually ask to see, and doing it with a tool built for the job. LoadView is a cloud-based, real-browser load testing platform, and the sections below map each piece of a DORA compliance reviewer’s checklist to the LoadView capability that produces it.
What This Guide Covers
- Where Load Testing Fits Into DORA
- The Audit Evidence a DORA Examiner Expects
- How LoadView Supports DORA Operational Resilience Testing
- Why Protocol-Only Load Numbers Don’t Hold Up in an Audit
- How to Produce DORA-Ready Testing Evidence
- The Bottom Line
- Frequently Asked Questions
Where Load Testing Fits Into DORA
DORA is risk-based, not prescriptive about tools. It does not say “run a 500-user load test every quarter.” It says test the ICT systems that support critical or important functions, on a regular basis, and act on what you find.
Two articles carry most of the weight for performance work:
- Article 24 sets the general testing principles. Financial entities test the ICT systems and applications that support critical or important functions at least once a year, using a risk-based approach.
- Article 25 lists the methods that program can use. Performance testing and end-to-end testing are named explicitly.
For a trading platform, a payments API, or an online banking portal, “withstand disruption” includes disruption from load: a market-open surge, a payroll-day spike, a promotion that triples checkout traffic. If the service slows down or falls over under volume, that is an operational resilience gap. And DORA expects you to have looked for it before production, which is where load testing for financial services earns its place in the program.
The stakes here are practical, not only procedural. Supervisors can require an entity to remediate resilience gaps they find, so a review that turns up an untested critical system tends to create unplanned work on a regulator’s timeline rather than your own.
The Audit Evidence a DORA Examiner Expects
Examiners work from evidence, not intentions. During a review of your resilience testing, expect them to look for artifacts like these:
Evidence auditors look for
What it demonstrates
Evidence auditors look for
Documented performance requirements
What it demonstrates
Response-time and throughput targets exist and are approved, so every test has a pass/fail bar.
Evidence auditors look for
Load testing before production releases
What it demonstrates
Volume checks are part of the release process, not an afterthought.
Evidence auditors look for
Peak volume or stress testing
What it demonstrates
The system was pushed to expected peaks and past them, so you know where it breaks.
Evidence auditors look for
Test reports with response times and error rates
What it demonstrates
Results are recorded, dated, and reproducible.
Evidence auditors look for
Capacity planning documentation
What it demonstrates
You know current headroom and roughly when you run out of it.
Evidence auditors look for
Actions taken when bottlenecks were found
What it demonstrates
Findings led to fixes and re-tests, not just filed reports.
Evidence auditors look for
Periodic re-testing as transaction volumes grow
What it demonstrates
Testing keeps pace with the business, rather than a one-time exercise.
The first row is where teams lose the most points. Without documented performance SLAs, a load test has no pass/fail line, and an auditor sees a chart with no standard behind it. Write the targets down first: P95 response time per critical transaction, an error-rate ceiling, and the peak load each system must handle.
Rows two and three are about timing and severity. Running a load test before each production release shows volume is checked before customers hit the code, and folding that check into your release pipeline keeps it consistent. Stress testing goes further than a load test, pushing past forecast peaks until something gives, so the breaking point is a number you know rather than a surprise you meet on market-open day.
Row four is the artifact examiners handle most. A report with response-time percentiles, error rates, and the load profile that produced them is the core evidence, and it needs a date and a version so it ties back to a specific release.
Row five connects the test to a forecast. Capacity planning documentation says how much headroom the last test measured and when growth will use it up. Rows six and seven separate a real program from a paper one. When a test surfaces a bottleneck, the examiner wants the follow-up, so LoadView reports that pinpoint performance bottlenecks make the action specific: which tier was slow, what changed, and the result of the re-test.
How LoadView Supports DORA Operational Resilience Testing
Each row of that evidence list maps to something LoadView does directly. The table below pairs the artifact an examiner asks for with the LoadView capability that produces it, so the compliance requirement and the tool feature line up one to one.
Audit evidence
How LoadView produces it
Audit evidence
Documented performance requirements
How LoadView produces it
Set pass/fail thresholds on response time and error rate per transaction, so every test runs against an approved bar rather than a vague "seems fast."
Audit evidence
Load testing before production releases
How LoadView produces it
Trigger LoadView tests from your CI/CD pipeline so a release cannot ship without a volume check attached to it.
Audit evidence
Peak volume or stress testing
How LoadView produces it
Shape the run with configurable load curves that hold virtual users at forecast peak, then step past it to find the breaking point.
Audit evidence
Test reports with response times and error rates
How LoadView produces it
Export a timestamped performance report with response-time percentiles, error rates, and a per-element waterfall for each run.
Audit evidence
Capacity planning documentation
How LoadView produces it
Read the load level where response times climb and errors start as your measured ceiling, and record it against forecast growth.
Audit evidence
Actions taken when bottlenecks were found
How LoadView produces it
Use the waterfall and per-tier timing to name the slow component, fix it, and re-run the same script for a before-and-after record.
Audit evidence
Periodic re-testing as transaction volumes grow
How LoadView produces it
Schedule recurring tests and keep them in the pipeline, so re-testing tracks growth instead of waiting for a calendar reminder.
Two LoadView details do most of the work here. The first is that tests run in real browsers, so the numbers in your report are the times a customer would actually see, which is what makes the report credible as resilience evidence. The second is that the whole flow is scripted as a user journey rather than a set of raw requests, so an end-to-end test under DORA Article 25 covers login, transaction, and confirmation the way a real session does. The next two sections cover each of those in turn.
Why Protocol-Only Load Numbers Don’t Hold Up in an Audit
A load test that fires raw HTTP requests can report large throughput numbers. But for a customer-facing financial service, those numbers describe the server, not the customer. They skip the JavaScript, the third-party fraud check, the SSO redirect, and the rendered confirmation screen.
An examiner asking whether customers can transact under load wants evidence about the customer’s experience, not just the origin’s request rate. Real-browser load testing runs the test through actual Chromium instances, so the response times in your report are the times a customer would see. In plain terms, the test loads the page the way a customer’s browser does—running the scripts, the redirects, and the rendering—rather than only pinging the server.
For a bank or payments provider, that is the gap between “the API answered in 200ms” and “the login-to-confirmation flow took nine seconds because the fraud-scoring call queued.” The second one degrades the service. And it is exactly what a resilience review is looking for, which is why transaction concurrency testing against the real user flow produces stronger evidence than a protocol-level throughput chart.
A tool reporting “100,000 requests per second” without executing the page is measuring HTTP throughput, not what a customer experiences at the login screen. An auditor reviewing customer-facing resilience wants the second number.
Protocol-level tests measure the server; LoadView’s real-browser tests measure the login-to-confirmation flow a customer runs.
How to Produce DORA-Ready Testing Evidence
You do not need a new tool category to satisfy this pillar. You need tests that map to the evidence list and a record you can hand to an auditor. Here is the sequence in LoadView:
- Write performance requirements for each critical function. Set response-time percentiles and an error-rate ceiling per transaction, get them signed off, and enter them as the pass/fail thresholds on the test so results grade themselves.
- Record the test as a real user flow. Use the EveryStep recorder to capture the actual journey (login, transaction, confirmation) click by click in a real browser, then replay it under load with web application load testing instead of replaying bare HTTP calls.
- Test to expected peak, then past it. Configure load curve types to hold virtual users at forecast peak for the load test, then a stepped curve that pushes beyond it for the stress test, so both the “can we handle the day” and the “where do we break” questions have answers on file.
- Inject load from the regions you serve. If your customers span the EU, run from more than 30 geo-distributed load injection zones so performance is measured where users actually are, not just from one data center.
- Keep the report. Export the performance test reports with percentiles, error rates, load profile, waterfall, and timestamp, and file them with the release record. That file is what the examiner reads.
- Re-test on a schedule and after change. Repeat at least yearly for critical functions, after any release that touches a critical path, and once growth moves you toward the capacity ceiling the last test found. Scheduling the run and wiring it into your CI/CD pipeline keeps that cadence automatic instead of a calendar reminder.
Handled this way, the evidence builds itself as a byproduct of testing you would want to run regardless. Because LoadView is fully cloud-hosted, there is no load-generation infrastructure to stand up or defend to an auditor, and the artifacts line up with what a DORA reviewer asks for, in the order they ask for it.
DORA’s scope also reaches the critical ICT third-party providers you rely on. If a payment gateway, identity service, or data API sits on a critical path, its behavior under load is part of your resilience picture too, so API load testing against those endpoints keeps the same evidence on file for the services you do not run yourself.
See how LoadView produces the evidence a DORA examiner asks for. Schedule a LoadView demo to size a test for your peak volumes and export the reports your auditors will ask for.
The Bottom Line
DORA does not hand you a load testing checklist, but its resilience testing pillar and the Article 25 methods make performance and load testing part of what a reviewer can inspect. The systems that matter are the ones supporting critical or important functions, and the standard is whether they keep serving customers under volume.
Produce the seven artifacts an examiner expects, base them on real-browser results rather than protocol-level throughput, and re-test as volumes grow. LoadView is built to generate each of those artifacts from a single scripted test, so a resilience review of your performance testing becomes a matter of handing over records you already keep.
Frequently Asked Questions
Does DORA Require Load Testing?
DORA does not name load testing as a standalone mandate. But Article 25 lists performance testing and end-to-end testing among the methods a resilience testing program can use, and Article 24 requires yearly testing of systems supporting critical or important functions. For customer-facing financial services, load and stress testing are the practical way to show those systems withstand disruption from volume.
What Load Testing Evidence Do DORA Auditors Look For?
Examiners typically look for documented performance requirements, load testing before production releases, peak volume or stress testing, test reports showing response times and error rates, capacity planning documentation, records of actions taken when bottlenecks were found, and periodic re-testing as transaction volumes grow.
How Does LoadView Help With DORA Compliance?
LoadView produces the load and performance testing evidence a DORA reviewer asks for. It scripts real user journeys in a real browser with the EveryStep recorder, runs them from more than 30 global injection zones, shapes load with configurable load curves for peak and stress tests, exports timestamped performance reports with response times and error rates, and can be scheduled or wired into CI/CD for periodic re-testing.
Is Performance Testing the Same as Penetration Testing Under DORA?
No. Article 25 lists them separately. Penetration testing and threat-led penetration testing check security resilience against attackers. Performance and load testing check whether systems stay responsive and available under volume. A resilience program needs both, and the evidence for each is different.
How Often Should We Re-Test Under DORA?
Article 24 sets a minimum of yearly testing for systems supporting critical or important functions. In practice, re-test whenever a release changes a critical path and whenever transaction volumes grow enough to move you toward the capacity limits your last test measured.