How to Integrate SaaS Escrow into a SaaS License Agreement

As enterprise companies including major international banks are adopting cloud applications as their preferred technology platform, we are seeing a huge increase in demand for SaaS escrow agreements.

Protecting software and data within an AWS, Microsoft Azure or Google Cloud environment creates a large amount of challenges that need to be addressed by companies looking to implement SaaS solutions.

The Scope of SaaS Escrow Agreements

In order for Escrow London to draft a comprehensive SaaS escrow solution, we need to create a scope of the deposit materials to be included as part of the solution. Deposit materials for a SaaS escrow agreement would usually include source code automatically deposited from the developer’s Git repositories in addition to deployment scripts, containers and databases. During the scoping stage, the expectations of the beneficiary and the capabilities of the SaaS vendor are taken into consideration. Options suggested for a SaaS escrow solution may include:

• Source Code via Git: Automated deposit directly from the SaaS vendor’s Git repositories (GitHub, GitLab, Bitbucket, Azure TFS etc).
• Replication: A complete replicated cloud environment, files and databases – essentially a Disaster Recovery (DR) site that would provide complete continuity of service in the event of a release event.
• Container Images: Automated deposits of (Docker) containers or other deployment and orchestration tools to a storage repository maintained by Escrow London.
• Database Files: Automated deposit of the database backup. This encrypted copy of the database (SQL, Postgres, MySQL, Oracle) may be replicated to an S3 or other cloud storage account managed by Escrow London or our proprietary data centre.
• Verification – How often the latest deposit materials are verified and tested to ensure they could be used in a trigger situation.
• Supporting build documentation – detailed guide required to re-deploy the system to a clean cloud environment.

When we commence discussions with SaaS vendors and their clients, our initial aim is to determine the desired expectations from the beneficiary side. For some clients, i.e. an airline looking to protect their SaaS hosted booking system, this may mean a completely live, replicated environment within AWS, Azure or Google Cloud hosted by Escrow London that may be switched over with immediate effect should a release condition occur. For other clients, a verified copy of the source code and their current database/s may be enough based on their own risk analysis.

Databases introduce another challenge. In many SaaS environments, client data resides on a multi-tenanted database instance. In such situations, we work with the developer to determine a secure methodology to extract the beneficiary data to a single database which is then encrypted before being deposited. From our experience, the most common databases used by SaaS vendors are SQL, MySQL, Postgres SQL, MongoDB and Oracle (to a lesser extent).

Once the scope of the service has been identified, a SaaS escrow template agreement is provided. This agreement covers every aspect of the SaaS escrow process and details the obligations of each party. The sections usually include:

• Deposit of Materials: This section clearly defines the obligation of the SaaS vendor to:
  • Deposit the source code, databases, application files and documentation.
  • Assign Escrow London as a recipient of all financial and billing information from the cloud vendor and to assign relevant billing permissions within the cloud platform.
  • Engage with Escrow London to deploy a replicated SaaS environment on a dedicated cloud account hosted by Escrow London.
  • Provide the names and contact details of personnel that maintain the knowledge of the SaaS development and structure.
• Storage and Security: This section details the obligation of Escrow London to securely store and manage the deposit materials.
• Events of Default: This section outlines what is considered an event of default under the agreement that may result in the release of the escrow deposit or trigger the continuity solution. This section is typically negotiated by both parties to a level that provides comfort before the agreement is finalised.
  • Material failure to support the SaaS environment. The SaaS vendor is always provided a fixed period to rectify any material failures before this clause can be invoked.
  • The SaaS vendor enters insolvency or bankruptcy according to relevant laws.
  • The SaaS vendor ceases active operations of its business or service defined within the SaaS license agreement.
  • The SaaS vendor assigns their intellectual property to a third party who does not offer the beneficiary a similar level of protection covered under the SaaS escrow agreement.

• Release of Deposit Materials: This section clearly defines the process in which the beneficiary may apply to Escrow London for the release of the escrow deposit and to activate the replicated environment. The clauses provide the opportunity for the SaaS vendor to dispute the event of default cited by the beneficiary and to seek resolution according to a defined dispute resolution process. The location of the arbitration may be assigned to a relevant jurisdiction (ie UK, US, Canada or Australia) during the agreement negotiation phase.

A sample of an Escrow London SaaS agreement may be downloaded from here. SaaS Escrow agreements that include AWS replication require a bespoke approach. Please contact us for more information.

##

About Escrow London

Escrow London is a global SaaS escrow company with offices in Atlanta, USA, London, UK, and Sydney, Australia.

We have invested considerable resources into innovation to reinvent software escrow for a SaaS world. Escrow London provides a range of SaaS Continuity escrow solutions suitable for AWS, Microsoft Azure and Google Cloud hosted SaaS applications. We support a wide range of clients includes major law firms, banks, central banks, insurance companies, technology companies and government organisations.