DORA Article 28 exit strategies: What financial entities need to build

Most teams working toward DORA compliance have an exit strategy on file. It names their critical vendors, describes how the firm would move off each one, and sits in a folder ready for the next audit. Their DORA Article 28 exit plan exists, the box is ticked, and the assumption is that the work is done.

That assumption is a trap. Article 28 does not ask whether you have written down what you would do if a critical ICT provider failed. It asks whether that plan would actually hold up if you ever had to use it. A DORA exit strategy that has only ever been described, and never tested, misses the point.

This post walks through what Article 28 genuinely demands, why a documented plan and a tested plan are not the same thing, and how to tell which one you currently have.

What Article 28 expects of you

Article 28 sits inside the rules set by the Digital Operational Resilience Act (DORA) for managing ICT third-party risk. The exit strategy obligation is narrower than people often assume. It applies specifically to ICT services that support critical or important functions, not to every vendor relationship you hold. The first job, then, is knowing which of your providers fall inside that scope.

For those that do, the regulation sets a four-part standard. Exit plans must be comprehensive, documented, sufficiently tested, and reviewed periodically. Three of those four words describe paperwork. One of them, "sufficiently tested," describes evidence, and it is where most exit programs fall short. The standard is also proportionate, tied to the criteria in Article 4(2), so a small firm and a systemic bank are not held to identical depth.

Plenty of teams can produce a plan that is comprehensive, documented, and reviewed each year. Far fewer can produce evidence that the plan was put under any kind of test. The regulation treats that evidence as part of the obligation, not an optional extra.

The difference between a filed plan and a tested plan

A plan is a description of intent. It says, in effect, "if this vendor fails, we will retrieve the source code, stand it up on alternative infrastructure, and migrate our data within 90 days." Every clause in that sentence is a claim.

A tested plan is what you have once someone has checked whether those claims are true. Once the build actually runs, you'll know for sure if that 90-day recovery estimate was even remotely realistic under termination conditions.

Until that confirmation exists, the plan means little in practice and even less to an auditor. They will not ask to see your exit strategy. They will ask to see your test results. If all you show up with is your disaster recovery plan, you have demonstrated intent, not capability. Article 28 was written to close exactly that gap, because intent has never kept a single critical system running.

» Take a look at exactly what you need for your software vendor exit planning.

What a tested exit strategy covers

If testing is the part that separates a real exit strategy from a written one, the obvious next question is what should you test. A DORA third-party risk exit strategy breaks down into four components under Article 28. Working through them is the most direct way to see where your own program is solid and where it needs refinement.

Transition plan

This is the documented sequence for moving off the vendor, with timelines attached. The timelines have to survive contact with realistic adverse conditions. A migration that takes three weeks when everyone cooperates can take three months when a vendor is insolvent and unresponsive. "Done" means the timeline has been pressure-checked against the messy version of events, not the tidy one.

Data portability

You need a confirmed ability to extract your data in a usable format under termination conditions. The phrase that matters is "usable format." Data you can technically export but cannot read, reload, or operate on is not considered portable. "Done" looks like a successful extraction that you have actually opened and worked with.

Alternative provider mapping

For each critical relationship, you need at least one identified alternative you could move to. This sounds like the simplest component, and on paper it is. The trap is naming an alternative you have never assessed for the specific function it would have to take over. "Done" means a named, evaluated option that could genuinely absorb the workload.

Periodic testing

This is the component that converts the other three from claims into evidence. It means running the recovery, on a cadence proportionate to the risk or whenever significant changes occur, and keeping a record of the result. "Done" is when you have proof that the materials were exercised and behaved as the plan said they would.

» Read our full guide for managing vendor risk with software escrow.

Where software escrow verification fits

Of the four components, the one teams find hardest to evidence is the recovery itself. You can write a transition plan and name an alternative provider on your own. Proving that the materials you hold would actually rebuild into a working system is a different kind of task, and it is where verified software escrow comes in.

Verification checks that the assets sitting in escrow, namely the source code, deployment configurations, credentials, and dependencies, are complete, current, and deployable. The point is not that the materials are present. It is that they have been confirmed to do what recovery would require of them. A deposit nobody has tested is the document problem all over again, just moved into a vault.

Codekeeper's Certified verification tier takes this furthest. It runs full test builds, adds expert human review, and confirms the deposited stack can be deployed. The output is a record that the recovery materials work, which is precisely the evidence Article 28(8) has in mind when it calls for an exit plan to be sufficiently tested. That record supports compliance with the testing requirement; it is evidence toward it, not a guarantee of the outcome. The regulation still expects the rest of the program to hold.

The Article 28 evidence pack: what an auditor asks to see

The cleanest way to find out whether your exit strategy is tested or merely written is to assemble what an examiner would ask for and see how much of it you can actually produce. If the folder fills easily, you are in good shape. If you find yourself reaching for the plan document to stand in for several items, that tells you what to work on. An Article 28 evidence pack generally includes:

• The escrow agreement covering the critical ICT relationship.

• Deposit logs showing the materials are current.

• A verification certificate confirming completeness and deployability.

• The transition plan with timelines that have been tested.

• A record of the most recent exit test and its result.

Notice that only the first and fourth items are documents in the ordinary sense. The rest are records of things having been done, and that is what makes the pack hard to keep whole. A certificate from last year does not prove this year's deposit still builds, so the evidence has to be regenerated as your software changes and each annual review comes around. Assembling the pack once is work. Keeping it current year after year for all vendor relationships is where teams tend to fall behind.

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

Common gaps in current exit programs

Check real exit programs against that list, and the same gaps show up over and over. This is not a sign of careless teams. Most programs were built to produce a document, not to prove the recovery works. The gaps tend to cluster in a few recognizable places:

• An exit strategy that describes a process but never references the actual materials needed to execute it. 

• Source code escrow in place, but no verification, so the deposit exists while its usability stays unconfirmed.

• Annual reviews that update the wording of the plan without ever testing whether recovery works.

• No alternative provider identified for a critical ICT relationship.

• Transition timelines that have never been stress-tested against a realistic failure.

Read down that list, and a pattern surfaces. Every gap is the same failure in a different form: claiming a capability the program has described but never confirmed. Closing them is not about writing more. It is about proving what you have already written.

A note for software vendors

If you sell software to EU financial institutions, this regulation lands on your desk too, just from the other side. Your clients now have to build Article 28 exit strategies for the critical services they buy, and yours may well be one of them.

In practice, their contracts will need to secure termination rights, the return of code and data, and active exit support from you. Escrow is how you show that is already handled. It turns a procurement delay into a short conversation and signals to a cautious buyer that you took their resilience seriously first.

» Discover how software escrow keeps financial service providers compliant.

The exit you build for the day it gets used

An auditor's questions were never the real test. The real test is the day a critical vendor goes down and you try to recover. That is when you find out whether the materials you kept actually rebuild into a working system, or fall short when it counts. Verified software escrow is one of the few ways to settle that question ahead of time, because the deposit is tested and confirmed to rebuild.

And that is the point of Article 28. The regulation calls for tested recovery evidence to ensure one firm losing a critical provider won't cascade that damage on to other firms or clients in the industry.

Most teams don't know where they'd actually stand if a critical vendor failed next week. That's worth finding out before it happens.

» Run Codekeeper's free risk assessment tool to see which vendors are carrying the most risk.