EU AI Act + DORA Intersection Compliance Stack Finale: Complete Developer Checklist for Dual-Regulated Institutions (2026)

Post #1581 in the sota.io EU Cyber Compliance Series

This is the fifth and final post in the EU AI Act + DORA Intersection series. Part 1 introduced the dual-compliance landscape for FinTech and InsurTech developers. Part 2 focused on ICT third-party AI vendor governance under DORA Art.28–31 and EU AI Act Art.25. Part 3 built the unified incident reporting playbook for AI system failures. Part 4 addressed MiCA CASPs operating under all three regimes simultaneously.

This finale brings together every obligation from the series into a single, actionable 55-item developer checklist — the master compliance map for any institution subject to both DORA and the EU AI Act. If you are a developer, architect, or compliance engineer at a bank, insurer, investment firm, CASP, or critical infrastructure provider that uses AI, this is your pre-August 2026 readiness reference.

Why the Intersection Matters More Than Either Regulation Alone

Neither DORA nor the EU AI Act was designed specifically for the other. DORA (Regulation (EU) 2022/2554) entered into force on 16 January 2023 and has been fully applicable since 17 January 2025. The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024, with the most significant obligations for high-risk AI systems under Title III becoming enforceable on 2 August 2026.

Yet for any financial institution that uses AI, these two regulations interact at every layer of the technology stack:

• DORA Art.9 mandates ICT security policies that must cover the development and testing lifecycle of ICT systems — the same lifecycle that EU AI Act Art.9 and Art.17 govern for high-risk AI systems through risk management systems and quality management frameworks.
• DORA Art.17–19 establish a tiered major incident reporting framework with timelines of 4 hours (initial notification), 24 hours (intermediate report), and 1 month (final report). EU AI Act Art.73 requires providers to report serious AI system incidents to national market surveillance authorities — and these events often overlap.
• DORA Art.28–30 govern the full ICT third-party risk lifecycle, from pre-contractual due diligence through exit strategies. When the ICT third party is an AI model provider or AI-as-a-service vendor, EU AI Act Art.25 imposes additional importer and distributor obligations on the deploying institution.
• DORA Art.26 requires that institutions maintain and test ICT business continuity policies. For AI systems, this intersects with EU AI Act Art.9(7)'s requirement for human oversight mechanisms and Art.14's mandate for human oversight specifically for high-risk AI.

The compliance gap — where institutions have addressed DORA but not yet mapped their AI systems to AI Act obligations, or vice versa — is the primary regulatory risk before August 2026.

The Combined Obligation Map: Matching DORA Articles to EU AI Act Equivalents

Before the checklist, understanding which obligations from each regulation address the same underlying risk makes implementation far more efficient. The following mapping shows where the regulations either align (same action satisfies both), layer (DORA sets the floor, AI Act raises it), or diverge (distinct and additive obligations).

ICT Risk Management (DORA Art.5–14) ↔ AI Risk Management (EU AI Act Art.9)

DORA Art.5 requires the management body to maintain ultimate responsibility for ICT risk management. EU AI Act Art.9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. These obligations align at the governance level — the same executive accountability structure can satisfy both — but diverge at the operational level. DORA ICT risk management focuses on confidentiality, integrity, and availability of ICT systems. EU AI Act Art.9(2) specifies that the AI risk management system must address risks to health, safety, and fundamental rights — a different scope requiring separate risk registers.

Action required: Maintain two distinct but cross-referenced risk registers: one for ICT/operational risk under DORA, one for AI system risk under EU AI Act Art.9. The management body approval process can be shared; the risk categories cannot be merged.

DORA Art.9 requires ICT security policies for network security, data leakage prevention, and data integrity. EU AI Act Art.10 and Art.12 require data governance and logging obligations for high-risk AI. These layer: AI Act Art.10 data governance applies specifically to training, validation, and test datasets, which DORA's generic data security policies do not address. Build AI-specific data governance policies that reference and extend your DORA ICT security framework.

Testing (DORA Art.24–26) ↔ AI System Testing (EU AI Act Art.9 and Art.15)

DORA Art.24 requires digital operational resilience testing, including advanced threat-led penetration testing (TLPT) for systemically important institutions. EU AI Act Art.9(8) requires that high-risk AI providers test their systems to identify the most appropriate risk management measures. Art.15 adds specific robustness, accuracy, and cybersecurity testing requirements. These obligations are additive: DORA TLPT tests infrastructure resilience; AI Act Art.15 testing targets model-level robustness and adversarial input resistance. Both are required for AI systems deployed in DORA-regulated contexts.

Incident Reporting (DORA Art.17–19) ↔ AI Incident Reporting (EU AI Act Art.73)

This is the highest-stakes intersection. The timelines differ, the authorities differ, and the definitions differ — but the triggering events frequently overlap.

DORA major ICT incident (Art.17): An ICT incident affecting the institution's operations, clients, or financial system stability, classified as major under the RTS criteria. Report to national competent authority (financial supervisor) within 4 hours of classification.

EU AI Act serious incident (Art.73): A malfunction or misuse of an AI system that results in death, serious bodily harm, significant disruption of critical infrastructure, or serious fundamental rights violations. Report to national market surveillance authority within 2 working days of the provider becoming aware (for life-threatening or fatal incidents immediately).

When an AI system failure causes significant service disruption at a financial institution, both reporting obligations may trigger simultaneously to different national authorities. The unified playbook from Part 3 of this series details the dual-reporting workflow.

Third-Party AI Vendors (DORA Art.28–31) ↔ AI Importers and Distributors (EU AI Act Art.25)

For any external AI model or AI-as-a-service provider, the dual obligations under DORA and the AI Act compound significantly. DORA Art.28 requires written contractual arrangements with ICT third-party providers covering security requirements, audit rights, termination provisions, and exit strategies. EU AI Act Art.25 requires importers to verify that the AI system conforms to the Act and that the provider has completed conformity assessment.

These are not alternatives — both sets of contractual provisions are required. The AI Act conformity declaration (Art.47) and CE marking (Art.48–49) are AI Act instruments; DORA Art.30's contractual requirements for incident notification rights and data portability are DORA instruments. Build vendor contracts that contain both sets of clauses in distinct sections.

The 55-Item Master Developer Checklist

This checklist covers all five posts in the series. Each item includes the triggering regulation and article, the responsible team, and the verification evidence required.

Section A: Governance and Accountability (Items 1–8)

Item 1: Management body DORA ICT risk mandate (DORA Art.5) Assign explicit board-level responsibility for ICT risk management. Document in board minutes. Evidence: board resolution or risk committee charter naming the responsible member.

Item 2: AI system provider accountability (EU AI Act Art.16) For each high-risk AI system you develop or deploy, identify the "provider" as defined in EU AI Act Art.3(3) and document internal responsibility. Evidence: AI system register with named providers per system.

Item 3: Deployer obligations assignment (EU AI Act Art.26) For each high-risk AI system you use but did not develop, document your deployer obligations including human oversight implementation, fundamental rights impact assessment (Art.27), and use-case restrictions. Evidence: deployer obligation matrix per system.

Item 4: DORA ICT risk management framework (DORA Art.5–13) Maintain a documented ICT risk management framework covering identification, protection, detection, response, and recovery for all ICT systems. Evidence: approved ICT Risk Management Framework document.

Item 5: AI risk management system (EU AI Act Art.9) Establish a separate risk management system specifically for high-risk AI systems, covering the entire lifecycle from development through decommissioning. Evidence: AI Risk Management System document with risk register.

Item 6: DORA information security policies (DORA Art.9) Implement ICT security policies covering data classification, network security, access control, encryption, and physical security. Evidence: approved DORA Information Security Policy set.

Item 7: AI Act quality management system (EU AI Act Art.17) Establish a quality management system for high-risk AI covering design specifications, testing procedures, change management, and post-market monitoring. Evidence: QMS documentation with version control.

Item 8: Business continuity for AI systems (DORA Art.11, EU AI Act Art.9) Document ICT business continuity policy under DORA Art.11 that explicitly addresses AI system failures as a business continuity scenario. Evidence: BCM documentation with AI failure scenarios.

Section B: Data Governance (Items 9–14)

Item 9: ICT asset inventory including AI components (DORA Art.8) Maintain a complete inventory of ICT assets including all AI models, datasets, and AI infrastructure components. Evidence: updated ICT asset register with AI system entries.

Item 10: Training data governance (EU AI Act Art.10) For high-risk AI systems you develop, document data governance policies covering training data collection, labelling, validation, and dataset management. Evidence: data governance policy with dataset documentation.

Item 11: Data quality validation procedures (EU AI Act Art.10(3)) Implement and document procedures for detecting and addressing data gaps, biases, and quality issues in training and validation datasets. Evidence: data quality assessment reports per model.

Item 12: Logging and record-keeping (EU AI Act Art.12) Implement automatic logging of events enabling post-deployment traceability for each high-risk AI system. Logs must cover at minimum input data characteristics and system outputs. Evidence: logging architecture documentation and sample log outputs.

Item 13: Log retention policies (EU AI Act Art.12, DORA Art.9) Align AI Act logging retention (minimum 6 months for deployers under Art.12(3), longer for certain categories) with DORA data retention policies. Evidence: documented retention schedule.

Item 14: Personal data processing in AI training (EU AI Act Art.10(5), GDPR) For AI systems trained on personal data, document the legal basis and implement privacy-by-design measures. Evidence: DPIA if required, data minimisation documentation.

Section C: Development and Testing (Items 15–22)

Item 15: Technical documentation for high-risk AI (EU AI Act Art.11) Prepare and maintain technical documentation as specified in Annex IV of the EU AI Act for each high-risk AI system. This must be available to national authorities on request. Evidence: completed Annex IV technical documentation per system.

Item 16: AI system accuracy, robustness, and cybersecurity testing (EU AI Act Art.15) Test high-risk AI systems for accuracy metrics, resilience against errors, and cybersecurity against adversarial inputs. Evidence: test results documentation and robustness metrics.

Item 17: DORA resilience testing (DORA Art.24–26) Conduct digital operational resilience testing covering at minimum vulnerability assessments, network security testing, and for systemically important entities, threat-led penetration testing. Evidence: TLPT assessment report or vulnerability scan results.

Item 18: Human oversight mechanisms (EU AI Act Art.14) For high-risk AI systems, implement technical measures enabling human operators to monitor and intervene in AI outputs. Document override procedures. Evidence: human oversight system architecture and procedures.

Item 19: Conformity assessment (EU AI Act Art.43) Complete conformity assessment for each high-risk AI system before deployment. For most systems in Annex III this is self-assessment; some categories require third-party assessment. Evidence: completed conformity assessment report.

Item 20: EU Declaration of Conformity (EU AI Act Art.47) Draft and sign the EU Declaration of Conformity for each high-risk AI system subject to the Act. Evidence: signed DoC per system.

Item 21: CE marking affixing (EU AI Act Art.48–49) Affix CE marking to high-risk AI systems (or their documentation where physical marking is not applicable). Evidence: CE marking procedure and applied marking.

Item 22: Registration in EU AI Act database (EU AI Act Art.51) Register high-risk AI systems in the EU AI Act database maintained by the European AI Office before deployment. Evidence: registration confirmation and database entry reference.

Section D: Third-Party AI Vendor Management (Items 23–32)

Item 23: ICT third-party provider register (DORA Art.28) Maintain a complete register of all ICT third-party providers, including AI model providers and AI-as-a-service vendors. Evidence: ICT third-party register with risk classification.

Item 24: DORA contractual requirements for AI vendors (DORA Art.30) Ensure written contracts with AI ICT third-party providers include: service level requirements, data security obligations, incident notification timelines, audit rights, and exit assistance. Evidence: contract templates and executed agreements.

Item 25: Exit strategy and substitutability assessment (DORA Art.29) For each critical AI ICT third-party provider, document an exit strategy covering data portability, migration timelines, and substitute provider options. Evidence: exit strategy documents per critical vendor.

Item 26: AI importer conformity verification (EU AI Act Art.25(1)) Before deploying an externally developed high-risk AI system, verify that the provider has completed conformity assessment and maintains technical documentation. Evidence: received DoC and conformity assessment summary from provider.

Item 27: AI distributor due diligence (EU AI Act Art.25(4)) If you distribute high-risk AI systems developed by a third party, verify that CE marking and required documentation are present and that the system has not been modified in ways affecting conformity. Evidence: distribution checklist per distributed system.

Item 28: AI vendor audit rights (DORA Art.30, EU AI Act Art.25) Negotiate and exercise audit rights for critical AI vendors. At minimum, request evidence of their AI Act conformity assessment and DORA ICT security compliance. Evidence: vendor audit reports or attestations.

Item 29: Sub-contractor AI risk cascade (DORA Art.31) Document the ICT sub-contractor chain for critical AI providers and apply the same due diligence requirements to material sub-contractors. Evidence: sub-contractor register and risk assessment.

Item 30: DORA critical ICT third-party provider (CTPP) compliance (DORA Art.31) If a regulator designates any of your AI vendors as a Critical ICT Third-Party Provider under DORA, adapt your oversight framework to the CTPP requirements. Evidence: CTPP designation monitoring procedure.

Item 31: AI vendor concentration risk assessment Assess concentration risk where multiple AI systems depend on the same vendor or foundation model. Document mitigation measures. Evidence: AI dependency map and concentration risk report.

Item 32: DORA notification of ICT third-party arrangements (DORA Art.28(3)) Some ICT third-party arrangements must be reported to supervisory authorities. Verify whether any AI vendor contracts trigger notification thresholds. Evidence: notification assessment per contract.

Section E: Incident Reporting and Response (Items 33–42)

Item 33: Major ICT incident classification criteria (DORA Art.17) Implement the classification criteria from the DORA RTS to distinguish between significant and major ICT incidents. Build classification procedures into your incident response workflow. Evidence: incident classification policy with DORA RTS criteria.

Item 34: DORA 4-hour initial notification readiness (DORA Art.18) Establish procedures enabling the 4-hour initial major incident notification to the national competent authority. Designate the notification recipient contact and template. Evidence: notification procedure with NCA contact details and template.

Item 35: DORA 24-hour intermediate report (DORA Art.19) Prepare the intermediate report template and assign responsibility for producing it within 24 hours of major incident classification. Evidence: intermediate report template and assignment.

Item 36: DORA 1-month final incident report Establish the post-incident review process to produce the final major incident report within one month of the initial notification. Evidence: final report template and review process.

Item 37: AI Act serious incident identification (EU AI Act Art.73) Define criteria for identifying serious incidents involving your high-risk AI systems — specifically events causing or potentially causing death, serious injury, critical infrastructure disruption, or fundamental rights violations. Evidence: AI Act serious incident classification procedure.

Item 38: AI Act serious incident reporting workflow (EU AI Act Art.73) Build the notification workflow to the national market surveillance authority (separate from DORA's NCA) for AI Act serious incidents. Designate responsibility. Evidence: dual-authority notification workflow and contact registry.

Item 39: Dual reporting decision matrix For any AI system operating in a DORA-regulated entity, maintain a decision matrix that identifies when an AI-related event triggers DORA major incident classification, EU AI Act serious incident reporting, both, or neither. Evidence: completed decision matrix.

Item 40: AI system post-market monitoring (EU AI Act Art.72) Implement a post-market monitoring system to collect and review data on deployed high-risk AI system performance and identify emerging serious incidents proactively. Evidence: monitoring architecture and data collection procedures.

Item 41: Internal reporting channels for AI concerns Establish internal channels for employees and external parties to report concerns about AI system compliance or safety, consistent with EU Whistleblower Protection Directive 2019/1937 obligations. Evidence: internal reporting procedure and designated contact.

Item 42: Incident response testing (DORA Art.26) Include AI-specific failure scenarios in ICT incident response exercises and tabletop simulations. Evidence: exercise records with AI failure scenarios.

Section F: Transparency and Human Oversight (Items 43–48)

Item 43: High-risk AI system transparency to deployers (EU AI Act Art.13) Provide deployers of your high-risk AI systems with instructions for use covering intended purpose, performance limitations, human oversight requirements, and prohibited uses. Evidence: Instructions for Use document per system.

Item 44: GPAI model transparency (EU AI Act Art.50) If you develop or deploy general-purpose AI (GPAI) models, implement technical measures for synthetic content labelling (watermarking), maintain model documentation, and provide model cards. Evidence: GPAI model documentation and watermarking implementation for applicable systems.

Item 45: AI-generated content disclosure to end users (EU AI Act Art.50(4)) Implement disclosure mechanisms to inform users when they interact with AI systems or AI-generated content. Exemptions apply for clearly obvious AI contexts. Evidence: disclosure implementation and UI documentation.

Item 46: Fundamental Rights Impact Assessment (EU AI Act Art.27) For deployers of high-risk AI systems in public administration or services affecting fundamental rights, complete a Fundamental Rights Impact Assessment before deployment. Evidence: completed FRIA per applicable deployment.

Item 47: Human oversight procedures for high-risk AI (EU AI Act Art.14) Document the human oversight procedures for each high-risk AI system, specifying who monitors outputs, what alert thresholds trigger human review, and how operators override automated decisions. Evidence: human oversight procedure per system.

Item 48: DORA training and awareness for AI resilience (DORA Art.13) Include AI-specific ICT risk and resilience training in your DORA staff training programme. Evidence: training records and curriculum.

Section G: MiCA CASP Specific (Items 49–52)

Item 49: MiCA CASP authorisation scope mapping If you are a MiCA-authorised CASP using AI for trading, KYC, or fraud detection, map each AI system to the MiCA service category it supports and verify which AI Act risk classification applies. Evidence: AI system to MiCA service mapping matrix.

Item 50: DORA applicability verification for CASPs Confirm that your CASP is within DORA scope (MiCA Art.59 authorisation is the trigger) and that your DORA implementation covers AI systems used in CASP operations. Evidence: DORA scope assessment document.

Item 51: MiCA client complaints handling for AI decisions For AI-assisted decisions affecting clients (automated trading, KYC rejections), ensure the MiCA complaints procedure (Articles 71 and 72 of MiCA's Title IV operational requirements) allows clients to challenge AI-assisted decisions effectively. Evidence: complaints procedure with AI decision escalation path.

Item 52: Algorithmic trading AI governance For AI-based algorithmic trading systems, verify compliance with both DORA ICT risk management (Art.5–13) and any applicable AI Act high-risk classification, plus MiFID II algorithmic trading controls where applicable. Evidence: algorithmic trading governance framework.

Section H: Timeline and Pre-August 2026 Priorities (Items 53–55)

Item 53: High-risk AI system inventory completion Complete the inventory of all AI systems you develop or deploy, classify each under the EU AI Act Annex III categories, and identify all high-risk systems. This is the precondition for items 15, 19, 20, 21, and 22. Target: completed by 30 June 2026.

Item 54: Conformity assessment completion Complete conformity assessments for all identified high-risk AI systems. For systems requiring third-party assessment, notified body engagement timelines may be 3–6 months — initiate immediately. Target: completed by 20 July 2026 to allow CE marking and registration before the August deadline.

Item 55: Registration of high-risk AI systems in EU database Submit registrations for all high-risk AI systems via the EU AI Act database portal before 2 August 2026. Registration is mandatory for providers before market placement of high-risk AI systems. Target: submitted by 1 August 2026.

Implementation Roadmap: June to August 2026

Given the 55-day window remaining until the AI Act deadline, the following phased approach prioritises the highest-risk gaps.

Weeks 1–2 (now through 22 June 2026): Complete the AI system inventory (Item 53). Map all AI systems to Annex III categories. Identify any gaps in DORA ICT third-party registers for AI vendors (Item 23). Begin technical documentation (Item 15) for identified high-risk systems.

Weeks 3–4 (23 June – 6 July 2026): Complete conformity assessments for self-assessment eligible systems (Item 19). Draft EU Declarations of Conformity (Item 20). Implement logging mechanisms for high-risk AI (Item 12). Complete AI risk management system documentation (Item 5).

Weeks 5–7 (7–25 July 2026): Finalise CE marking (Item 21). Complete human oversight procedures (Item 47). Implement dual incident reporting workflow (Item 38–39). Conduct AI system robustness testing (Item 16).

Week 8 (26 July – 1 August 2026): Register all high-risk AI systems in the EU database (Item 55). Verify that all DORA contractual updates for AI vendors are complete (Item 24). Issue final compliance attestation.

The EU-Native Toolchain for Dual-Regulated Institutions

For institutions under both DORA and the EU AI Act, the choice of development and deployment infrastructure has direct compliance implications. DORA Art.9 mandates that ICT security policies cover the full development lifecycle. EU AI Act Art.10 requires data governance that includes controls over where training data is stored and processed. Art.17's QMS requirements mean that your CI/CD pipeline and model registry need audit trails meeting EU AI Act standards.

Deploying on infrastructure subject to US CLOUD Act jurisdiction creates a residual risk: US authorities could request access to AI training data, model weights, or operational logs in ways that conflict with GDPR, DORA data classification requirements, and EU AI Act Art.10's data governance standards. EU-native infrastructure — hosted in the EU, operated by EU-headquartered companies, with no parent company subject to extraterritorial data access laws — eliminates this jurisdiction conflict.

The EUCS High certification level addresses precisely this need: HSM-backed key management, EU-only data access controls, and EU-established legal entities operating the cloud infrastructure.

sota.io is designed as infrastructure for EU-regulated SaaS developers. All infrastructure runs on EU-certified cloud, under EU jurisdiction, with data residency guarantees compatible with DORA Art.9 data security requirements and EU AI Act Art.10 data governance. For development teams building dual-regulated AI applications, removing infrastructure compliance risk means the compliance work focuses where it should: on the AI system itself.

Conclusion: The Intersection Is the Work

Throughout this series, the central finding has been consistent: DORA and the EU AI Act do not create duplicate obligations that can be satisfied once — they create overlapping frameworks that each require independent implementation, with coordination required to avoid gaps.

The 55 items in this checklist represent the union of both sets of obligations for institutions subject to both regulations. No shortcut exists: a financial institution deploying high-risk AI cannot satisfy the AI Act simply by extending its DORA compliance programme, nor can it rely on AI Act conformity to substitute for DORA ICT risk management controls.

What the intersection does enable, when managed intentionally, is efficiency: a unified governance structure, shared evidence repositories, a single vendor management process that satisfies both DORA Art.28–31 and EU AI Act Art.25 requirements, and a dual incident reporting workflow that eliminates duplicated classification work.

The August 2026 deadline is the forcing function. For developers and compliance engineers at dual-regulated institutions, the readiness question is not whether to start — it is how much of the 55-item checklist remains incomplete with 55 days left.

This concludes the EU AI Act + DORA Intersection series. For the foundational dual-compliance overview, see Part 1. For AI vendor governance specifics, see Part 2. For the unified incident reporting playbook, see Part 3. For the crypto-specific MiCA CASP guide, see Part 4.