DORA Is in Force. Your AI Vendor Layer Is the Gap Nobody Wants to Admit
The Digital Operational Resilience Act has been in application since 17 January 2025. Most financial institutions have addressed the obvious pillars: they have updated their incident reporting procedures, reviewed their cloud contracts, and assigned someone to own the ICT risk management framework. What most boards have not properly stress-tested is the AI vendor layer.
OpenAI, Anthropic, Microsoft Azure AI, AWS Bedrock, and Google Cloud AI are not a special category under DORA. They are ICT third-party service providers, subject to the full weight of Articles 28 through 30. The European Supervisory Authorities made this explicit when they published the first official list of 19 designated Critical ICT Third-Party Providers in November 2025 — a list that includes AWS, Microsoft, Google Cloud, Deutsche Telekom, Oracle, and SAP. If your institution uses any of these providers to run AI workloads that support critical or important functions, your Articles 28-30 obligations apply in full, regardless of whether you have formally acknowledged them.
This is not a theoretical concern. EBA supervisory assessments in 2025-2026 show that DORA Pillar 4 — third-party risk management — has the highest rate of compliance gaps of any pillar. The AI vendor layer is the newest and least-mapped component of that gap. This checklist is designed to close it.
Why the Mythos Precedent Changes Your TLPT Baseline
The companion article to this piece covered the Claude Mythos Preview evaluation in detail. The headline finding from the UK AI Safety Institute: Claude Mythos achieved a 73% solve rate on professional-grade CTF cybersecurity challenges, and Anthropic's own threat intelligence report documented an 80-90% automation rate for a nation-state espionage campaign using Claude. These are not edge cases. They represent the new baseline for what a well-resourced threat actor can do with commercially available AI.
DORA Article 26 requires Threat-Led Penetration Testing to be intelligence-led — scenarios must mimic the tactics, techniques, and procedures of real actors who pose a genuine threat to the institution's critical functions. The ECB's TIBER-EU SSM Implementation Guide, published in November 2025, is explicit: Significant Institutions will be tested on live production systems by qualified external teams, based on real threat intelligence. If your TLPT scenarios were designed before AI-assisted attack automation became a documented threat actor capability, they are not meeting the standard the ECB will apply.
This is the regulatory context in which the following checklist should be read. It is not a theoretical compliance exercise. It is the minimum defensible position for a financial institution that will face ECB, PRA, BaFin, or FCA scrutiny in the next 12 to 36 months.
The Six-Pillar DORA AI Compliance Checklist
Pillar 1: AI Vendor Classification and Inventory (Articles 6 and 8)
The first obligation is the most foundational and the most commonly incomplete. Article 8 requires financial entities to identify, classify, and accurately record ICT business operations, information assets, roles, and dependencies. For AI vendors, this means mapping every AI tool in use — generative AI APIs, inference services, AI-enabled SaaS platforms, and embedded AI features in existing software — against DORA's ICT third-party service provider definition.
The practical questions your compliance team must be able to answer are: Which AI vendors support critical or important functions? What is the concentration risk if a single AI provider experiences an outage or a security incident? Does any vendor appear on the ESA CTPP list published in November 2025? Has the institution documented its AI vendor inventory at the entity, sub-consolidated, and consolidated levels as Article 28(3) requires? If any of these questions cannot be answered with documentary evidence, the inventory is incomplete.
Pillar 2: Contract Compliance (Article 30)
Article 30 specifies mandatory contract clauses that must be present in every ICT third-party arrangement. For AI vendors, this means reviewing every contract — including API terms of service, enterprise agreements, and SaaS subscriptions — for the following: service descriptions and SLAs that cover AI-specific failure modes such as model drift, hallucination rates, and inference outages; the financial entity's audit rights; the regulator's audit rights; data security standards; business continuity obligations; and termination rights.
The most common gap is the absence of regulator audit rights. Standard commercial AI vendor agreements are written for enterprise software procurement, not financial services regulation. The regulator's right to audit an AI vendor is not a standard clause in an OpenAI or Anthropic enterprise agreement. It must be negotiated. DORA's text contains no grace period for legacy contracts: arrangements in place before 17 January 2025 must be renegotiated to include these clauses. This is not optional and it is not deferred.
Pillar 3: AI-Specific Threat Detection (Articles 9 and 10)
Article 10 requires financial entities to implement tools to swiftly identify suspicious activity, conduct frequent testing, and allocate adequate resources to track user behaviour and ICT anomalies. The challenge for AI vendor relationships is that the anomaly signatures are different from those of traditional ICT services.
An AI-assisted attack may not look like a conventional intrusion. Prompt injection attacks, model manipulation, automated phishing campaigns generated at scale, and AI-assisted reconnaissance of legacy system vulnerabilities all produce different telemetry patterns than the attack vectors that most financial institution detection systems were calibrated for. Updating detection systems to include AI-assisted attack vectors is not a future-state aspiration under DORA — it is a current Article 10 obligation. The Mythos evaluation documented that AI-assisted attacks can automate the reconnaissance and exploitation phases of an attack at a speed and scale that makes traditional signature-based detection insufficient.
Pillar 4: Incident Response for AI Breaches (Articles 11, 13, 17, and 19)
Articles 11 and 17 require comprehensive ICT business continuity policies, response plans, and incident management processes. Article 13 requires post-incident learning and crisis communication. Article 19 requires mandatory reporting of major ICT incidents to regulators. For AI-assisted breaches, each of these obligations has a specific implication that most existing incident response playbooks do not address.
The practical gaps are: incident classification criteria that do not include AI-assisted attack scenarios; response playbooks that assume a human attacker operating at human speed rather than an AI agent operating at machine speed; post-incident analysis processes that do not specifically examine how AI capabilities were exploited; and reporting chains that have not been updated to include AI-related incidents as a named category. Article 13's learning obligation is particularly important here — the ECB will expect to see evidence that institutions are updating their threat models based on documented AI attack capabilities, not just responding to incidents after the fact.
Pillar 5: TLPT Red-Teaming for AI Attack Vectors (Article 26)
Article 26 mandates Threat-Led Penetration Testing for Significant Institutions at least every three years, covering all critical or important functions on live production systems. The ECB's TIBER-EU SSM Implementation Guide published in November 2025 clarifies the standard: tests must be intelligence-led, scenarios must reflect real threat actor capabilities, and institutions must produce evidence that they are learning and improving from each test cycle — not just completing a periodic compliance exercise.
For institutions that have already completed a TLPT cycle, the question is whether the scenarios used reflected the current AI-assisted threat landscape. A TLPT conducted in 2023 or 2024 that did not include AI-assisted attack automation scenarios is not a defensible baseline for 2026 ECB scrutiny. The scope of TLPT must also include AI vendor dependencies — if a critical function relies on a cloud AI API, that dependency is in scope for the test. Institutions that treat TLPT as an isolated three-year exam rather than a continuous resilience programme are accumulating regulatory exposure between cycles.
Pillar 6: Board and Governance (Articles 5 and 6)
Article 5 places the management body at the centre of ICT risk governance. The management body must formally approve the ICT risk management framework, take direct responsibility for ICT risk, and ensure that adequate resources and capabilities are in place. Article 6 requires the framework to be recorded, periodically reviewed, and internally audited by personnel with the necessary expertise.
For AI risk specifically, this means the board cannot delegate the question to IT middle management. The fiduciary exposure from an AI-assisted breach — particularly one that a regulator determines could have been anticipated and mitigated — sits at director level. The practical governance requirements are: formal board sign-off on the AI vendor due diligence process; AI risk as a standing agenda item on the risk committee; documented board-level awareness of AI-assisted threat scenarios including Mythos-class capabilities; and evidence that the management body has reviewed and approved the institution's TLPT programme and its AI-specific scope.
The EU AI Act Layer: A Second Compliance Clock Running Simultaneously
DORA is not the only regulatory framework that applies to AI vendor relationships in financial services. The EU AI Act (Regulation EU 2024/1689) adds a second layer that runs simultaneously. A single AI vendor relationship can trigger obligations under both frameworks at the same time, and a vendor can satisfy one and fail the other.
DORA governs operational resilience, concentration risk, and contractual adequacy. The EU AI Act governs algorithmic transparency, fairness, human oversight, and conformity assessment for high-risk AI systems. Financial institutions that use AI for credit risk decisioning, insurance underwriting, or employment-related decisions are deployers of high-risk AI systems under the EU AI Act's Annex III classification. As a deployer, the institution must ensure appropriate human oversight, monitor the AI system for risks, report serious incidents to national competent authorities, and maintain documentation sufficient to demonstrate compliance.
The EU AI Act's Annex III high-risk obligations were originally scheduled for August 2, 2026. The Digital Omnibus on AI, agreed politically on May 7, 2026, would extend this deadline to December 2, 2027 — but as of this writing, the Omnibus has not been formally adopted or published in the Official Journal of the European Union. Until formal adoption occurs, the August 2, 2026 deadline remains operative. Institutions should continue compliance preparations in line with the existing deadline, as DLA Piper's April 2026 guidance confirmed.
What the Risk Committee Agenda Should Look Like Now
The question that regulators will ask — and that no board wants to answer unprepared — is not "do you have an AI policy?" It is "can you demonstrate, with documentary evidence, that you have assessed your AI vendors against Articles 28-30, that your TLPT scenarios reflect current AI-assisted threat actor capabilities, that your incident response playbooks cover AI-assisted breach scenarios, and that your management body has formally approved and reviewed all of the above?"
The institutions that will navigate the next wave of regulatory scrutiny without incident are the ones that treat AI risk governance as a board-level fiduciary obligation now, before they are required to explain a gap to the ECB, PRA, or BaFin. The checklist above is the minimum. The institutions that move beyond compliance to genuine operational resilience — continuous TLPT cycles, real-time AI vendor monitoring, board-level AI risk literacy — are the ones that will not be in the news for the wrong reasons.
Finance is the opening act. Every sector with networked infrastructure and legacy code faces this wave next. The question is whether your board is asking the right questions before the regulator does.
About the Author
Modi Elnadi is Founder and Director of Marketing and AI Growth at Integrated.Social, a London-based B2B AI growth marketing agency. Modi works at the intersection of agentic AI strategy, regulatory risk communication, and B2B demand generation for financial services, technology, and professional services clients. He has built AI governance communication frameworks for commercial and compliance stakeholders, translating complex regulatory obligations — including DORA, the EU AI Act, and the UK's AI Cyber Code of Practice — into commercially actionable board-level intelligence. His work spans agentic AI deployment strategy, AI search optimisation, and the pipeline measurement systems that make AI marketing programmes commercially accountable. He writes regularly on AI risk governance, B2B GTM strategy, and the regulatory frameworks shaping enterprise AI adoption in 2026.
DORA Is in Force. Your AI Vendor Layer Is the Gap Nobody Wants to Admit
The Digital Operational Resilience Act has been in application since 17 January 2025. Most financial institutions have addressed the obvious pillars: they have updated their incident reporting procedures, reviewed their cloud contracts, and assigned someone to own the ICT risk management framework. What most boards have not properly stress-tested is the AI vendor layer.
OpenAI, Anthropic, Microsoft Azure AI, AWS Bedrock, and Google Cloud AI are not a special category under DORA. They are ICT third-party service providers, subject to the full weight of Articles 28 through 30. The European Supervisory Authorities made this explicit when they published the first official list of 19 designated Critical ICT Third-Party Providers in November 2025 — a list that includes AWS, Microsoft, Google Cloud, Deutsche Telekom, Oracle, and SAP. If your institution uses any of these providers to run AI workloads that support critical or important functions, your Articles 28-30 obligations apply in full, regardless of whether you have formally acknowledged them.
This is not a theoretical concern. EBA supervisory assessments in 2025-2026 show that DORA Pillar 4 — third-party risk management — has the highest rate of compliance gaps of any pillar. The AI vendor layer is the newest and least-mapped component of that gap. This checklist is designed to close it.
Why the Mythos Precedent Changes Your TLPT Baseline
The companion article to this piece covered the Claude Mythos Preview evaluation in detail. The headline finding from the UK AI Safety Institute: Claude Mythos achieved a 73% solve rate on professional-grade CTF cybersecurity challenges, and Anthropic's own threat intelligence report documented an 80-90% automation rate for a nation-state espionage campaign using Claude. These are not edge cases. They represent the new baseline for what a well-resourced threat actor can do with commercially available AI.
DORA Article 26 requires Threat-Led Penetration Testing to be intelligence-led — scenarios must mimic the tactics, techniques, and procedures of real actors who pose a genuine threat to the institution's critical functions. The ECB's TIBER-EU SSM Implementation Guide, published in November 2025, is explicit: Significant Institutions will be tested on live production systems by qualified external teams, based on real threat intelligence. If your TLPT scenarios were designed before AI-assisted attack automation became a documented threat actor capability, they are not meeting the standard the ECB will apply.
This is the regulatory context in which the following checklist should be read. It is not a theoretical compliance exercise. It is the minimum defensible position for a financial institution that will face ECB, PRA, BaFin, or FCA scrutiny in the next 12 to 36 months.
The Six-Pillar DORA AI Compliance Checklist
Pillar 1: AI Vendor Classification and Inventory (Articles 6 and 8)
The first obligation is the most foundational and the most commonly incomplete. Article 8 requires financial entities to identify, classify, and accurately record ICT business operations, information assets, roles, and dependencies. For AI vendors, this means mapping every AI tool in use — generative AI APIs, inference services, AI-enabled SaaS platforms, and embedded AI features in existing software — against DORA's ICT third-party service provider definition.
The practical questions your compliance team must be able to answer are: Which AI vendors support critical or important functions? What is the concentration risk if a single AI provider experiences an outage or a security incident? Does any vendor appear on the ESA CTPP list published in November 2025? Has the institution documented its AI vendor inventory at the entity, sub-consolidated, and consolidated levels as Article 28(3) requires? If any of these questions cannot be answered with documentary evidence, the inventory is incomplete.
Pillar 2: Contract Compliance (Article 30)
Article 30 specifies mandatory contract clauses that must be present in every ICT third-party arrangement. For AI vendors, this means reviewing every contract — including API terms of service, enterprise agreements, and SaaS subscriptions — for the following: service descriptions and SLAs that cover AI-specific failure modes such as model drift, hallucination rates, and inference outages; the financial entity's audit rights; the regulator's audit rights; data security standards; business continuity obligations; and termination rights.
The most common gap is the absence of regulator audit rights. Standard commercial AI vendor agreements are written for enterprise software procurement, not financial services regulation. The regulator's right to audit an AI vendor is not a standard clause in an OpenAI or Anthropic enterprise agreement. It must be negotiated. DORA's text contains no grace period for legacy contracts: arrangements in place before 17 January 2025 must be renegotiated to include these clauses. This is not optional and it is not deferred.
Pillar 3: AI-Specific Threat Detection (Articles 9 and 10)
Article 10 requires financial entities to implement tools to swiftly identify suspicious activity, conduct frequent testing, and allocate adequate resources to track user behaviour and ICT anomalies. The challenge for AI vendor relationships is that the anomaly signatures are different from those of traditional ICT services.
An AI-assisted attack may not look like a conventional intrusion. Prompt injection attacks, model manipulation, automated phishing campaigns generated at scale, and AI-assisted reconnaissance of legacy system vulnerabilities all produce different telemetry patterns than the attack vectors that most financial institution detection systems were calibrated for. Updating detection systems to include AI-assisted attack vectors is not a future-state aspiration under DORA — it is a current Article 10 obligation. The Mythos evaluation documented that AI-assisted attacks can automate the reconnaissance and exploitation phases of an attack at a speed and scale that makes traditional signature-based detection insufficient.
Pillar 4: Incident Response for AI Breaches (Articles 11, 13, 17, and 19)
Articles 11 and 17 require comprehensive ICT business continuity policies, response plans, and incident management processes. Article 13 requires post-incident learning and crisis communication. Article 19 requires mandatory reporting of major ICT incidents to regulators. For AI-assisted breaches, each of these obligations has a specific implication that most existing incident response playbooks do not address.
The practical gaps are: incident classification criteria that do not include AI-assisted attack scenarios; response playbooks that assume a human attacker operating at human speed rather than an AI agent operating at machine speed; post-incident analysis processes that do not specifically examine how AI capabilities were exploited; and reporting chains that have not been updated to include AI-related incidents as a named category. Article 13's learning obligation is particularly important here — the ECB will expect to see evidence that institutions are updating their threat models based on documented AI attack capabilities, not just responding to incidents after the fact.
Pillar 5: TLPT Red-Teaming for AI Attack Vectors (Article 26)
Article 26 mandates Threat-Led Penetration Testing for Significant Institutions at least every three years, covering all critical or important functions on live production systems. The ECB's TIBER-EU SSM Implementation Guide published in November 2025 clarifies the standard: tests must be intelligence-led, scenarios must reflect real threat actor capabilities, and institutions must produce evidence that they are learning and improving from each test cycle — not just completing a periodic compliance exercise.
For institutions that have already completed a TLPT cycle, the question is whether the scenarios used reflected the current AI-assisted threat landscape. A TLPT conducted in 2023 or 2024 that did not include AI-assisted attack automation scenarios is not a defensible baseline for 2026 ECB scrutiny. The scope of TLPT must also include AI vendor dependencies — if a critical function relies on a cloud AI API, that dependency is in scope for the test. Institutions that treat TLPT as an isolated three-year exam rather than a continuous resilience programme are accumulating regulatory exposure between cycles.
Pillar 6: Board and Governance (Articles 5 and 6)
Article 5 places the management body at the centre of ICT risk governance. The management body must formally approve the ICT risk management framework, take direct responsibility for ICT risk, and ensure that adequate resources and capabilities are in place. Article 6 requires the framework to be recorded, periodically reviewed, and internally audited by personnel with the necessary expertise.
For AI risk specifically, this means the board cannot delegate the question to IT middle management. The fiduciary exposure from an AI-assisted breach — particularly one that a regulator determines could have been anticipated and mitigated — sits at director level. The practical governance requirements are: formal board sign-off on the AI vendor due diligence process; AI risk as a standing agenda item on the risk committee; documented board-level awareness of AI-assisted threat scenarios including Mythos-class capabilities; and evidence that the management body has reviewed and approved the institution's TLPT programme and its AI-specific scope.
The EU AI Act Layer: A Second Compliance Clock Running Simultaneously
DORA is not the only regulatory framework that applies to AI vendor relationships in financial services. The EU AI Act (Regulation EU 2024/1689) adds a second layer that runs simultaneously. A single AI vendor relationship can trigger obligations under both frameworks at the same time, and a vendor can satisfy one and fail the other.
DORA governs operational resilience, concentration risk, and contractual adequacy. The EU AI Act governs algorithmic transparency, fairness, human oversight, and conformity assessment for high-risk AI systems. Financial institutions that use AI for credit risk decisioning, insurance underwriting, or employment-related decisions are deployers of high-risk AI systems under the EU AI Act's Annex III classification. As a deployer, the institution must ensure appropriate human oversight, monitor the AI system for risks, report serious incidents to national competent authorities, and maintain documentation sufficient to demonstrate compliance.
The EU AI Act's Annex III high-risk obligations were originally scheduled for August 2, 2026. The Digital Omnibus on AI, agreed politically on May 7, 2026, would extend this deadline to December 2, 2027 — but as of this writing, the Omnibus has not been formally adopted or published in the Official Journal of the European Union. Until formal adoption occurs, the August 2, 2026 deadline remains operative. Institutions should continue compliance preparations in line with the existing deadline, as DLA Piper's April 2026 guidance confirmed.
What the Risk Committee Agenda Should Look Like Now
The question that regulators will ask — and that no board wants to answer unprepared — is not "do you have an AI policy?" It is "can you demonstrate, with documentary evidence, that you have assessed your AI vendors against Articles 28-30, that your TLPT scenarios reflect current AI-assisted threat actor capabilities, that your incident response playbooks cover AI-assisted breach scenarios, and that your management body has formally approved and reviewed all of the above?"
The institutions that will navigate the next wave of regulatory scrutiny without incident are the ones that treat AI risk governance as a board-level fiduciary obligation now, before they are required to explain a gap to the ECB, PRA, or BaFin. The checklist above is the minimum. The institutions that move beyond compliance to genuine operational resilience — continuous TLPT cycles, real-time AI vendor monitoring, board-level AI risk literacy — are the ones that will not be in the news for the wrong reasons.
Finance is the opening act. Every sector with networked infrastructure and legacy code faces this wave next. The question is whether your board is asking the right questions before the regulator does.
About the Author
Modi Elnadi is Founder and Director of Marketing and AI Growth at Integrated.Social, a London-based B2B AI growth marketing agency. Modi works at the intersection of agentic AI strategy, regulatory risk communication, and B2B demand generation for financial services, technology, and professional services clients. He has built AI governance communication frameworks for commercial and compliance stakeholders, translating complex regulatory obligations — including DORA, the EU AI Act, and the UK's AI Cyber Code of Practice — into commercially actionable board-level intelligence. His work spans agentic AI deployment strategy, AI search optimisation, and the pipeline measurement systems that make AI marketing programmes commercially accountable. He writes regularly on AI risk governance, B2B GTM strategy, and the regulatory frameworks shaping enterprise AI adoption in 2026.
