Software Escrow Verification Explained

What is software escrow?

Software escrow is an arrangement where a supplier deposits the source code and build materials for their software with an independent third party. If the supplier fails, is acquired or stops supporting the product, the customer can obtain that material under agreed release conditions and keep the software running.

Three parties are involved. The supplier or licensor writes and owns the software. The beneficiary or licensee is the customer whose business depends on it. The escrow agent is the neutral party that holds the deposit and decides, against the terms of the agreement, whether a release is justified. That neutrality is the whole point. A promise from a supplier that they will hand over the code if they go under is worth very little once there is an administrator in the building.

In the UK, escrow is most common in financial services, healthcare, local government, logistics and manufacturing, which is to say anywhere a small software house sells a critical system to a much larger organisation. The larger organisation cannot accept the risk that the smaller one disappears. Escrow is how that risk gets parked.

What does software escrow verification actually involve?

Verification tests whether the deposited material can genuinely be turned back into working software. In practice that means auditing the supplier's build process, recreating the build environment in an independent test laboratory, compiling the source code from scratch and documenting every step so a third party could repeat it later.

The distinction matters more than most buyers realise. Escrow without verification is storage. Somebody has put files in a vault and everybody has assumed they are the right files. Verification is the part that turns that assumption into evidence, and it is regularly the point at which uncomfortable things surface.

The stages of a verification exercise

1. Audit the deposit. Check the contents against what the agreement says should be there. Is the source complete? Does the version match what is actually running in production?
2. Interview the build team. Document what the build genuinely depends on. Compiler versions, licensed components, environment variables, and the manual steps that never made it into the written process.
3. Recreate the build environment. Construct a clean, isolated environment from scratch using only the deposited material and the documented dependencies, with no access to the supplier's own machines.
4. Compile from source. Build the application in that clean environment and confirm the output matches the expected deliverables, recording every error and workaround needed along the way.
5. Test the result. Install and run the compiled software to confirm it starts, connects to its dependencies, and behaves as the release it claims to be.
6. Document and report. Produce a report a third party could follow during a real release event, stating what was proven, what could not be proven, and the gaps to close before the next deposit.

Step three is where the time goes. A modern build depends on a specific compiler version, a set of third party libraries, a licence server, a signing certificate, an operating system patch level, and often one setting on one machine that one developer configured in 2019 and has never thought about since. None of that is malice. It is simply how software gets built when nobody has ever had to rebuild it from cold.

What are the different levels of software escrow verification?

Escrow agents typically offer verification in tiers, and the names vary between providers. The substance is broadly consistent, and the choice comes down to how much assurance the beneficiary needs against how much they are prepared to pay.

A file integrity check is better than nothing and cheap enough that there is no excuse for skipping it. But if the software genuinely underpins the business, a build test is the first level that answers the actual question, which is whether anybody other than the supplier can produce a working copy.

Does my business need software escrow?

It is worth considering when a supplier's software is critical to your operations, when switching away from it would be slow or expensive, and when the supplier is small enough that its failure is a realistic risk. If losing the software would stop you trading, escrow is usually cheaper than the alternative.

Some practical tests:

• If this supplier ceased trading tomorrow, how long could you keep operating on the current installation before something broke?
• Is there a comparable product you could migrate to, and how many months would that migration take?
• Does the software hold data you are legally obliged to retain or produce?
• Is the supplier owner managed, venture funded, or otherwise dependent on a small number of people?
• Would a regulator or auditor expect to see a continuity arrangement for this system?

If the honest answers are "not long", "over a year" and "yes", the cost of escrow with verification stops looking like an expense and starts looking like insurance priced sensibly.

What happens in a release event?

A release event is a trigger defined in the escrow agreement, usually supplier insolvency, breach of a support obligation, or ceasing to trade. When one occurs and is confirmed, the escrow agent releases the deposited material to the beneficiary so they can continue running and maintaining the software.

The moment of release is the worst possible time to discover the deposit is incomplete. The supplier is gone, so nobody can answer questions about the build. The developers have moved on. Whatever was not written down is now genuinely lost. A verified deposit means the beneficiary receives material that somebody independent has already rebuilt at least once, along with a report explaining how they did it.

That report is often more valuable than the code. Source code without a working build process is a research project. Source code with a tested, documented build is a system you can hand to a new development team on a Monday morning.

Why do escrow deposits fail verification?

Almost always because of ordinary gaps rather than bad faith. The patterns repeat across industries and technology stacks:

• Missing third party components. A licensed library the supplier is not permitted to redistribute, or simply never thought to include.
• Undocumented tooling versions. The build works on one compiler patch level and silently fails on the next.
• Machine specific build scripts. Hard coded paths, local certificates, and assumptions about a developer's own workstation.
• Version drift. The deposited source is six months behind the release running in production, so the rebuilt software is not the software the beneficiary uses.
• Missing deployment detail. The application compiles, but nothing explains how it is configured, hosted or connected to its database.
• Stale deposits. The deposit was made once, at signature, and never updated as the product moved on.

None of these are difficult to fix once identified. That is the argument for verifying early rather than at the point of crisis: a failed verification in a calm year is a to do list, while the same failure during a release event is a business continuity incident.

Does SaaS software need escrow?

It needs a different kind. Source code alone will not restart a hosted service, so SaaS escrow arrangements also cover infrastructure configuration, deployment scripts, database schemas and data extracts. Verification for SaaS is about proving the service can be stood up somewhere else, not just compiled.

In practice this means testing the infrastructure definition as seriously as the application code, and confirming that the beneficiary could obtain their own data in a usable format on short notice. A SaaS escrow arrangement that covers only source code is answering a question nobody asked.

How I ended up specialising in this

I joined NCC Group in December 2014 as an integrity test analyst, validating and verifying source code deposits, processing customer deposits and producing client integrity test reports. From 2015 to 2019 I worked as a verification consultant, auditing and documenting the processes required to build and deploy client software, including visits to client sites in the UK and internationally.

Between 2019 and 2023 I moved into a more hands-on technical role as a Software Build Consultant. That was a deliberate narrowing. I wanted to focus on one specific service line rather than a broad range, and the build side was the part I found most interesting.

The service was selling perfectly well. Delivery was the part that was not keeping up, which is the harder problem of the two, because every slipped delivery lands on a client who has already been promised something. So we started small. A team of two, effectively as a test run, to see whether it could be done properly.

Over the next few years we grew that team to five, and it became the strongest performing service in its range. That did not come from selling it harder. Two things made the difference, and neither was working longer hours.

Getting involved before the sale, not after it. Once the people who would actually do the work were part of the pre-sale conversation, the scope was realistic from the start. We stopped inheriting commitments that could not be met, and we could tell a client what was genuinely achievable before anyone signed rather than three weeks into the engagement.

Relationships, because a focused team meant the same faces every time. That built real working relationships with the ISVs whose software we were rebuilding, with the clients relying on the arrangement, and internally with the scheduling and sales teams. That last part is underrated. Verification depends on people answering awkward questions about their own build process, and on getting the right engineer booked for the right week. Both go faster when the people involved already know and trust you.

That is the part most people underestimate about verification. The technical skill matters, but what turns it into a service that can be delivered reliably is a repeatable process and honest scoping, so that every engagement is not a bespoke research project with an unknown end date.

By 2023 I felt I had achieved what I set out to do. Staying would have meant maintaining something that already worked rather than building something new, and that would have limited my growth. So I decided it was time to move on.

What an independent consultant adds

Escrow agents do a necessary job and do it at scale. What they cannot easily do is sit on your side of the table. An independent consultant can review an escrow agreement before you sign it, check that the verification level you are paying for actually matches the risk you are carrying, and translate a verification report into a plain answer to the only question that matters: if this supplier vanished, could we carry on?

On the supplier side, the work is preparing the deposit so it passes. That means documenting the build honestly, identifying dependencies that cannot legally be deposited and finding an alternative, and putting a process in place so the deposit stays current instead of ageing quietly for four years.

That is the background I bring to escrow work now, alongside the day to day consulting and technical work I take on through BAV Tech Solutions.