DORA + EU AI Act: Build One Testing Program, Not Two

European banks are running two sets of compliance tests right now: DORA operational resilience tests (required under Digital Operational Resilience Act, fully applicable since January 2025) and EU AI Act conformity assessments (deadline August 2026, enforcement ramping through 2026-2027).

Most compliance teams treat these as entirely separate workstreams. Different teams, different methodologies, different documentation outputs. One goes to the CISO's team, one goes to the model risk or AI governance team.

This separation creates duplicated work — and, more problematically, it creates a gap between two frameworks that should be protecting the same thing.

What DORA requires for AI-driven systems

DORA (Digital Operational Resilience Act) establishes ICT risk management requirements for financial entities. Article 25 requires "advanced testing of ICT tools, systems and processes based on threat-led penetration testing" (TLPT) for critical systems.

For banks that use AI in critical operational functions — fraud detection running 24/7 on transaction flows, AML screening on every payment, credit systems processing loans — those AI systems are within the scope of DORA's critical ICT systems definition.

DORA's threat-led penetration testing requirement means: test the system against realistic attack scenarios based on current threat intelligence. Not theoretical vulnerabilities. Current attack patterns from real threat actors.

For AI systems in 2026, the current threat actors are adversarial AI researchers and financial crime operators. Their attack toolkit includes exactly the attack categories in FinProof's taxonomy: indirect injection through documents, tool description poisoning, RAG knowledge base manipulation, multi-hop data traversal.

A DORA TLPT exercise for a banking AI system should include these attacks. If it doesn't, it isn't testing against current threat intelligence — it's testing against the threat model of 2020, when banking AI systems were much simpler.

What the EU AI Act requires for the same systems

The EU AI Act's Article 9 risk management system requires "testing to identify the most appropriate risk management measures" against "foreseeable misuse" of high-risk AI systems.

For a fraud detection AI: foreseeable misuse includes adversarial inputs designed to evade detection, crafted transactions designed to probe the system's decision boundaries, injection attacks through transaction metadata.

For a credit scoring AI: foreseeable misuse includes manipulated input data designed to influence the score, injection through KYC documents, RAG poisoning of the underwriting knowledge base.

These are the same attack categories that DORA's TLPT requirement would test for, because they're based on the same current threat intelligence.

Where the frameworks diverge

DORA and the EU AI Act don't require identical things. They require overlapping things.

DORA focuses on operational resilience: can the system continue to function correctly under adversarial conditions? Does an attack that succeeds cause operational disruption, or does the system fail gracefully?

EU AI Act focuses on harm prevention: does the system produce harmful outputs when misused? Are the harm categories mapped and managed?

The overlap: adversarial testing for both frameworks uses the same attack scenarios. The difference is in how you interpret and document the results.

For DORA: the result is described in terms of operational impact — did the attack cause a system failure, a processing error, a compliance failure that required manual intervention?

For EU AI Act: the result is described in terms of harm categories — did the attack cause prohibited output, data leakage, unauthorized action, or regulatory violation?

A single adversarial test run can produce both sets of results if you design the test methodology and documentation correctly.

The unified testing program

Here is how to run one testing program that satisfies both frameworks:

Phase 1: Attack scenario design (common)

Design adversarial test scenarios based on current threat intelligence for AI systems in banking. FinProof's taxonomy provides a structured starting point. For each scenario, document:

• Attack type and methodology
• Which system component it targets (model, knowledge base, tool interface, session context)
• Expected outcome if attack succeeds

This phase is identical for both DORA and EU AI Act purposes.

Phase 2: Test execution (common)

Run the adversarial tests against the target AI system in a test environment. Document:

• Test inputs (or attack categories and counts, if individual inputs are security-sensitive)
• Pass/fail results per attack category
• Attack success rates

This phase is identical for both frameworks.

Phase 3: Documentation — DORA perspective

For each successful attack, document:

• Operational impact: what function was disrupted? For what duration?
• Recovery: how is normal operation restored after a successful attack?
• Detection: was the attack detected? How quickly?

This produces the DORA TLPT documentation: evidence that you've tested operational resilience against current threat-led attack scenarios.

Phase 4: Documentation — EU AI Act perspective

For each successful attack, document:

• Harm category: which Article 9 risk area does this failure implicate?
• Severity: what is the potential impact on individuals or on regulatory compliance?
• Risk management measure: what control is implemented to address this risk?

This produces the EU AI Act Article 9 documentation: evidence of a risk management system that identifies foreseeable misuse and implements appropriate measures.

Phase 5: Remediation (common)

Implement the risk management measures identified. Retest to verify they work. This phase is identical for both frameworks.

The time and cost case

Running two separate testing programs for the same AI system under DORA and the EU AI Act roughly doubles the testing effort. Attack scenario design, test execution, documentation, and remediation are all duplicated.

A unified program, designed with dual documentation from the outset, requires roughly 30-40% more effort than a single-framework program — not 200%. The marginal cost of producing DORA-framed documentation from results already collected for EU AI Act purposes is low. The marginal cost of running a separate DORA testing exercise from scratch is high.

More practically: many banks are resource-constrained on adversarial AI testing expertise. A unified program means your best adversarial testing resources are focused on one well-designed exercise, not split across two parallel exercises with duplicated setup.

The gap that still needs attention

The DORA-EU AI Act overlap is largest for AI systems used in critical operational functions. There's a category where the overlap is smaller: AI systems used in customer-facing applications (chatbots, advice tools) that aren't critical operational infrastructure under DORA but are high-risk AI under the EU AI Act.

For those systems, the EU AI Act testing obligation stands alone. DORA's TLPT requirement doesn't apply to non-critical systems.

Don't let the unified program framing cause you to skip DORA testing for systems that don't qualify under the AI Act's high-risk category, or skip AI Act testing for systems that are operationally critical but not high-risk AI under the Act's definitions. Map each system to both frameworks explicitly before designing the test program.

A practical starting point: for each AI system currently deployed, produce a two-column table:

This table, completed for your specific systems, tells you which test exercises can be unified and which require separate work.

• FinProof mapped to both EU AI Act and DORA risk frameworks: finproof@zytratechnologies.com
• Agent Siege (agentic attack scenarios): finproof.ai/agent-siege

See also: EU AI Act Article 9: Red Team Requirements for Banking · BFSI AI Attack Taxonomy: 11,474 Prompts · How to Evaluate LLM Guardrails in Banking