<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=10643465&amp;fmt=gif">

Don’t make it easy for failure: Plan for the vendors you’ll lose

Reliable vendors only lower the odds. Learn why vendor failure is a numbers game, what it costs, and how escrow keeps continuity in your hands.
Ben Espach
Last updated:

Most businesses choose their critical vendors with care. They pick the established name, check the funding, and sign with the provider half their industry already runs on, trusting that a company of a particular size or pedigree will still be around in 10 years.

But giants fall too.

Size and a long track record make vendor failure less likely, and that’s all they can do. Even the safest vendor you can find is still a bet on another company’s future. While it’s a good hedged bet, it’s gambling nonetheless.

This post is part of a series on this year’s Cybersecurity Awareness Month themes for 2026, and it zooms in on why vendor failure ultimately comes down to odds, what each side of a software relationship loses, and how to keep continuity in your hands despite unexpected service loss.

“They’ll always be around” is a dangerous assumption

Most people picture vendor failure as a bankruptcy, and that’s looking at things a bit too narrowly. You can lose access to a vendor’s software while the vendor is still in business, through quite a few events you have no say in. In the end, the result is always the same.

A vendor shutdown takes the product with it

Anyone in third-party risk management could tell you that a provider’s bankruptcy, insolvency, or closure is a nightmare to deal with. But an acquisition can end a product too. The new owner just decides one day which products stay and which get deprecated. If the one your operations depended on got caught in the crossfire, you’re thrown into emergency recovery mode.

Geopolitical disruptions cut off access to healthy vendors

Sanctions and export bans aren’t the first thing you think about when mapping out third-party risk, but they can end your access to software overnight. Even tariffs can make a product too expensive for a vendor to maintain or provide to certain customers.

The worst thing is, the provider didn’t even do anything wrong. When a government decides to add a country or company to a sanctions list, vendors don’t have a say over who they’re allowed to serve. And sanctions usually carry a “with immediate effect” timeline, so you won’t be getting a heads-up before losing access either.

Upstream outages cascade down through your vendor

Most vendor reviews stop at the vendor itself. You check their security certifications, read their uptime commitments, and maybe ask for a recent audit report. But your vendor’s software runs on hosting and services from a list of other providers, and none of them were in that review. When one of them goes down, your vendor goes down with it, and so do you.

When the providers behind your vendor are the biggest names on the internet, it’s easy to treat them as the safest part of the chain. But Uptime Institute has tracked publicly reported outages for nine years, and about two-thirds of them started at third-party providers, with cloud and internet giants like Cloudflare and CrowdStrike among them.

When one of those critical providers goes down, everyone downstream ends up waiting on the same fix. Users wait on their vendor, and the vendor sits refreshing a status page for a provider it can’t do anything about. Even vendors have vendors, which means they carry both risk from above and pressure from below.

» Find out more about how one company’s breach becomes everyone’s outage.

Vendor failure follows the odds

Risk teams usually assess vendors one at a time, and seen that way, failure often looks unlikely. But your business runs on hundreds of them at once. At that scale, vendor failure is a matter of statistics, and probability doesn’t care how carefully you chose.

After more than a decade of managing software escrow, Codekeeper puts the failure rate at 2 in 10 vendors within 3 years. That sounds manageable until you take into account that Zylo’s 2026 SaaS Management Index found the average company runs 305 SaaS applications alone. At that failure rate, a typical business should expect to lose access to 40+ systems in that time.

That’s what turns vendor selection into a gamble. A thorough review improves the odds on each vendor, the way a careful player picks better bets. But you’re still holding hundreds of bets at once. Eventually, some of them are going to lose.

Core systems get signed for the long haul, with the expectation that they’ll run for years. The US Bureau of Labor Statistics tracked businesses opened in 2013, and in the information sector, which includes software companies, only 29.1% were still operating 10 years later. For a newer vendor, those are long odds over the life of a system.

So a continuity plan that only holds while every one of your vendors stays in business is built on numbers you already know are against you.

» Look at what happens when a vendor nobody thought could fail shuts down unexpectedly.

What each side loses when one disappears

Statistics tell you a vendor failure is coming, but not what the day looks like or who pays for it. Synapse’s collapse shows both, and that most of the people it hurt were a step or two removed from it.

Synapse sold the software behind a long list of consumer fintech apps. Partner banks held the deposits, but Synapse kept the ledger of who owned what. When Synapse filed for bankruptcy in April 2024, access to that ledger went with it.

Users lose more than a few weeks of access

In early May, a partner bank froze accounts, saying Synapse had denied it access to the system holding records on end users, deposits, and transactions. The losses landed fast.

That last loss is what US bank regulators moved to fix after Synapse. In September 2024, the Federal Deposit Insurance Corporation proposed a rule requiring banks to keep direct, continuous, and unrestricted access to records a third party holds for them, even through that third party’s bankruptcy. For banks, continuity of access would become a compliance requirement, written into their contracts.

Vendors caught in the middle have nothing to fall back on

The fintech apps were vendors too, and Synapse was their only route to the banks. When it went down, they had nothing ready to switch to, and each paid for it in a different way.

Secure essential systems that outlast any vendor

True software security has to look at resilience from all angles. It doesn’t help if you’ve hardened yourself against attacks but a vendor failure still takes you down. Especially since EU financial supervisors saw failures outnumber attacks five to one in 2025, with system failures behind 51% of 3 383 major incidents and cybersecurity behind 10%.

But unlike attacks, protecting against vendor failure isn’t something you can take care of in-house. You can patch your systems, monitor them, and train your team to spot an intruder. You can’t keep another company solvent, stop its owners from selling, or pull its records out of a bankruptcy.

You can, however, make sure the software you depend on doesn’t sit only with the vendor. With escrow, a provider can deposit the materials behind its software with an independent party like Codekeeper, and an escrow agreement sets out when they’re released to you. Codekeeper’s in-house counsel drafts that agreement in 1–3 days.

What goes into the deposit depends on the software it protects, and daily syncs through 50+ integrations keep it current, with no limit on deposits or storage.

  • Software Escrow protects software installed on your own systems, with the vendor depositing its source code, data, and documentation so you can recover without waiting on anyone.

  • SaaS Escrow covers cloud software, adding the deployment infrastructure, credentials, and third-party dependencies the application runs on, which reaches into the vendor’s own chain of providers.

  • AI Escrow backs up the AI stack a business builds on top of an AI provider, from custom prompts and fine-tuning to agent workflows, so it can move to another provider if that one fails or changes course.

Across all three, release conditions typically cover bankruptcy, insolvency, discontinued support, and material breach, and both sides can agree to add others, like an acquisition. For a vendor, the same agreement answers the continuity questions that procurement teams raise, without dragging out the deal. It’s how we protect both sides of a software relationship.

» See where vendor failure sits among the four software risks this series covers.

Prove your continuity before someone asks

With an agreement signed and a deposit syncing with development of your essential software every day, it’s easy to treat the job as done. But a deposit only earns its keep when someone builds working software from it, and release day is the wrong moment to try that for the first time.

Verification runs that test ahead of time. Codekeeper rebuilds the software from the deposit, tests it, and records the results in certificates and reports you can use as software resilience evidence. They’re the documents you reach for when an auditor asks how your continuity would hold up.

Regulators on both sides of the Atlantic expect this kind of preparation. TheEU’s Digital Operational Resilience Act (DORA) requires financial entities to plan for the failure of the providers behind their critical functions, and our guide to DORA Article 28 explains what that involves. Vendors selling into those industries can hand the same certificate to buyers who need to show it.

Plan for vendor failure the way you plan for attacks

Every outage also comes with a bill. In Uptime Institute’s 2026 outage analysis, 57% of organizations put the cost of their most recent major outage above $100,000. When the outage starts with a vendor, your business carries that cost for as long as the vendor takes to recover, and none of it shows up on the vendor’s invoice.

Between the odds, that bill, and what regulators now expect, vendor failure is part of resilience you have to start building into your continuity plan, alongside attacks. If the plan ends at your own systems, it covers the threat you already watch and skips the one more likely to stop you.

Keep an eye out for the next post in this series, on non-compliance and why a continuity clause on its own won’t satisfy the regulators and enterprise buyers who ask you to prove it.

» Keep your continuity independent of any vendor’s survival with Codekeeper’s Software Escrow.

Share this article
Share on facebook Share on linkedin Share on twitter Share on email
blog_book_a_demo_cta_3x
Have questions about protecting your software?
Our escrow experts are standing by to help.
Book a free demo