Source code escrow is bought as insurance and managed as paperwork. A tripartite agreement is signed, the vendor makes an initial deposit, an annual fee is paid, and the arrangement appears in a vendor management register as a mitigating control against supplier failure. Several years later, when the control is needed, the deposit turns out to be three years and four major versions old, unverified, and missing the build environment required to compile it.
That outcome is not unusual and it is entirely predictable from the way the arrangement is administered. The agreement creates obligations on the vendor to deposit and update, and obligations on the customer to pay fees and to commission verification if it wants any assurance. The vendor obligations are rarely monitored by the customer. The customer obligations are often reduced to paying the annual invoice.
This datasheet sets out which escrow terms matter, why deposit currency is the dominant variable, how verification levels differ and what each proves, how release triggers should be drafted to be provable, and how the equivalent arrangement works for cloud services. It is written for vendor management, application owners and technology legal teams.
What the arrangement has to get right
An escrow arrangement is only as good as five terms, and all five need to be recorded and monitored rather than simply agreed. The agreement existing is not itself a control.
- Deposit scope, source code plus build scripts, dependency inventory with versions, toolchain and environment specifications, schemas, interface documentation and technical documentation.
- Update obligation, the trigger for refreshing the deposit, ideally tied to release cadence with a maximum interval fallback, and the evidence the agent provides confirming each deposit.
- Verification level, what the escrow agent is engaged to confirm, ranging from media readability through completeness analysis to full build and functional testing.
- Release conditions, the defined triggers, the evidence the customer must present, the vendor objection window and the dispute mechanism if the release is contested.
- Post-release rights, the licence scope on release, covering permitted use, modification, third-party contractor access and duration, which is frequently narrower than customers assume.
The fifth term is the one most often discovered late. A release that grants a licence to use the code for internal maintenance of existing installations only, with no right to engage a third-party development firm, may not permit the continuity activity the customer actually needs. Post-release licence scope should be read against the realistic recovery plan rather than accepted as standard language.
Every other escrow term is secondary to whether the deposited material matches what is deployed. A perfectly drafted release trigger delivering a four-version-old codebase produces a migration project rather than continuity. Tie deposit updates to release events, require the agent to confirm each deposit, and track the interval between the last deposit and the currently deployed version as the primary health metric for the arrangement.
Why escrow arrangements fail
The failures below are administrative and therefore preventable. In most cases the agreement was adequate and nobody was monitoring the obligations it created.
- Deposits fall out of date. Update obligations tied to the calendar rather than to releases, and never monitored, leave the deposit progressively further from the deployed version.
- The deposit was never verified. Without at least completeness verification, the customer holds an unproven asset, and full build verification is the only level that establishes the code compiles.
- Release triggers are unprovable. Triggers phrased around material breach or failure to maintain, without measurable definition, become a dispute at the moment the customer can least afford one.
- Build environment is missing. Source without toolchain versions, dependency inventory and environment specification is frequently not buildable, and the gap is only discovered after release.
- Nobody owns the arrangement. Fees are paid by procurement while deposit currency belongs to nobody, which is a straightforward obligation ownership gap.
Getting the arrangement into working order
Step 1, Inventory existing arrangements
List every escrow arrangement with its vendor, the software covered, the agent, the fee, the last confirmed deposit date and whether any verification has ever been performed. This list is usually shorter than the register suggests and less current than expected, and arrangements covering decommissioned software are a recoverable cost.
Step 2, Assess against deployed versions
For each arrangement, compare the last deposit to the currently deployed version. The gap, expressed in releases rather than months, is the honest measure of protection. Arrangements with multi-version gaps need a deposit refresh before anything else is worth doing.
Step 3, Fix the update obligation
Where update terms are calendar based, renegotiate to release-linked deposits with a maximum interval fallback, and require the agent to issue deposit confirmation the customer receives directly. Receiving confirmation from the agent rather than relying on vendor assertion is what makes the obligation monitorable.
Step 4, Commission proportionate verification
Match verification level to the criticality of the software. Media verification is sufficient for low-criticality applications. Applications whose loss would materially disrupt operations warrant full build verification, and the cost of that is small relative to the cost of discovering after release that the deposit does not compile.
Step 5, Make triggers provable and assign owners
Redraft release conditions so each one can be evidenced from documents the customer can obtain, and define measurable thresholds for support failure. Then assign deposit monitoring to the application owner and release trigger interpretation to legal, recorded against the vendor contract.
Audit your escrow arrangements
A working session on deposit currency, verification and release terms across your portfolio.
Continuity arrangements for cloud services
The traditional escrow model assumes the customer could run the software itself given the code, which holds for on-premises products and breaks for multi-tenant services. For a cloud application, source code is necessary and far from sufficient, because the running service depends on infrastructure definitions, deployment automation, configuration, secrets management, third-party service dependencies and operational runbooks that no code repository contains. What has emerged in response is a continuity arrangement covering deposit of infrastructure as code, deployment scripts, configuration templates, a documented dependency map including third-party services, data export capability with a defined format, and operational documentation sufficient for a competent provider to stand the service up. The useful test when negotiating one is to ask what a third party would need to operate this service, and then compare that list to the deposit schedule. Arrangements that pass the test tend to include a data egress commitment as well, because continuity without customer data is not continuity. Tracking these deposits is the same discipline as the traditional form, and it belongs alongside the rest of the software estate as described in the CLM software evaluation checklist.
Verification levels and what they prove
The table below sets out the common verification tiers, what each establishes and where each is appropriate. The relevant decision is proportionality, because full build verification on every arrangement is rarely justified and on critical applications is rarely optional.
| Verification level | What it establishes | Appropriate for | Residual risk |
|---|---|---|---|
| Deposit receipt only | Material was delivered and logged | Low-criticality applications | Contents unknown |
| Media and file integrity | Files are readable and not corrupt | Low-criticality applications | Completeness unproven |
| Completeness analysis | Documented inventory is present | Moderate criticality | Buildability unproven |
| Full build verification | Source compiles into working binaries | Business-critical applications | Functional behaviour untested |
| Build plus functional test | Binaries behave as expected | Highest criticality applications | Ongoing currency still required |
Escrow is one of the few controls that can appear entirely healthy in a register while providing no protection at all. The agreement is signed, the fee is paid, the arrangement is listed, and none of that establishes that the deposit matches the deployed version, compiles, or would be licensed for the recovery activity actually planned. Making it real requires four things tracked continuously. Deposit currency measured in releases, verification proportionate to criticality, release triggers provable from obtainable evidence, and a named owner who is not the person paying the invoice.
For related guidance, see Open source license clauses in customer contracts, Tenant improvement allowance tracking for lease teams and ESG and supply chain due diligence clause tracking.
