DORA Compliance

What is DORA compliance?

DORA compliance is the state of meeting the obligations set out in the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, which governs how financial entities manage information and communication technology risk, report disruptive incidents, test their own resilience, and oversee the technology providers they depend on.

The regulation became enforceable on 17 January 2025 and reaches a wide span of regulated firms, from banks and insurers to payment institutions and crypto-asset service providers, together with the technology providers judged critical to them. Its scope extends well past the security team.

How DORA compliance works

Compliance work under DORA runs as a loop with four moving parts: map, control, test, evidence.

Mapping comes first. A firm inventories the ICT systems supporting each critical or important business function, then traces the dependency chain outward to the vendors and subprocessors sitting underneath them. Nothing downstream works without that map.

Control follows. Each mapped dependency gets a named owner, a documented risk assessment, and the technical constraints that keep it inside policy. In a customer-facing stack those constraints are usually the same AI guardrails that limit what an automated system may retrieve, say, or execute.

Testing turns paper controls into observed behaviour. Scenario exercises and threat-led testing sit alongside the AI agent testing that regulated support teams already run before every release.

Evidence closes the loop. Registers, incident records, and test artefacts have to be produced on request in a form a supervisor can read, which is why most DORA programmes are built on top of an existing AI compliance function that already owns policy mapping and audit response.

What DORA requires

The regulation is organised into five workstreams, and most programmes staff them separately.

• ICT risk management: A governance framework owned at board level, covering identification, protection, detection, response, and recovery across systems supporting critical functions.

• Incident management and reporting: Classification criteria for ICT-related incidents plus a staged notification path to the competent authority once an incident is judged major.

• Digital operational resilience testing: A programme of regular testing, with advanced threat-led penetration testing reserved for larger and more systemically significant entities.

• ICT third-party risk: A live register of technology providers carrying risk ratings and contractual terms, plus exit plans for the arrangements that matter most.

• Information sharing: Voluntary arrangements for exchanging cyber threat intelligence between financial entities inside trusted communities.

DORA compliance vs NIS2 vs GDPR vs SOC 2 Type II

Buyers routinely conflate these four, because each lands on the same security team and asks for overlapping artefacts. NIS2 is an EU directive addressing cybersecurity for essential and important entities across many sectors, transposed separately by each member state. GDPR is scoped to personal data and the rights of the people that data describes. SOC 2 Type II is a voluntary attestation an auditor issues about one service organisation's controls over a defined window. DORA compliance is narrower in sector and broader in subject: it treats operational continuity in finance as a supervised outcome.

If you are an EU-regulated financial entity, or you sell technology into one, DORA compliance is unavoidable and the other three do not discharge it. Suppliers typically bring the audit report; the register, the testing calendar, and the supervisory relationship stay with the firm.

Why DORA compliance matters for customer experience

Operational resilience becomes a customer experience problem the moment it fails. When a payment rail degrades, customers do not read status pages; they call, message, and open tickets, so contact volume peaks exactly when the systems agents depend on are slowest.

Without a mapped dependency chain, nobody can tell the contact centre which downstream failures are live, so agents improvise and each one improvises differently. The gap shows up again afterwards: a firm that cannot reconstruct which customers were affected cannot make them whole, and remediation drags for weeks.

The tradeoff is real. Change control slows releases, the testing calendar consumes engineering weeks that would have shipped features, and a register kept current costs somebody's continuous attention. Firms that defer that cost pay it under time pressure during a live incident, when the price is highest.

How is DORA compliance measured?

Supervisory judgement here is closer to pass or explain than to a score. Authorities ask whether the register is complete, whether the testing programme actually ran, and whether incidents were classified and escalated inside their windows.

Internally, four numbers do most of the work: the share of ICT arrangements with a completed risk assessment, median time from detection to classification, the share of critical functions with a recovery path tested in the last cycle, and the count of open findings past their remediation date.

The useful discipline is treating regulatory clocks as measurable service levels, the way US telemarketing rules already are. The eCFR text of 47 CFR 64.1200 fixes an 8 a.m. to 9 p.m. local calling window and a 30-day limit on honouring an opt-out request, thresholds a system either meets on every attempt or misses measurably. DORA's reporting deadlines behave the same way once your telemetry can timestamp the moment of classification.

How AI agents change DORA compliance

An AI agent in a support queue is an ICT arrangement with an unusual property: it acts. It retrieves from internal systems, calls tools that move money or change account state, and produces text that becomes part of the customer record. Each of those is a dependency to register, a decision to log, and a behaviour to test.

That mechanism changes what evidence looks like. The AI agent framework underneath determines whether a tool call can be replayed, attributed to a session, and bounded by policy, so architecture choices made for latency end up deciding whether an incident is reconstructable at all.

The consequence is organisational. Vendor diligence and DORA mapping ask most of the same questions, which is why CX teams increasingly fold the register work into their existing evaluation of AI support platforms for compliance officers and produce one evidence pack that serves both reviews.

Implementing DORA compliance in a support stack

Judge a programme on the axes that decide whether evidence exists on the day a supervisor asks for it.

Coverage: does the mapping reach every ICT arrangement supporting a critical or important function, including the tools one team bought on a card.

Integration surface: can your logging, ticketing, and identity systems emit a timestamped record of who did what, because evidence assembled by hand is evidence produced late.

Governance and ownership: accountability sits with the management body, so a programme parked entirely inside a security team lacks the authority to reopen a vendor contract.

Certifications: ISO 27001 is the baseline most banks now demand from suppliers before commercial conversations start, and ISO 42001 is moving into the same slot for AI systems. Neither discharges the obligation; both shorten diligence.

The constraint teams underestimate is subprocessor churn. A vendor changes hosting region or adds a model provider mid-contract, and last quarter's certified register is stale before anyone notices.

DORA compliance and AI governance

DORA sits inside a broader governance stack that regulated support teams are already assembling. Where an automated agent answers customers, SOC 2 AI support keeps the agent, its data flows, and its subprocessors inside one audited control boundary, and that boundary is precisely what a third-party register has to describe. Conversation logs become usable evidence only when entity extraction lifts case identifiers, timestamps, and account references out of free text into fields a query can count. Teams working toward both often start from an EU AI Act compliance checklist, since the artefacts overlap heavily.

What does DORA compliance mean in plain terms?

Think of DORA compliance as a fire code for a bank's technology. A fire code does not stop fires; it insists exits exist, that they are marked, that someone tests the alarm on a schedule, and that the building can show it did. DORA applies that logic to outages, cyber incidents, and supplier failures.

DORA stands for the Digital Operational Resilience Act, written into law as Regulation (EU) 2022/2554. Absent it, a firm discovers which supplier holds up its card issuing on the morning that supplier goes dark, and finds out with customers already on the phone.

The tradeoff is honest: resilience is bought with money and slowness. Two providers cost more than one good one, and exit plans stay usable only if they are rehearsed, which nobody enjoys scheduling in a quarter with a product deadline.

Common DORA compliance mistakes

Four patterns account for most failed programmes.

Treating the register as a document. A register compiled once for a deadline decays with every contract amendment, region migration, and new subprocessor. The mechanism is drift: the artefact is accurate the day it is signed and unverifiable a quarter later, so it stops functioning as evidence.

Mapping systems without mapping functions. Teams inventory applications because applications have owners, then discover mid-incident that nobody recorded which business function each application supports. Criticality is a property of the function, and it cannot be inferred from the server list.

Buying attestations as a substitute for oversight. A supplier's audit report describes that supplier's controls across a past window. It says nothing about the concentration risk of routing four critical functions through one provider, and nothing about whether you could actually exit.

Testing only what restarts easily. Recovery exercises gravitate toward the systems that are cheap to spin up, which leaves the dependencies with manual failover untested until the day they fail.