.jpg)
Table of contents
What the new DORA report changes
On June 3, 2026, the European Supervisory Authorities published their first annual report on major ICT incidents under DORA. It noted 3,383 incidents across the EU financial sector in 2025 and described ICT risk as increasingly borderless and interconnected.
That report changes what DORA compliance actually means in practice.
Until now, DORA has mostly asked firms to show they have resilience controls in place. With a full year of incident data behind it, the direction is shifting toward something harder: proving those controls hold up against the real failures regulators are now tracking. The report suggests a clear mechanism for this: incident data should feed back into regression testing, failover testing, recovery validation, and third-party control testing, so that testing reflects what is actually going wrong rather than what firms assumed might go wrong.
The assumption behind DORA's feedback loop
Feeding incident data into testing like this only works if the incident can be reconstructed. A system outage or a cyberattack leaves a trail: logs, stack traces, timestamps, transaction IDs. You can retrace what happened, rebuild it as a test scenario, and check whether a fix actually holds. For the kind of ICT failures DORA has mostly seen so far, that assumption is reasonable.
It gets harder for a category of incidents the report doesn't break out separately: failures caused by autonomous AI agents acting inside core financial services processes.
Why regression testing doesn't hold for AI agents
An agent's bad outcome rarely traces to one clean failure point. It’s usually the result of a chain of decisions, a retrieval, a judgment call, a tool call a few steps earlier, none of which leaves the kind of trail a stack trace does.
Even where logs exist, the same input can produce a different output next time, because of model updates, the current business state, or plain variance inherent to LLM-based systems.
Traditional regression testing assumes a fixed input maps to a fixed expected output. Testing an agent means checking whether AI system outputs (in production) stay within acceptable bounds, which is a different discipline than most QA teams in this sector are set up for today.
The real gap: reconstructing business context
Underneath both problems, the tracing gap and the non-determinism, sits a harder one. What actually caused the outcome usually was not the prompt. It was the state of the customer's accounts, relationships, and history at the moment the agent acted on them.
That context is typically assembled on the fly, retrieved and joined for that one interaction, and rarely persisted anywhere it can be pulled back up later. So even when a bank knows an agent made a bad call involving a specific customer, reconstructing what that customer's data actually looked like at that moment, in order to replay the scenario and test a fix, is often not possible.
The article's own figures make the third-party version of this worse: about 30% of major incidents already trace back to third parties. When agents act across several third-party systems on their own, the business context behind a failure ends up split across systems no single team fully owns.
This points to something DORA's incident-driven testing model has not caught up to yet. Feeding an AI-related incident back into testing means being able to reconstruct point-in-time business context: what the agent actually saw, about which customer or account, at the moment it acted. That is a data architecture question before it is a testing question.
Where K2view's approach fits
K2view's Data Product Platform organizes data around real business entities, such as a customer, an account, or a policy, rather than around individual systems, databases, and tables. Because that entity-level context is a standing data product rather than something assembled and discarded per interaction, it stays available after the fact.
That means a financial institution can evaluate and replay the AI agent's interaction with a specific customer, at a specific moment, instead of manually reconstructing it, system by system, which might take days. K2view’s AI Evaluation and Observability is built for exactly that: evaluating and replaying an incident against the real conditions that produced it, rather than an approximation.
Once that context exists, provisioning it into a test environment quickly, which K2view's Agentic TDM is built for, is what keeps testing paced with how often these incidents will occur. That part matters, but it depends on the first part being true.
The takeaway
DORA's whole philosophy assumes a financial institution can always go back and ask its systems what happened. Autonomous AI is the first category of risk where that is not guaranteed by default. The same gap, being able to account for what an AI system saw and did with real business data, shows up anywhere agents act on that data, not only in testing.
Contact us to see K2view's AI Evaluation and Observability in action.
