Software Escrow: Protect Your Business If a Supplier Fails

If your business relies on a piece of software to sell, deliver, or manage your services, it’s easy to assume it’ll always be there when you need it.

But what happens if the supplier goes bust, stops maintaining the product, or simply refuses to support you unless you pay more?

This is where software escrow comes in. Done properly, software escrow can help you keep operating if your software supplier fails - and it’s particularly useful for small businesses that can’t afford prolonged downtime.

Below, we’ll break down what software escrow is, when it makes sense, what should go into an escrow agreement, and how it ties into other key legal protections you’ll want in place from day one.

What Is Software Escrow (And Why Should Small Businesses Care)?

Software escrow is a legal and practical arrangement where a software supplier deposits key materials (usually the software source code and supporting documentation) with an independent third party (the escrow agent).

The idea is simple:

• You keep using the software as normal while the supplier remains operational and continues to support it.
• If a “release event” happens (for example, the supplier becomes insolvent), the escrow agent releases the escrow materials to you so you can maintain or run the software.

This matters because many businesses rely on software in a way that’s not obvious until it fails. Think:

• your booking system
• your customer database/CRM
• your EPOS or inventory system
• your website or eCommerce checkout
• your payroll or time-tracking platform
• a bespoke app or internal tool

If that supplier disappears, you could face:

• operational downtime (missed sales, missed bookings, missed deadlines)
• security and compliance risks (unpatched vulnerabilities, inability to manage access)
• data access issues (especially if the software is tied to your customer data)
• unexpected rebuild costs (replacing a bespoke system is rarely quick or cheap)

Software escrow isn’t about mistrusting suppliers - it’s about making sure your business is protected if something outside your control happens.

When Do You Actually Need Software Escrow?

Not every SaaS subscription needs escrow. If you’re using a mainstream tool with easy switching options, the cost and admin may not be worth it.

Software escrow is most relevant when your business has any of the following risk factors:

You’re Using Bespoke Or Highly Custom Software

If the software is tailored to your business processes (or integrated deeply into your systems), replacing it quickly may be unrealistic. Escrow can give you a practical “back-up plan” if the supplier can’t continue supporting it.

The Supplier Is A Small Or Early-Stage Company

Startups and smaller developers can be brilliant - but they can also be more vulnerable to cashflow issues, changes in direction, or acquisition.

Escrow can reduce your dependency risk without needing to walk away from a good supplier.

The Software Is Business-Critical

Ask yourself: if the software stopped working tomorrow, could you still trade?

If the honest answer is “no”, escrow is worth considering.

You’re In A Regulated Or High-Risk Sector

Businesses handling sensitive data or where downtime has major consequences (for example, healthcare services, financial services suppliers, or critical infrastructure) may treat escrow as an important contractual safeguard.

You Need To Show Risk Management To Stakeholders

If you’re seeking investment, tendering for contracts, or partnering with larger organisations, you may be asked about continuity planning. A properly structured escrow arrangement can be part of that story, alongside a solid contract framework and good record-keeping.

How Does A Software Escrow Arrangement Work?

A typical software escrow setup involves three parties:

• Supplier (the software vendor/developer)
• Customer (your business)
• Escrow agent (an independent third party holding the escrow materials)

There are a few common structures, but many follow a similar process:

1) You Agree The Escrow Terms Upfront

This includes what gets deposited, how often it gets updated, and what events trigger release.

In practice, this is usually done as either:

• a tri-party agreement (supplier + customer + escrow agent in one contract), or
• two linked agreements (supplier ↔ escrow agent and customer ↔ escrow agent), with matching terms.

2) The Supplier Deposits The Materials

This is commonly called the “deposit”.

Depending on the agreement, deposits might happen:

• once at the start of the relationship
• at key milestones (e.g. after major releases)
• on a regular schedule (monthly/quarterly)

3) The Escrow Agent Verifies (Optional But Often Recommended)

One big risk with escrow is that the supplier deposits something incomplete or unusable - for example, only partial source code, or code without the build instructions needed to compile it.

Some escrow arrangements include a verification step (sometimes “technical verification”), where the escrow agent checks the deposit is complete and can be used in practice.

4) Release Happens Only If A Defined “Release Event” Occurs

If the agreed release event happens, the escrow agent releases the materials to you so you can maintain and keep using the software (usually via an internal team or a replacement developer).

It’s important that release isn’t subjective. A well-drafted agreement spells out objective triggers and a clear release process.

What Should Be Included In A Software Escrow Agreement?

Escrow only works if the right materials are deposited, and if the release conditions and permitted use are clear. Otherwise, you may end up with access to files you can’t legally or practically use.

Here are the key clauses and practical points we usually expect to see addressed in a software escrow agreement.

1) The Escrow Materials (What Is Actually Deposited)

This is the heart of software escrow. For example, deposits might include:

• source code (including all relevant modules/components)
• build scripts and build tools
• deployment instructions and environment configuration
• technical documentation and architecture diagrams
• database schema and data dictionaries
• API documentation and integration guides
• third-party dependencies list (and how licensing is handled)
• keys or credentials (carefully managed) needed to deploy, where appropriate

For small businesses, a practical way to think about it is: if someone new had to take over maintaining the software, what would they need?

2) Deposit Frequency And Updates

Software changes constantly. If the deposit isn’t updated, escrow becomes a false sense of security.

Common approaches include:

• deposit on each new production release
• scheduled deposits (e.g. quarterly)
• deposit whenever a “material change” occurs (e.g. major security fix or new core feature)

3) Verification Requirements

Verification can be a game-changer, especially if you don’t have a technical team that can assess whether the deposit is usable.

Verification might include:

• checking the files match the stated inventory
• testing that the code compiles
• confirming the deployment instructions work

This can add cost, but it can also prevent a nasty surprise when you need the escrow materials most.

4) Clear Release Events (When You Get Access)

Release events need to be specific and objective. Examples often include:

• insolvency, administration, liquidation, or dissolution of the supplier (as defined in the agreement)
• supplier ceasing to trade
• supplier failing to provide support/maintenance for a defined period
• supplier materially breaching the software agreement and not remedying it within a set timeframe
• supplier discontinuing the product

The “supplier breach” option can be useful, but it has to be drafted carefully - otherwise the supplier may resist, or you may end up in a dispute about whether the trigger has occurred.

5) Licence Rights After Release (What You’re Allowed To Do)

Even if you receive the source code, you still need legal permission to use it.

So the escrow agreement should spell out what you can do after a release, such as:

• use the code internally to maintain business operations
• appoint a third-party developer to maintain it on your behalf
• modify the code for bug fixes and security updates

It should also clarify what you can’t do (for example, resell the code, publish it, or use it to create a competing product), unless that’s part of the deal.

This is where escrow overlaps with the broader contract documents your software relationship should have in place - often a properly drafted Software Development Agreement (for bespoke builds) or an ongoing Software Licence Agreement.

6) Confidentiality And Security Controls

Source code is valuable intellectual property. The agreement should address:

• how the escrow agent stores and secures the materials
• who can access the materials upon release
• confidentiality obligations (before and after release)

If the escrow materials include personal data (for example, database copies for testing or restoration), you’ll also need to think about privacy compliance under the UK GDPR and the Data Protection Act 2018. In many software supply relationships, it’s also important to have a Data Processing Schedule in place to set out how personal data is handled.

7) Fees And Who Pays Them

Escrow involves ongoing costs (the escrow agent’s fees, and sometimes verification fees). The agreement should clearly allocate responsibility for:

• setup fees
• annual storage/administration fees
• verification costs (if any)
• release fees (if release occurs)

There’s no one-size-fits-all. Some suppliers pay as part of the service. In other cases, the customer pays because they’re requesting the additional protection.

Common Mistakes With Software Escrow (And How To Avoid Them)

Software escrow is a great tool - but only if it’s done properly. These are some common pitfalls we see.

Mistake 1: Escrow Is Mentioned In A Contract But Never Implemented

Sometimes a contract says “the supplier will enter into escrow arrangements”, but the parties never sign the escrow agreement or make the deposit.

Fix: tie escrow to a practical timeline (for example, “within 30 days of contract start”), and make it a condition of rollout if the system is critical.

Mistake 2: The Deposit Is Out Of Date

If the supplier deposited the source code a year ago but the product has changed significantly since, the escrow materials may be close to useless.

Fix: set clear deposit triggers and require regular updates.

Mistake 3: No Verification (So You Don’t Know If It Works)

A deposit might technically exist, but still be incomplete - missing dependencies, documentation, or build instructions.

Fix: consider verification, especially for bespoke software that is deeply embedded in your operations.

Mistake 4: The Release Rights Are Too Narrow

If your agreement only allows you to “view” the code, but not to modify or maintain it, release might not help you keep trading.

Fix: ensure the post-release licence actually gives you the operational rights you need.

Mistake 5: Escrow Is Used Instead Of Good Contract Protections

Escrow should be one layer of protection - not the only one.

Even if you have escrow, you still want a clear contract that covers things like:

• support and maintenance obligations
• service levels and response times
• security responsibilities
• ownership of intellectual property (especially if custom development is involved)
• termination and exit support (data export, handover, transition assistance)

Where you’re engaging a supplier to build something bespoke, a tailored IT Service Agreement or development agreement often does the heavy lifting, with escrow acting as a continuity safety net.

Key Takeaways

• Software escrow is an arrangement where software source code and critical materials are held by an independent third party and released to you if a defined event occurs (like supplier insolvency).
• Escrow is most useful when the software is business-critical, bespoke, or difficult to replace, or when the supplier is smaller and higher risk.
• A solid escrow agreement should clearly cover what gets deposited, how often it’s updated, whether verification is required, and exactly when release happens.
• Even after release, you need clear licence rights to use, maintain, and (if needed) modify the software to keep trading.
• Escrow should sit alongside a well-drafted software contract (for example a Software Licence Agreement or Software Development Agreement) and proper privacy documentation where personal data is involved.

This article is general information only and does not constitute legal advice. Software escrow outcomes (including whether materials are released, and what you can do with them) depend on the wording of your contracts and the facts of the situation.

If you’d like help putting the right legal protections in place for a key software supplier - including software escrow terms, licensing, and data protection clauses - you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.