DORA Compliance in the Age of AI Agents: What Security Teams Must Know

European regulators no longer treat cyber resilience as a paper exercise. The Digital Operational Resilience Act, now enforceable across the EU financial sector, requires banks, insurers, and investment firms to prove, with evidence, that they can withstand and recover from ICT disruption, not just document a plan for one. For CISOs and security architects, that shift changes what “compliant” actually means.

It also changes what falls under supervisory scrutiny. The systems doing the work inside EU financial institutions increasingly include AI agents that read customer records, call trading APIs, and take action inside core banking platforms without a person approving each step. This article breaks down what the Digital Operational Resilience Act (DORA) actually requires, which financial entities it covers, and where AI agent risk now sits inside its ICT risk perimeter.

What Is the Digital Operational Resilience Act (DORA)?

The Digital Operational Resilience Act, formally Regulation (EU) 2022/2554, entered into force on January 16, 2023, and became fully applicable on January 17, 2025. It is a single, directly applicable EU regulation rather than a directive that each member state transposes differently, which is precisely the point: before DORA, EU financial entities managed ICT and cyber risk under a patchwork of national rules and sector guidance.

DORA replaces that fragmentation with one harmonized standard. It functions as lex specialis for the financial sector, meaning it takes precedence over the broader NIS2 Directive for any entity that falls within its scope. And it marks a philosophical shift: financial regulation historically managed operational risk through capital buffers sized for a worst-case scenario. DORA instead asks whether an institution can keep running, not whether it can absorb the loss if it can't. Per EIOPA, the regulation is designed to ensure banks, insurers, and investment firms can withstand, respond to, and recover from ICT-related disruptions such as cyberattacks or system failures.

Which Financial Entities Are Covered Under DORA?

Article 2 of DORA defines the in-scope entities, and the list is intentionally broad. It spans 21 categories of financial entities, covering nearly every regulated participant in the EU financial system rather than a narrow slice of it.

In scope, among others:

• Credit institutions (banks), including neo-banks and their EU branches
• Payment institutions and electronic money institutions
• Investment firms, UCITS managers, and alternative investment fund managers
• Insurance and reinsurance undertakings and certain insurance intermediaries
• Crypto-asset service providers authorized under MiCA
• Central securities depositories, central counterparties, and trading venues
• Credit rating agencies and crowdfunding service providers
• ICT third-party service providers designated as critical (CTPPs)

A proportionality principle scales the depth of the obligation to an entity's size, risk profile, and complexity, and microenterprises benefit from a simplified ICT risk management framework. But proportionality is not an exemption: even the smallest in-scope firm still has to meet DORA's incident reporting and third-party risk provisions. According to EIOPA, tens of thousands of financial entities and their critical ICT providers now fall within DORA's reach.

The oversight extends beyond the financial sector's traditional borders, too. Non-EU financial entities with an EU branch must comply, and the European Supervisory Authorities (ESAs) can designate a technology vendor as a critical ICT third-party provider even if that vendor is headquartered outside the EU. That designation is not theoretical: in November 2025, the ESAs named the first group of CTPPs subject to direct oversight, including the major cloud platforms that now sit underneath most enterprise AI deployments.

The Five Pillars of DORA

DORA organizes every obligation into five interconnected pillars. A security leader who understands these five areas understands the entirety of what the regulation asks for.

1. ICT risk management

The most extensive pillar. Financial entities must establish, document, and continuously review an ICT risk management framework covering identification, protection, detection, response, and recovery for every ICT asset. The management body, not a delegated risk function, is accountable for approving and overseeing that framework.

2. ICT-related incident management and reporting

Entities must detect, classify, and log ICT incidents, then report anything meeting the “major incident” threshold to their competent authority on a strict timeline: an initial notification within four hours of classification, followed by intermediate and final reports.

3. Digital operational resilience testing

Every in-scope entity runs a risk-based testing program covering its critical or important functions at least annually. Entities designated as significant face a heavier obligation on top of that baseline, covered in detail below.

4. ICT third-party risk management

Financial entities remain fully accountable for ICT services even when a third party delivers them. Contracts with providers must specify service levels, audit rights, exit strategies, and incident notification duties, and entities must maintain a Register of Information documenting every ICT third-party arrangement, reported to competent authorities annually.

5. Information and intelligence sharing

The only pillar DORA encourages rather than mandates. Entities are invited to share indicators of compromise, attacker tactics, and lessons learned through industry arrangements, strengthening the sector's collective defense.

Where AI Agents Fit Inside DORA's ICT Risk Perimeter

DORA does not mention artificial intelligence or AI agents anywhere in its text. That silence is often misread as absence of obligation. In practice, the opposite is true: an AI agent that accesses data, calls APIs, and takes action inside a financial entity is an ICT system in the meaning DORA already uses, so Chapter II's risk management obligations apply to it the same way they apply to a core banking platform. In January 2026, Germany's BaFin made this explicit in non-binding guidance stating that AI systems, including large language models and agentic workflows, get no separate regime and must be governed inside existing DORA risk management and testing frameworks.

Consider a claims-processing agent at an EU insurer. It reads incoming policyholder documents, checks them against a legacy claims system, and files a payout instruction through a third-party payments API, with no person reviewing each individual case. If that agent misreads a document and authorizes an incorrect payout, or calls an API outside its intended scope, the resulting disruption has to be evaluated against DORA's major-incident thresholds under Articles 17 through 19 the same way a core system outage would be. The agent did not need a special AI clause in the regulation to fall inside it.

Three structural realities make this harder in practice than it sounds:

• Dependency chains get longer. An agent's tool calls typically span a foundation model provider, an orchestration layer, and downstream APIs, each mapping onto DORA's third-party and sub-outsourcing provisions and each needing a place in the Register of Information.
• Identity attribution breaks down. Traditional identity and access controls were built to link an action to a named human. An agent acting under a shared service account leaves a log that shows what happened but not which agent, running which plan, under whose authorization, initiated it.
• Shadow AI expands the blind spot. Employees connecting unsanctioned AI tools to internal systems create exactly the kind of undocumented ICT dependency that a Register of Information is supposed to eliminate.

This is the core argument behind Zenity's approach to AI agent security: the agent is the new endpoint. It is the system executing actions, making decisions, and introducing new risk vectors, which means it needs the same governed inventory, access controls, and continuous AI Security Posture Management that DORA already expects of every other ICT asset. Discovering shadow AI before a supervisor does is the difference between an evidence gap and an incident report.

Digital Operational Resilience Testing and TLPT Requirements

DORA's testing pillar operates on two tiers, and the distinction matters for planning and budget.

Standard resilience testing

Threat-led penetration testing (TLPT)

Who

All in-scope financial entities

Entities designated “significant” by their competent authority

Frequency

At least annually

At least every three years

Scope

Systems and applications supporting critical or important functions

Live production systems, using real threat intelligence and methods including social engineering

Who tests

Independent internal or external party

Accredited external red team and threat-intelligence provider; internal testing allowed twice in three cycles

Threat-led penetration testing follows the TIBER-EU methodology that DORA's regulatory technical standards were built on, and it is deliberately covert: the defending team is not told a test is underway, which is what makes the results a genuine measure of detection and response rather than a checklist exercise. Purple teaming, where the red team and the internal blue team debrief together afterward, is mandatory under DORA's closure phase, and where a critical or important function depends on a third-party provider, that provider's systems may be pulled into scope under Article 26. For financial entities running AI agents, that scope question is no longer hypothetical: an agent's behavior under adversarial pressure, and the third-party model and cloud infrastructure it depends on, increasingly falls inside what a TLPT engagement is expected to exercise.

Penalties for Non-Compliance

DORA's enforcement mechanism gives competent authorities real financial leverage, and 2026 marks the shift from policy review to active supervision.

• Financial entities face fines of up to 2% of total worldwide annual turnover for breaches of DORA's requirements.
• Critical ICT third-party providers (CTPPs) can be fined up to €5,000,000, or up to 1% of average daily worldwide turnover, imposed directly by their Lead Overseer.
• Ongoing non-compliance can accrue daily penalty payments of up to 1% of average daily turnover, for up to six months, on top of the base fine.
• Individual board members can face personal fines of up to €1,000,000, reflecting DORA's insistence that ICT risk ownership sits with the management body, not a delegated function.
• Beyond fines, competent authorities can issue binding remediation orders and, in cases of persistent or severe non-compliance, restrict or suspend a firm's operating license.

For a mid-sized bank or insurer, months of unresolved non-compliance can accumulate into a multi-million-euro exposure that dwarfs the cost of building the program in the first place.

Building a DORA-Ready Program for AI Agents

DORA was not written with AI agents in mind, and it did not need to be. An agent that reads data, calls APIs, and takes action is an ICT system under a framework that already covers ICT systems, third-party dependencies, and the incidents they cause. The obligation exists whether or not a security team has mapped it yet.

Securing AI agents under DORA means securing them with controls that persist across the full lifecycle, from build time to runtime, and give a supervisor a governed inventory, an audit trail, and evidence of testing on demand, not a policy document assembled after the fact.

Want to see where your organization's AI agents sit inside your DORA risk register? See how Zenity brings agent behavior into your ICT risk and resilience program and start closing the evidence gap before a supervisor finds it.

FAQs About the Digital Operational Resilience Act

What is the Digital Operational Resilience Act (DORA)?

DORA, formally Regulation (EU) 2022/2554, is an EU regulation requiring banks, insurers, investment firms, and other financial entities to manage ICT risk, report major incidents, test their digital resilience, and oversee ICT third-party providers under one harmonized, directly applicable framework.

When did DORA become applicable?

DORA entered into force on January 16, 2023, and became fully applicable across the EU on January 17, 2025, after a two-year implementation period.

Does the Digital Operational Resilience Act apply outside the EU?

Yes. Non-EU financial entities with a branch in an EU member state must comply, and technology providers outside the EU can be designated critical ICT third-party providers and brought under direct ESA oversight if EU financial entities depend on them.

Do AI agents fall under DORA?

DORA does not name AI agents specifically, but an agent that accesses data, calls APIs, or takes action inside a financial entity's systems is an ICT system in the sense DORA already regulates, so the ICT risk management, incident reporting, and testing obligations apply to it.

What is the difference between standard resilience testing and TLPT?

Standard testing is an annual, risk-based assessment required of every in-scope entity. Threat-led penetration testing (TLPT) is a covert, intelligence-driven red-team exercise on live production systems, required at least every three years for entities designated as significant, and it must involve an accredited external provider in at least one of every three cycles.

What are the penalties for DORA non-compliance?

Financial entities can be fined up to 2% of total worldwide annual turnover, critical ICT third-party providers up to €5 million, and individual board members up to €1 million, with additional daily penalties for ongoing non-compliance.

Are small financial firms exempt from DORA?

No. Microenterprises benefit from a simplified ICT risk management framework, but they remain subject to DORA's incident reporting and third-party risk provisions. Proportionality scales the obligation; it does not remove it.

How does DORA relate to the EU AI Act?

The two frameworks ask different questions of the same system: DORA asks whether an AI agent is operationally resilient, while the EU AI Act asks whether it is governed, fair, and subject to human oversight. A financial entity running high-risk AI use cases, such as credit scoring, needs to satisfy both simultaneously.