Disaster and Contingency Plans for SaaS Applications: A Legal Perspective

Going to a Software-as-a-Service (SaaS) model has plenty of advantages for both customers and vendors, but also comes with many risks not associated with the traditional software licensing model. The risks and potential solutions need to be understood by both customers and vendors in order to successfully negotiate win-win results. Handling these issues properly by a SaaS provider can also be a good way for the vendor to distinguish itself from the competition, because most vendors have not properly managed these issues and customers are certainly concerned about them.


The risks include:

  • System goes down or is “dysfunctional” for some period of time
  • Loss of data
  • Security breach of system
  • Vendor ceases operations
  • Vendor breaches its support obligations

Since the customer does not possess the software or related data when operating with SaaS applications, these and other types of failures can put the customer’s business at risk when mission critical services are provided via the SaaS applications. Even if the applications are not mission critical, failure of the SaaS applications can result in major losses or disruption to the customer’s business. If a substitute vendor or solution is required, selecting a new vendor, performing due diligence, negotiating agreements, implementing and testing the new solution will all take significant time.

Traditional Solutions

The traditional solutions described below are often negotiated in SaaS transactions. However, in practice, these solutions may not be all that practical to either enforce and/or implement when the critical moment arrives.

  • Disaster Recovery. Disaster recovery commitments by the vendor are important if the application and/or servers go down in order to be up and running again quickly. However, it is difficult for a customer to dictate the specifications for disaster recovery. Therefore, a customer will have to rely on the disaster recovery plan that the vendor has in place, which may not be adequate for all circumstances. Furthermore, the disaster recovery plan may fail for components provided by third parties, such as the hosting and third party services integrated into the SaaS platform. At a minimum, customers should require that: (i) vendors provide the details of the disaster recovery plan to the customer, (ii) a third party tests the disaster recovery plans annually and (iii) the vendor provide a copy of the test report to the customer.
  • Data Backup. Data backup and delivery is critical. Often the customer relies on data backup performed by the vendor. The customer should require backups to be performed daily and from time to time verify that the customer can actually access and utilize the data in the format used by the vendor.  An added protection is to have the vendor transfer the backup to the customer on a regular basis. However, this can incur additional costs. Even with data backups being performed, in many cases, the data cannot be efficiently used without the particular SaaS platform. Therefore, there will be no ability to get quickly up and running.
  • Escrow. Source code escrows are a common approach. This solution, theoretically, solves the issue of being able to efficiently utilize the backed up data. Most vendors have established master source code escrow accounts and can simply add a new customer as a beneficiary. A critical provision of a source code escrow agreement is the triggers that allow a release of the escrow. In short, the triggers need to be crystal clear, and provide the customer with quick access. If the ability to access the escrow is delayed, then the escrow arrangement loses practical value. Additionally, many customers are not staffed appropriately to be able to operate and maintain the SaaS application on a release of source code, which also makes the source code escrow have minimal value.
  • In House Licensing. Some SaaS vendors have an in house licensing model allowing the customer to install the application on its own servers rather than using the application through a SaaS platform. While exercising this option loses the advantages of a SaaS platform, it provides the security of the traditional licensing model. An idea is to provide this as an option in the agreement, in case it becomes apparent that the vendor has or is likely to have difficulties performing. 

Emerging Solutions

  • Expanded Escrow. In addition to source code, other components can be escrowed in order to allow for implementing a mirror of the vendor’s environment. These additional components may include application data and system configuration specifications. Of course, as with all of the above options, testing is critical to ensure that the plan would actually work when needed.
  • SaaS Recovery Services. Another option is a service that is offered by third parties where they mirror the SaaS application on the third party’s system. Therefore, everything can be up and running immediately (if all goes as planned). This is similar to the source code escrow in that this service requires a third party agreement, with trigger events and other necessary provisions. Typically, third party operation would continue until the vendor is able to assure the customer that the vendor is back in operation. In order for this to be a real solution, it would need to be combined with a source code escrow as well, otherwise the software would not be able to be supported and maintained properly. However, as with all of these options, the devil is in the details.
By William S. Galkin, Esq. | February 13, 2014



Share This Story, Choose Your Platform!

William Galkin manages GalkinLaw. Mr. Galkin has dedicated his legal practice to representing Internet, e-commerce, computer technology and new media businesses across the U.S. and around the world. He serves as a trusted adviser to both startup and multinational corporations on their core commercial transactions.


Subscribe to Blog Updates