When an enterprise customer builds a critical business process around a third-party software application — whether an ERP system, a manufacturing execution platform, a financial modelling tool, or a compliance management system — it creates an operational dependency on the continued availability of that software. If the vendor becomes insolvent, is acquired by a competitor who discontinues the product, or simply ceases to support the relevant version, the customer faces the prospect of a critical system becoming unavailable or unmaintainable at short notice. Software escrow agreements are the established mechanism for managing this risk, but their effectiveness depends critically on the structure of the agreement and the nature of the software being escrowed.
The Basic Mechanics of Software Escrow
A software escrow arrangement involves three parties: the software vendor (the licensor), the customer (the licensee), and the escrow agent (a neutral third party). The vendor deposits the source code of the software, together with build instructions, technical documentation, and other materials necessary to understand and maintain the code, with the escrow agent. The escrow agent holds these materials under the terms of the escrow agreement and releases them to the customer only when a specified release condition occurs.
The release conditions — the events that trigger the escrow agent to release the deposited materials to the customer — are the most commercially significant provisions in the agreement. Typical release conditions include the vendor’s insolvency or appointment of a receiver, administrator, or liquidator; the vendor’s material breach of the software licence agreement where the breach is not cured within a specified period; the vendor’s discontinuation of support for the software without providing a migration path; and sometimes the vendor’s acquisition by a competitor or a change of control that adversely affects the customer’s use of the software.
Upon release, the customer receives a licence to use the source code for the limited purpose of maintaining and supporting the software for its own internal use. This survival licence is typically non-exclusive and non-transferable, allowing the customer to keep the system running and to have the code maintained by its own IT team or a third-party contractor, but not to commercialise or distribute the software.
What Must Be Deposited: The Completeness Problem
The fundamental risk in any software escrow arrangement is that the deposited materials are incomplete, outdated, or insufficient to actually build and maintain the software without the vendor’s involvement. This is the most common real-world failure mode of escrow agreements: the customer experiences a release event, obtains the deposited materials, and discovers that the source code is missing critical components, does not compile without proprietary development tools, relies on third-party libraries that are not included in the deposit, or is so poorly documented that it cannot be maintained by anyone other than the original developers.
Addressing this risk requires careful specification of deposit requirements in the escrow agreement. A comprehensive deposit should include the complete source code in buildable form, all build scripts and configuration files, documentation of the development environment including the versions of compilers, build tools, and dependencies used, a build test demonstrating that the deposited materials can be compiled into a working executable, documentation of the software architecture and data structures, and any third-party libraries or components incorporated into the software (subject to their own licences permitting distribution).
The deposit must also be kept current. Software that is actively developed will diverge from the deposited version over time, and a deposit made at contract inception may be significantly outdated by the time a release event occurs. Escrow agreements should require periodic updates of the deposited materials — at minimum annually and ideally following each major release — with verification that the updated deposit is complete and buildable. Some escrow agents offer verification services that include independent compilation testing of the deposited materials; these are strongly advisable for customers whose operational dependency on the software is significant.
SaaS and Cloud Delivery: The Escrow Challenge
The traditional software escrow model was designed for on-premises installed software. In the SaaS world, the customer typically has no installed software to maintain — the application runs on the vendor’s cloud infrastructure and the customer accesses it through a browser or API. This creates a fundamentally different continuity risk profile: not only does the customer need the source code, but it also needs the infrastructure to run it, the database and configuration for its specific tenant data, and the operational expertise to deploy and maintain a cloud application.
For SaaS customers, a pure source code escrow provides limited protection. Even if the customer receives the source code following a vendor failure, it faces the formidable challenge of deploying and operating that code on its own infrastructure — which requires cloud hosting, DevOps capabilities, and engineering expertise that most enterprise customers do not have in-house. The time required to stand up a production-ready deployment from source code is typically weeks to months, during which the customer’s critical system is unavailable.
The industry has responded to this challenge with several approaches. SaaS escrow or continuity services — offered by specialist providers including Iron Mountain, EscrowTech, and others — go beyond source code escrow to include deposits of virtualised environments, container images, database backups, deployment scripts, and infrastructure-as-code that can be deployed more rapidly than bare source code. Some providers offer tested continuity services that include periodic exercises of the release and deployment process, verifying that the deposited materials can actually produce a running system within a specified recovery time objective.
An alternative approach is the data portability and export right. Rather than escrow of the software itself, enterprise customers negotiate contractual rights to export all their data in a standard, machine-readable format and to retain that data for migration to an alternative system if the vendor relationship terminates. This approach acknowledges that maintaining the vendor’s proprietary software may be impractical and focuses on protecting the customer’s data — the commercially irreplaceable asset — rather than the software that processes it.
Regulatory Drivers: DORA and Critical Third-Party Risk
For financial institutions subject to the EU Digital Operational Resilience Act (DORA), software escrow and continuity planning for critical IT systems is not merely a commercial preference but a regulatory obligation. DORA requires financial institutions to assess the concentration risk associated with critical third-party IT service providers, to maintain exit strategies for critical relationships, and to include specific contractual provisions in agreements with critical third-party providers covering audit rights, sub-outsourcing governance, data portability, and business continuity arrangements.
DORA’s requirements effectively mandate that financial institutions operating in the EU address the SaaS continuity problem contractually, through exit strategies and termination assistance provisions that require the vendor to support an orderly migration to an alternative system. The regulatory backdrop of DORA has increased the leverage of financial institution customers in negotiating escrow and continuity provisions with SaaS vendors — and has given vendors a commercial incentive to offer certified continuity solutions as a competitive differentiator in the financial sector.
NIS2’s resilience requirements create comparable drivers for entities in other critical sectors, including healthcare, energy, and essential service operators, who must demonstrate that their critical IT dependencies have been managed to a standard consistent with their NIS2 obligations. Procurement of critical software without adequate continuity arrangements may itself be considered a deficiency in the entity’s risk management programme.
Negotiating Escrow Provisions: Commercial Context
Software escrow negotiations are influenced by the commercial relationship between vendor and customer. Large enterprise customers with significant contractual leverage can typically negotiate comprehensive escrow arrangements as a condition of contract. Smaller customers, or those purchasing standardised SaaS products on the vendor’s standard terms, may find that the vendor is unwilling to provide bespoke escrow arrangements or to incur the cost of maintaining an escrow deposit for every individual customer.
The commercial reality is that software vendors have limited incentive to make it easy for customers to maintain their software without the vendor’s continued involvement, because the ease of migration is a determinant of customer retention. Vendors will often resist broad release conditions, insist on arbitration or verification procedures that delay release, and argue that the deposited materials will be quickly outdated given the pace of development. Enterprise customers should anticipate these positions and be prepared to negotiate specifically on the completeness of the deposit, the currency of updates, the release conditions, and the release verification procedure.
Conclusion
Software escrow agreements remain a valuable risk management tool for enterprise customers who have built critical operations around a vendor’s software, but their effectiveness depends entirely on execution quality: what is deposited, whether it is complete and current, whether it can actually be used to maintain the software following a release event, and whether the continuity plan addresses the specific delivery model of the software in question. In the SaaS era, pure source code escrow is often insufficient, and customers should push for continuity arrangements that address the full stack of their operational dependency. Regulatory frameworks including DORA and NIS2 are creating mandatory drivers for this type of analysis that will progressively raise standards across regulated industries.