Software escrow is an arrangement in which an independent third party holds source code and other agreed software materials for release when specified contractual conditions are met.
For private equity and M&A buyers, finding an escrow agreement in the data room is only the starting point. An outdated or untested deposit may expose gaps in the target’s customer commitments or leave it without a workable recovery option if a critical supplier fails. Technical due diligence should establish what protection the arrangement provides, whether the deposited materials are usable and what it would take to maintain or restore the service.
What is software escrow and why does it matter in M&A?
A typical arrangement involves three parties:
- The depositor. Usually the software owner or supplier, which deposits source code and other agreed materials.
- The beneficiary. Typically a customer or licensee entitled to receive those materials when the agreement’s release conditions are met.
- The escrow agent. An independent party responsible for holding the deposit and administering its release under the agreement.
Release events may include supplier insolvency, cessation of support or other defined failures. The agreement determines when materials can be released and how the beneficiary may use them.
Buyers should ask transaction legal advisers to assess whether those rights can be exercised as intended, including if the supplier enters insolvency. Technical diligence must then establish whether the released materials would be usable.
In an acquisition, software escrow can matter in two ways:
- Customer obligations the buyer inherits. A software business may have committed to maintaining escrow deposits for its customers. Buyers need to understand which products and versions are covered, whether deposits are current and whether the target is meeting its contractual commitments.
- Supplier protections the acquired business relies on. The target may depend on third-party software to operate critical systems. Buyers need to establish whether escrow provides a credible route to maintaining or restoring those systems if a supplier fails.
The level of scrutiny should reflect business criticality. Where software is readily replaceable or other continuity arrangements are sufficient, escrow may offer limited additional value.
Why a source code escrow agreement does not guarantee recoverability
An escrow agreement establishes what should be deposited and when it can be released. It does not demonstrate that those materials are sufficient to rebuild, maintain or run the software.
A business-critical application may depend on libraries, build tools, configuration files, deployment scripts, databases, external services and knowledge held by its engineering team. If those dependencies are unavailable or undocumented, access to the source code may offer limited practical protection.
The NCSC’s guidance on build environment security and secure design and development reinforces the importance of build infrastructure and third-party component inventories. Although this is not escrow guidance, it helps explain why source code alone may be insufficient.
Buyers should first establish the intended outcome – maintaining the software, restoring a service or supporting migration to an alternative. They can then assess:
- Does the deposit cover the version needed for that outcome?
- Are the required dependencies identifiable and accessible?
- Could a suitably skilled team build and deploy the application using the supplied materials and instructions?
- What data, infrastructure and operational access would be needed?
- Could the work be completed within the business’s required recovery timeframe?
- Does the beneficiary have the necessary rights to use the materials and supporting components?
A deposit need not reproduce the entire production environment. It must contain, or provide a credible route to obtaining, what is needed for its intended purpose. Current materials, clear documentation, appropriate rights and relevant independent testing can provide meaningful protection.
Source code is an asset. Recoverability is a capability. Technical due diligence needs to distinguish between them.
What technical due diligence should check in software escrow
An escrow review should start with the intended maintenance or recovery outcome, then examine whether the agreement, deposited materials and supporting arrangements can deliver it.
For buyers conducting software, platform or IT due diligence during M&A, seven checks provide a practical assessment framework.
| Assessment | What the buyer should establish | Evidence to request |
|---|---|---|
| 1. Existence | Which agreements exist, which products and entities are covered, and who benefits? | Executed agreements, schedules, party details and covered product lists |
| 2. Scope | What materials are deposited, what is excluded and how does this affect the intended outcome? | Deposit inventories, technical schedules and documented exclusions |
| 3. Currency | Does the deposit cover the relevant software versions and meet agreed update obligations? | Deposit update records, version histories and mapping to production releases |
| 4. Verification | What has been tested, by whom, under what conditions and with what results? | Verification reports, test dates, software versions, test scope and unresolved findings |
| 5. Recoverability | Could a suitably skilled team use the materials to achieve the intended outcome within the required timeframe? | Build and deployment instructions, dependency inventories, recovery tests, resource requirements and estimated timings |
| 6. Rights | When can materials be released, how may they be used and does the acquisition affect those rights? | Escrow terms, licence provisions, assignment and change-of-control clauses, required consents and legal review |
| 7. Transaction impact | What do any gaps mean for the acquisition, and which actions are needed before or after completion? | Prioritised risks, remediation options, estimated costs and effort, named owners and deadlines |
The depth of assessment should reflect business criticality. A readily replaceable application may need limited investigation. A platform supporting the target’s principal revenue-generating service warrants closer examination.
Independent technical assessment helps buyers distinguish demonstrated capability from supplier or management assurances. Legal advisers should assess contractual rights and obligations, while technical reviewers establish whether the proposed maintenance or recovery activity is feasible.
Findings should feed into the wider technical due diligence report, connecting each material gap to its commercial implications, the investment thesis and a clear decision or action.
Software escrow verification. What has actually been proved?
Buyers should examine the verification report behind any certificate. Receiving deposited materials, checking their contents, building the software and restoring a working service demonstrate different things.
| Evidence or test | What it may demonstrate | What it does not necessarily prove |
|---|---|---|
| Deposit receipt | Materials have been received and recorded | That they are complete, current or usable |
| Content or integrity checks | Specified files are present or pass defined integrity checks | That the software can be built, deployed or operated |
| Build verification | The tested version can be built using the materials and environment provided | That it can be deployed and operated as a working service |
| Recovery testing | A defined recovery process meets specified success criteria in a test environment | That untested dependencies, failure scenarios or subsequent software changes are covered |
These are categories of evidence, rather than standard industry certification levels. Providers may use different terminology and test scopes.
When reviewing a verification report, establish:
- What was tested. The deposit date, software version, environment and dependencies used.
- How success was defined. Whether testing covered compilation, deployment, functional operation or service recovery, including elapsed recovery time where relevant.
- What remained unresolved. Exclusions, failed steps, manual workarounds and outstanding findings.
- Who performed the work. What assistance the original developers provided and whether another suitably skilled team could repeat the process using the deposited materials and documentation.
A successful build is useful evidence. If the intended outcome is to restore a customer-facing service, testing should also address the data, infrastructure, integrations and operating procedures needed to deliver that service.
Verification findings must also be considered against subsequent changes. A successful test of an earlier release may leave material changes to the current application unexamined.
The buyer needs to understand what the verification demonstrated, what remains untested and whether that evidence supports the intended recovery outcome.
Why SaaS escrow needs a different assessment
Traditional source code escrow often aims to enable a customer to maintain software when its supplier can no longer support it. With Software as a Service (SaaS), continuity may also depend on infrastructure, data and services outside the customer’s control.
Application code is only one part of that environment. Databases, cloud hosting, deployment tools, authentication, integrations and monitoring may all be needed to keep the service running.
The assessment should establish which outcome the arrangement is intended to support:
- Independent recovery. Rebuilding and operating the application in a separate environment.
- Temporary continuity. Maintaining access to the existing hosted service during a transition.
- Migration. Extracting and transferring data, and moving to an alternative service.
Each outcome requires different evidence. Buyers should establish whether:
- Customer data can be accessed, exported and restored in a usable form.
- The application can operate without the supplier’s shared infrastructure or internal services.
- Hosting, authentication and other essential third-party services will remain available, with funding and account access arranged.
- A suitably skilled team is available to take over, with sufficient documentation and operational access.
- The transition can be completed within the business’s required timeframe.
Access to data, hosting accounts, credentials and third-party systems must also comply with contractual, security and data protection requirements. An escrow agreement should not be assumed to grant rights beyond those agreed with the relevant parties.
For an M&A buyer, SaaS escrow needs to demonstrate a credible route to continued service, supported by the people, permissions, infrastructure and funding required to deliver it.
Software escrow and stressed exit planning for regulated firms
Where an acquisition target relies on third-party software to deliver important business services, escrow may form part of its supplier exit arrangements.
The Prudential Regulation Authority’s Supervisory Statement SS2/21 on outsourcing and third-party risk management expects firms within its scope to maintain business continuity and exit plans for material outsourcing, including a stressed exit following supplier failure. Paragraph 10.16 of the November 2024 version identifies contractual or escrow arrangements as possible temporary measures to support continuity. It does not impose a general requirement to use software escrow.
For a buyer acquiring a PRA-regulated business, the assessment should establish whether its exit strategy relies on escrow and whether that reliance is supported by evidence:
- Is the intended continuity or recovery outcome clearly defined?
- Can the necessary materials, data, infrastructure and expertise be accessed?
- Has the exit plan been tested, including the time needed to obtain and use the deposited materials?
- Could the firm maintain or restore the relevant important business services within its applicable impact tolerances?
When assessing a software supplier to regulated firms, buyers should also examine the continuity commitments made in customer contracts and the supplier’s ability to meet them.
An effective exit plan needs more than release rights. It needs a tested, resourced route to continued service.
The software escrow red flags buyers should investigate
Escrow findings should be prioritised by their potential business impact. An incomplete administrative record may need clarification; an unavailable dependency could make recovery unachievable.
| Warning sign | Why it matters | Diligence response |
|---|---|---|
| Deposit updates cannot be demonstrated | The materials may not cover the relevant production version or meet contractual update obligations | Reconcile deposit records with releases and agreed obligations; identify any required updates |
| Verification excludes a critical recovery requirement | A material continuity assumption remains untested | Define the missing test and determine whether it must be completed before acquisition |
| A critical dependency cannot be obtained or recreated | Recovery may rely on unavailable technology, access or specialist knowledge | Assess alternatives, remediation feasibility, cost and timing |
| Release or permitted-use rights are unclear | The beneficiary may be unable to obtain or use the materials as intended | Refer to legal advisers to assess enforceability, restrictions and any required amendments |
| Customer commitments exceed the escrow arrangements in place | The target may be failing to meet contractual obligations | Reconcile material customer contracts with deposits, update schedules and verification commitments |
| Release and recovery timings exceed business requirements | The service may remain unavailable beyond an acceptable period | Assess the full timeline, identify delays and evaluate alternative continuity measures |
| No capable team or funding is available to execute recovery | Technically usable materials may still provide little operational protection | Establish who would perform the work, with what access, resources and budget |
| Material recovery gaps have no credible remediation plan | The remaining exposure may undermine the investment thesis | Reassess commercial assumptions, risk acceptance and potential transaction protections with the deal team |
These findings should inform the acquisition decision in proportion to business criticality, disruption consequences and available alternatives.
Each material finding should lead to a clear outcome – further evidence, remediation with an owner and deadline, or explicit acceptance of the remaining risk. The deal team should also know whether action is required before or after completion.
How escrow findings should influence the acquisition decision
Consider a hypothetical acquisition of a SaaS business whose main product generates a substantial share of its revenue.
The target has escrow agreements with several enterprise customers. Due diligence reveals that the deposited source code is two major releases behind production, with no documented independent build verification.
This establishes an evidence gap. The buyer cannot yet confirm whether the deposit could support maintenance of the current product. It also raises a separate question about compliance with customer commitments.
The deal team needs to resolve three issues:
- Contractual exposure. Legal advisers should establish whether the target has met its deposit and verification obligations, and assess the consequences of any breach.
- Technical remediation. Technical reviewers should determine what an updated deposit needs to contain, which tests are appropriate and whether any dependencies prevent successful verification.
- Commercial impact. The investment team should assess remediation costs, timing and any implications for customer relationships, recurring revenue or the acquisition plan.
If the gap can be resolved through a deposit update and successful verification, the response may be straightforward. If investigation exposes missing dependencies, undocumented build processes or substantial recovery work, the buyer needs to understand the wider implications for maintainability and future investment.
For material issues, the deal team may seek remediation before completion, agree a funded post-completion plan or consider contractual protections with legal advisers. Significant unresolved exposure may also affect valuation or the decision to proceed.
Each material finding should leave the buyer with four answers:
- What risk has been established, and what could it mean for the business?
- What evidence is still missing?
- What work, cost and ownership are needed to reduce the risk?
- Must that work happen before completion, or can it be managed afterwards?
The purpose is to give the buyer a clear basis for deciding what must change, what it will cost and whether the remaining risk is acceptable.
When escrow findings warrant deeper technical investigation
Independent technical assessment is particularly useful when escrow supports a business-critical application, a material customer commitment or a significant supplier dependency, and the available evidence leaves important questions unanswered.
Missing build instructions, inaccessible dependencies or reliance on individual developers may reveal wider weaknesses in maintainability and operational resilience. Buyers need to understand how those weaknesses affect continuity, future change and the investment required after acquisition.
The assessment should give the deal team clear findings, supporting evidence and prioritised actions, with realistic estimates of the effort needed to address material gaps.
Our Trust & Verify Advisory examines engineering delivery evidence, challenges assumptions and identifies practical improvement priorities. If escrow findings raise wider concerns about the target’s engineering capability, speak to us about the questions that need independent investigation.
For more on presenting findings to investment teams and other decision-makers, read our guide to technical due diligence reports.
Software escrow earns its place in an acquisition assessment when there is credible evidence of what it can deliver, what it depends on and where its limits lie.
Frequently asked questions about software escrow
What is software escrow?
Software escrow is a contractual arrangement in which an independent third party holds agreed software materials, such as source code, build instructions and supporting documentation. The materials can be released to a beneficiary when specified contractual conditions are met, subject to agreed rights of use.
What should buyers check in source code escrow?
Buyers should establish which agreements exist, who benefits, what the deposits contain and whether they cover the relevant software versions. They should examine verification results, recovery dependencies and contractual rights, including any effect of the acquisition on those rights. Material gaps should have a clear remediation plan or an explicit decision to accept the risk.
What does software escrow verification prove?
It depends on the tests performed. A deposit receipt confirms that materials were received; build verification may demonstrate that a particular version can be built under defined conditions. Recovery testing can provide stronger evidence of operational capability, but buyers should review its scope, dependencies, success criteria and unresolved findings.
Does source code escrow guarantee recovery?
No. Recovery may also require data, infrastructure, third-party services, permissions and suitably skilled people. Buyers need evidence that these resources can be brought together within the business’ required timeframe. Access to source code alone does not demonstrate that capability.
What is the difference between source code escrow and SaaS escrow?
Source code escrow typically supports continued maintenance of software. SaaS escrow or continuity arrangements may also address the data, hosting, configurations and operational access needed to maintain a hosted service, recover it elsewhere or migrate to an alternative. Buyers should examine the actual coverage rather than rely on the arrangement’s name.
Is software escrow mandatory in an acquisition?
Software escrow is not a standard requirement of every acquisition. Its relevance depends on the target’s customer commitments, supplier dependencies, business criticality and existing continuity arrangements. Transaction legal advisers should confirm any applicable contractual, legal or sector-specific requirements.
Does escrow prove ownership of software intellectual property?
No. Holding or depositing source code does not establish ownership or unrestricted rights to use it. Legal due diligence should separately examine intellectual property assignments, licences, third-party components and any restrictions affecting use, modification or transfer.
Should escrow deficiencies be resolved before completion?
Material gaps may need to be resolved before completion where they expose the business to unacceptable contractual or continuity risk. Other issues may be managed through an agreed post-completion plan with funding, ownership and deadlines. The decision should reflect the business impact, remediation feasibility and the buyer’s risk appetite.
