DORA AI Governance Banking: How the Digital Operational Resilience Act Applies to AI Systems

DORA has applied directly across the EU financial sector since January 17, 2025, and the settled position — confirmed by BaFin's December 18, 2025 guidance — is unambiguous: AI systems are ICT systems, with no special carve-out, "no AI bonus" in BaFin's own phrasing. AWS, Microsoft Azure, and Google Cloud are now three of the 19 providers the European Supervisory Authorities designated as Critical Third-Party Providers in November 2025, placing them under direct EU supervisory oversight. Every bank running generative AI through Azure OpenAI, ML pipelines on AWS, or analytics through Google Cloud has DORA obligations tied to those relationships whether anyone flagged them as "DORA-relevant" or not.

Most banks treated DORA as an IT resilience exercise — business continuity plans, ICT incident response, resilience testing of core banking systems — and left AI out of it, because AI got filed under model risk management instead of ICT risk management. That compartmentalization stopped being defensible the moment DORA took effect, and BaFin's December 2025 guidance closed the last bit of ambiguity: there's no special treatment for AI just because it's newer or harder to classify than a mainframe application.

The November 2025 CTPP designation was the moment this stopped being theoretical. The ESAs didn't name obscure vendors — they named AWS, Azure, and Google Cloud alongside Oracle, IBM, SAP, Deutsche Telekom, Equinix, and Swift, which is to say, the actual infrastructure most banking AI runs on. A bank deployed on all three hyperscalers for different workloads is now a customer of three separately-designated CTPPs, each carrying its own concentration risk, contractual, and exit-planning obligations under DORA.

DORA Article 5's management body knowledge requirement has an AI dimension boards haven't fully absorbed yet. A board that can evaluate ICT risk generally but can't evaluate the AI-specific risks sitting inside that ICT framework — model drift, adversarial attacks, AI vendor concentration, generative AI incident response — doesn't meet the "sufficient knowledge" bar DORA sets. That doesn't mean every director needs to become an AI engineer; it means AI risk expertise needs to be available to the board, and risk reporting needs to present AI risk in terms the board can actually evaluate rather than translate on the fly.

Five DORA Obligations That Apply Directly to AI Systems

AI in the ICT Asset Register

DORA Article 8 requires a current register of all ICT assets, software included, supporting critical or important functions — and AI systems count, whether that's a foundation model accessed via API, an internally built ML model in production, or an AI-assisted decision tool. The register needs to capture dependencies explicitly: a generative AI deployment running on an Azure OpenAI endpoint has to show the Microsoft Azure (CTPP) dependency in the register, not bury it in a vendor contract nobody cross-referenced. A DORA-compliant ICT asset register that leaves out the bank's AI systems isn't DORA-compliant — it's compliant for everything except the part most likely to generate an incident.

AI in the ICT Risk Management Framework

DORA Articles 5–16 require a comprehensive ICT risk management framework covering identification, protection, detection, response, and recovery — and AI introduces risks that framework wasn't originally built to address. Model drift isn't a security incident but degrades reliability anyway; adversarial inputs are a form of ICT security attack specific to AI; prompt injection exploits an LLM's own instruction-following behavior; and hallucination functions as an operational risk when incorrect AI output feeds a financial decision. A framework covering only availability, integrity, and confidentiality in the traditional sense, with nothing addressing these AI-specific failure modes, is incomplete for any institution deploying AI in critical functions — which by 2026 is essentially every institution.

AI ICT Incident Reporting

DORA's incident reporting framework runs on tight clocks: initial notification within four hours of classifying an incident as major, an intermediate report within 72 hours, and a final report within one month. Determining whether an AI incident even qualifies as "major" requires applying DORA's major-incident criteria to AI-specific failure modes — a material adversarial attack causing financial losses or customer harm, a critical AI system outage hitting a large client base or critical infrastructure, or a significant AI-driven data breach. Most banks have mature cybersecurity incident response procedures; very few have AI incident classification procedures fast enough to hit the four-hour clock when the trigger is a hallucination cascade or a prompt injection, rather than a familiar ransomware pattern.

Resilience Testing of AI Systems

DORA Articles 24–27 require digital operational resilience testing, including threat-led penetration testing (TLPT) for significant institutions — and AI systems in critical functions belong in that testing scope. That means adversarial robustness testing (probing the AI with inputs designed to degrade or manipulate its output, the AI equivalent of penetration testing), stress testing AI-assisted decisions under degraded input data quality, and failover testing to confirm the fallback — human review, a rule-based backup, an alternative model — actually works as specified when the primary AI fails. Most TLPT programs today test network, application, and infrastructure security; AI adversarial testing needs different tooling and a different team, and bolting it onto an existing TLPT scope without that adjustment produces a test that looks thorough and isn't.

Critical Third-Party Provider Obligations

The November 2025 CTPP designations made explicit what was already structurally true: AWS, Google Cloud, and Microsoft are systemic infrastructure for EU banking AI, full stop. A bank running generative AI on Azure OpenAI, ML pipelines on AWS, or analytics on Google Cloud carries specific DORA concentration risk, contractual, and exit-planning obligations for each of those relationships under Article 30. Banks that haven't assessed their AI vendor relationships against those contractual requirements and built a credible exit strategy for each CTPP have an open DORA compliance gap sitting exactly where EU supervisors are now looking first.

India's Parallel Framework: RBI, SEBI, and CERT-In

RBI's Master Direction on Outsourcing of Information Technology Services, effective October 1, 2023, governs AI systems sourced from third-party vendors — including international cloud providers — much the way DORA governs CTPP relationships: vendor risk assessment, contractual data security and audit rights, concentration risk management for critical functions, and contingency planning for vendor failure or exit. Indian banks running AI workloads on AWS, Google Cloud, or Microsoft Azure need to assess those relationships under this framework now. India hasn't designated Critical Third-Party Providers the way the EU has, but RBI's emphasis on concentration risk management effectively demands the same analysis without the formal CTPP label attached.

SEBI's CSCRF applies to brokers, asset managers, depository participants, clearing corporations, and market infrastructure institutions, with a risk-tiered structure — Market Infrastructure Institutions carry the most stringent requirements, ahead of Qualified REs and mid-market entities. AI systems used in trading, surveillance, and investor analytics at these entities fall squarely inside CSCRF compliance scope, and firms that treated CSCRF as a pure cybersecurity exercise separate from their AI governance program should reconnect the two before their next SEBI inspection.

RBI's data localization requirements for payment system data apply to AI processing as much as to storage. A fraud detection, AML, or credit scoring model processing payment transaction data has to be checked against localization rules even when storage itself is compliant — if the AI's actual processing happens on cloud infrastructure outside India, that can breach localization even with fully localized storage sitting underneath it. This architectural nuance — storage compliant, processing not — is a gap we see repeatedly in banks that treated data localization as a storage-layer checkbox rather than a processing-layer constraint.

The direction's six-hour mandatory incident reporting window applies to AI incidents that qualify as cybersecurity incidents: a prompt injection causing unauthorized data disclosure, an adversarial attack on a fraud model, or compromise of an AI system embedded in critical infrastructure. Indian banks need AI incident classification procedures that can actually hit that six-hour window — which is tighter than DORA's four-hour clock sounds, because CERT-In's six hours starts at detection, not at the point someone decides the incident is "major."

What to Do About It

• Add every AI system — foundation models accessed via API, internal ML models, AI-assisted decision tools — to your DORA ICT asset register with explicit CTPP dependency mapping, this quarter, not at next year's audit.
• Extend your ICT risk management framework to name model drift, adversarial attacks, and prompt injection as covered risk types, not just availability/integrity/confidentiality in the traditional sense.
• Build an AI incident classification procedure fast enough to hit DORA's four-hour and CERT-In's six-hour reporting clocks — test it with a tabletop exercise, not just a policy document.
• Confirm your TLPT program's scope explicitly covers AI adversarial robustness testing with appropriately different tooling, not a network pentest relabeled.
• Document an exit strategy for each hyperscaler CTPP relationship your AI workloads depend on, and verify RBI's data-localization rules are satisfied at the processing layer, not just the storage layer.

Zytra maps AI systems into your DORA ICT asset register, extends your ICT risk framework to cover AI-specific failure modes, integrates AI incident response with DORA reporting timelines, and produces the CTPP concentration risk documentation EU supervisors are examining for.

Talk to sales