DORA Article 28 exit strategies: what financial entities need to build.

Most teams working towards DORA have an exit strategy on file. It names their critical providers, describes how the firm would move off each one, and sits ready for the next review. Article 28 asks a different question: would the plan work if you had to use it?

A plan that has been written down but never tested describes an intention. This article covers what Article 28 expects, why a documented plan and a tested plan aren't the same thing, what a tested exit strategy covers, and the evidence that shows yours has been tested.

What Article 28 asks of you

Article 28 of the Digital Operational Resilience Act (DORA) sets out how financial entities manage the risk that comes from their ICT third-party service providers. The exit strategy obligation is narrower than many teams assume. It applies to ICT services that support critical or important functions, not to every supplier you use. So the first job is knowing which of your providers fall inside that scope.

For those that do, paragraph 8 sets the standard for exit plans.

Codekeeper's evidence supports your assessment. Whether it meets a specific requirement is for you and your assessor to decide.

That's four requirements: comprehensive, documented, sufficiently tested and reviewed periodically. Three of them can be met on paper. "Sufficiently tested" can't. It asks for evidence that something was done, and that's where most exit programmes have the least to show.

The standard is also proportionate. The paragraph points to the criteria in Article 4(2), which apply the rules in proportion to a firm's size and risk profile. A small payment institution and a large bank aren't expected to test to the same depth.

A filed plan and a tested plan

A plan describes what you intend to do. It might say: if this provider fails, we'll retrieve the source code, stand it up on other infrastructure and migrate our data within 90 days. Every part of that sentence is a claim.

A tested plan is what you have once someone has checked those claims. When the software has been rebuilt from what you hold, you know whether 90 days was realistic, and what was missing.

That's the difference a reviewer looks for. A plan shows intent. A dated test result shows capability. Article 28(8) asks for both.

For the wider exercise, step by step, see our guide to software vendor exit planning.

What a tested exit strategy covers

If testing is what separates a working exit strategy from a written one, the next question is what to test. In practice, an exit plan for a critical ICT provider comes down to four working parts. Going through them is the quickest way to see where your programme is solid and where it needs work.

1. A transition plan

The documented sequence for moving off the provider, with timelines. The timelines have to hold up under adverse conditions. A migration that takes three weeks when everyone cooperates can take three months when the vendor is insolvent and unresponsive. Done means the timeline has been checked against the difficult version of events, not the tidy one.

2. Data portability

A confirmed ability to extract your data in a usable format when the contract ends. "Usable" is the word that matters: data you can export but can't read, reload or work with isn't portable. Done means an extraction you've opened and worked with.

3. An alternative

For each critical relationship, at least one alternative you could move to: another provider, or bringing the service in-house. Naming one is easy. Done means an option you've assessed for the specific function it would take over.

4. Periodic testing

The part that turns the other three from claims into evidence. It means running the recovery on a cadence that matches the risk, and again when something significant changes, and keeping a record of the result. Done means proof that the materials were exercised and behaved as the plan said they would.

Where rebuild evidence fits

Of the four parts, the recovery itself is the hardest to evidence. You can write a transition plan and assess an alternative on your own. Showing that the materials you hold would rebuild into working software is a different task. It needs the deposit, a clean environment and someone who didn't write the code.

A deposit nobody has tried to rebuild is the document problem again, moved into a vault. Codekeeper's proof comes in three steps, and each one adds a different document to your file:

• Software Resilience Certificate, with every protection. The deposit is held, and an automated check, with a vault report, has confirmed what's in it.
• Recoverability Certificate, with Escrow Pro, Resilience Pro and Continuity Pro. Agentic Verification: AI agents rebuild the deposit in the Codekeeper AI Verification Lab, with no help from the vendor, in hours. The run also produces build steps, an SBOM, an Exit workbook and a deployable copy.
• Tested Exit Report, from an Exit Exercise, an add-on to any plan. Our specialists rebuild the application by hand in a clean room, from the deposit alone, and test the business functions you nominate, without the original developers. The report records pass or fail, the gaps found and the date, with an annex mapped to DORA.

Which proof you need depends on the function. For ICT services that support critical or important functions, our guidance is Resilience Pro or Continuity Pro, plus an Exit Exercise when the plan needs exercising, not just a rebuild. The DORA page maps each document to Article 28.

What to keep on file

The clearest way to find out whether your exit strategy is tested or only written is to assemble what a reviewer would ask to see, and check how much of it you can produce. If the plan document ends up standing in for several items, that's where to start. For one critical provider, the file usually holds:

Only the agreement and the plan are documents in the ordinary sense. The rest are records of things having been done, which is what makes the file hard to keep whole. A certificate from last year doesn't show that this year's deposit still builds, so the evidence has to be refreshed as the software changes.

Not sure which providers need this? Learn how to assess your vendor risk and match the right protection to each one.

Common gaps

Check real exit programmes against that file and the same gaps come up. It's rarely a sign of a careless team. Most programmes were built to produce a document, not to show that the recovery works. The gaps tend to sit in a few places:

• An exit strategy that describes a process but never names the materials needed to carry it out.
• Source code in escrow that has never been rebuilt, so the deposit exists but nobody knows whether it builds.
• Annual reviews that update the wording of the plan without testing the recovery.
• No alternative identified for a critical ICT relationship.
• Transition timelines that have never been checked against a realistic failure.

Each gap is the same issue in a different form: a capability the programme describes but hasn't confirmed. Closing them isn't about writing more. It's about testing what's already written. For the wider picture, read our guide to managing vendor risk with software escrow.

A note for software vendors

If you sell software to EU financial entities, Article 28 reaches you too, from the other side. Your customers have to plan their exit from the ICT services they rely on, and yours may be one of them.

Expect their risk and procurement teams to ask how they would exit, and what would happen to the code and data if you couldn't support them. Escrow answers that before they ask. With Escrow Pro, you can also show them a Recoverability Certificate: proof the deposit builds without your help, so due diligence doesn't stall the deal. Read more on software escrow for financial services.

Test it before you need it

A review is one test of an exit plan. The other comes on the day a critical provider stops and you start the recovery. That's when it matters whether the materials you hold rebuild into working software.

Rebuild evidence answers that question in advance, on a schedule you choose, with a dated record for your file. To see where you stand first, the free risk assessment shows which providers carry the most risk.