DORA 2026: This is how banking test automation will be auditable and provable
Since 17 January 2025, DORA has required the EU financial sector to independently test critical ICT systems at least annually, and institutions subject to TLPT every three years with a threat-driven penetration test. The requirement is not to “test”, but to perform testing in a documented, repeatable and audit-provable manner. This is where test automation becomes truly valuable: when all runs are traceable and not chained to a single vendor.
A year ago, on June 18, 2025, the RTS (Commission Delegated Regulation (EU) 2025/1190) detailing the TLPT was published. Since then, the question has shifted to practice: can daily test automation hold its own in a surveillance audit? This article is about how.
The DORA testing requirement consists of three layers, each built on top of the other. It is worth treating them separately, as compliance covers all three.
A risk-based, comprehensive testing programme for ICT
systems supporting critical/important functions.
Frequency: at least annually.
Who applies: All financial entities except micro-enterprises
Vulnerability Testing, Source Code Review, Scenario-Based Testing, Performance Testing, End-to-End Testing, Penetration Testing.
Frequency: As per the Program
Who Applies to: All Financial Entities Except Micro-Enterprises
Threat-driven penetration testing on live, production systems
Frequency: At least every three years
Applicable to: Designated, significant institutions
DORA Article 24. emphasizes that it is essential that tests are conducted by an independent party. The independent tester can be an internal or external testing team. If internal testing is conducted, the company must avoid conflicts of interest during the planning and execution. This is not an organizational formality, but rather means that the results of the test should not depend on who ran it and on what device.
Most financial organizations have test automation. DORA does not examine the organizational solution used to perform testing. The audit looks at whether we can retrieve evidence of testing months later regarding:
If the answer to these questions is a screenshot and a “yes”, there is no test from an audit perspective. Auditability is not report generation at the end. The trail must be generated during the test run, unmanipulated.
An auditor doesn’t want to see test cases, but that the critical business function is covered. To do this, the test needs to be linked to the requirement, and the run should be recorded with a timestamp, environment ID, and result. The chain should work in two directions: from the requirement I can tell where the test is, and from a run I can trace back which function it verified.
A flaky test here costs more than a tense minute. If the same test is green today and red tomorrow, with unchanged code, then neither run proves anything. DORA expects repeatable, reliable testing, and determinism provides the basis for this: as long as the results of the critical test suite are unpredictable, there is nothing to refer to in the audit.
This pillar is the one that organizations realize the last and learn the most expensively. If test automation is done in a closed format by a single tool vendor, the risk is concentrated in the audit when the evidence is collected.
It is risky to leave the audit trail in the vendor’s system. This is because if the contract with the testing company ends or the support for the tool is discontinued, the availability of evidence going back years becomes questionable.
In addition, there is the concentration risk, which DORA specifically addresses. Article 30(3)(d) requires that outsourced automated testing providers be contractually obligated to cooperate in the TLPT, and a closed test tool must also comply with the DORA guidelines.
The third key risk is migration debt: if a test tool needs to be changed and the test assets are not portable, the continuity of compliance with the third pillar of DORA is interrupted precisely during the change.
Vendor independence is therefore primarily a matter of ownership. The test assets and audit trail must remain the bank’s, even if the test tool changes.
Our automated testing tool, ACE, is designed to address the above three requirements as part of its operation.
The intention of auditability is that the trace of the execution is generated during runtime and can be traced in a chain from the requirement through the test to the result. The goal of vendor independence is that the test assets and the audit trail remain the bank’s, and that a change in the choice of tool does not block access to previous evidence. All this is aimed at the area where “almost good” is not an option: banking and business-critical systems.
This approach is a practical translation of DORA Articles 24-26 into engineering language. The goal is a continuous compliance routine, in which each release leaves its own trail.
