Talk to us
DORA Explained

DORA and AI Agents: Operational Resilience for Governed Workflows

DORA is the EU Digital Operational Resilience Act, in force since January 2025. It applies to financial entities in the EU and requires them to ensure the operational resilience of the ICT systems they depend on. AI agents that take actions in production systems fall inside that scope: if an agent changes a record, moves a payment, or touches critical infrastructure, it is an ICT-supported function, and its governance must survive the same scrutiny as any other part of your IT estate.

What DORA requires when agents act in production

ICT risk management

Financial entities must identify, assess and manage ICT risk as part of a sound framework. An agent acting on production systems needs documented risk assessment, defined boundaries on what it can reach, and controls proportionate to the harm it could cause.

Logging and evidence

DORA requires detailed logging of events affecting ICT-supported functions. For agents, that means a record of every action: what the agent proposed, what policy allowed, what a human approved, and what changed in the source system.

Operational resilience testing

Entities must test their digital operational resilience. For agent workflows, this means drills: can you stop the agent, prove it stopped, and list what it did? A deployment rollback is not a kill switch.

Third-party risk

DORA governs ICT third-party providers. If your agents run on a vendor platform or call external model APIs, those dependencies are in scope — data residency, exit plans and contractual assurances all apply.

Incident reporting

Major ICT incidents must be classified and reported. An agent that takes a wrong consequential action is an incident like any other, and you must be able to reconstruct exactly what happened, when, and who was accountable.

The agent kill-switch test

DORA's resilience testing has a concrete agent translation. Run this drill on one production agent: press the stop control and start a timer. Pass means zero actions after the stop decision, a complete write list in under ten minutes, a rollback path or named human owner for every write, and restart blocked until a named approver signs off. If the answer to "can you stop it?" is a deployment rollback, the agent is not resilient. Moring'srisk and control framework is built around exactly this drill, and our freeagent readiness checklist scores it.

Frequently asked questions

Do AI agents fall within DORA scope?

DORA regulates ICT systems and digital operational resilience, not AI specifically. But an AI agent that acts inside a financial entity's production systems is part of the ICT estate: it accesses systems, changes records, and creates operational risk. Supervisors will expect the same logging, risk assessment, incident response and third-party controls for agent activity as for any other automated system. The governance burden lands whether or not the word "AI" appears in the regulation.

What logging does DORA require for agent activity?

DORA requires financial entities to maintain detailed logs of events affecting ICT-supported functions, sufficient to reconstruct what happened. For agents, a defensible log captures: the agent identity (not a shared service account), every tool invocation and system change, the policy decision that allowed or refused the action, human approvals for gated actions, and timestamps consistent across systems. Logs an auditor can tamper with do not satisfy the requirement.

How do we test agent resilience under DORA?

DORA's resilience testing applies to the functions agents support. A practical agent drill: trigger the stop control, verify no actions occur after the stop decision, produce a complete list of everything the agent wrote in a defined window, confirm each write has a rollback path or named human owner, and prove restart requires a named approver. If you cannot pass this drill, the agent is not operationally resilient, whatever the deployment dashboard says.

Does DORA apply to model providers like OpenAI or Anthropic?

DORA applies to ICT third-party service providers that financial entities depend on, including cloud and critical ICT services. Model API providers are increasingly treated as part of the dependency chain. The practical consequence for you: an agent that calls an external model API creates a third-party dependency you must assess, contract for, and be able to exit — and the entity relying on the service carries the resilience obligation.

How does DORA relate to the EU AI Act?

They are complementary. The EU AI Act regulates the AI system itself: classification, documentation, human oversight, conformity. DORA regulates the operational resilience of the systems the AI runs in: logging, incident response, testing, third parties. A bank deploying governed agents needs both: the AI Act asks "is this AI system governed?" while DORA asks "can this estate survive whatever it does?" Moring addresses both layers — agent governance for the AI Act, action-level evidence and stop controls for DORA.

How does Moring support DORA obligations for agents?

Moring provides the controls DORA examiners will look for: per-agent identity so every action is attributable; immutable action records with policy decisions and human approvals; tested stop controls that halt new and in-flight actions with a complete write list; deployment inside your own cloud so the dependency stays yours to govern; and drill-ready evidence for resilience testing. Your agent workflow becomes an auditable ICT function rather than an ungoverned shadow system.

Sources

  • DORA — Regulation (EU) 2022/2554: Official text of the Digital Operational Resilience Act. EUR-Lex. Accessed October 2026.
  • EIOPA and EBA DORA supervisory expectations: Supervisory statements on ICT risk and operational resilience testing. EIOPA. Accessed October 2026.

Preparing agents for DORA scrutiny?

We help EU financial entities map agent workflows to DORA obligations: identity, logging, stop controls and evidence.

Talk to Moring