Audience: For CISOs, compliance officers, and IT risk managers at EU-regulated financial institutions.
DORA (EU 2022/2554) applies to all EU financial entities since January 2025. ECB supervisory letter SSM-2026-0301 requires AI-cyber action plans from significant institutions by October 31, 2026.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
1. Regulatory Landscape
The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) establishes a harmonized ICT risk management framework for all EU financial entities -- banks, insurers, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third-party service providers. DORA became applicable on January 17, 2025.
Five Pillars of DORA
| Pillar | Articles | Scope |
|---|---|---|
| ICT Risk Management | Art. 5--16 | Governance framework, identification, protection, detection, response, recovery, learning |
| Incident Reporting | Art. 17--23 | Classification, notification, and reporting of major ICT-related incidents |
| Resilience Testing | Art. 24--27 | Basic testing, advanced threat-led penetration testing (TLPT), third-party testing |
| Third-Party Risk | Art. 28--44 | ICT third-party risk management, oversight framework for critical providers |
| Information Sharing | Art. 45 | Voluntary cyber threat intelligence sharing arrangements |
DORA applies regardless of whether the ICT system in question uses AI. However, AI systems deployed in financial services are subject to DORA's requirements for any ICT function they support -- including model serving infrastructure, automated decision systems, and fraud detection pipelines. Where AI systems are also high-risk under the EU AI Act, both regulatory frameworks apply concurrently.
ECB Supervisory Context
ECB supervisory letter SSM-2026-0301 is a supervisory communication -- not binding law -- addressed to the 113 significant institutions (SIs) under direct ECB supervision. The letter reflects the ECB's observation that AI adoption in banking has outpaced governance maturity, particularly in cybersecurity controls around AI model deployment. It requests that SIs submit AI-cyber action plans by October 31, 2026, covering internet-facing asset inventory, vulnerability management for AI-specific attack surfaces, continuous monitoring of AI systems, and operational resilience of AI-dependent business processes.
While the ECB letter is not a separate regulatory framework, its expectations map directly to DORA obligations. This guide treats the ECB letter as a supervisory overlay on DORA -- identifying where ECB expectations create additional evidence requirements beyond the statutory minimum.
2. DORA ICT Risk Management Mapping (Art. 5--14)
DORA's ICT risk management chapter requires financial entities to establish, maintain, and continuously improve a comprehensive ICT risk management framework. The following table maps each article to the SWT3 witness procedures that record evidence of compliance. SWT3 does not implement these controls -- it witnesses that they were active and creates cryptographic anchors proving their state at a specific point in time.
| DORA Article | Requirement | SWT3 Procedure(s) | Evidence Recorded |
|---|---|---|---|
| Art. 5--6 | ICT risk management framework and governance | AI-GOV.1, AI-GOV.5 |
Governance policy attestation, board-level oversight documentation, risk appetite alignment |
| Art. 7 | ICT systems, protocols, and tools | AI-ENV.1, AI-ENV.2 |
Runtime environment attestation, infrastructure configuration state, dependency inventory |
| Art. 8 | Identification of ICT assets and risks | AI-SBOM.1, HBOM-INV.1 |
Software bill of materials hash, hardware inventory count, component baseline delta |
| Art. 9 | Protection and prevention | AI-SEC.1, AI-GRD.1, AI-CYBER.1 |
Security control attestation, guardrail activation state, cyber resilience posture |
| Art. 10 | Detection of anomalous activities | AI-DRIFT.1, AI-PERF.1 |
Drift detection threshold, performance degradation metrics, anomaly detection state |
| Art. 11 | Response and recovery | AI-SAFE.1, AI-SAFE.2, AI-INCIDENT.1 |
Kill switch availability, fallback activation readiness, incident response attestation |
| Art. 12 | Backup policies and restoration | AI-LCM.1 |
Lifecycle management state, model versioning, rollback capability attestation |
| Art. 13 | Learning and evolving | AI-AUDIT.1 |
Audit trail completeness, post-incident review documentation, lessons-learned attestation |
| Art. 14 | Communication | AI-TRANS.1 |
Transparency attestation, disclosure completeness, stakeholder notification state |
DORA does not prescribe specific technical implementations -- it requires that the ICT risk management framework be "comprehensive" and "well-documented." Query SWT3 anchors across AI-GOV.1, AI-SEC.1, AI-DRIFT.1, and AI-INCIDENT.1 to verify that governance, protection, detection, and response controls were active over the assessment period. Gaps in anchor cadence may indicate periods where controls were not operational.
Art. 5--6: Governance and Framework
ICT Risk Management Framework Witnessing
Witnesses that an AI governance policy exists and has been reviewed. Under DORA Article 5(2), the management body bears "ultimate responsibility" for the ICT risk management framework. AI-GOV.1 anchors provide timestamped evidence that governance documentation was current at the point of attestation.
Framework Review and Update Witnessing
Witnesses that the governance framework was reviewed and updated. DORA Article 6(5) requires the framework to be "reviewed at least once a year" and "upon the occurrence of major ICT-related incidents." Consecutive AI-GOV.5 anchors demonstrate review cadence.
Art. 8: Identification
ICT Asset Identification Witnessing
Witnesses that a software bill of materials was generated for an AI system. DORA Article 8(1) requires financial entities to "identify, classify and adequately document all ICT supported business functions, roles and responsibilities." An SBOM anchored via AI-SBOM.1 provides component-level evidence of ICT asset identification.
Infrastructure Asset Identification Witnessing
Witnesses that a hardware inventory was produced. DORA Article 8(4) requires entities to "identify all sources of ICT risk" including infrastructure dependencies. Hardware BOM anchors demonstrate that the physical compute layer supporting AI systems has been inventoried.
Art. 9--10: Protection and Detection
Protection and Prevention Witnessing
Witnesses that security controls around an AI system are active. DORA Article 9(2) requires "policies, procedures, protocols and tools on ICT security" that are "proportionate" to the ICT risk exposure. Security control anchors provide evidence that protective measures were operational.
Anomalous Activity Detection Witnessing
Witnesses that drift detection mechanisms are active for an AI model. DORA Article 10(1) requires "mechanisms to promptly detect anomalous activities." For AI systems, model drift is a primary anomaly signal -- performance degradation, distribution shift, or concept drift can indicate that the system is no longer operating as validated.
Continuous Monitoring Witnessing
Witnesses that AI model performance is being monitored. DORA Article 10(2) requires entities to "set up mechanisms to detect, in a timely manner, ICT network performance issues and ICT-related incidents." Performance monitoring anchors provide cadence evidence for detection capability.
Art. 11--12: Response, Recovery, and Backup
Response Mechanism Witnessing
Witnesses that a kill switch or emergency shutdown mechanism exists for an AI system. DORA Article 11(1) requires "a comprehensive ICT business continuity policy" including the ability to "quickly, appropriately and effectively respond" to ICT-related incidents. A kill switch anchor proves the mechanism was available at attestation time.
Recovery Readiness Witnessing
Witnesses that a fallback or manual override system is available. DORA Article 11(3) requires entities to "set up, maintain and periodically test" backup arrangements. Fallback anchors demonstrate that an alternative processing path exists if the AI system fails or must be withdrawn.
Incident Management Witnessing
Witnesses that incident response procedures are in place and have been exercised. DORA Article 11(6) requires "an adequate number of tests of the ICT business continuity plans." Incident response anchors record that the response capability was verified.
Backup and Restoration Witnessing
Witnesses AI model lifecycle management including versioning and rollback capability. DORA Article 12 requires backup policies that are "proportionate to the scale of the entity's operations." Lifecycle anchors demonstrate that model state can be restored to a known-good version.
Art. 13--14: Learning and Communication
Post-Incident Learning Witnessing
Witnesses that audit trail mechanisms are operational. DORA Article 13(1) requires financial entities to "have in place capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents." Audit anchors provide evidence that learning mechanisms are in place and that post-incident reviews are documented.
Communication and Disclosure Witnessing
Witnesses that transparency and disclosure obligations have been addressed. DORA Article 14 requires "communication plans" for both internal and external stakeholders. Transparency anchors record that disclosure documentation was current at attestation time.
3. DORA Third-Party Risk (Art. 28--30)
DORA Chapter V establishes a comprehensive third-party risk management framework. For AI systems, this is particularly relevant because most financial institutions rely on external providers for model training infrastructure, cloud compute, foundation models, and data pipelines. DORA Article 28(1) requires financial entities to "manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework."
| DORA Article | Requirement | SWT3 Procedure | Evidence Recorded |
|---|---|---|---|
| Art. 28(1) | Third-party risk management policy | AI-SUPPLY.1 |
Supply chain attestation, vendor inventory, risk assessment state |
| Art. 28(5) | Register of ICT third-party arrangements | AI-CHAIN.1 |
Chain-of-custody attestation, dependency enumeration, sub-processor mapping |
| Art. 29 | Preliminary assessment and due diligence | AI-TRUST.1 |
Trust verification state, credential presentation, provider assessment outcome |
| Art. 30 | Contractual provisions | AI-SUPPLY.1 |
Supply chain contract review attestation, SLA evidence |
Third-Party Risk Management Witnessing
Witnesses that supply chain governance controls are active for AI system dependencies. DORA Article 28(2) requires financial entities to "adopt and regularly review a strategy on ICT third-party risk." Supply chain anchors provide timestamped evidence that vendor risk assessments were conducted and that the third-party register was maintained.
Due Diligence and Assessment Witnessing
Witnesses that trust verification was performed for an AI provider or component. DORA Article 29(1) requires financial entities to "assess whether the envisaged contractual arrangement for the use of ICT services" meets risk standards. Trust anchors record that due diligence was completed before or during provider engagement.
Sub-Processor and Dependency Witnessing
Witnesses chain-of-custody for AI system components across multiple providers. DORA Article 28(5)(a) requires a "register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." Chain-of-custody anchors record the full dependency map including sub-outsourcing arrangements.
DORA Article 28(3) requires annual review of third-party arrangements. Query AI-SUPPLY.1 and AI-TRUST.1 anchors for the preceding 12 months to verify review cadence. A financial entity using AI models from three providers should have at least three AI-TRUST.1 anchor sets -- one per provider relationship -- with annual renewal evidence.
Cloud Provider and AI Vendor Perspective
If your organization provides AI infrastructure, cloud compute, or foundation models to EU financial institutions, your customers will need this evidence from you. DORA Article 28(5) requires financial entities to maintain a register of all third-party ICT arrangements -- and to assess your operational resilience as part of their risk framework. Proactively providing SWT3 witness anchors for AI-SUPPLY.1 (supply chain governance), AI-TRUST.1 (trust verification), and AI-CHAIN.1 (sub-processor mapping) streamlines your customers' DORA compliance and differentiates your offering in regulated markets. See the Enterprise Readiness Guide for positioning SWT3 evidence in procurement conversations.
4. DORA Incident Reporting (Art. 17--19)
DORA Chapter III requires financial entities to classify, manage, and report major ICT-related incidents. For AI systems, incidents may include model failures affecting customer-facing services, adversarial attacks on fraud detection, or data pipeline breaches corrupting model inputs.
| DORA Article | Requirement | SWT3 Procedure | Evidence Recorded |
|---|---|---|---|
| Art. 17(1) | ICT-related incident management process | AI-INCIDENT.1 |
Incident management process attestation, classification criteria, escalation paths |
| Art. 17(3) | Early warning indicators and detection | AI-DRIFT.1 |
Drift detection as early warning mechanism, threshold configuration |
| Art. 18 | Classification of ICT-related incidents | AI-INCIDENT.1 |
Classification criteria application, severity determination |
| Art. 19 | Reporting of major incidents | AI-AUDIT.1 |
Audit trail of incident lifecycle, reporting timeline adherence |
DORA Article 19(1) imposes strict reporting timelines: an initial notification within 4 hours of classification as major, an intermediate report within 72 hours, and a final report within one month. SWT3 witness anchors do not automate regulatory reporting, but they provide timestamped evidence of when the incident was detected, classified, and escalated -- supporting compliance with the notification timeline.
Cost impact is a DORA incident classification factor. Article 18(1)(b) includes "economic impact" among the criteria for classifying an ICT-related incident as major. Abnormal token spend -- a 10x cost spike from a misconfigured model route, for example -- may itself constitute a reportable incident if it materially affects the entity's operations. AI-COST.1 anchors provide real-time cost evidence that can serve as both the detection mechanism and the supporting documentation for cost-related incident classification. See the AI Inference FinOps Guide for implementation details.
Compare the timestamp on the AI-DRIFT.1 or AI-PERF.1 anchor that first recorded the anomaly against the AI-INCIDENT.1 anchor that classified it. The delta provides evidence of detection-to-classification response time. DORA requires "prompt" classification -- extended delays between detection and classification anchors warrant investigation.
5. DORA Resilience Testing (Art. 24--27)
DORA Chapter IV requires digital operational resilience testing proportionate to the entity's size and risk profile. For AI systems, resilience testing includes adversarial robustness evaluation, stress testing of model serving infrastructure, and validation of fallback mechanisms.
| DORA Article | Requirement | SWT3 Procedure | Evidence Recorded |
|---|---|---|---|
| Art. 24(1) | General requirements for testing | AI-ROBUST.1 |
Robustness testing attestation, test coverage, adversarial evaluation state |
| Art. 25(1) | Testing of ICT tools and systems | AI-REDTEAM.1 |
Red team exercise attestation, finding count, remediation tracking |
| Art. 26 | Advanced TLPT testing | AI-REDTEAM.1 |
Threat-led penetration test witnessing, TIBER-EU alignment |
| Art. 25(2) | Vulnerability assessments | AI-CYBER.1 |
Vulnerability scan attestation, finding classification |
Resilience Testing Witnessing
Witnesses that robustness or resilience testing was performed on an AI system. DORA Article 24(1) requires "a sound and comprehensive digital operational resilience testing programme." Robustness anchors demonstrate that testing occurred and record the scope and outcome of the evaluation.
Threat-Led Testing Witnessing
Witnesses that adversarial or red team testing was conducted. DORA Article 26 requires significant financial entities to "carry out at least every 3 years advanced testing by means of TLPT." Red team anchors record that adversarial evaluation was performed, covering both traditional penetration testing and AI-specific attack vectors (prompt injection, model extraction, data poisoning).
DORA Article 24(6) requires that testing be "undertaken by independent parties." Check the AI-REDTEAM.1 anchor metadata for evidence of external tester involvement. Entities subject to TLPT (Art. 26) should show AI-REDTEAM.1 anchors at least every 36 months.
6. ECB AI-Cyber Supervisory Letter (SSM-2026-0301)
ECB supervisory letter SSM-2026-0301, issued in March 2026, is addressed to the 113 significant institutions under direct ECB supervision. It is a supervisory communication -- not a regulation or directive -- but carries significant supervisory weight. Non-compliance with ECB supervisory expectations can result in increased capital requirements under the Supervisory Review and Evaluation Process (SREP), targeted on-site inspections, or formal supervisory measures.
The letter identifies four priority areas where the ECB expects SIs to demonstrate progress in AI-cyber governance by October 31, 2026. Each area maps to DORA obligations and corresponding SWT3 witness procedures.
6.1 Internet-Facing Asset Inventory
The ECB expects SIs to maintain a complete inventory of internet-facing assets, including AI model endpoints, API gateways serving model predictions, and data ingestion pipelines exposed to external networks.
| ECB Expectation | DORA Article | SWT3 Procedure |
|---|---|---|
| Complete asset inventory including AI endpoints | Art. 8(1) | AI-SBOM.1, HBOM-INV.1 |
| Classification of AI assets by criticality | Art. 8(4) | AI-GOV.1 |
| Documentation of AI model serving infrastructure | Art. 7 | AI-ENV.1, AI-ENV.2 |
6.2 Vulnerability Management
The ECB expects robust vulnerability management processes that account for AI-specific attack surfaces -- including adversarial inputs, model poisoning vectors, and supply chain vulnerabilities in model dependencies.
| ECB Expectation | DORA Article | SWT3 Procedure |
|---|---|---|
| AI-specific vulnerability scanning | Art. 9(2) | AI-CYBER.1 |
| Adversarial robustness evaluation | Art. 24--25 | AI-ROBUST.1, AI-REDTEAM.1 |
| Supply chain vulnerability assessment | Art. 28 | AI-SUPPLY.1 |
6.3 Monitoring and Detection
The ECB expects continuous monitoring of AI systems, with specific attention to model drift, performance degradation, and anomalous inference patterns that could indicate adversarial activity or data quality issues.
| ECB Expectation | DORA Article | SWT3 Procedure |
|---|---|---|
| Continuous model performance monitoring | Art. 10(1) | AI-PERF.1 |
| Drift detection and alerting | Art. 10(2) | AI-DRIFT.1 |
| Anomaly detection for AI inference | Art. 10(1) | AI-GRD.1 |
6.4 Operational Resilience
The ECB expects SIs to demonstrate that AI-dependent business processes have fallback mechanisms, that model failures do not cascade into critical service disruptions, and that AI systems can be rolled back or replaced under stress.
| ECB Expectation | DORA Article | SWT3 Procedure |
|---|---|---|
| Kill switch / emergency shutdown | Art. 11(1) | AI-SAFE.1 |
| Fallback and manual override | Art. 11(3) | AI-SAFE.2 |
| Model rollback capability | Art. 12 | AI-LCM.1 |
| Incident response exercising | Art. 11(6) | AI-INCIDENT.1 |
SIs preparing their October 31, 2026 action plans can reference SWT3 witness anchors as evidence of progress. The anchor timeline across the four priority areas demonstrates that controls were activated and verified during the preparation period. For follow-through evidence collection in 2027, a continuous cadence of anchors across all four areas provides supervisory-grade evidence that the action plan was executed -- not merely filed.
7. Relationship to SR 11-7 / SR 26-2
US financial institutions subject to Federal Reserve SR 11-7 (Model Risk Management) or its successor SR 26-2 face model risk governance requirements that overlap significantly with DORA's AI-related obligations. For institutions operating in both US and EU jurisdictions, or for EU subsidiaries of US bank holding companies, the regulatory overlap creates an opportunity to generate evidence once and satisfy both frameworks.
| Requirement Area | DORA Article | SR 11-7 / SR 26-2 Element | SWT3 Procedure |
|---|---|---|---|
| Model governance | Art. 5--6 | Model Risk Governance Framework | AI-GOV.1 |
| Model validation | Art. 24--25 | Effective Challenge / Independent Review | AI-ROBUST.1 |
| Ongoing monitoring | Art. 10 | Outcomes Analysis / Performance Monitoring | AI-DRIFT.1, AI-PERF.1 |
| Model inventory | Art. 8 | Model Inventory and Tiering | AI-SBOM.1 |
| Third-party models | Art. 28--30 | Vendor Model Risk Management | AI-SUPPLY.1, AI-TRUST.1 |
| Model lifecycle | Art. 12 | Model Development, Implementation, Use | AI-LCM.1 |
The key distinction: DORA focuses on operational resilience (can the entity continue operating if the AI system fails?), while SR 11-7 / SR 26-2 focus on model risk (is the model producing reliable outputs?). Both require evidence of governance, testing, monitoring, and lifecycle management -- but with different emphases. SWT3 witness procedures record evidence at a level of abstraction that serves both frameworks simultaneously.
For detailed SR 11-7 and SR 26-2 mappings, see the dedicated crosswalk guides linked in the references section below.
8. Quick Start
The following examples demonstrate witness calls relevant to financial institutions operating under DORA. Each call produces an SWT3 witness anchor that can be independently verified.
Python
TypeScript
Each witness call records the event with the specified factors and produces an anchor at the configured clearing level. The anchor string can be verified at sovereign.tenova.io/verify using only the anchor value -- no API keys or vendor access required.
Every witness anchor can be independently verified at sovereign.tenova.io/verify using only the anchor string. No API keys, no vendor access. SHA-256 runs locally in the browser.
9. Cross-References and Resources
Related Guides
- SR 11-7 Model Risk Management Overlay -- US Federal Reserve model risk governance mapping
- SR 26-2 GenAI Model Risk Crosswalk -- Successor to SR 11-7 with GenAI-specific requirements
- AI Inference FinOps Guide -- Token spend governance, cost anomaly detection as incident indicator (DORA Art. 18)
- EU AI Act Crosswalk -- Full EU AI Act mapping including Article 9 risk management
- ISO 42001 Implementation Evidence Guide -- AI management system certification evidence
- EU Product Liability Directive Crosswalk -- Continuous liability and evidence retention