Software Escrow: What It Is, When It Works, and When It Does Not

What is software escrow?

Software escrow is an agreement between three parties:

• The supplier (also called the depositor or licensor), who writes and owns the software
• The beneficiary, which is you, the customer relying on that software
• The escrow provider, an independent company that holds the materials

The supplier deposits its source code, build scripts, documentation, and supporting materials with the provider. Those materials sit dormant. If a pre-agreed release event occurs, the provider verifies that the event has happened and releases the materials to the beneficiary.

The point is continuity. If the company that built and maintains a system you depend on stops being able to maintain it, you are left with software you cannot fix. Escrow gives you a route to keeping it running.

What escrow is not

Three misconceptions cause most of the disappointment:

It is not a transfer of ownership. Release usually comes with a limited licence to use the code for maintaining your own deployment. You do not acquire the right to resell the product, and you should read the licence terms carefully rather than assuming.

It is not a guarantee that you can take over the system. It gives you the materials. Whether your team, or a partner, can pick up an unfamiliar codebase and run it is a separate question, and the answer depends heavily on quality and documentation.

It is not a substitute for owning the code. If you can negotiate ownership or a perpetual source licence in the first place, you have solved the problem more directly. Escrow exists for the situation where the supplier will not agree to that, which is normal for a licensed product and unusual for bespoke development.

The verification problem

This is the part that decides whether your escrow arrangement is useful, and it is the part buyers most often skip to save money.

Deposit levels, and what each actually proves

Providers offer tiers. The names differ between providers, but the substance is consistent.

A standard deposit tells you almost nothing. It is an upload with a certificate attached. The provider has not opened it, has not built it, and cannot tell you whether it is complete.

Why unverified deposits fail

The failure modes are mundane and consistent:

• Missing dependencies. The code references internal libraries, private package feeds, or licensed third-party components that were never deposited.
• No build instructions. The application builds fine on a machine configured over three years by a developer who has since left, and nowhere else.
• Stale deposits. The agreement says quarterly updates. In practice the last deposit was made at go-live, four years ago, and the running system has moved a long way since.
• Missing secrets and configuration. Connection strings, certificates, and API keys are correctly excluded from source control, and are therefore also absent from the deposit.

Every one of these is discovered at the point of release, which is exactly the moment when you have no leverage, no supplier to ask, and a live system to keep running. As Escode, one of the larger providers, puts it in its guidance on verification, an unverified deposit can contain gaps that only become visible when it is too late to fix them.

The practical rule: if you are not paying for at least build verification on a genuinely critical system, you have bought a document rather than a capability. Either fund the verification or accept, in writing, that the arrangement is largely presentational.

Keeping the deposit current

Verification is a point-in-time exercise. A deposit verified at go-live proves nothing about the version running eighteen months later.

Set a deposit cadence proportionate to release frequency, require evidence that each deposit happened, and put the obligation in the maintenance agreement rather than only in the escrow agreement. Then actually check. An escrow schedule nobody audits is the most common form of this failure.

Source code escrow versus SaaS continuity escrow

These are different products solving different problems, and buying the wrong one is a common and expensive error.

Source code escrow suits on-premises or self-hosted software. You get the code, you build it, you deploy it on infrastructure you already control.

SaaS or continuity escrow suits software you consume as a service. Here the source code on its own is close to useless. To keep a cloud product running you also need:

• Infrastructure definitions, ideally as code
• Environment configuration and secrets management
• Third-party service dependencies, including their contracts and credentials
• Your data, in a documented and restorable format
• A runbook someone unfamiliar with the system can follow

Continuity escrow products address this by holding the deployment materials and, in some arrangements, maintaining a dormant or standby environment that can be activated. That is a substantially more involved service than storing a repository, and it is priced accordingly.

If the system you are protecting is SaaS, ask providers specifically how their product handles data and environment, not just code. If the answer is only about source code, it does not solve your problem.

When escrow is the wrong answer

Escrow is a workaround for not owning the thing you depend on. Sometimes there is a better option.

When you should own the code instead

For bespoke development, ownership is normal and negotiable. If a supplier is building software specifically for you, and you are paying for it, there is usually no good reason for you not to hold the source.

Where ownership is agreed, escrow adds cost and a false sense of process without adding protection. What you need instead is:

• The repository, under your organisation’s control
• A build pipeline that runs somewhere you can reach
• Deployment documentation good enough for a third party to follow
• A named alternative supplier who could pick it up

Our guide to software IP, licensing, and source code handover covers how to structure this, and choosing a long-term technology partner covers assessing supplier durability before you sign.

When the system is not critical enough to justify it

Escrow costs money every year, and verification costs considerably more. Run the question honestly: if this supplier disappeared tomorrow, what would actually happen?

If the answer is that you would migrate to an alternative product over a few months with some disruption, escrow is probably not worth it. Reserve it for systems where the answer is that the business stops.

When the real risk is something else

Escrow protects against supplier failure. It does nothing about the risks that are more likely to hurt you:

• A supplier that stays solvent but becomes unresponsive
• A product that stops being developed while support technically continues
• Price increases at renewal on a system you cannot leave
• Your own data being difficult to extract

Those are contract and exit-planning problems. Escrow is not the tool for them, and buying escrow can create a false impression that they are covered.

What actually happens when a supplier fails

The mechanics matter, because release is rarely as clean as the diagram suggests.

Administration is not the same as disappearance

When a UK company enters administration, an administrator takes control and may continue trading the business while seeking a sale. During that period the supplier may still be servicing your contract, which means a release condition drafted as “insolvency” may be contested by an administrator who considers the obligations still being met.

Draft release conditions with this in mind. Insolvency alone is a weaker trigger than insolvency combined with a failure to continue support.

The intellectual property may be sold

A realistic and under-considered outcome is that the administrator sells the intellectual property to a buyer with no interest in your particular deployment. The new owner may discontinue the product, change the commercial terms, or simply not respond.

This is why the release condition covering transfer of intellectual property to a party that will not honour the same protections is worth insisting on. It is often the clause that actually gets used.

The insolvency law point people get backwards

Section 233B of the Insolvency Act 1986, inserted by section 14 of the Corporate Insolvency and Governance Act 2020, is frequently cited in escrow discussions and frequently misread.

Section 233B is headed “Protection of supplies of goods and services”. It stops a supplier from terminating its contract, or invoking a termination right, purely because the company receiving the supply has entered a relevant insolvency procedure. In other words, it protects you when you become insolvent, by keeping your suppliers supplying.

Escrow addresses the opposite direction: your supplier failing. The two provisions cover different risks and neither removes the need for the other. Anyone telling you that CIGA 2020 makes escrow unnecessary has the direction of travel backwards.

The UK and EU regulatory picture

No regulation mandates software escrow by name. Several require the outcome that escrow is one way of evidencing.

PRA SS2/21. The Prudential Regulation Authority’s supervisory statement on outsourcing and third party risk management sets expectations for PRA-regulated firms, including a chapter on business continuity and exit plans. Its scope is broader than technology, covering outsourcing generally.

DORA. The EU Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025. It is scoped specifically to information and communication technology risk and carries detailed requirements for managing third-party ICT providers. UK firms with EU operations or EU customers should assume it is in scope until they have checked otherwise.

FCA operational resilience. Firms are expected to identify important business services and set impact tolerances, then be able to remain within them through severe but plausible disruption. A critical supplier failing is a severe but plausible scenario.

The practical point for all three: what these regimes want is a credible plan, tested. An escrow agreement is evidence of a plan. An escrow agreement with current, verified deposits and a documented activation runbook is evidence of a credible one. Regulators can tell the difference, and increasingly ask.

Choosing an escrow provider

The UK market is small and reasonably mature. Escode, formerly NCC Group’s escrow business, is the largest. Escrow London, Vaultinum, and others compete alongside it.

Assess on these points rather than on price alone:

• Verification capability. Can they build your technology stack, in-house? A provider whose verification is a checklist rather than an engineering exercise is not offering verification.
• SaaS and cloud continuity products. If your exposure is a cloud product, does the provider actually hold environments and data, or only code?
• Security certifications. ISO 27001 as a minimum. You are handing them your supplier’s crown jewels.
• Financial durability. An escrow provider that fails is its own failure mode. Check how long they have operated and who owns them.
• Release track record. Ask directly how many releases they have executed and how those went. A provider with no release history has never had its process tested.
• Agreement flexibility. Can release conditions be negotiated, or is it a fixed template? Multi-beneficiary agreements, common for licensed products, need particular attention to whether your specific interests are represented.

Beware of escrow bundled into a software contract at the supplier’s discretion, with the supplier choosing the provider and the level. That arrangement optimises for the supplier’s cost, not your protection.

A practical checklist

If you are putting escrow in place, work through this in order.

1. Confirm escrow is the right instrument. If you could own the code, own the code. If the system is not business-critical, consider whether the annual cost is justified.
2. Identify what you would actually need to run the system. Code, infrastructure definitions, configuration, data, third-party dependencies, and documentation. This list determines whether you need source code escrow or continuity escrow.
3. Negotiate release conditions properly. Insolvency, ceasing to trade, discontinuing the product, unremedied material breach of support obligations, and transfer of intellectual property to a party that will not honour the same terms.
4. Buy verification. At minimum a full build verification for anything genuinely critical. Get the verification report and read it.
5. Set and enforce a deposit cadence. Tie it to release frequency, require evidence, and diarise the check.
6. Write the activation runbook. Who does what on the day, which internal team or external partner picks the system up, and where it would be hosted. An untested plan is a document.
7. Review annually. Systems change, criticality changes, and suppliers change hands.

Where to go next

• If you are commissioning bespoke software and would rather own it outright: software IP, licensing, and source code handover
• If you are assessing whether a supplier will still be there in five years: choosing a long-term technology partner
• If you are weighing a licensed product against building your own: own vs rent: perpetual licence vs SaaS
• For the wider contract picture: software development contracts in the UK

Talk Think Do builds custom software where clients hold the source code, the repository, and the deployment pipeline throughout, which is a stronger position than any escrow arrangement. Where a licensed product genuinely requires escrow, we work with Escrow London and can advise on verification scope. To talk through a specific supplier risk, book a consultation.