Source code escrow is a contractual continuity arrangement. A supplier deposits agreed software material with an independent escrow agent, and the customer may receive it if specified release conditions occur. It can reduce dependence on a critical proprietary supplier, but it does not automatically provide ownership, a working system or a replacement support team.
When escrow may be proportionate
Escrow is most relevant when:
- business-critical software is controlled by an external supplier;
- the customer cannot maintain the software without access to protected material;
- supplier failure would cause serious operational harm;
- there is no realistic short-term replacement product;
- the supplier will not assign the source code but accepts continuity protection;
- the software is sufficiently stable and valuable to justify continuing administration and verification.
It is less useful for easily replaceable SaaS tools, genuinely open-source software already available to the customer or systems where the customer already controls the current repository and deployment assets.
Understand the three-party arrangement
A typical arrangement involves the software supplier, the customer or beneficiary, and the escrow agent. The agreement should define:
- what is deposited;
- how often it is updated;
- how deposits are verified;
- which events can trigger release;
- how a disputed release is handled;
- what rights the customer receives after release;
- who pays the fees;
- how the arrangement ends or transfers.
Deposit more than raw source files
| Material | Why it matters |
|---|---|
| Current source code and history | Provides the software material and evidence of the maintained version. |
| Build instructions and dependency definitions | Allows another team to reproduce the application. |
| Database schema and migrations | Supports deployment and data compatibility. |
| Deployment and infrastructure information | Explains how the system reaches a working environment. |
| Configuration templates | Identifies required settings without depositing live secrets unnecessarily. |
| Technical and operational documentation | Reduces dependence on the original team's memory. |
| Third-party component register | Shows licences, subscriptions and dependencies that escrow cannot transfer automatically. |
Choose useful verification
A deposit can be present but unusable. Verification may range from checking that files can be opened to attempting a complete build in a controlled environment. The appropriate level depends on criticality and cost.
For important systems, ask whether verification confirms:
- the material matches the agreed product and version;
- the code is complete and free from obvious corruption;
- dependencies and build instructions are present;
- a clean build can be produced;
- material is refreshed after significant releases.
Define release conditions carefully
Possible triggers include supplier insolvency, permanent cessation of support, material unremedied breach or failure to maintain the product. Wording such as “supplier unavailable” may be too vague; wording limited to one narrow legal event may fail to protect the practical risk.
The agreement should include notice, evidence, response periods and dispute handling. Obtain legal advice on the release mechanism and its interaction with the main software contract.
Plan what happens after release
Release is the start of recovery, not the completion of it. The customer may still need:
- lawful rights to use and modify the released material;
- cloud, domain and database access;
- business data and current backups;
- commercial component licences;
- a replacement development and support team;
- time to understand, build and secure the application.
If these dependencies remain solely with the supplier, escrow provides limited continuity.
Escrow readiness questions
- What specific business interruption is escrow meant to reduce?
- Does the customer already control the current repository?
- Will the deposit be updated and independently verified?
- Are build, deployment and database materials included?
- What rights apply after release?
- Which cloud services, licences and data remain outside escrow?
- Who could operate the software after a release?
Test whether escrow solves the real gap
Run a continuity workshop using a realistic scenario such as supplier insolvency. List every asset needed to keep the service running. Use the result to decide whether escrow solves a genuine gap or whether direct repository control, better handover and tested data export would provide stronger protection.