A practical guide to ESMA compliance and software continuity

If you work at a regulated financial firm, you've probably watched ESMA turn up in the same sentence as DORA and NIS2 more than once. It usually shows up in a contract clause or an audit question, and you've likely wondered what it's asking of you.

The honest answer is that ESMA compliance is rarely a single rule you can tick off. It's layered, and a 2025 change moved most of the weight somewhere you might not expect. This guide explains what ESMA is, what complying with it means now, and the question underneath it all.

What is ESMA?

The European Securities and Markets Authority (ESMA) is the independent European Union authority that oversees securities markets, protects investors, and works to keep the financial system stable.

It's been operating since January 2011, it's based in Paris, and it took over from an earlier body called the Committee of European Securities Regulators. If you've dealt with EU market rules for any length of time, you've been dealing with ESMA's work whether its name was on the page or not.

Everything ESMA does traces back to three objectives:

• Investor protection: making sure people who put money into markets are treated fairly and understand the risks.

• Orderly markets: keeping trading transparent, efficient, and working the way it should.

• Financial stability: strengthening the system so it can take a shock without falling over.

Those three goals are easy to state. What matters for you is how ESMA goes about reaching them, because that's what decides whether it touches your software at all.

How ESMA works in practice

Here's the part that trips people up. ESMA doesn't usually regulate your firm directly. Mostly, it writes the rules and lets others enforce them.

Its output mostly takes the form of guidelines, technical standards, and recommendations. National competent authorities (the regulators in each EU country, usually shortened to NCAs) are expected to follow them, and they pass that expectation on to the firms they supervise.

ESMA only supervises a small set of entities itself, mainly credit rating agencies and trade repositories. For everyone else, ESMA's influence reaches you through your national regulator and through the single rulebook it helps build. It's a common set of standards meant to keep the rules consistent across the EU.

Because ESMA works through other people's enforcement, complying with ESMA almost never means satisfying one ESMA rule. It means meeting the requirements ESMA has shaped, wherever they've ended up living. And in 2025, a lot of them moved.

What ESMA compliance looks like in 2026

So what does ESMA compliance involve today? For most firms, it means complying with the rules ESMA has shaped across conduct, transparency, and reporting. That part hasn't changed.

What changed is where the rules on technology and operational continuity live. On January 17, 2025, the Digital Operational Resilience Act (DORA) became applicable across the EU. DORA pulled together the requirements for managing technology risk and third-party providers, including the cloud, and absorbed most of what ESMA's older guidelines used to carry.

ESMA then trimmed its own rules to fit. On July 11, 2025, it revised its cloud outsourcing guidelines so they apply to a narrow group only: certain fund depositaries under the Alternative Investment Fund Managers Directive (AIFMD) and the Undertakings for Collective Investment in Transferable Securities (UCITS) directives that sit outside DORA. The revised guidelines took effect on September 30, 2025.

What changed, in one line: most of ESMA's technology and cloud outsourcing requirements moved into DORA. ESMA's own cloud guidelines now bind only a small set of fund depositaries that DORA doesn't cover.

So does ESMA compliance still apply after DORA? Yes, but for most firms, the operational resilience part of it now lives inside DORA, not the old ESMA cloud guidelines. If you're a financial entity in DORA's scope, that's where your obligations sit today. The label on the rule changed; the expectation behind it didn't soften.

» Take a look at what your obligations look like now under DORA. 

ESMA's cloud outsourcing guidelines: the nine principles

Beyond who they bind, the guidelines come down to nine principles for any firm that outsources functions to a cloud provider:

1. Governance, oversight, and documentation: keep a clear, current record of what you've outsourced and who's accountable for it.

2. Pre-outsourcing due diligence: assess the provider and the risk before you sign anything.

3. Key contractual elements: write the rights, obligations, and service levels into the contract explicitly.

4. Information security: set security requirements in your policies and the agreement, then monitor them.

5. Exit strategies: be able to leave the arrangement without disrupting your business.

6. Access and audit rights: keep the right for you and regulators to inspect the provider.

7. Sub-outsourcing: track and control the providers your provider relies on.

8. Notification to regulators: tell your national competent authority before outsourcing critical functions.

9. Ongoing supervision: monitor the arrangement for as long as it runs, not only at the start.

Read that list and one thing becomes clear. It's less a technology checklist than a description of staying in control of something you've handed to someone else. Eight of the nine are about governance and oversight. One of them is about getting out, and that one is where most firms quietly fall short.

» Learn more about setting up audit-ready governance documentation. 

Why exit strategies are the part most firms get wrong

An exit strategy sounds simple until you ask what it requires. ESMA doesn't just want a clause saying you may terminate. It wants evidence that you could move off a critical provider and keep running, in a planned exit and in an ugly one: the provider going under, the contract collapsing, or the service degrading until you have to leave fast.

That means the migration steps can't only exist on paper. They have to be documented and tested, so you know they work before the day you need them. A plan you've never run is a hypothesis, not a capability.

Here's where the gap opens. Most firms have the clause and not the capability. The contract grants a right to exit, the runbook describes how, and nobody has ever checked whether the team could rebuild the system from what they hold.

A right to leave is not the same as a tested ability to leave.

If your provider holds the source code, the data, and the knowledge to run the system, your exit plan depends on materials you don't possess. That's the practical problem the next section addresses.

» Take a look at our full guide to setting up your vendor exit strategy

Where software escrow fits

Software escrow is one recognized way to close that gap, and it predates all of these regulations by decades. The idea is simple. A neutral third party holds the materials a firm would need to keep a critical system running or move it elsewhere, and releases them under conditions agreed in advance.

In practice, the escrow agent holds:

• the source code behind the system,

• the data and configuration it runs on,

• and the documentation needed to rebuild or migrate it.

If a release condition is met (the provider becomes insolvent, breaches the contract, or discontinues the product), those materials are released to you.

On its own, that turns a contractual right to exit into possession of what you'd need to act on it. Verification goes further: by rebuilding the deposited system and testing that it works, it produces a documented record (a Software Resilience Certificate) proving recovery has been tested, not assumed.

That's the difference exit strategies turn on. Not whether you're allowed to leave, but whether you have proof you can.

How ESMA, DORA, and NIS2 fit together

These three names travel together for a reason. They overlap at the edges, and a single firm can sit under all of them at once. This is how they divide up.

Notice what the right-hand column keeps repeating. Different regulators, different wording, the same underlying demand: show that you can keep critical systems running when a provider can't. ESMA shaped that expectation, DORA now carries most of its weight, and NIS2 (the EU's second network and information security directive) extends a similar logic well beyond finance.

» Find out more about where global regulatory shifts are heading.

What this means for you

It's tempting to read ESMA compliance as a question of which rules apply to you right now. But that answer keeps moving. The cloud-outsourcing position alone changed twice in 2025, and the next change will move it again.

What doesn't move is the thing all these rules keep describing: being able to leave a critical provider and keep running. The firms in the best shape aren't the ones tracking every regulatory update. They built that capability, so they're covered whatever the rule is called next.

» Most firms answer to several of these rules at once. See how Codekeeper approaches software continuity compliance across industries and regulations.