Digital Operational Resilience Act (DORA)

Why DORA exists

The financial sector runs on technology, and that technology increasingly comes from outside the firm: cloud platforms, software vendors, data providers, and — most recently — AI and large language model (LLM) services. Before DORA, ICT risk requirements were spread unevenly across EU directives, national rules, and supervisory guidance, leaving gaps between Member States and between types of institution.

DORA replaces that patchwork with one directly applicable regulation. The goal is straightforward: a financial entity should be able to withstand, respond to, and recover from any ICT-related disruption — whether a cyberattack, a vendor outage, or a failure in a system it depends on but does not own. Because it is a regulation rather than a directive, DORA applies consistently across the EU without requiring separate transposition into each national legal system.

The five pillars of DORA

DORA is commonly described in terms of five areas of obligation. Together they span the full lifecycle of ICT risk — from day-to-day management, through incident handling and testing, to the governance of external providers and the sharing of threat intelligence.

ICT risk management

Financial entities must maintain a comprehensive ICT risk-management framework, owned and overseen by the management body. This includes identifying and classifying ICT assets and dependencies, protecting them, detecting anomalies, and maintaining business continuity and recovery capabilities. Governance is explicit: accountability sits with leadership, not only with the technology function.

ICT-related incident reporting

Entities must detect, manage, classify, and report significant ICT-related incidents to their competent authorities, following harmonized criteria and timelines. The aim is a consistent, comparable view of incidents across the sector so that supervisors can see systemic patterns rather than isolated reports.

Digital operational resilience testing

Entities must test their resilience regularly using a risk-based program — from basic vulnerability assessments and scenario testing to advanced threat-led penetration testing for the most significant institutions. Testing is intended to surface weaknesses before an adversary or an outage does.

ICT third-party risk management

DORA gives particular weight to the risks that arise when critical functions depend on external providers. Entities must manage third-party ICT risk across the contract lifecycle, maintain a register of contractual arrangements, and ensure contracts include defined rights around security, audit, monitoring, and exit. In addition, DORA establishes an EU-level oversight mechanism for ICT third parties designated as critical, so that the most systemically important providers are supervised directly.

Information and intelligence sharing

DORA encourages financial entities to share cyber threat information and intelligence with one another on a voluntary basis, within trusted communities, to strengthen collective defense across the sector.

DORA's pillars at a glance

Where AI fits into DORA

DORA does not single out artificial intelligence, but its definitions are broad enough that AI tools fall squarely within scope. An LLM assistant, an AI coding tool, or an autonomous agent platform is an ICT asset that supports the entity's services. When that capability is delivered by an external provider — which is almost always the case for frontier models — it is also an ICT third-party service.

That dual classification matters. It means AI usage is subject to the same obligations as any other technology the firm depends on:

• Risk management — AI tools and the data they touch must be inventoried, classified by criticality, and brought into the entity's ICT risk framework rather than adopted informally outside it.
• Third-party oversight — where an AI service supports an important or critical function, it falls under DORA's third-party risk requirements, including contractual rights and inclusion in the register of arrangements.
• Incident handling — disruptions, failures, or harmful outputs from an AI system can constitute ICT-related incidents that need to be detected, classified, and potentially reported.
• Auditability — supervisors and internal control functions need evidence of what AI systems were used, by whom, and what actions they took on the firm's behalf.

The challenge for most financial entities is visibility. AI tools enter the organization through browsers, desktop applications, and agent integrations — often faster than governance can keep up. Without a control plane, a firm cannot answer basic DORA-relevant questions: which AI services are in use, what data they receive, and what autonomous agents do once connected to internal systems.

Questions DORA raises about AI usage

• Which AI tools and services are in use, and who provides them? — An inventory that maps AI usage to ICT assets and third-party providers.
• What data is being sent to external AI models? — Visibility into prompts and tool-call arguments before they leave the organization.
• What did an autonomous agent access or change? — A record of agent actions against internal systems and external APIs.
• Can we produce evidence on demand? — A tamper-evident audit trail that withstands supervisory and internal review.