Stressed exit testing: What it is, what it proves, and how to run one

Somewhere in your operational resilience documentation sits a vendor exit plan. It names the critical supplier, the trigger conditions, the steps your team would take if that supplier failed. It reads well, it passed internal review — and yet nobody has ever run it. Stressed exit testing exists to fix exactly that.

When done right, a tested exit plan can prove exactly how you would cope when a vendor disappears. And with new regulations tightening in all key industries, that's not a process you can ignore. This article takes you through why it's necessary and how to run your tests correctly.

Why "tested" is the operative word in most new regulations

Read the relevant clauses closely and the same verb keeps surfacing. DORA Article 28(8) tells financial entities their exit plans must be "comprehensive, documented and ... sufficiently tested and reviewed periodically." The drafters could have stopped at documented. They didn't, because it means nothing if left untested.

The UK's PRA goes further and names the scenario directly. Under Supervisory Statement SS2/21, firms must test an exit strategy that separates a stressed exit, the failure or insolvency of a provider, from an ordinary planned one. The stressed version has to hold under real pressure.

Australia's CPS 230 lands on the same point from another angle. It requires business continuity plans to be tested against severe but plausible scenarios, and says plainly those scenarios must include the disruption of a material service provider. Since July 2025, that testing is law.

Three regulators, three jurisdictions, one shared instinct. Each agrees that a firm holding a documented plan with no evidence behind it has done half the job. So, they forced testing into law.

» Take a closer look at what your exit strategy for DORA needs to include. 

What a stressed exit test actually involves

Strip away the regulatory language, and the exercise becomes clear. A stressed exit test recreates the worst version of a vendor failure and checks whether you survive it. You assume no notice, no cooperation, and a handover that never arrives. Any best-case condition you leave in defeats the point.

What that takes is more than a copy of the source code. You need the build scripts and configs that turn code into a running system, the dependencies it calls, the credentials that reach the database, and somewhere to host it. Miss one and recovery stops.

So a stressed exit test proves something a document review never can: that those pieces exist and your team can actually run them. If all you've confirmed is that the plan reads well and the contract grants you the files, you've tested the paperwork, not the exit.

The six things a stressed exit test has to confirm

Vendor exit plan testing is only as good as the questions it asks. A test that confirms the easy things and skips the hard ones hands you a certificate and a false sense of safety. A complete test confirms six things, each one a place where an untested plan quietly breaks.

1. The materials are current. The deposited code, data, and configurations match what is running in production today, not a snapshot from six months and several releases ago.

2. The materials are complete. Nothing critical is missing. Dependencies, configuration files, and credentials are all present, because a rebuild stops dead at the first thing that isn't there.

3. The materials are usable. What you hold can be deployed, not just stored. A vault full of files you can't run is an archive, not a recovery position.

4. The rebuild works without the vendor. A qualified team can stand the system up using only what the deposit contains, with no calls to people who no longer work there.

5. The timeline is realistic. Recovery finishes inside your recovery time objective (RTO), the maximum downtime your business and your regulator will accept before the consequences start.

6. The evidence is auditable. The test produces documentation an examiner can read, follow, and trust as proof the exercise happened and held.

How to run your test without touching production

The obvious worry stops many firms before they start. Testing an exit sounds like pulling the plug on a live vendor to see what happens, which no operations lead will sign off on. It doesn't work that way, and the reason points straight to the method.

You never touch the production system. You spin up a fresh environment, a clean cloud instance, or isolated sandbox with no link to the vendor, and rebuild the application there from the backed up materials alone. Restore the database from the deposited copy, run the build, wire in dependencies and credentials, and bring the system up.

Then you confirm it actually works. Log in, run the core transactions, check the data is intact, and that the integrations respond. Document each step and where it stalled as you go. The live service keeps running untouched while you prove recovery beside it.

Doing this by hand for every critical vendor is a real lift. That's why escrow verification services exists to run the rebuild, confirm it works, and hand you the documented evidence. Letting a third-party handle the rebuild also ensures it's a true blind build that proves the system is recoverable from just those elements.

What your evidence pack needs to contain

A test that leaves no trace might as well not have happened. When an examiner from the DORA, the PRA, or APRA asks you to demonstrate your exit capability, a spoken account of an exercise you ran last spring won't hold. The output is the point, and it has a defined shape.

A complete evidence pack from a stressed exit test holds the following:

• The date and scope of the test, naming the vendor relationship and the systems covered.

• The assets tested, recording exactly what the deposit contained at the moment the test ran.

• The methodology, describing how the test was conducted and who carried it out.

• The result, stated as a clear pass or fail, with specific detail on any gap the test exposed.

• A Software Resilience Certificate, documenting that recovery from the deposit was confirmed.

• A remediation log, tracking every gap found and what was done to close it.

Two of those items decide whether the pack survives scrutiny. The result has to admit failures honestly, and the remediation log has to show you acted on them. An evidence pack recording only successes tells an experienced examiner the test was never stressful enough to find anything.

» If you need to answer to DORA specifically, take a look at how you need to set up your evidence for Article 28. 

How often a stressed exit test needs to run

Annual is the working answer for critical vendors. It's what auditors expect to see, and it lines up with how most firms schedule their other resilience testing. For a vendor whose software barely changes, that's genuinely enough.

The trouble is that an annual schedule measures time, and the thing that actually puts your recovery at risk is change. Every release the vendor ships moves the live system a little further from the copy you hold in a backup or software escrow. A vendor pushing updates every week can drift out of testable range in a month. 

Best practice is to test after anything that considerably alters the system: a major release, an acquisition, a rebuilt deposit. Skip that, and your annual test still passes, but it only proves you could have recovered a version of the system you stopped running months ago.

Where stressed exit tests fall apart

A stressed exit test usually fails for one of four reasons. None of them are surprising, and all of them were fixable long before the test ran. The point of testing is to find them while you still have time to do something about it.

1. The deposit had gone stale. Releases kept shipping while the deposited copy sat untouched, so the team rebuilt a version of the software that production left behind long ago.

2. Something essential was never deposited. A third-party library, a set of credentials, or a server configuration lived outside the deposit, and the rebuild stalled the moment it was needed.

3. Nobody on hand could do the rebuild. The knowledge required to stand the system up belonged to the vendor's engineers, and once they were gone, so was any way to use the materials.

4. The RTO was a guess. The plan assumed recovery in days, the real rebuild ran into weeks, and the gap between the two surfaced at the worst possible moment.

Three of these four are housekeeping. Keep the deposit current, deposit everything, and check your RTO against a real rebuild time, and they go away. The fourth is the hard one. You can store the code, but you can't store the knowledge of how to run it, and that leaves when the vendor does. A test is the only way to find out whether your own team can manage without them.

Where to start if you have never tested

If you haven't run a test like this, you're in good company. Stressed exit testing is new, and most teams wrote their exit plans to satisfy an audit without ever checking whether the recovery would actually work.

Start by deciding which vendors are worth testing. Not every supplier needs a full stressed exit test, so focus on the critical few your operations can't run without. Codekeeper's risk assessment tool can help you sort that quickly.

From there, the steps are straightforward: confirm the deposit is current and complete, verify the materials are usable, run the test in an isolated environment, and document the result. The verification step is the one most teams can't do alone.

Proving the materials will work is the hard part, and Codekeeper's Certified verification can do it for you. It runs the build, confirms the system deploys, and issues a Software Resilience Certificate, the documented proof that DORA and CPS 230 ask for.

The disaster recovery plan isn't enough

Most teams already test their disaster recovery plan, and it gives a reasonable sense that recovery is covered. But a DR test only proves you can recover from your own failures, a dead server, an offline data center, or a backup you need to restore. Every one of those assumes the vendor is still there.

A vendor disappearing is a different failure. The people who built the system are gone, the environment they ran it in is gone, and none of your own backups bring them back. That failure is the one regulators now expect you to plan for.

» If you'd rather not run the rebuilds yourself, Codekeeper's Certified verification of software escrow deposits can do the stressed exit testing for you. Book a 30-minute demo to see how it works.