Software escrow is a well-established but frequently misunderstood risk mitigation mechanism in technology procurement contracts. Many customers assume it is irrelevant to cloud or SaaS arrangements, but this is a misconception. Others implement escrow arrangements that are poorly structured or inadequately maintained, only to discover that they provide little or no practical protection at the worst possible time: when the vendor becomes insolvent, is acquired, or ceases to provide support.

Chapter 9 of the 2nd Edition of Maddocks’ Technology Procurement Handbook provides detailed, practical guidance on software escrow, covering what it is, when it should be used, and the key terms customers should negotiate to ensure that escrow arrangements deliver real protection. Below, we highlight some of the key takeaways.

What is software escrow? 

Source code (the human-readable version of software) is the crown jewel asset of any software licensor: it is the core intellectual property that represents competitive advantage and control. Because of this, vendors typically make only object code (the compiled, machine-readable version of the software that can be executed, but not readily read or modified) available to customers, retaining source code for themselves. Under a SaaS or cloud model, neither source code nor object code is made available to the customer.

Customers relying on business-critical software need assurance that they will not be left without recourse if something happens to the vendor or if the vendor fails to deliver. Software escrow is designed to address this risk. In a software escrow arrangement, the customer, the vendor and a trusted third party (an ‘escrow agent’) enter into a tripartite escrow agreement under which the escrow agent holds the source code and other key materials on behalf of both parties, and releases them to the customer upon the occurrence of defined trigger events.

Under a software escrow arrangement:

• the vendor periodically deposits source code, documentation and other escrow materials with the escrow agent;
   
• commonly, the escrow agent securely holds and validates those materials, ensuring they are complete and up to date; and
   
• the customer may obtain release of the escrow materials if a defined release trigger occurs, such as the vendor becoming insolvent or ceasing to provide support.

Traditional versus modern escrow 

Traditional escrow models rely on physical media (such as tapes or hard drives) stored in a warehouse or vault. This approach is generally inadequate for modern software, particularly cloud and SaaS solutions, because:

• physical media cannot adequately capture complex cloud deployments, modular software architectures or third-party integrations;
   
• updates are manual and infrequent, meaning the version of the materials held in escrow may be significantly outdated;
   
• verification is often basic and may not confirm that the materials are complete or functional; and
   
• restoration in the event of a vendor failure can be slow, technically complex and resource-intensive.

Modern SaaS escrow models address these limitations by storing materials in a secure cloud environment and supporting continuous updates, automated verification and streamlined restoration. Additional capabilities can include virtual environment replication, data escrow (particularly important for SaaS customers who also need to recover operational data, not just source code), API and integration escrow, and real-time monitoring of escrow materials. For Australian government customers and other regulated entities, the location of escrow storage (onshore versus offshore) should also be considered in light of data sovereignty requirements.

There is a common misconception that escrow cannot be used for SaaS or cloud services, but this is not the case. Modern escrow models are specifically designed for these environments, and customers should not assume that cloud deployment is a barrier to implementing escrow.

Key terms to negotiate 

• Escrow materials

  Customers should ensure that the definition of escrow materials is broad enough to enable a competent developer (with no prior familiarity with the software) to build, run and maintain it. Source code alone is often insufficient. The deposit should also include:

  • technical documentation (including software architecture, APIs, build instructions and continuous integration/continuous deployment (CI/CD) pipeline configurations);
  • deployment and build scripts, configuration files and development environment specifications;
  • executable versions of the software and relevant databases or data schemas; and
  • access credentials, passwords or encryption keys required to operate the software.

  Customers should also address the frequency of deposits. Best practice, particularly for cloud and SaaS solutions, is to require automated or continuous deposits aligned with each new software release or update, so that the escrowed version remains current. Infrequent manual deposits risk the escrow agent holding a version of the software that is significantly out of date.

• Release events

  Customers should ensure that release events are defined broadly enough to cover all realistic scenarios. Common release events include:

  • the vendor becoming insolvent or ceasing to carry on business;
  • the vendor ceasing to provide support, maintenance or essential updates for a defined period;
  • termination of the software licence agreement due to the vendor's breach; and
  • assignment of IP rights in the software to a third party.

  Customers should also consider whether less common triggers (such as change of control, foreign influence or the vendor exiting a particular jurisdiction) are relevant to their circumstances.

• Release procedure

  If a release event occurs, customers should be able to obtain the escrow materials promptly, and ideally within a defined timeframe (for example, within 5 business days of a valid release request). Vendors may seek to include dispute provisions that suspend or delay release pending resolution of a dispute about whether the trigger has occurred. Customers should resist provisions that allow release to be delayed unreasonably, as they undermine the fundamental purpose of the escrow arrangement. If some form of dispute mechanism is accepted, it should be strictly time-limited.

• Verification

  Escrow arrangements are of little value if the deposited materials are incomplete, outdated or non-functional, yet this is often not discovered until a release event occurs. Customers should negotiate the right to conduct periodic verification testing (for example, annually), not just upon a release event. Verification can range from basic checks (such as confirming accessibility and scanning for viruses) to advanced testing, such as deploying the software in a test environment to confirm it is genuinely functional and current.

  The appropriate level of verification will depend on the complexity of the software. Customers should consult their technical stakeholders to determine what is required and ensure that the escrow agreement clearly captures those requirements. The cost of verification is generally borne by the customer.

• Licence rights

  Standard intellectual property licence provisions typically do not grant customers the right to modify source code (and under the Copyright Act 1968 (Cth), customers generally have no such right without an express licence). The escrow agreement should therefore include a broad licence that takes effect upon a release event, ideally a perpetual, royalty-free licence granting the customer rights to use, modify, enhance and sublicense the source code, including the right to engage third-party contractors to maintain or develop the software.

• Non-solicitation

  Many technology agreements include non-solicitation clauses that prevent customers from hiring or engaging the vendor's personnel. Following a release event, the vendor's staff are often the most practical resource for maintaining the escrowed software. Customers should seek an express carve-out from any non-solicitation restrictions for release event scenarios, to ensure the escrow arrangement can deliver its intended purpose.

• Escrow agent obligations

  Customers often focus on negotiating escrow terms with the vendor, but overlook the terms imposed on the escrow agent itself. The escrow agreement should require the escrow agent to comply with strict confidentiality and information security obligations (the deposited materials are often highly commercially sensitive), comply with the Privacy Act 1988 (Cth) where the materials contain personal information, and accept clear liability for failing to safeguard or release the materials when required. Where relevant, requirements for escrow materials to be stored onshore should also be expressly addressed.

Final thoughts 

Software escrow is not a ‘set and forget’ arrangement. An escrow agreement that appeared adequate at signing can quickly become ineffective, whether due to outdated deposits, inadequate verification testing, or a licence that prevents the customer from actually using the materials following a release event. To deliver real protection, escrow arrangements must be carefully designed, regularly maintained and reviewed as the software and the vendor’s circumstances change over time. When done well, software escrow can give customers genuine confidence that critical business operations will continue even if a vendor fails or ceases to support the software.

This article highlights only some of the key considerations explored in Chapter 9 of our Technology Procurement Handbook. The full handbook includes:

• detailed guidance, worked examples and practical negotiation tips to assist customers in reviewing and negotiating effective software escrow arrangements; and
• a range of additional chapters, including chapters on artificial intelligence, privacy, service levels and reseller arrangements.