DORA Compliance and the EU AI Act: One Compliance Stack

Two regimes, one firm

A bank, insurer, lender, or capital markets firm operating in the EU now answers to two overlapping rulebooks for its technology. DORA compliance governs how the firm keeps its ICT systems resilient and its third parties under control. The EU AI Act governs what the firm may build and deploy when that same ICT includes artificial intelligence. Read the two laws separately and they look like two projects with two owners, two registers, and two audit cycles. Read them together and they are mostly one job: a single compliance stack for regulated AI.

The practical questions most firms ask are narrower than the legislation. It is rarely "what does the EU AI Act cover in theory." It is "which of my systems are in scope, who is accountable, and which controls do I need to evidence, by when." Two questions matter up front: what does DORA require of financial institutions, and what is the EU AI Act and who does it apply to. Answer both and the architecture of the combined stack follows.

A regulated firm should treat DORA and the EU AI Act as one control environment with two legal bases, not as two separate programmes. The regimes differ in purpose, but they demand the same underlying capabilities: an inventory of systems and third parties, a documented risk framework, tested incident response, and a management body that can evidence its oversight. Building those capabilities once, and mapping them to both regimes, is cheaper than building them twice.

DORA: ICT risk, resilience, third-party

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), applies since 17 January 2025 to nearly every financial entity in the EU: banks, payment and e-money institutions, investment firms, insurers and intermediaries, and crypto-asset service providers, among others. Its scope is broad because its subject is narrow: the operational resilience of the ICT that financial services run on.

What does DORA require of financial institutions? Four obligations carry most of the weight.

ICT risk management

DORA requires an ICT risk management framework proportionate to the size, scale, and complexity of the entity. The framework must identify, protect, detect, respond to, and recover from ICT risk, and it must be governed from the top. DORA makes resilience a board-level matter, not an IT-margin annotation: the management body is accountable, and it must define, approve, and periodically review the framework and the risk appetite behind it.

The core DORA deliverable is a documented, management-body-approved ICT risk management framework with named roles, a defined risk appetite, and a review cycle. Firms must identify critical or important functions, map the information assets and third parties that support them, and protect those assets with controls that are tested rather than assumed.

Digital operational resilience testing

DORA does not allow a firm to claim resilience it has not exercised. It mandates a testing programme proportionate to risk, and it requires threat-led penetration testing (TLPT) at least every three years for financial entities identified as significant. TLPT matters because it tests against a real adversary's tactics, techniques, and procedures rather than a generic vulnerability scan. For AI systems, this extends naturally to security testing of the model and its supply chain, not just the infrastructure around it.

ICT-related incident reporting

DORA standardises how incidents are classified and reported. Major ICT-related incidents must be reported to the competent authority on fixed timelines: an initial notification within four hours of classification (and no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month. The deadlines are short on purpose. They force a firm to build incident classification and response muscle that works under pressure, not a retrospective write-up process bolted on after the fact.

Third-party risk

DORA recognises that most financial ICT now runs on someone else's cloud, SaaS, or managed service. It requires a register of information covering all ICT third-party service providers, contracts that include mandatory minimum provisions (access, audit, exit, notification), and a strategy for terminating or substituting critical providers. The uncomfortable part for many firms is the liability: a financial entity remains fully responsible for DORA compliance even when a third party delivers the service.

The EU AI Act: risk tiers and obligations

The EU AI Act (Regulation (EU) 2024/1689) is a product and market-access law, not an operational-resilience law. What is the EU AI Act and who does it apply to? It regulates AI systems placed on the market or put into service in the EU, and it applies to providers, deployers, importers, and distributors regardless of where they are established. Its reach is extraterritorial: a model built outside the EU and used inside it falls within scope, and a firm that deploys someone else's model is a deployer with obligations of its own.

The Act sorts AI into risk tiers and attaches obligations accordingly.

Unacceptable risk: prohibited

Some practices are banned outright from 2 February 2025: social scoring, manipulative or exploitative techniques, and certain biometric categorisation and real-time remote biometric identification in public spaces. Financial services rarely sit in this tier, but a firm should confirm none of its use cases do before it assumes the question away.

High risk: the tier that matters for financial services

High-risk systems carry the substantive obligations, and two routes place a financial AI system in that tier. First, AI used as a safety component of a regulated product (Annex I). Second, and far more commonly, AI in a use case listed in Annex III, which includes creditworthiness assessment and credit scoring, and risk assessment and pricing for life and health insurance.

For regulated financial firms, the centre of gravity in the EU AI Act is Annex III: credit scoring, creditworthiness assessment, and life and health insurance risk assessment and pricing are explicitly high risk. For a lender, the underwriting model is high risk. For an insurer, the pricing model can be. A high-risk system must carry a documented risk management system, data governance, technical documentation, automatic logging, human oversight, accuracy and robustness, cybersecurity, a conformity assessment, registration in the EU database, and post-market monitoring including serious incident reporting.

Limited and minimal risk

Limited-risk systems carry transparency duties: a chatbot must disclose that it is AI, and synthetic content must be marked. Everything else is minimal risk with no mandatory obligations. The classification exercise is still where most firms trip, because a system's tier depends on its intended purpose, not on how the vendor labels it in the contract.

Application timeline

The Act entered into force on 1 August 2024 and applies in phases: prohibitions and AI literacy from 2 February 2025, general-purpose AI model obligations from 2 August 2025, the bulk of the Act including most high-risk obligations from 2 August 2026, and the remaining Annex III high-risk requirements on 2 August 2027. The Commission has also proposed a simplification package that would narrow the high-risk scope and adjust some dates, so firms should track the final text before freezing budgets.

Where the two regimes overlap

The two instruments are different in kind, but they converge on the same operational surface for a regulated firm using AI.

First, both demand a governed risk management framework with a documented methodology and an accountable management body. DORA's ICT risk framework and the AI Act's high-risk risk management system are not the same document, but they should share one risk taxonomy and one risk appetite so a control is built once and mapped to both.

Second, both impose incident reporting with fixed timelines. DORA's four-hour, 72-hour, and one-month ladder for major ICT incidents, and the AI Act's serious incident reporting for high-risk systems, should feed one incident response capability. A model failure inside a bank's lending system will often be both at once: an ICT incident and a high-risk AI serious incident.

Third, both regulate third parties. DORA governs ICT third-party service providers and the register of information. The AI Act governs the AI value chain, including general-purpose AI models and downstream deployer obligations. A firm that uses a foundation model or a vendor AI system sits in both, and its vendor due diligence should produce one questionnaire, not two.

The overlap is not coincidence: both regimes are asking the same question, whether the firm can prove it understands and controls its technology risk. Credit scoring is the cleanest example. The scoring model is high risk under the AI Act, and the infrastructure it runs on is in scope under DORA. One system, two regimes, one control environment.

A combined compliance stack

Building one stack means collapsing the two regimes onto shared capabilities rather than running parallel workstreams.

One inventory, two lenses

Start with a single register of every AI system and every supporting ICT asset and third party. Tag each entry twice: once with its DORA criticality (does it support a critical or important function?) and once with its AI Act risk tier (prohibited, high, limited, minimal). This inventory is the substrate for every other control, and it is the first thing either auditor will ask to see.

One risk framework, one taxonomy

Maintain a single risk management framework with a shared taxonomy that both regimes can reference. Map DORA's ICT risk categories and the AI Act's high-risk requirements onto the same controls, so one evidence pack satisfies two auditors. Where a control is genuinely different, record the difference; where it is the same control with two names, do not duplicate it.

One third-party and model register

Combine the DORA register of information with AI vendor and model due diligence. For every third party, record the contract provisions DORA requires and the AI Act value-chain role the vendor plays. For models, connect model risk management to the same register: versions, data lineage, validation results, and ongoing monitoring.

One incident and testing capability

Operate one incident response function with a single classification triage that routes to both DORA and AI Act reporting timelines, and run resilience testing (including TLPT) and AI-specific validation from one assurance calendar. Governed agentic orchestration earns its keep here: if agents touch credit or insurance decisions, every action needs an audit trail, because both regimes will ask what the system did and why.

The output of a combined stack is a single evidence base: one inventory, one risk register, one third-party register, and one incident and testing log that can be cut for either regulator on demand. The governing question at every control is not "which regime is this for," it is "can I evidence this to either of them." Security hardening of the AI system and the software around it is the concrete way to satisfy DORA's ICT protection and the AI Act's cybersecurity requirements in one pass.

First steps

Do not start by buying tooling or rewriting policies. Start with scope and ownership.

1. Scope the entity and the systems

Confirm whether the firm is a DORA in-scope financial entity and whether it places or deploys AI systems in the EU. Then inventory the AI systems and the ICT that supports them, and apply the two-lens tagging described above. Most firms overestimate how many systems are genuinely high risk and underestimate how many third parties they depend on.

2. Assign accountable owners

Name the management body member accountable for ICT risk and for AI governance. Both regimes are explicit that accountability sits at the top. An AI governance framework without a named accountable owner is documentation, not governance.

3. Run a gap assessment against both regimes

Map existing controls to DORA's four pillars (risk management, testing, incident reporting, third-party risk) and to the AI Act's high-risk obligations. The gaps will cluster around evidence: most firms have controls they cannot prove. The gap list is the roadmap.

4. Build the evidence base before the deadline

Stand up the inventory, risk register, third-party register, and incident log as living documents, then backfill evidence for the systems that matter most. Treat the DORA obligations already in force and the 2 August 2026 AI Act milestone as the dates that make this urgent rather than optional.