Vendor exit risk: How to assess it and what to do about it

Anyone who manages vendor exit risk across a large portfolio almost certainly doesn't manage it evenly. Either teams apply the same level of scrutiny to every vendor relationship, or they sort risk by gut feel. Either way, the ranking isn't deliberate. The trouble with that is it creates gaps in their vendor exit risk plan.

Two vendors can carry the exact same risk on paper and put you in completely different positions if they fail. So the real work isn't deciding whether you have exit risk. You do. The work is figuring out where that risk concentrates, and matching the right amount of protection to each vendor instead of treating them all alike.

What vendor exit risk actually means

Vendor exit risk is what you're exposed to when a vendor leaves, whether through insolvency, acquisition, or a decision to discontinue the product you rely on. The vendor exits, and you're left running on software you don't control and can no longer count on or maintain. 

It gets confused with two neighboring problems, so it's worth drawing the line clearly. Vendor offboarding risk is about you ending a relationship cleanly, on your terms. Vendor lock-in is about being unable to leave even when you want to.

Software vendor exit risk is the opposite situation: the vendor is the one leaving, and you're caught completely unaware.

» Learn how to manage all manner of vendor risks with software escrow.

Why exposure varies across your portfolio

Here's where the even-handed approach falls apart. Picture two vendors in your portfolio. One runs your payroll. The other hosts the internal wiki where teams keep meeting notes. Both are third-party software. Both carry vendor exit risk in the strict sense, because either one could go under tomorrow.

But the day each of them fails looks nothing alike. If the payroll vendor disappears, people don't get paid, and you have a legal and operational emergency within a single cycle. If the wiki vendor disappears, someone grumbles, you export what you can, and you find another place to put notes by the end of the week.

That difference is the whole point of a vendor exit risk assessment. The strict definition treats those two vendors as equals, but your continuity plan can't afford to. What separates them is what their leaving would do to you, and how hard it would be to recover afterward.

The two questions that determine your exposure

Knowing how to assess vendor exit risk comes down to answering two questions about each vendor, honestly. The first measures what you'd lose. The second measures how trapped you'd be. Score both, and a vendor's real exposure becomes something you can clearly rank and plan for.

1. How critical is this vendor to your operations?

This question is all about consequences. If the vendor vanished overnight, would your operations stop, slow down, or barely notice? And how fast would the pain arrive? Speed matters as much as severity, because a system you can live without for a month is a different problem from one you can't live without for an hour.

To score it, answer these:

• Would a core business process stop or seriously degrade if this vendor's software went dark?

• How quickly would that happen: within hours, days, or weeks?

• Could you keep operating manually, even partially, while you find a fix?

2. How hard would recovery be if they exited?

This question focuses on capability. A vendor can be mission-critical and still be a manageable risk, as long as you can rebuild or migrate without them. What turns criticality into genuine exposure is not having what you'd need to recover on your own.

To score it, answer these:

• Do you hold the source code, deployment configurations, and credentials needed to run or rebuild this system without the vendor?

• Is the documentation current enough that your team could follow it under pressure?

• Has anyone actually tested a recovery, or are you assuming it would work?

The three-tier framework

Once you've scored both dimensions, every vendor falls into one of three tiers. The tier is set by how the two scores combine, and it tells you how much protection the relationship warrants. The point isn't to label vendors for its own sake. It's to stop over-protecting the wiki and under-protecting the payroll system.

Score honestly, and the tiers sort themselves. A vendor that's both hard to live without and hard to recover from is Critical, plain and simple. If only one of those is true, it's Significant. If neither is, it's Standard, and you can stop worrying about it and move on.

What the right control looks like at each tier

Each tier points to a different level of control. The higher the exposure, the more you put behind the relationship, which means the critical tier is where real protection belongs, and the standard tier is where you can keep things light.

Critical vendors

For a critical vendor, a contract clause promising access to source code isn't enough on its own. Software escrow hands over the source code, deployment configurations, credentials, and dependencies you'd need to rebuild or migrate.

But holding the materials and being able to use them are different things, and this is where most teams quietly overestimate themselves. Recovery readiness gets scored on the assumption that the documentation is current, the build still runs, and someone knows how to drive it. You don't find out whether any of that is true until you test it, and most teams never do.

That's the gap verification closes, by rebuilding the deposited materials to confirm they're complete and buildable, so your recovery is something you've proven won't let you down. Pair that with an exit plan you've actually run through, and the tier is covered.

Significant vendors

A significant vendor doesn't need the full apparatus, but it does need more than boilerplate. Prioritize the contract clauses that matter when an exit goes wrong: rights to source code on defined triggers, data return obligations, and reasonable transition periods.

From there, weigh software escrow against the cost of rebuilding from scratch. If recovery looks slow or uncertain, escrow earns its place. If you could realistically replace the vendor in-house, contract terms and a contingency plan will carry you. It comes down to playing it safe or risking downtime on your own abilities.

Standard vendors

For standard vendors, keep it proportionate. Standard due diligence and clean offboarding procedures are enough, because the whole reason they're in this tier is that losing them wouldn't hurt much or take long to fix. Putting real resources here pulls them away from the vendors that genuinely threaten your operations.

Where this becomes a compliance obligation

If you work in a regulated industry, this framework isn't just good practice. It's increasingly the baseline that regulators expect.

DORA, the EU's Digital Operational Resilience Act, has applied across EU financial services since January 2025 and requires documented and tested exit strategies for any vendor supporting a critical function. Australia's CPS 230 sets the same expectation for material service providers, and in the US, guidance from the Federal Financial Institutions Examination Council (FFIEC) pushes banks toward contingency planning for vendor termination.

Notice what those rules have in common. They single out vendors tied to critical functions, and they ask for recovery that's been tested, not just promised. That's the same two-axis logic you just applied, now written into regulation.

The tiering work you do for your own sake turns out to be the work that satisfies an auditor too.

» For more detail on meeting these obligations, check out our DORA compliance article.

Where to start

Here's the thing most teams get backwards. The problem usually isn't a missing control. It's a missing map. Plenty of organizations have escrow agreements and contract clauses scattered across their portfolio. Often they're placed wherever someone happened to push for them, with no clear view of whether they sit on the vendors that warrant them.

Building that map is a smaller job than it sounds, and is worth it to stop you from putting protection in the wrong places. You don't have to assess all 200 vendors this quarter. Start with the handful you suspect are critical and run them through the two questions.

» If you want a more in-depth look at your vendor exit risk exposure, you can score your critical vendors with Codekeeper's free risk assessment tool.