Build or Bluff: Turning Software Escrow Into a Tested Recovery Capability

Software escrow is often bought the way insurance is bought: as a document that makes a risk feel managed. For many UK regulated estates, the arrangement is little more than a clause in a supplier contract and a certificate in a drawer. The critical third-party application is named, a deposit is said to exist, and the recovery plan assumes that one day the source will arrive and the organisation will build its way out of trouble. That assumption deserves testing.

The clause is not the capability

An escrow agreement creates a legal right to access material under defined conditions. It does not prove that the material is complete, that it matches the version in production, that the build instructions are accurate, or that the organisation could assemble a working system from it. Those are engineering and assurance questions. Treating a contract clause as a recovery control is the escrow illusion: the comfort is real, but the capability is unproven.

For UK technology leaders, the distinction matters because operational resilience expectations increasingly focus on evidence of recoverability, not merely the existence of plans. Auditors and boards are entitled to ask a simple question: if the supplier failed tomorrow, could we rebuild the service, and can we show our working? A dated, reproducible test build is a far stronger answer than a legal schedule.

Define what buildable actually means

Buildable does not mean that a zip file opens. It means that a competent team, working in a clean environment, can take the deposited material and produce an artefact that behaves like the production system within an agreed tolerance. That definition should be written down before any test begins, because it determines what must be deposited.

At minimum, the deposit should include application source, build scripts, configuration templates, database schema and migration scripts, generated code where regeneration is not practical, static assets, licence files, and any proprietary libraries the supplier is permitted to deposit. It should also include the toolchain: compiler versions, package manager lock files, container base images, SDKs, and the exact environment variables and secrets-handling instructions needed to reproduce a build. Where the supplier uses internal package repositories, the deposit must include the packages or a lawful mechanism to obtain them.

A useful test is to ask the supplier to nominate a build steward who has never worked on the product and ask them to build it from the deposit alone. If that person needs tribal knowledge, the deposit is incomplete.

Run a clean-room test cycle

Verification should be scheduled, not improvised. A annual or twice-yearly cycle is usually proportionate for critical systems, with a smaller quarterly check for deposits that change frequently. The test should run in an isolated environment that mirrors the production build platform closely enough to be credible, but without access to the supplier's internal systems. Document the operating system, runtime, package sources, network restrictions and identity assumptions used.

The first test will often fail. That is valuable. Record precisely where it fails: a missing dependency, an expired certificate, an undocumented environment variable, a database migration that assumes a prior state. Share the failure log with the supplier and require a corrected deposit. The second test proves the correction. The third test proves that the correction has not drifted. Over time, the organisation moves from hoping the deposit is adequate to knowing when it was last proven.

Take the dependencies with the source

Most failed escrow tests are not caused by missing application code. They are caused by missing context. Modern systems depend on package registries, container images, external services, cryptographic material and platform configuration. Some of those dependencies cannot be escrowed in the traditional sense, but they can be described, pinned or substituted.

A practical deposit should therefore include a dependency manifest with versions and checksums, a list of external services required at build time and run time, and a statement of which dependencies are commercially licensed and therefore not included. Where a dependency cannot be deposited, the agreement should name an alternative: a supported mirror, a source-code licence, or a documented substitution path. The same logic applies to toolchains. A source deposit that requires an obsolete compiler no longer available from the vendor is not a recovery asset; it is a museum piece.

Build an evidence file that survives scrutiny

Evidence should be proportionate but sufficient. For each test, retain the date, the test lead, the environment specification, the deposit identifier and checksum, the build commands executed, the outcome, the defect log, and the supplier's remediation response. If the build succeeded, retain the artefact hash and a short record of the functional checks performed against it. If it failed, retain the failure evidence and the date by which a corrected deposit was accepted.

This file becomes the basis for board reporting. A single page can state which critical systems have escrow arrangements, when each deposit was last verified, whether the test build succeeded, and what remains outstanding. That is more useful than a list of contract references. It also gives auditors a clear trail from the resilience plan to a tested recovery assumption.

Negotiate for verification, not just access

Vendor negotiations should move beyond the standard clause. Ask for a named deposit schedule, a commitment to update the deposit within an agreed period of each major release, and the right to test-build at a defined frequency. Seek clarity on whether test builds may be performed by a third-party verification service under confidentiality, and on who bears the cost of remediation when a deposit is found deficient. Confirm that the deposit includes build instructions and toolchain details, not just source files. Where the supplier resists, ask what specifically cannot be deposited and why. The answer is often more informative than the clause.

From comfort to capability

Escrow is not useless. It is simply unfinished until it has been tested. The organisations that get value from it are those that treat the deposit as a controlled artefact with a date, a checksum and a build record. For UK leaders responsible for operational resilience, the objective is not to collect more legal paperwork. It is to replace an untested assumption with a reproducible capability — and to be able to prove, when asked, that the source code you paid for actually builds.