Learn
By the end of this article, you’ll understand exactly where DORA and the AI Act overlap, where they diverge, and how to build one unified compliance programme that satisfies both - saving roughly 40% of the effort compared to treating them separately.
I was in a meeting last month with a bank’s Chief Risk Officer who said something that stuck with me: “We have a DORA team and an AI governance team, and they’ve never spoken to each other.”
That’s insane. And it’s common.
The Digital Operational Resilience Act (DORA), applicable since January 2025, governs ICT risk management across the financial sector. The EU AI Act, with high-risk provisions enforceable from August 2026, governs AI systems used in decision-making. For any financial institution running AI - which is to say, nearly every financial institution in 2026 - both apply simultaneously to the same systems.
Your AI-powered credit scoring model? It’s an ICT service under DORA and a high-risk AI system under the AI Act. Your fraud detection engine? ICT asset under DORA, potentially high-risk AI under the AI Act. Your algorithmic trading platform? DORA, AI Act, and MiFID II. Building separate compliance programmes for each is like hiring two architects to design the same building without telling either one about the other. You’ll end up with contradictions, gaps, and a bill that makes you question your career choices.
The Five Overlap Zones
Let me map the specific areas where DORA and the AI Act impose overlapping requirements on the same AI systems. These are the zones where a unified approach saves the most effort.
Zone 1: Risk Assessment
DORA (Article 6) requires financial entities to have an ICT risk management framework that includes identification, protection, detection, response, recovery, and learning processes. Every ICT system - including AI systems - must be risk-assessed.
AI Act (Article 9) requires a risk management system for each high-risk AI system, covering identification of known and foreseeable risks, risk estimation, risk evaluation, and mitigation measures.
The overlap: Both want you to assess risks for the same system. DORA looks at operational resilience risks (availability, integrity, continuity). The AI Act looks at AI-specific risks (bias, accuracy, robustness, fairness). A unified risk assessment with two modules - ICT resilience and AI-specific - satisfies both without duplicating the stakeholder interviews, asset identification, and threat modelling that both require.
Zone 2: Documentation
DORA (Articles 8-9) requires ICT asset registers, documentation of the ICT risk management framework, business continuity plans, and communication strategies.
AI Act (Annex IV) requires technical documentation covering system description, development process, training data, testing methodology, performance metrics, risk mitigations, and human oversight measures.
The overlap: Your AI system appears in both documentation sets. Instead of maintaining two separate records, create a layered documentation architecture. The system record in your ICT asset register links to the AI Act technical documentation. Risk assessments are tagged to both DORA and AI Act requirements. Business continuity plans reference AI-specific fallback procedures. One system, one documentation family, two regulatory outputs.
Zone 3: Testing
DORA (Articles 24-27) mandates digital operational resilience testing: vulnerability assessments, penetration testing, scenario-based testing, and TLPT for designated entities.
AI Act (Article 9(5-7)) requires testing before deployment and throughout the lifecycle: accuracy testing, robustness testing, bias testing, performance under real-world conditions.
The overlap: Design an integrated testing programme. Your penetration test can include adversarial ML attack scenarios (testing both ICT resilience and AI robustness). Your scenario-based testing can include combined failure modes: system outage + model degradation + data quality issues. One test cycle, two sets of regulatory evidence.
Zone 4: Incident Reporting
DORA (Article 19) requires reporting of major ICT incidents to the financial supervisor within 4 hours (initial), 72 hours (intermediate), and 1 month (final).
AI Act (Article 62) requires reporting of serious incidents involving high-risk AI to the market surveillance authority.
The overlap: A single event can trigger both. Your AI fraud detection system goes down (DORA major ICT incident) and simultaneously produces discriminatory outputs during degraded mode (AI Act serious incident). You need a dual-track incident classification that simultaneously assesses both DORA severity criteria and AI Act severity criteria, and routes notifications to both the financial supervisor and the market surveillance authority.
Zone 5: Third-Party Management
DORA (Articles 28-30) requires detailed third-party ICT risk management: Register of Information, contractual requirements (audit rights, exit strategies, data location), due diligence, concentration risk assessment.
AI Act (Articles 16 and 26) imposes obligations on AI providers and deployers, including vendor due diligence for third-party AI systems, access to technical documentation, and monitoring capabilities.
The overlap: When you buy an AI system from a vendor, that vendor is both an ICT third-party provider (DORA) and an AI provider (AI Act). Your vendor management framework must address both: DORA’s contractual requirements (exit plans, audit rights) and AI Act deployer obligations (access to documentation, ability to monitor for bias). One vendor contract, one relationship, two sets of regulatory expectations.
Where They Don’t Overlap (and You Can’t Shortcut)
A unified approach saves effort on the overlaps. But there are genuinely unique requirements in each regulation that the other simply doesn’t address. These are the areas where assuming “if I’m DORA-compliant, I must be AI Act-compliant too” will get you in trouble.
DORA-only requirements
Register of Information
The structured register of all ICT third-party relationships with ESA entity codes, contractual linkages, and function mappings. The AI Act has no equivalent.
xBRL-CSV reporting
The specific structured data format required for regulatory submissions. Pure DORA, no AI Act involvement.
TLPT
Threat-led penetration testing for designated entities. TIBER-EU methodology. Separate requirement entirely.
Concentration risk
Assessment of over-reliance on single ICT providers. DORA-specific concern not addressed by the AI Act.
AI Act-only requirements
Conformity assessment
The formal process of verifying compliance with AI Act requirements. DORA uses supervisory review, not conformity assessment.
Fundamental rights impact assessment
Required for certain high-risk AI deployers (Art. 27). DORA has no human rights dimension.
Algorithmic explainability
High-risk AI outputs must be interpretable by human overseers. DORA doesn’t care about explainability - a black box is fine under DORA, not under the AI Act.
Bias and fairness testing
Systematic testing for discriminatory outputs. A core AI Act requirement (Art. 10) with no DORA equivalent.
Real-World Scenarios: How This Plays Out
Theory only takes you so far. Here’s how the dual-regulation problem shows up in practice.
Scenario: AI credit scoring at a mid-sized bank
The bank uses a third-party AI credit scoring model, retrained on their own data with custom decision thresholds.
DORA obligations: The vendor goes in the Register of Information. The contract needs DORA-compliant clauses (audit rights, exit strategy, data location). The system must be in the ICT asset register. Business continuity plans must cover what happens when the scoring system is unavailable. Incidents affecting the system must be classified using DORA RTS criteria.
AI Act obligations: Because the bank substantially modified the model (retraining on own data, custom thresholds), they’re likely treated as a provider, not just a deployer. They need a conformity assessment, Annex IV technical documentation, bias testing, human oversight mechanisms, and EU database registration. If the model systematically underscores certain demographics, that’s an AI Act violation.
The unified approach: One risk assessment with ICT resilience and AI-specific modules. One documentation package that satisfies both DORA’s asset register requirements and the AI Act’s Annex IV. One vendor management framework covering DORA contractual provisions and AI Act deployer/provider obligations. One testing programme covering resilience, accuracy, and fairness.
Scenario: AI-driven insurance underwriting
An insurer uses AI to price health insurance policies based on risk factors.
DORA obligations: ICT asset register inclusion, third-party risk management if the model is outsourced, operational resilience testing, incident reporting for system failures.
AI Act obligations: Annex III explicitly covers insurance pricing as high-risk. Conformity assessment required. Must demonstrate non-discrimination in pricing outcomes. Must provide meaningful explanations to policyholders about how their premium was determined. Fundamental rights impact assessment may apply. Human oversight for individual underwriting decisions.
The crunch point: If the AI model produces discriminatory pricing for certain demographic groups, the insurer faces AI Act penalties (up to €15M or 3% of turnover) and potential regulatory action from the insurance supervisor. Two regulators, one problem, simultaneous consequences.
Scenario: A dual incident
A bank’s AI fraud detection system experiences a data pipeline failure. During the outage, the system runs on stale data and starts flagging transactions from certain geographic regions at disproportionately high rates.
DORA incident: The system outage meets major ICT incident thresholds. 4-hour initial notification to financial supervisor. Intermediate report within 72 hours. Root cause analysis and final report within 1 month.
AI Act incident: The discriminatory flagging constitutes a serious incident under Article 62. Notification to market surveillance authority. Documentation of impact on affected individuals.
The lesson: One event, two incident reports, two regulators, two timelines, two sets of remediation expectations. Your incident response playbook must handle this dual-track scenario, or you’ll miss a reporting obligation.
How to Build the Unified Programme
Enough about the problem. Let’s talk solutions. Here’s the approach I’d recommend for any financial institution that needs both DORA and AI Act compliance.
Step 1: Single inventory. Maintain one inventory of all ICT assets and AI systems. Each entry should be tagged with both its DORA classification (critical or important function? Third-party provided?) and its AI Act classification (high-risk? Who’s the provider? Who’s the deployer?). This becomes your single source of truth.
Step 2: Combined risk assessments. For every AI system, conduct one risk assessment with two modules. Module 1 covers DORA ICT resilience risks (availability, integrity, recovery, concentration). Module 2 covers AI Act risks (bias, accuracy, robustness, explainability, data quality). Same stakeholders, same workshop, two outputs.
Step 3: Integrated testing. Design test plans that generate evidence for both regulations. A penetration test that includes adversarial ML attack scenarios covers DORA Article 24 and AI Act Article 15. A scenario test that simulates system failure with model degradation covers DORA resilience testing and AI Act robustness testing.
Step 4: Dual-track incident response. Build one incident response playbook that, for every AI-related incident, simultaneously assesses DORA severity and AI Act severity, identifies both notification targets, and tracks both remediation streams.
Step 5: Unified governance. Don’t have a “DORA committee” and an “AI ethics board” that never talk to each other. Create a single governance structure where ICT risk and AI governance are discussed together. The board needs to understand both - DORA Article 5 requires board-level ICT risk oversight, and AI Act Article 4 requires AI literacy at the leadership level.
Step 6: Use a platform that understands the intersection. This is where tooling matters. A platform that only does DORA or only does AI governance forces you to maintain parallel systems. A multi-framework platform that maps the relationships between DORA and AI Act requirements lets you see where one control satisfies both, and where you have gaps. Venvera supports 13 frameworks including both DORA and the EU AI Act, with cross-framework mapping built in.
Stop Treating Them as Separate Problems
The financial institutions that will navigate this well are the ones that recognise something fundamental: DORA and the AI Act aren’t two separate compliance problems. They’re two lenses on the same operational reality.
Every AI system in a financial institution is also an ICT system. Every ICT risk assessment for an AI-powered service must consider AI-specific risks. Every third-party AI vendor is also a third-party ICT provider. The overlap isn’t incidental. It’s structural.
The institutions that build unified programmes - shared risk assessments, integrated testing, combined documentation, dual-track incident response - will spend less, move faster, and face fewer supervisory findings. Those that maintain parallel silos will do twice the work for half the assurance.
The DORA team and the AI governance team need to talk to each other. Preferably yesterday.
Unify Your DORA and AI Act Compliance
Venvera manages cross-regulation compliance for European financial institutions - DORA, EU AI Act, GDPR, NIS2, and 9 more frameworks with built-in mapping. Starting at €399/month, hosted in Amsterdam.
Book a Demo →Last updated: March 2026. Both DORA and the EU AI Act are subject to ongoing delegated acts, regulatory technical standards, and supervisory guidance. Monitor updates from the ESAs, European AI Office, and your national competent authorities.