Who this is for: Banks, insurance companies, investment firms, payment institutions, and crypto-asset service providers deploying AI/ML in the EU. ICT risk managers, compliance officers, CISOs at financial entities. Third-party ICT service providers offering AI-powered services to EU-regulated financial entities. GRC architects building unified DORA + EU AI Act compliance frameworks.
In force since January 17, 2025. DORA (EU Regulation 2022/2554) applies to virtually all EU-regulated financial entities. Although DORA does not mention AI explicitly, AI systems are ICT systems and must be governed within the DORA ICT risk management framework. Article 9(10) of the EU AI Act explicitly permits integration of AI risk management into DORA ICT risk management procedures. Penalties: up to 2% of total worldwide annual turnover. Board members face personal fines up to EUR 1,000,000.
Contents
1. Overview 2. The Five DORA Pillars and AI 3. Obligation-to-Procedure Mapping 4. Detailed Procedure Cards 5. Quick Reference 6. Quick Start 7. References1. Overview
The Digital Operational Resilience Act (DORA) establishes a comprehensive framework for managing ICT risks in the EU financial sector. It applies to over 22,000 financial entities and ICT third-party service providers. AI/ML systems fall squarely within DORA's scope as ICT systems that process data, make decisions, and interact with critical business processes.
For financial entities deploying AI, DORA creates five interlocking compliance obligations that apply to every AI system used in operations, risk management, customer interaction, or decision support. DORA's requirements are complementary to the EU AI Act: Article 9(10) of the AI Act explicitly enables organizations to embed AI risk management into their existing DORA ICT risk management framework, creating a unified governance structure.
In January 2026, Germany's BaFin issued non-binding guidance clarifying that AI-based systems must be integrated into DORA-compliant ICT risk management frameworks, signaling that supervisory expectations include AI even where DORA's text does not name it explicitly.
2. The Five DORA Pillars and AI
| Pillar | DORA Articles | AI Relevance |
|---|---|---|
| 1. ICT Risk Management | Art. 5-16 | AI systems must be identified, classified, documented, and governed within the ICT risk management framework. Includes AI asset inventory, access controls, change management, and business continuity for AI services. |
| 2. ICT Incident Reporting | Art. 17-23 | AI-related incidents (model failures, data breaches, adversarial attacks, hallucination-driven errors) must be detected, classified, reported, and resolved per DORA timelines. Major incidents require notification to competent authorities. |
| 3. Digital Operational Resilience Testing | Art. 24-27 | AI systems must be included in resilience testing programs. Significant entities must conduct threat-led penetration testing (TLPT) that covers AI attack surfaces including prompt injection, model extraction, and data poisoning. |
| 4. Third-Party Risk Management | Art. 28-44 | Third-party AI providers (model APIs, embedding services, managed ML platforms) are ICT third-party service providers under DORA. Contracts must include audit rights, data location, subcontracting controls, and exit strategies. |
| 5. Information Sharing | Art. 45 | Voluntary sharing of AI threat intelligence, adversarial techniques, and model vulnerability information within trusted communities. |
3. Obligation-to-Procedure Mapping
| DORA Obligation | SWT3 Procedure | What It Witnesses | DORA Article |
|---|---|---|---|
| ICT Governance | AI-GOV.1 | AI governance policy established within ICT risk management framework | Art. 5 |
| ICT Risk Identification | AI-RISK.1 | AI system risks identified, categorized, and assessed | Art. 6-7 |
| Incident Detection | AI-INCIDENT.1 | AI-related incident detected, classified, and reported | Art. 17-19 |
| Incident Response | AI-IR.1 | AI incident response capability exercised | Art. 17 |
| Resilience Testing | AI-ROBUST.1 | AI system resilience tested under stress conditions | Art. 24-25 |
| Threat-Led Testing | AI-REDTEAM.1 | Adversarial testing of AI attack surfaces (TLPT) | Art. 26 |
| Third-Party Assessment | AI-GOV.5 | Third-party AI vendor risk assessment completed | Art. 28-30 |
| Supply Chain Risk | AI-SUPPLY.1 | AI supply chain risk assessed (model providers, data sources, APIs) | Art. 28 |
| Audit Trail | AI-AUDIT.1 | AI system audit log integrity verified | Art. 12 |
| Record Keeping | AI-LOG.1 | AI system logs retained for required period | Art. 12 |
| Asset Identification | AI-PERF.1 | AI system performance metrics tracked as ICT asset | Art. 8 |
| Protection/Prevention | AI-CYBER.1 | AI system cybersecurity controls attested | Art. 9 |
4. Detailed Procedure Cards
ICT Risk Management for AI Systems (Pillar 1)
DORA requires: Financial entities must establish an ICT risk management framework that identifies, classifies, and documents all ICT assets, including AI systems. The framework must assess risks, define tolerance levels, implement safeguards, and monitor continuously. The management body bears ultimate responsibility for ICT risk management (Art. 5(2)).
How SWT3 addresses it: The witnessRisk() call records the risk assessment for each AI system, including risk categories (operational, security, model, data), severity ratings, and mitigation status. Each assessment creates a verifiable record that AI systems are governed within the broader ICT risk framework.
AI-RISK.1 anchors should cover every AI system in the ICT asset inventory. Factor A records the risk category. Factor B records the severity. Factor C records mitigation status. Cross-reference with AI-GOV.1 to demonstrate governance is in place, and with AI-PERF.1 to show the AI system is tracked in the ICT asset register. The management body's approval should be evidenced by governance anchors predating deployment.
ICT Incident Reporting for AI (Pillar 2)
DORA requires: Financial entities must detect, manage, and report ICT-related incidents. Major incidents must be reported to competent authorities within prescribed timeframes (initial notification within 4 hours of classification, intermediate report within 72 hours, final report within one month). AI-specific incidents include model failures affecting critical services, adversarial attacks, data breaches through model outputs, and hallucination-driven operational errors.
How SWT3 addresses it: AI-INCIDENT.1 records incident detection, classification, and reporting. AI-IR.1 records the incident response actions taken. Together, they create a timestamped chain from detection through resolution that proves compliance with DORA reporting timelines.
The time delta between the first AI-INCIDENT.1 anchor (detection) and the classification anchor must not exceed 4 hours for major incidents. Cross-reference AI-IR.1 anchors to demonstrate response actions were taken. The complete chain from detection to resolution should be traceable. For AI-specific incidents, correlate with AI-DRIFT.1 (model drift), AI-SEC.1 (adversarial attack), or AI-SAFE.1 (safety failure) to identify the root cause.
Resilience Testing and TLPT for AI (Pillar 3)
DORA requires: Financial entities must establish digital operational resilience testing programs proportional to their size and risk profile. Significant entities must conduct threat-led penetration testing (TLPT) at least every three years. For AI systems, resilience testing should cover AI-specific attack surfaces including prompt injection, model extraction, data poisoning, and adversarial inputs.
How SWT3 addresses it: AI-ROBUST.1 records resilience testing under stress conditions (degraded inputs, high volume, component failure). AI-REDTEAM.1 records adversarial red team campaigns targeting AI-specific vulnerabilities. Both produce anchors that prove testing was conducted and document outcomes.
AI-ROBUST.1 anchors should appear at least annually (proportionality principle). AI-REDTEAM.1 anchors should appear at least every three years for TLPT-scoped entities. Factor A identifies the test type (stress, adversarial, chaos). Factor B records the test scope. Factor C records findings. Cross-reference with AI-SEC.1 to show that findings from testing informed security control updates.
Third-Party AI Provider Risk (Pillar 4)
DORA requires: Financial entities must manage risks from ICT third-party service providers, including pre-contract due diligence, contractual requirements (audit rights, data location, subcontracting), ongoing monitoring, and exit strategies. For AI, this covers model API providers (OpenAI, Anthropic, Google), managed ML platforms, embedding services, and any third-party component in the AI pipeline.
How SWT3 addresses it: AI-GOV.5 records the third-party vendor assessment, including due diligence findings, contractual compliance, and risk rating. AI-SUPPLY.1 tracks the broader AI supply chain, including model provenance, data source risks, and component dependencies.
AI-GOV.5 anchors should exist for every third-party AI provider before contract execution. Factor A identifies the provider. Factor C records the risk rating and contractual compliance status. AI-SUPPLY.1 should cover the complete AI supply chain. Cross-reference with AI-SBOM.1 for the component inventory. For critical third-party providers, demonstrate that exit strategies have been documented.
5. Quick Reference
| Examiner Question | Where to Look |
|---|---|
| Are AI systems in the ICT asset register? | AI-PERF.1 anchors for each AI system. Cross-reference with AI-GOV.1 for governance coverage. |
| Has AI risk been assessed within the ICT risk framework? | AI-RISK.1 anchors. Factor A = risk category. Factor C = mitigation status. Must cover all AI systems. |
| How are AI incidents detected and reported? | AI-INCIDENT.1 chain from detection to resolution. 4-hour classification window for major incidents. AI-IR.1 for response actions. |
| Has resilience testing included AI attack surfaces? | AI-ROBUST.1 (annual) + AI-REDTEAM.1 (TLPT every 3 years). Factor A = test type. Factor C = findings. |
| Are third-party AI providers assessed and monitored? | AI-GOV.5 for vendor assessment. AI-SUPPLY.1 for supply chain. AI-SBOM.1 for component inventory. |
| Are AI system audit trails maintained? | AI-AUDIT.1 for integrity. AI-LOG.1 for retention. Both must cover the DORA-required retention period. |
| Are AI cybersecurity controls in place? | AI-CYBER.1 attestation. Cross-reference with AI-SEC.1 (threat detection) and AI-SEC.2 (input validation). |
6. Quick Start
pip install swt3-ai
# Initialize with the financial services profile
swt3 init --profile finserv-governance --tenant YOUR_TENANT
# Run the demo to see witness anchors generated
python -m swt3_ai.demo
# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile finserv-governance
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
7. References
- DORA: Regulation (EU) 2022/2554, Official Journal of the European Union
- EIOPA: Digital Operational Resilience Act
- FTI Consulting: AI and DORA
- IAPP: From NIS2 to DORA and the AI Act
- Related: SR 11-7 Model Risk Management Overlay
- Related: NIS2 Directive Crosswalk
- Related: EU AI Act Crosswalk
- SWT3 UCT Registry, 280 procedures across 9 namespaces
- SDK Documentation, Python, TypeScript, and 5 additional language SDKs