DORA compliance: requirements, pillars, and how to meet them

For most of 2024, DORA was a deadline on a slide. Teams built policies, mapped vendors, and got ready for the January 2025 start date. That phase is over.
In 2026, supervisors across the EU are no longer asking whether you have a plan.

They're asking to see proof that it works.

That changes what DORA compliance means in practice. The documents still matter, but they're only where the work starts. What a supervisor wants now is evidence that your resilience measures hold up when something breaks.

This guide covers what DORA is, who it applies to, the five pillars, the third-party rules where most of the work sits, the penalties for getting it wrong, and how software escrow fits into a tested compliance program.

What DORA is and why it exists

To see why proof matters this much, it helps to start with what DORA was built to do.

What is DORA? The Digital Operational Resilience Act, Regulation (EU) 2022/2554, is the EU law that sets binding rules for managing information and communication technology (ICT) risk in the financial sector. It runs to 64 articles across nine chapters and has applied since January 17, 2025. 

DORA exists because two problems had been building for years. EU countries each had their own patchwork of resilience rules, so a bank operating across borders met a different standard in every market. Meanwhile, the whole sector had come to lean on a small handful of cloud and technology providers.

DORA's answer to both is one set of operational resilience requirements, applied the same way everywhere. The goal is that financial entities can withstand an ICT disruption, respond to it, and recover from it, instead of finding out mid-crisis that nobody planned for the provider that just went dark.

Who DORA applies to

Those requirements reach further than many firms first assume.Article 2 brings around 22 000 financial entities into scope, across roughly 20 categories. If you sit in any of these, DORA applies to you directly:

• Banks and credit institutions

• Insurers and reinsurers

• Investment firms and trading venues

• Payment and electronic-money institutions

• Crypto-asset service providers

• The ICT third-party providers that serve all of the above

The last group is the part people miss. DORA's reach extends to the providers themselves, wherever they're based. A cloud or software vendor headquartered outside the EU still falls in scope the moment it serves an EU financial entity's critical operations.

Once you know DORA applies to you, the real question is what it requires. That's organized into five pillars.

The five pillars of DORA

The five pillars each cover a different part of staying operational under ICT stress. Together they describe the full set of DORA requirements, from day-to-day governance to what happens when an outside provider fails.

1. ICT risk management (Articles 5-16)

This is the foundation the other pillars rest on. You need a documented framework for identifying, protecting against, detecting, and recovering from ICT risk, owned at board level. It covers your systems, the controls around them, and the governance that keeps them under review.

2. ICT incident management and reporting (Articles 17-23)

When something goes wrong, you have to detect it, classify how serious it is, and report major incidents to your competent authority on tight deadlines. The point is consistency. Regulators want every major incident handled and reported the same way, so they can see systemic problems forming across the sector.

3. Digital operational resilience testing (Articles 24-27)

Every entity has to test its ICT systems regularly to find weaknesses before an attacker or an outage does. Larger, more significant firms go further, running threat-led penetration testing that simulates a real attack. This pillar is where "we have a plan" has to become "we checked the plan works."

4. ICT third-party risk management (Articles 28-44)

This is the pillar most firms underestimate, and the one supervisors are scrutinizing hardest in 2026. It governs how you manage the outside providers your critical operations depend on, from contracts to exit plans. There's enough here that it gets its own section next.

5. Information sharing (Article 45)

The fifth pillar encourages financial entities to share cyber-threat intelligence with each other through trusted arrangements. Unlike the rest, this one is voluntary. DORA frames it as a way for the sector to spot threats together. You won't be penalized for sitting it out.

DORA's ICT third-party risk requirements

The reason third-party risk gets this much attention is simple. Most of what a financial entity runs on today, it doesn't build or control. DORA treats that dependency as a risk you're expected to manage and prove you've managed.

Article 28 sets the structure. Underneath it sit the obligations that most 2026 supervisory reviews are built around:

• A Register of Information (Article 28(3)) listing every ICT contract, which authorities can demand at any time

• An assessment of concentration risk (Article 29), so you know how exposed you are when too much rides on one provider

• Mandatory contract clauses (Article 30) covering audit rights, termination, and continuity, which older contracts must be renegotiated to include

• Documented exit strategies (Article 28(8)) for any service supporting a critical or important function

There's a layer above the firm. Under Articles 31-44, the European Supervisory Authorities can designate the most systemic providers as Critical ICT Third-Party Providers and oversee them directly.

On November 18, 2025, they named the first 19. The supervisor is now reaching past your own walls, into the supply chain itself.

Of all these obligations, one is where firms most often look compliant on paper and fall short in practice: the exit strategy.

Why a written exit strategy isn't enough

This is where careful firms get caught as easily as careless ones. Article 28(8) asks for an exit strategy, and most firms write a decent one. But a written plan and a working one aren't the same thing, and DORA's operational resilience requirements are built to expose the gap.

The testing pillar does that exposing. An exit strategy that's never been rehearsed is just a set of assumptions about the worst day you'll have: whether you can rebuild the systems, run them, and keep serving customers without the provider who used to do it for you.

Closing that gap means showing the recovery path works under real conditions. For some dependencies that means a tested multi-vendor setup, for others a data-portability arrangement you've exercised. For software supporting a critical function, it means software escrow, the kind where the deposit has been verified as buildable.

That last point matters more than it sounds. Around 90% of traditional escrow deposits fail if they're not stress-tested and verified.

A deposit nobody has rebuilt is just a hope with paperwork attached.

»  Find out how you can set up your vendor exit planning with software escrow

Penalties and enforcement

DORA compliance isn't enforced from one central office. Day-to-day supervision sits with national competent authorities: BaFin in Germany, the ACPR in France, the CSSF in Luxembourg, the Central Bank of Ireland, the Banca d'Italia, and their counterparts in each member state.

What they can impose varies by country, because DORA leaves administrative penalties for financial entities to national law under Articles 50-52. The often-cited benchmark is up to 2% of total annual worldwide turnover, but some member states set ceilings as high as 5% to 10%.

Individual managers can be held personally liable too. Designated critical providers face a separate, EU-level regime: the lead overseer can levy penalty payments of up to 1% of their average daily worldwide turnover, every day, for up to six months.

The reason this matters now rather than later is timing. The preparation years are behind us, and 2026 is when supervisory reviews start in earnest.

How software escrow supports DORA compliance

So where does software escrow fit into all of this? It's the concrete mechanism behind several of the obligations we've walked through, especially the ones in the third-party pillar.

The clearest fit is the exit strategy under Article 28(8). A verified escrow arrangement gives you a tested route to keep a critical function running if the provider stops. The source code, build instructions, and dependencies sit with a neutral third party, confirmed to rebuild the software.

It supports the contract obligations under Article 30, too. The escrow agreement, with its defined release triggers, is the working mechanism behind the continuity and termination clauses DORA expects those contracts to contain.

It also chips away at concentration risk. Holding an independent, recoverable copy of critical software reduces how completely you depend on any single provider staying in business.

What turns escrow from a filing-cabinet exercise into evidence is verification. A deposit that's been independently rebuilt and certified gives you something dated and inspectable for your Register of Information. 

DORA compliance checklist

Use this as a quick self-check. If you can tick all of these, your DORA compliance is in good shape:

• Map your ICT risk management framework against all five pillars

• Build and maintain a current Register of Information covering every ICT contract

• Classify which services support a critical or important function

• Assess your concentration risk across providers

• Renegotiate ICT contracts to include the Article 30 clauses

• Write exit strategies for every critical or important dependency

• Test those exit strategies and document the results

• Verify that any escrow deposits are complete and buildable

The part of DORA you can't leave as a draft

DORA compliance has a quiet trap built into it. The parts you can prepare in advance, like the policies, the register, and the signed contracts, are the ones that feel like progress, so they get done first.

The part that decides whether you stay operational, the tested exit strategy, is the one most easily left as a draft.

That's the gap supervisors are looking for in 2026. And it closes the moment you stop trusting your recovery plan and start testing it. A verified escrow deposit is one of the clearest ways to do that for the software your critical functions run on.

»  Find out how software escrow can strengthen your compliance evidence on our DORA solutions page.