There is a version of DORA compliance that most financial institutions have been living with for the past year and a half — one where the primary concern was getting frameworks in place, documentation produced, and internal policies aligned with the regulation's five pillars. That version is over. On 17 January 2025, DORA became applicable, and DORA resilience testing QA requirements moved with it. In 2026, national competent authorities across the EU moved from supervisory tolerance into active review. The question supervisors are now asking is not whether a bank has a DORA compliance programme. It's whether that programme produces evidence that holds up under scrutiny.
For QA teams at banks, insurers, and payment institutions, this shift changes the nature of the work in a way that's worth being precise about. DORA's resilience testing requirements — Articles 24 through 27, and the accompanying Regulatory Technical Standards — don't ask for test results. They ask for a documented, auditable chain from the ICT systems that support critical functions, through the tests that verified their resilience, to the outcomes those tests produced. That's a different thing entirely from running a test suite and pointing at the green dashboard.
Building Qualigentic — our AI QA platform for regulated industries — forced us to think carefully about what that evidence chain looks like in practice, and why conventional testing infrastructure, however mature, tends to fall short of what DORA's supervisory phase actually demands.
What the supervisory shift actually means for testing teams
José Manuel de Araluce, writing in QA Financial in March 2026, put the change directly: "With the 'training wheels' now off, 2026 marks the first true test of DORA, and both financial institutions and CTPPs will feel the difference." The shift he describes is specific: supervisors are moving away from assessing policies and towards assessing operational evidence. A well-written incident response procedure is not the same thing as proof that the procedure works when a real incident occurs. A test plan that describes what will be tested is not the same thing as a signed record showing what was tested, when, against which requirement, and what the outcome was.
This distinction — between documentation of intent and documentation of execution — is where most testing programmes at financial institutions are currently exposed. The gap isn't usually a lack of testing. Most mature engineering teams at banks run substantial test suites, with coverage metrics that look credible on a dashboard. The gap is in the traceability of those tests to regulatory requirements, and in the format of the output they produce. A coverage percentage, however high, is not auditable evidence. It doesn't tell a supervisor which specific ICT system was tested, under what conditions, by whom, with what result, and whether that result was reviewed before the system was promoted to production.
Supervisors are no longer assessing whether a bank has a testing programme. They're assessing whether that programme produces evidence that survives a regulatory examination.
The five pillars, and where testing fits
DORA structures its requirements across five domains. It's worth being precise about which of them directly implicates the QA function, because the temptation to treat DORA as primarily a security or governance concern misses where the operational pressure on testing teams actually sits.
What DORA resilience testing QA evidence actually requires
The concept of an evidence chain is simple in principle and demanding in practice. A supervisor reviewing your DORA resilience testing programme needs to be able to trace, for any given ICT system supporting a critical function, the path from the requirement that system must meet, through the test case designed to verify it, to the execution record that shows what happened when that test ran, to the sign-off confirming the result was reviewed by someone with authority to do so. Each link in that chain must be present, timestamped, and immutable — not editable after the fact.
Most testing infrastructure is not built for this. Test management tools record results, but they don't enforce traceability to requirements. CI/CD pipelines run tests, but the logs are overwritten or archived in formats that aren't structured for regulatory retrieval. Coverage reports aggregate outcomes but discard the individual execution records that regulatory review actually needs. None of this is a design failure — these tools were built to support development velocity, not regulatory audit. The problem is that regulatory audit is now a requirement, and the gap between development tooling and audit-ready evidence is real.
The specific problem with AI testing tools and DORA
In January 2026, Germany's BaFin issued non-binding guidance confirming that AI systems — including generative AI tools and large language models — are not a separate regulatory regime under DORA, and must be embedded into existing ICT governance, testing, and third-party risk frameworks. The practical consequence for financial institutions using AI-assisted testing tools is direct: those tools are themselves ICT systems under DORA. If they process test data in a cloud environment, they create a Critical ICT Third-Party Provider dependency that requires formal management under Articles 28–31.
This is not a theoretical concern. A bank that adopts a cloud-based AI testing platform to improve its DORA resilience testing programme may simultaneously create the third-party risk exposure that DORA is designed to manage. The institutional logic is sound — use AI to generate more tests, faster, with better coverage — but the architectural consequence, if the tool is cloud-dependent, is a new entry on the institution's DORA third-party risk register.
On-premise deployment resolves this. When the testing infrastructure runs within the institution's own perimeter, there is no third-party ICT provider relationship to manage under DORA. The data doesn't leave. The execution records stay within the institution's own audit infrastructure. The evidence chain is complete and self-contained.
The difference between testing more and testing with evidence
There's a version of DORA preparation that focuses on test volume — running more tests, covering more of the codebase, generating more scenarios. Volume is not irrelevant, but it's not what the supervisory phase of DORA is evaluating. A test suite that runs 10,000 cases and produces a dashboard showing 94% pass rate does not, by itself, satisfy Article 25's requirement for documentation that supports supervisory review. What matters is whether the tests map to the ICT systems and functions that DORA identifies as in scope, and whether the records of those tests are structured to answer the questions a supervisor will ask.
The question a DORA supervisor asks is not "how many tests did you run?" It's "show me the evidence that the ICT system supporting this critical function was tested, when, with what outcome, and who signed off."
This reframing changes the priority of QA work in a regulated institution in a way that's worth sitting with. The shift isn't from less testing to more testing. It's from testing as a quality assurance activity to testing as an evidence-generating activity with a defined regulatory purpose. The output of the process isn't a coverage metric — it's a structured record that answers specific regulatory questions and can be retrieved, intact and unmodified, when a supervisor asks for it.
What DORA doesn't require — and where the risk of overcorrection sits
It's worth being precise about what DORA's resilience testing requirements don't demand, because the regulatory pressure to demonstrate compliance can produce responses that are more burdensome than the regulation actually requires.
The question worth asking before your next supervisory review
The most useful preparation for a DORA supervisory review isn't a compliance checklist review. It's a simulation: if a supervisor asked your team, today, to produce the complete evidence record for the resilience testing of your three most critical ICT systems, what would you be able to show them, and how long would it take to produce it?
If the answer involves searching across multiple tools, assembling records from different systems, and hoping the logs haven't been rotated, the gap is structural — not a matter of running more tests. The tests may already exist. What's missing is the infrastructure to produce them as evidence on demand, in the format a supervisor expects, with an unbroken chain from requirement to result.
That's the problem Qualigentic was built to address. Not to replace the testing work that QA teams already do well, but to produce the evidence layer that DORA's supervisory phase requires — with on-premise deployment that keeps data within the institution's own perimeter, RBAC-controlled sign-off workflows, and evidence chains that are retrievable as structured records, not reassembled from CI logs on the day a supervisor asks.
2026 is the year that distinction starts to matter in practice. The institutions that prepared for it are better positioned than those that are preparing now. But prepared and unprepared are both better positions than assuming the test suite is the evidence.
