- ESMA's Principles on third-party risks supervision (12 June 2025) say ICT services are DORA's territory and "out of scope of these principles" (para 7). Production's FAQ says the opposite ("ESMA's principles cover … business software").
- ESMA's Guidelines on outsourcing to cloud service providers were reissued on 30 September 2025. They now apply to competent authorities and to certain AIF and UCITS depositaries that aren't DORA financial entities; the 2021 version ceased to apply to DORA entities (para 4). Production doesn't mention the guidelines at all.
- The headline uses the words DORA Article 28(8) and cloud Guideline 5 share: exit plans that are "comprehensive, documented and sufficiently tested". Whichever text applies, the evidence is the same. The 30 September 2025 date is the cover date of the revised guidelines; they apply from publication in all EU official languages (para 3), and ESMA's document page doesn't date the translations, so no application date is stated.
- The visual is an example evidence file for a fund-services firm. Names, dates and contents are fictional and labelled.
Comprehensive, documented, sufficiently tested.
That's how DORA and ESMA's cloud guidelines both describe a good exit plan, and which one applies depends on your firm. Codekeeper gives you the evidence for either: the software rebuilt without the vendor, dated and on file.
Not sure which text applies to you? Start with the table
- Trusted by 3,500+ teams
- ISO/IEC 27001:2022 certified
- Evidence for cloud Guideline 5 and DORA Art. 28(8)
Trusted by 3,500+ teams, from regulated enterprises to fast-growing software vendors
- Cloud guidelines (ESMA65-294529287-4737, 30 Sep 2025): para 1 (who), para 3 (they apply from publication on ESMA's website in all EU official languages, to arrangements entered into, renewed or amended from then), para 4 (the previous guidelines "cease to apply to those financial entities subject to DORA"), paras 30 to 32 (Guideline 5, exit strategies).
- Principles (ESMA42-1710566791-6103, 12 Jun 2025): para 7 (scope, ICT out), para 8 (specific sectoral requirements prevail), para 31 (Principle 8, contractual arrangements). ESMA's news item says they "provide a common supervisory basis to National Competent Authorities (NCAs) and ESMA".
- DORA entities in the first row are the ones already checked in Article 2(1) for the DORA page; "the other entities listed in Article 2(1)" covers the rest without naming any we haven't checked. Fact-check, 7 Oct: the row used to say the earlier guidelines "ceased to apply to you once DORA applied". Para 4 says they "cease to apply" to DORA entities "in light of the application of DORA" and gives no date, so the row now follows that wording. Paras 1, 3, 4, 30 and 31, and Principles paras 7, 8 and 31, were rechecked against the ESMA PDFs.
- Not used: production's "four key controls to prevent empty shell operations", "Maintained operating licenses", "Avoided emergency system rebuilds costing millions", "Accelerated regulatory approval", and the claim that the principles help interpret "MiFID II, EMIR, and UCITS". None was checked.
What ESMA asks
First, which text applies to you.
For software and cloud services, most firms in ESMA's remit answer to DORA. ESMA's own guidelines and principles cover the rest.
| If you are | What applies to the software and cloud services you rely on |
|---|---|
| A financial entity under DORA | Investment firms, trading venues, central counterparties, central securities depositories, managers of alternative investment funds and the other entities listed in DORA Article 2(1). DORA covers the ICT services you use, including exit plans under Article 28(8). In light of DORA, ESMA's earlier cloud guidelines no longer apply to you.See our DORA page. |
| A depositary of AIFs or UCITS outside DORA | Depositaries referred to in Article 21(3)(c) and Article 21(3), third subparagraph, of the AIFMD, and in Article 23(2)(c) of the UCITS Directive, where they aren't DORA financial entities. ESMA's Guidelines on outsourcing to cloud service providers (2025) apply, including Guideline 5 on exit strategies.Guidelines, paras 1 and 30 to 32. |
| A national competent authority | The cloud guidelines apply to you too. ESMA's Principles on third-party risks supervision give you and ESMA a common supervisory basis for third-party arrangements other than ICT services.Principles, para 7. |
| Any firm in ESMA's remit, for arrangements outside DORA | Your supervisor may use the Principles for outsourced functions and other third-party arrangements that aren't ICT services. Where your sectoral rules already set specific requirements, those prevail.Principles, para 8. |
“In case of outsourcing of critical or important functions, a firm should ensure that it is able to exit the cloud outsourcing arrangement without undue disruption to its business activities and services to its clients … For that purpose, a firm should: a) develop exit plans that are comprehensive, documented and sufficiently tested. These plans should be updated as needed, including in case of changes in the outsourced function;”
“Exit plans shall be comprehensive, documented and, in accordance with the criteria set out in Article 4(2), shall be sufficiently tested and reviewed periodically.”
“Important to note that the management of ICT risk and the use of third-party service providers to provide ICT services fall under the scope of the Digital Operational Resilience Act (DORA) and are therefore out of scope of these principles.”
“The arrangements should provide a contractual basis for … business continuity, including record retention, entity’s termination rights and exit plans to ensure that, post-termination or otherwise whenever necessary due to failures on the third-party’s part, the entity can terminate or exit the contract with no ongoing remaining regulatory, operational or technological dependency on the third-party.”
Codekeeper's evidence supports your assessment. Whether it meets a specific requirement is for you and your assessor to decide.
Where software you don't control fits
An exit strategy describes the move. Evidence shows it works.
Exit strategies name the triggers, the alternative and the transition. When the provider has failed, the move depends on what you hold. Codekeeper holds it and proves it rebuilds.
Name the arrangements
Add the applications behind your critical or important functions, cloud or on-premise.
Attach the protection
Resilience Pro or Continuity Pro for each one. The deposit syncs daily from the provider's repositories.
Rebuild without the vendor
Run up to four rebuilds a year. Each successful run issues a dated Recoverability Certificate.
Exercise the exit
Add an Exit Exercise to test the functions you nominate, with an annex mapped to your framework.
- The last row is careful about scope. The Principles exclude ICT services, so the row speaks only to arrangements outside DORA, such as an outsourced function a provider runs on its own software. That's where Principle 8's "technological dependency" bites.
- Confirm before launch: whether the live environment map is a document customers receive (open item from the DORA and NIS2 pages).
- 16 Oct: Continuity Pro added. Rebuild evidence (Exit workbook, build steps, SBOM, Recoverability Certificate, run report, deployable copy) now comes with Escrow Pro, Resilience Pro and Continuity Pro; base Continuity no longer includes Agentic Verification. The live environment map row stays "Continuity": both levels include it.
Evidence map
What each document adds to your exit strategy.
Every document is dated and tied to one application, so your file shows what was tested, how and when.
| What your exit strategy needs | Codekeeper evidence |
|---|---|
| Comprehensive and documented Cloud guidelines para 30(a) · DORA Art. 28(8) | The recovery process step by step, and the components the application needs. Exit workbookBuild stepsSBOMEscrow Pro · Resilience Pro · Continuity Pro |
| Sufficiently tested Cloud guidelines paras 30(a) and 31(e) · DORA Art. 28(8) | AI agents rebuild the deposit in the Codekeeper AI Verification Lab, with no help from the vendor. Add an Exit Exercise to test the business functions you nominate, without the original developers. Recoverability CertificateRun reportTested Exit ReportPro levels · Exit Exercise as an add-on |
| Trigger events, including the provider's failure Cloud guidelines para 31(b) | Release or recovery conditions written into the agreement before anything goes wrong. Escrow AgreementResilience ArrangementEvery protection |
| Back to the firm or to an alternative Cloud guidelines para 30(b) | A deployable copy to start from. With Resilience, Codekeeper runs the recovery for you. Deployable copyExit workbookEscrow Pro · Resilience Pro · Continuity Pro |
| Business continuity during the transition Cloud guidelines para 30(b) | We map the live environment at setup, keep the map current, and if the provider stops, keep it paid and switched on for an agreed period while we recover. Live environment mapContinuity |
| No ongoing technological dependency, outside DORA Principles para 31 | Where a provider runs your function on its own software, the deposit is held by a neutral party and, with Pro, proven to rebuild without the provider. Software Resilience CertificateVault reportRecoverability CertificateEvery protection · Recoverability Certificate with Pro levels |
Codekeeper's evidence supports your assessment. Whether it meets a specific requirement is for you and your assessor to decide.
Which protection fits
Who runs the recovery when a provider stops?
Escrow means the deposit is released to you and you run the recovery. Resilience costs more because we do the recovery. Continuity costs more again because we also keep the live environment switched on.
Escrow
Released to you→Self-Run Recovery
When the agreed conditions are met, the deposit is released to you. Escrow Pro adds proof it builds, from $449. Explore Escrow
From $199
Resilience
Comes to us→Managed Recovery
If the application fails, Codekeeper runs the recovery for you. Resilience Pro starts from a deposit we know builds, from $649. Explore Resilience
From $399
Continuity
Live service kept on+Managed Recovery
Everything in Resilience, plus the live environment kept paid and switched on for an agreed period while we recover. Continuity Pro adds proof it builds, from $1,699. Explore Continuity
From $1,449
Prices per application per month, for software applications; SaaS and AI applications have their own rows. Setup is $499 per arrangement for Escrow and Resilience, and $999 for Continuity. Our guidance for critical or important functions: Resilience Pro or Continuity Pro, plus an Exit Exercise. It's guidance, not a compliance promise. See all prices
Exit Exercise, from $12,000
An add-on to any plan, for when your exit strategy needs exercising and not just a rebuild. You get a Tested Exit Report with an annex mapped to your framework.
Sample evidence pack
See what your auditor would receive.
An anonymised set of outputs from a real Agentic Verification run, so you can judge the evidence before you talk to us.
- Recoverability Certificate
- Run report
- SBOM and Exit workbook excerpts
Questions
ESMA, answered.
Do ESMA's cloud outsourcing guidelines still apply to us?
Only if you're a competent authority or one of the depositaries they name. The 2025 guidelines apply to depositaries of AIFs referred to in Article 21(3)(c) and Article 21(3), third subparagraph, of the AIFMD, and depositaries of UCITS referred to in Article 23(2)(c) of the UCITS Directive, where they aren't financial entities to which DORA applies. For DORA financial entities, the previous guidelines ceased to apply.
We're a DORA financial entity. Where do we look?
DORA. Its rules on ICT third-party risk include Article 28(8): “Exit plans shall be comprehensive, documented and, in accordance with the criteria set out in Article 4(2), shall be sufficiently tested and reviewed periodically.” See our DORA page for the evidence that applies there.
Who are ESMA's third-party principles for?
Supervisors. ESMA says they “provide a common supervisory basis to National Competent Authorities (NCAs) and ESMA”. They apply across EU securities markets within ESMA's remit, but not to ICT risk or ICT services, which fall under DORA. Where sectoral rules set specific requirements on third parties, those prevail.
What does an exit strategy have to cover under the cloud guidelines?
Guideline 5 asks for exit plans that are comprehensive, documented and sufficiently tested, alternative solutions and transition plans, and support from the provider for an orderly transfer. The exit strategy should define its objectives, trigger events (including the provider's failure), a business impact analysis, roles and responsibilities, a test of its appropriateness and success criteria for the transition.
What does “sufficiently tested” mean in practice?
Neither text prescribes a method. Guideline 5 gives one example of testing: an analysis of the costs, impact, resources and timing of moving to an alternative provider. A rebuild without the vendor adds evidence that the software itself comes back, and an Exit Exercise tests the business functions you nominate.
Will this make us compliant?
No product can do that on its own. Codekeeper gives you evidence for your file: certificates, run reports, SBOMs, Exit workbooks and Tested Exit Reports with an annex mapped to your framework. Whether it meets a specific requirement is for you and your assessor to decide.
We provide software to securities firms. Does this help us?
Yes. Your customers have to plan their exit from you, under DORA or the cloud guidelines. With Escrow Pro you can show them the application rebuilds without your team, before they ask. Either party to the agreement can request an Exit Exercise.
Exit plans that are tested, and on file.
We'll work out which text applies to each of your critical providers, and the evidence each one needs.