SaaS Agreements: Key Contractual Provisions

Many, perhaps trending to most, commercial licensors and licensees are utilizing delivery models other than the historic on-premised method (i.e., using computer hardware located at the end user’s location) for providing and accessing software applications. Most commonly illustrated through the use of “cloud computing,” these delivery models raise many of the same issues involved in traditional software licensing, while at the same time creating issues unique to the respective delivery model. Cloud computing provides on-demand delivery of IT resources and applications via the Internet with substantially pay-as-you-go pricing, allowing customers to reduce initial IT expenses while having the ability to quickly increase or decrease IT resources to meet their perhaps varying needs.

Under a “SaaS” model, access to a software application is provided to the customer as a service. The vendor/cloud provider or another party hosts the software application on its web servers or via a third-party application service provider, allowing customers access to the software using web browser software via a portal and/or the Internet. The customer does not license a copy of the software but accesses the software as a service on an as-needed basis.

(A) Overview

(i) Benefits

From a software cloud provider’s perspective, SaaS allows the cloud provider to reduce its support costs by maintaining a single version of its software on a single platform. A SaaS model allows cloud providers to monitor how their customers use the application, bring improvements to the market, and address uniformly for all customers any problem that arises. The cloud provider’s support staff is able to evaluate a customer’s problem as each customer is using the same application on the same platform. Updates are automatically made available to customers instead of customers having to wait to receive, install, integrate and pay for, the newest update. In addition, SaaS allows the cloud provider to sell to customers who may not be able to afford the upfront fees required to procure the software and/or the infrastructure to support it.

From the customer’s perspective, the customer is able to reduce its information technology costs by not having to purchase an application license, the hardware required to run it, as well as fees for updates and technical support. All of these costs are built into the fee for accessing the application, allowing the customer to direct its technology budget to those technologies that will provide a competitive advantage in its industry.

For cloud provider–owned applications, the customer’s cost to access the application should be reduced as the price is amortized among several users and the subscription fee is often based on usage. By paying only for its proportionate share of computing power and other resources that it uses, the customer avoids paying for excess capacity. The usage fee is amortized over the period of the customer’s use as differentiated from the purchase of a software license where payment in full is usually due immediately upon acquisition of the license. This payment mechanism evens out the user’s payments over the course of a year, potentially helping cash flow.

The customer will also avoid the significant time and cost of installing an application. In essence, application management has been outsourced, allowing the customer’s IT staff to focus on other projects. Because the software is already operating on the cloud provider’s system, the time to begin using the new application is dramatically reduced. The customer’s software usage is fully monitored by the cloud provider, allowing the cloud provider to instantaneously receive “feedback,” speeding the pace of improvements to the application, and allowing customers to benchmark against their peers. Further, the customer is able to automatically access the most recent updates and enhancements to the application without the risks inherent in transitioning to a new version.

(ii) Limitations

SaaS does have several limitations/reasons for concern. The greatest is that the customer has relinquished control over its IT to a third party and is totally dependent on the third party to consistently deliver access without interruption while using a secure environment. Although the customer is purchasing a service not a software license, a customer still needs contingencies that address sudden cessation of the cloud provider’s business or an event of force majeure, as application continuity is necessary to enable end user business continuity (contingency) plans. The customer also lacks the ability to customize the applications for its needs as most cloud providers will only modify the application for very large customers.

Another challenge for customers is that many cloud providers require customers to use the cloud provider’s non-negotiable template agreement to purchase the cloud provider’s services. These cloud providers argue that pro forma contracts are industry standard and reflect the nature of lower margins and shared services, thus negating the need to negotiate the contract. Although a cloud provider’s contract may be non-negotiable, customers should carefully review the agreement to make sure it meets their needs. For example, does the agreement provide the use rights the customer requires, such as allowing the customer, its contractors, and the customer’s customers to access and the software?

(iii) Delivery Models

SaaS is usually delivered through one of two models: a hosted application model or a software-on-demand model. In the hosted application management model, a hosting provider hosts the desired application, delivering the application to its customers over the Internet. Under the software-on-demand model, the cloud provider (i.e., the software cloud provider/licensor or cloud provider) provides its customers network-based access to a single copy of an application modified for SaaS over a network. Software on demand is also known as the “application service provider” model. In both cases, the customer is paying for access to the application. The cloud provider may choose to have someone else host it, but delivery is the same and essentially “on-demand.” In most situations, the cloud provider will provide, maintain and host an application while providing the customer access to the application. The application may be held in a dedicated environment with its own instance of the application, or alternatively, the application may be hosted in a multi-tenant environment with a common version of the application running on a logically partitioned environment.

A shared multi-tenant environment uses a single instance of the application to provide access to multiple customers. All customers access and use the same instance of the application, creating an efficient means of implementing patches, upgrades, fixes and maintenance. A single tenant environment provides access by a single customer creating a more expensive service that cannot be easily scaled. A shared environment creates greater security risks as many clients’ data may be hosted on a single server. Thus, clients with sensitive data will often insist on dedicated servers. The language below reflects the potential convers of customers.

Dedicated/Partitioned Environment. Any time Services are performed at the Customer Facilities, Vendor shall provide the Services using hardware, software and related resources dedicated solely to supporting Customer. Unless otherwise expressly provided in this Agreement, all Services provided from the Vendor’s Facilities shall be provided using partitioned or dedicated Equipment. Vendor shall not provide any Services from a shared processing environment unless specifically approved in writing by Customer.

The cloud provider may choose to deliver SaaS either by hosting the application itself or by outsourcing the hosting of the application to a hosting provider. Usually, the cloud provider will use its own proprietary software which it provides to its customers. In some cases, a hosting provider will license a copy of the software from the cloud provider and set up a SaaS model with its own customers. In the latter case, the hosting provider acquires rights from the software cloud provider and provides access and use of the application to customers. This approach is often co-defined through a “reseller” situation.

(B) Contractual Provisions

(i) Services

The underlying SaaS agreement between the parties should clearly set forth the cloud provider’s obligations and the services it will provide. In a SaaS relationship, most cloud providers will provide:

• Access to an identified application,
• Technology updates,
• Data storage,
• Data back-up,
• Data security, and
• User support.

To the extent a service is not listed, the customer should assume it is not included. For example, if data back-up is not listed, the customer should assume the cloud provider will not be providing such services and the customer should back-up its own data on a regular basis. To the extent the cloud provider desires to implement a material change in the provided services, the cloud provider should be required to provide the customer advance notice of any material change, and the customer should have the right to terminate the agreement for convenience without penalty.

If applicable, proof of concept or beta testing should be conducted prior to making any long-term commitments to the cloud provider. The customer should ensure that the data created by the application is compatible with the customer’s legacy systems (e.g., that the data schema are susceptible to “extract transform and load” (“ETL”) modification and injection to other current systems) and thus avoid any potentially costly and time-consuming data migration project. The cloud provider should also be willing to provide the customer a written commitment as to the application’s future features and functionality that will be made available to customers. A prudent cloud provider may be hesitant to do so, however, to retain the maximum flexibility to operate its business.

(ii) Ownership of Data

From the customer’s perspective, the agreement should clearly state:

• the customer owns its data (and all intellectual property rights related thereto);
• the customer will have immediate access to its data without charge upon demand;
• upon termination of the agreement the customer may take its data to a new cloud provider; and
• the format in which the data will be returned to the customer.

The agreement should also describe how and in what format the data will be returned and prohibit the cloud provider from withholding data for non-payment. Return of the data should be prompt and not conditioned on the customer meeting a payment demand by the cloud provider.

Sometimes it is the customer’s responsibility to remove the data, i.e., to copy it onto its own system. If this is the case, the customer should make sure that once the data has been copied and the customer has confirmed it has a reliable copy of its data, the cloud provider destroys the data that remains on the cloud provider’s systems. Usually, the cloud provider will want to do so in accordance with its own practices, e.g., by overwriting, etc. To the extent any data is contained on backup tapes, the backup tapes should be immediately destroyed, and an authorized officer of the cloud provider should certify that the tapes have been destroyed. Finally, the agreement should set strict time frames for the destruction or return of the data.

Some customers may require the cloud provider to issue a “destruction certificate” as proof of action by the cloud provider. However, there may be issues with respect to multi-tenancy environments where redundant data sets or similar copies of data continue to exist. Unless the relationship is managed in a single tenant database, it may not be possible to assure total destruction of the data. Contrary to the point above, it is also critical from the customer’s perspective that the cloud provider be prohibited from destroying the customer’s data in the event of non-payment until the customer has provided written instructions to do so.

Prudent cloud providers should develop an internal guidance/checklist setting forth the actions to be completed prior to executing a destruction certificate to avoid unintentionally creating liability on the cloud provider’s behalf. To avoid potential problems, the certificate should be signed by the team lead for the team that completed the work, usually a member of the IT department.

(iii) Cloud Provider Access and Use of Customer Data

Cloud providers often seek access to the customer’s data for many reasons including the cloud provider’s desire to aggregate and resell the customer’s data to third parties. Under no circumstances should the cloud provider be able to sell the customer’s data to a third party even if it has been “cleansed” of any identifying information. The cloud provider should be contractually prohibited from accessing or disclosing the customer and customer data. While prudent customers should seek to limit the cloud provider’s use of their data, the cloud provider should have the ability to collect and analyze usage data to improve the quality of the cloud provider’s services including as input for its product/services “roadmap.” The agreement should clearly state that all customer data, including customer data, is confidential regardless of whether it is displayed or accessible by the cloud provider. Allowing the cloud provider to access customer data may raise antitrust issues as well as limit the customer’s ability to claim trade secret protection for such data. For a discussion of trade secrets in the cloud see Sandeen, Lost in the Cloud: Information Flows and the Implications of Cloud Computing for Trade Secret Protection, 19 Va. J.L. & Tech. 1 (2014).

The customer should not agree to amorphous language such as the cloud provider will “comply with industry standards” or the cloud provider will “use commercially reasonable efforts to protect the customer’s confidential information.” A prudent customer will also seek to prohibit the storage of users’ credentials and passwords by the cloud provider.

Model language favoring the cloud provider:

We routinely collect and analyze metadata regarding your usage of the Cloud Services, excluding any personal data. We may use this information to gauge Cloud Services usage levels and application performance, as well as to create anonymized statistics for our own marketing purposes.

The following language provides the cloud provider even greater leeway to utilize the customer’s data.

Vendor may use and reproduce Company Data at the direction of Company (such direction taking the form of the terms of this Agreement and the relevant Schedules) for the limited purposes of providing, operating, and maintaining the Services provided to Company. Company will secure for Vendor the right to use and reproduce Company Data, including any Personal Information therein, solely to the extent necessary to provide the Services to Company, without creating any obligations for Vendor beyond those set forth in this Agreement. Vendor may use usage patterns, trends, and other statistical data derived from use of the Services (but not Company Data itself) for the purposes of providing, operating, maintaining, or improving the Services and any Vendor products and services used to deliver the Services.

Compare the preceding language to the following language which favors the customer:

Customer grants Vendor a limited, royalty-free, non-exclusive, non-transferable and non-sublicensable license to process the Customer Data only in the United States as instructed by Customer and only to provide the services for Customer’s benefit so long as Customer uploads or stores Customer Data in the System, subject to all terms and conditions of this Agreement.

(iv) Data Retention

Given significant numbers of customers, relatively short contract lengths, and the commoditized nature of cloud computing, many cloud providers retain customer data for very short periods of time. To the extent the customer has specific concerns, it should ensure the underlying agreement allocates not only responsibility for data retention and backup but also the time period in which data will be retained. The period of retention will depend on RTO/RPO’s, requirement for the retention of metadata and the cost of doing so. RTO and RPO are common terms used to measure “Recovery Time Objectives” or how long it will take to recover data and resume using an application that has gone down. “Recovery Point Objectives” speaks to data freshness at the time of recovery. Sometimes, companies can recover data that is a week old meaning all the data from the current week would be lost. For mission critical applications, RPOs of less than one hour are standard.

Another issue for consideration is litigation holds for litigation, including the ability of the cloud provider to retain metadata. A prudent customer will contractually provide how it will notify the cloud provider of any litigation hold and how the cloud provider will preserve the relevant data. The failure to do so may lead to discovery sanctions on the customer in the event of any litigation.

Further, to the extent a cloud provider is required to destroy or retain the customer’s data, the parties should realize that it is virtually impossible to destroy all data as customers’ data will be inevitably retained in backup tapes and the memory of the servers. As a result, some negotiated transactions include provisions for ongoing but secure storage by the former cloud provider of former customer data for specified, tax, quality control, or other purposes.

(v) Pricing and Payment

Customers may be charged through various means, including on a per-user per-month basis, on a monthly subscription for the customer’s entire company, and results for a customer’s use of the application. For example of the last, infrequent pricing metric, a marketing software company is paid according to the number of solid leads generated through the customer’s use of the software.

Customers should carefully evaluate a contract’s pricing model to ensure the pricing structure is clearly delineated and that the customer has the ability to independently verify any amounts that it is billed by the cloud provider. If access is based on the number of seats or users, the definition of “users” will serve as the basis for establishing the aggregate fee paid by the customer. As such, the customer should clearly understand how the application will be used and who will be accessing and using the application.

For example, if a cloud provider defines a “user” as a named individual accessing the system, the “named user” terminates their employment, and a replacement employee is hired, is the customer is required to purchase a new license of the new employee or may it transfer the license from the old employee to the new employee? Like a traditional license, the price should be fixed for a set period of time, and the amount of any future price increases should be capped.

Further, if the customer’s customers will be indirectly accessing the application, do they need a license? The customer’s failure to obtain the rights it requires or understand its use rights may prevent it from achieving the synergies it expected from using the application as well as cause the customer to incur significant unforeseen costs. See SAP UK Limited v. Diageo Great Britain Ltd [2017] EWHC 189 (TCC) February 16, 2017 (SAP successfully sought additional compensation for Diageo’s customers access and use of SAP’s software).

Most cloud providers require the customer to pay quarterly or annually in advance, eliminating any payment risk.

(vi) Performance Standard/Service Level Agreements (SLAs)

Service levels are very important as they establish the cloud provider’s minimum performance obligations and the degree of access that the customer will have to the application or services, including the customer’s own data. Many cloud providers, however, do not offer meaningful SLAs, arguing the application must meet the demands of multiple customers. Most cloud providers will at least offer availability service levels, and some may be willing to provide additional remedies beyond service credits for an additional fee. If appropriate, customers should seek to negotiate additional SLAs including response times, bandwidth and security breaches, although most cloud providers will only agree to meet minimum legal requirements. SLAs almost never cover failover guarantees or contingencies that address issues beyond the cloud provider’s control, such as the sudden cessation of the cloud provider’s business or an event of force majeure. Cloud providers should avoid being measured on any customer-dependent elements such as location processing capability.

Service levels should reflect the usage of the application. For example:

• How is the application being used?
• Where are the employees using the application located?
• What time of day will the employees be accessing and using the application?

A successful service level should be objective, critical to the successful performance of the services, tailored to the services, and achievable by the measured party. Common service levels include:

• Availability (both network and application)
• Remedies (including financial penalties/credits)
• Problem response time
• Issue resolution/Escalation Procedures, including status reporting
• User support
• Data return (Recovery Time/Recovery Point Objectives)
• Simultaneous visitors/users
• Page response times

(vii) Data Security

Security is important when utilizing a SaaS model, but it is especially important for those customers utilizing a public cloud. By centralizing a party’s data in a secure data center, a party may actually increase its security (e.g., via the greater skills, resources, oversight, and testing that may be enabled by greater scale, i.e., a cloud provider testing and optimizing cybersecurity on behalf of multiple customers and its overall business model, versus a single entity attempting to achieve cybersecurity excellence only on its own behalf and outside its core focus or competencies). On the other hand, the customer has ceded control over its data and now is dependent on the cloud provider for protection.

There are three aspects of security: physical security, technical security and administrative security. Prudent customers should undertake a comprehensive risk assessment that evaluates the scope of the purchased services and seek to identity any threats and vulnerabilities to receiving those services. It should assess the cloud provider’s security policies and ascertain the potential risk of a threat triggering a vulnerability as well as the potential impact if such a threat occurs. Customers will typically address their concerns with the cloud provider and incorporate its security requirements in the underlying agreement—often as a detailed, separate exhibit to the contract. Depending on the value of the contract and the importance of the application, the customer should visit the facility from which the cloud services are provided, if applicable and allowed, and request a written copy of the cloud provider’s security protocol for the building’s physical security and the security of the network from intrusion, and viruses, as well as annual updates. The customer should closely examine and vet the cloud provider’s policies as well as ascertain the specific type of infrastructure used by the cloud provider to provide the hosting services.

The cloud provider should undertake an external and internal security analysis several times a year. The results of these efforts should be provided to the customer without the customer having to request it.

Most important, however, is the definition of “data,” as the definition will establish the cloud provider’s security, confidentiality, and privacy obligations. Is “data” limited to information stored by the cloud provider, or does it include data created and collected by the cloud provider in the course of delivering services to the cloud provider? Customers should seek to draft the definition of “data” as broadly as possible to ensure that its data is completely secured.

Security Standards

Multi-tenancy creates significant risks that other customers may be able to access or extract a customer’s data, increasing the risk of viruses and malware entering the customer’s environment as well as other security lapses. As such, customers should carefully negotiate the agreement’s security standards after identifying potential risks and potential approaches to mitigate the identified risks. Such risks, both internal and external, as well as the agreed upon risk mitigation controls, must be continually monitored during the term of agreement.

To avoid ambiguity, the parties should specify the specific security standard the cloud provider must adhere to. The customer should ensure that the data center is ISO compliant as well as SSAE 18/ ISAE 3402 compliant. SSAE 18 SOC 2 and SOC 3 set forth significantly more stringent audit standards and are specifically focused on data centers. ISAE 3402 is the international equivalent of SSAE 18 and should apply and be reported against whenever data is kept in a global environment. See Chapter 7.E of The Practical Guide to Software Licensing and Cloud Computing, 7th Edition, for a more detailed discussion of SSAE 18 and its requirements.

The cloud provider should maintain a written comprehensive information security program that includes reasonable security procedures and practices to ensure the security, confidentiality, privacy, availability and integrity of user content and other information if transmitted through or stored in connection with the services. Sophisticated customers seek to negotiate these cybersecurity specifications, attaching the agreed upon standards as a detailed exhibit to the agreement.

Location of Data

Prudent customers should consider contractually specifying the jurisdiction in which their data must be housed, or alternatively require that all data remain within the continental United States to avoid subjecting the customer to the laws of those jurisdictions in which the data resides, including the jurisdiction’s privacy laws, data transfer laws and jurisdictional discovery rules. The European Union has very restrictive laws as to data protection and prohibits the transfer of data to countries with inadequate data protection laws. To the extent a customer allows its data to be removed from the United States, a customer should monitor the data’s location to avoid any potential prohibition by the jurisdiction to which its data was moved from relocating the data back to the United States. Savvy customers will include an audit provision allowing the customer to audit the cloud provider’s compliance with its contractual obligations related to data location.

The citizenship of the owners of the data will dictate which state laws govern the vendor’s privacy and security obligations.

Physical Security

Physical security should not be overlooked. The cloud provider should be able to provide the customer with a written security plan setting forth the protections implemented at its data centers including:

• limiting and segmenting physical access,
• restricting physical access to required personnel,
• personnel background checks,
• badging, and
• training.

The customer should carefully evaluate the cloud provider’s security protections. The customer should understand who has access to its confidential information and data and under what circumstances.

• Who has the ability to modify such data?
• What controls are in place to protect the customer from an unauthorized individual accessing and modifying the customer’s data?
• Where is the cloud provider’s data center located?
• Does the data center have adequate physical and virtual security?
• Does the cloud provider have appropriate virus protection software and appropriate security measures to protect the customer’s data and internal systems?
• What particular testing and validation processes and third-party certifications, if any, will be required?
• May the customer initiate periodic “penetration testing” and if so under what parameters?
• What if any cybersecurity-specific insurance coverage(s) must the cloud provider procure and maintain on the customer’s behalf, at what levels and for what duration? The customer should ensure the required protections are maintained 24x7x365 days a year.

Technical Security

The cloud provider should utilize advanced software to detect any attempted and any actual intrusions to its network, as well as eliminate viruses and similar problems. A customer should require that its data be encrypted not only at rest (storage) but also during transmission (i.e., both “at rest” and “in transit”). Not all cloud provider applications are encrypted, making data stored on such applications vulnerable to misappropriation or theft. A customer should insist that the cloud provider comply with specific encryption standards for the encryption of the customer’s data. The language below illustrates this point:

Customer will encrypt the Data using the AES-256 standard and store on Vendor Simple Storage Service (S3) devices within the Vendor east coast and west coast data centers. When needed, the encrypted Data will be replicated to Elastic Band Storage (EBS) devices and made available during the boot process to server instances and associated server user accounts with proper credentials. The credentials will be stored and maintained within the Customer-managed data center and presented to the Vendor server instances only during the boot process. No credentials will be stored in the Vendor cloud environment.

The cloud provider should be required to utilize sophisticated intrusion protection and detection software as well as peripheral equipment and be required update it on a continuous basis to ensure it remains current with the latest technology. The cloud provider should be contractually obligated to provide detailed reports for any attempted intrusions of material significance as well as any resulting data breaches. The agreement should establish a change-of-custody log and tightly control and restrict access to any data as well as provide an audit procedure for auditing network and user transactions. In cases where the nature of the customer’s data warrants it, the parties should also consider the use of a virtual private network (VPN) to further reduce security risks.

The parties should establish stringent requirements for the storage of customer credentials and passwords outside of the cloud, including strong access controls. In addition, the agreement should address other common-sense security controls, such as staff screening, firewall standards, access logs and the ability of third-party contractors to access the system. Priority should also be given to preservation of security controls as part of any disaster recovery plans.

Administrative Security

Administrative security refers to the management operational controls and procedures implemented to protect the system’s security, including:

• Authentication of HTTP clients
• Administrative console security
• Naming security
• Use of SSL transports
• The common user registry
• The authentication mechanism
• The authentication protocol

Security Breaches and Incidents

The cloud provider should be obligated to notify the customer immediately in the event of a data breach or suspected breach and provide a detailed written explanation of the nature of such breach/suspected breach and the actions it has taken to remedy such breach. The agreement should address the parties’ respective responsibilities for complying with all federal, state, and local data breach notification laws, including which party has responsibility for drafting a notice to any affected parties, sending the notice, paying for all costs associated with doing so, and identifying costs the responsible party must assume. In addition, the agreement should address which party must pay for any costs associated with complying with new laws enacted after the execution of the agreement.

The most important aspect in framing the parties’ obligations is the definition of “data breach,” as the definition will establish the scope of each party’s obligations. Both parties should ensure they understand the ramifications of the definition and how it will impact their obligations and potential liability.

The agreement also should set out in detail the necessary response on the part of the cloud provider to a data breach, including how quickly the cloud provider must contact the customer to disclose the existence of an intrusion or breach, via what means, how much information the cloud provider must provide the customer, what steps the cloud provider must take to investigate, if the cloud provider will interface with law enforcement and how, how often the cloud provider will update the customer on actions taken to mitigate the effects of any breach, and what remedies the cloud provider will offer, if any. From the customer’s perspective, the customer does not want the affected individuals or entities or its board of directors and executives to first learn that there has been a security breach involving its data from the media or a third party.

(viii) Disaster Recovery

Disaster recovery differs from business continuity in that business continuity addresses issues that may arise in the ordinary course of business such as bugs, hacking, general down time and other service interruptions. Disaster recovery addresses incidents more akin to an event of force majeure such as a natural disaster. The cloud provider’s disaster recovery plans should be carefully reviewed by the customer and include the level of redundancy for the application, i.e., the availability of the application in the event of a failure of the primary server or application (such as a geographically distant “hot” site), the cloud provider’s protocol for backing up data (e.g., what frequency, testing, passwords, chain of custody, etc.), the storage of such data offsite, as well as the duration for which it will retain the backups. See Chapter 7.F of The Practical Guide to Software Licensing and Cloud Computing, 7th Edition, for a more detailed discussion of disaster recovery issues. The cloud provider should be able to provide a detailed plan addressing a power outage, natural disaster, equipment failure, the sudden cessation of its business (bankruptcy notwithstanding) and so on, as well as service level agreements for uptime and the ability to log onto the application independently of the cloud provider (for more information, see Chapter 9, Section A.5 of The Practical Guide to Software Licensing and Cloud Computing, 7th Edition, discussing SaaS Escrow). Finally, the cloud provider should disclose any audit protocols it has adapted to ensure its existing protocols and methodologies are followed. The customer should also ask the cloud provider about any previous security problems or service interruptions.

(ix) Indemnification

As with any commercial agreement, indemnification plays an important role in allocating and managing the parties’ risk. While indemnities have traditionally addressed third-party claims, both parties should provide a direct cross-indemnity to the other, although the breadth of their respective indemnification obligations will likely differ. Many parties will seek an indemnity for breach of contract but doing so cannot be justified as each party’s remedy should lie in a breach of contract claim.

Customers should seek to have the cloud provider indemnify them for:

• Intellectual property infringement claims arising from intellectual property selected and used by the cloud provider
• Compliance with laws
• Breach of confidentiality
• Breach of the agreement’s security obligations and standards by the cloud provider

In those situations where the cloud provider will not agree to indemnify the customer, the customer should seek to have the cloud provider pay for any costs associated with a party’s notification obligations under law or the terms of the contract. These may include investigating the breach, notifying the affected individuals and entities of any breach or security incident, staffing any help desk assisting with questions regarding the breach or security incident and the cost of any credit monitoring.

Model language for the cloud provider’s indemnity obligations follows:

Vendor will defend, indemnify and hold Customer and its respective officers, directors, employees and agents (each an “Indemnified Party”) harmless from and against all liabilities, damages, claims, costs and expenses (including reasonable attorneys’ fees and costs and expenses of expert witnesses) or other losses (collectively, “Losses”) brought by a third party against an Indemnified Party arising from the acts or omissions of Vendor, its employees, affiliates, subcontractors or agents in the performance of the Services.

Vendors should seek to have the customer indemnify them for:

• Intellectual property infringement claims arising from the customer’s content as well as any intellectual property selected and used by the customer
• Compliance with laws
• Breach of confidentiality
• Defamatory statements
• Violation of law
• Breach of the cloud provider’s Acceptable Use Policy (AUP) including non-compliance with the cloud provider’s security policy

Model language for the customer’s indemnity obligations follows:

You agree to indemnify, defend and hold Us, our affiliates and licensors, each of our and their business partners and each of our and their respective employees, officers, directors and representatives, harmless from and against any and all claims, losses, damages, liabilities, judgments, penalties, fines, costs and expenses (including reasonable attorneys’ fees), arising out of or in connection with any claim arising out of:

1. Your use of the Services in a manner not authorized by this Agreement, and/or in violation of the applicable restrictions, AUPs, and/or applicable law,
2. Your Application, Your content, or the combination of either with other applications, content or processes, including but not limited to any claim involving infringement or misappropriation of third-party rights and/or the use, development, design, manufacture, production, advertising, promotion and/or marketing of Your Application and/or Your content,
3. Your violation of any term or condition of this Agreement, including without limitation, Your representations and warranties, or
4. You or Your employees’ or personnel’s negligence or willful misconduct.

(x) Limitation of Liability

To understand and quantify its risk, the customer should undertake due diligence that includes a review of the cloud provider’s technology platform and security practices. Doing so will allow the customer to potentially mitigate any risks associated with the purchased services. By purchasing SaaS services, the customer is outsourcing a service that it did not want to provide itself as well as a set of operational, compliance, and legal risks that it did not want to assume. Thus, a cloud provider should not be expected to assume a risk that the customer itself was unwilling to assume, as the cloud provider is not an insurer of the customer’s risks.

It is in both parties’ interest to limit risk. The mere fact that personally identifiable information (PII) is exposed does not necessarily mean that the cloud provider (as opposed to the customer or a third party) did anything wrong or that it could have prevented the breach. Some industry commentators assert that no cloud provider (or government agency or non-profit) can guarantee against sophisticated intrusions and all technology failures. One solution may be to have the parties share any potential liability. Although the structure of any compromise is subject to negotiation, one compromise may be to have the cloud provider assume liability up to a certain dollar amount, with the customer assuming any excess liability.

Some breaches should naturally result in greater liability on the cloud provider’s behalf. If a cloud provider fails to follow its stated security procedures, there is justification to seek a larger or even unlimited liability. In many contracts, intentional actions impose unlimited contractual liability on the cloud provider’s behalf, at least after negotiation by knowledgeable customers.

The actual limits of liability will depend on the facts of the underlying transaction:

• What is the nature of the stored/processed data?
• Is the data highly confidential and proprietary, or a mere aggregation of data that may be re-assembled from other sources?
• To what extent does the data set include data owned by third parties who have entrusted it to the customer, who may have its own obligations and liability under such arrangements?
• How much revenue is the cloud provider receiving?
• How much risk is arising from the underlying technology platform?
• Is the customer utilizing a public or a private cloud?
• If the cloud provider offers premium services and/or additional security protection at a higher fee, has the customer elected same?

Almost all cloud providers insist on a waiver of any special incident or consequential damages and seek to limit the cloud provider’s liability to any service level credits. Any overarching cap is usually tied to a multiple of the monthly fees received by the cloud provider within a set time period, e.g. three months (though many customers will negotiate seeking longer durations). Common exclusions to the limitation of liability include intellectual property infringement, gross negligence, willful misconduct and some indemnification obligations.

Customers should carefully consider whether a disclaimer of indirect damages is appropriate, as in the event of a breach, a significant portion of the customer’s damages may be indirect damages. For example, the destruction or loss of data will result in substantial consequential or indirect damages. The sensitivity of the data in question will likely determine the importance for a customer to recover its consequential/indirect damages.

At least one court has voided a limitation of liability where the cloud provider acted in a reckless or grossly negligent manner resulting in a substantial loss of the customer’s data. Clark Street Wine and Spirits v. Emporos Systems Corp., Italy, 754 F. Supp.2d 474, 481–82 (E.D.N.Y. 2010) (“In view of great damage to customers and business that breaches of a computer system may cause, a jury may find that the responsible entities, such as [the cloud provider], should take special precautions to protect these systems.”).

(xi) Term

SaaS agreements often have a relatively short term as opposed to on premise licenses. Given the trend of failing prices over the last several years, a fixed priced, shorter term (1–2 year) cloud agreement is often favored by the customer.

Many cloud providers require buyers of subscription-based services to commit to purchase a minimum volume or dollar amount for a set period of time. In doing so, cloud providers argue that “revenue recognition” rules require the cloud provider to seek revenue minimums and committed term lengths to recognize the associated revenue. Contractual minimums also allow the cloud provider to recover its upfront research, development, infrastructure, and other service-enabling costs incurred in establishing the software availability. From the customer’s perspective, minimum commitments create the potential for significant financial risk. Therefore, prudent customers will seek to negotiate shorter minimum terms and favorable termination rights to ensure financial flexibility and avoid limiting their options.

(xii) Suspension and Termination

Most cloud providers insist on the contractual right to immediately suspend access or use of the services in the event the customer undertakes any actions that:

• violate the law,
• violate the cloud provider’s acceptable use policy (AUP),
• adversely impact the ability of other customers to use the service,
• access other customers’ data,
• spam,
• create offensive content,
• cause intellectual property infringement, or
• endanger the security of the system.

While most cloud providers will not relinquish the right of suspension, prudent customers often try to limit suspension solely to material violations of the underlying agreement that threaten the security of the cloud service. In addition, they seek to negotiate a notice and cure period for inadvertent violations to avoid an immediate interruption of the customer’s access to the services. While some cloud providers will agree to provide notice and a very short cure period, other cloud providers are unwilling to do so.

Some large customers take the position that the cloud provider may not terminate the agreement for any reason, including the customer’s nonpayment, arguing that the cloud provider’s remedy lies solely in a suit for breach of contract. Further, the customer’s access and use rights shall continue during the termination process. They do so in the belief that the services are mission critical and cannot be easily transferred to a new cloud provider. From the cloud provider’s perspective, the requirement to bring a suit delays its remedy and increases its costs while creating a significant administrative and financial burden.

Many customers seek the ability to terminate their agreement for convenience. While termination for convenience provisions are common in many services agreements, the customer’s ability to terminate the agreement and the cost to do so will depend on a number of factors, including the pricing model used by the cloud provider and the cost of any capital expenditures the cloud provider made on the customer’s behalf.

If the cloud provider is providing services under a metered model without a commitment, the customer may have the right to terminate the agreement for convenience, but under a subscription model, where pricing discounts are provided based on volume commitments that termination for convenience would negate, cloud providers are unlikely to accept a termination for convenience provision. If the cloud provider purchased hardware and software on the customer’s behalf, another factor that will impact the customer’s ability to terminate for convenience is the amount of any unamortized capital expenditures. In such cases, cloud providers will most likely require the customer to pay the cost of any unamortized capital expenditures as a condition precedent to any termination for convenience.

Also important from the cloud provider’s perspective, revenue is recognized ratably over the life of the contract, and if the contract may be terminated for convenience, the cloud provider will likely be unable to potentially recognize the total contract value to investors, lenders or other constituents.

If the underlying agreement provides the cloud provider the right to make unilateral changes to the parties’ agreement or the underlying application, the customer should insist on the right to terminate the agreement for convenience without charge in the event any such change has a material impact on the services purchased by the customer.

(xiii) Transition Rights

Perhaps the most important issue, but perhaps under-managed, for the customer is transition rights. In the event of the early or natural termination of the agreement, the customer wants to ensure an orderly transition of its business to a new cloud provider. Also known as the “Exit Strategy” or “Exit Plan,” most good customer Program Management Offices (PMOs) contemplate an exit strategy as a part of their Governance, Risk and Compliance (“GRC”) policy; that is, if they have a GRC policy.

The agreement should set out in detail the time period during which the cloud provider must provide transition support to the customer, the cost of such services and preferably the process for coordinating the parties (possibly including not only the end user and initial cloud provider, but also the successor cloud provider, if any). The cloud provider should be contractually obligated to provide services during the transition period at the same service level as it did during the agreement term and to fully cooperate with the customer during the transition of its data to an alternative provider or back in-house. In the event the agreement was terminated due to the customer’s breach, the cloud provider should strictly limit the length of any transition period to limit the time and effort it is required to exert in the transition effort and possibly require pre-payment including any professional services necessary to extract and migrate data to a new solution.

Finally, a prudent customer should ensure the underlying agreement sets forth in detail the customer’s rights upon the termination of the agreement and that any such transition will not interrupt its business. To that end, the customer should obtain:

• a contractual commitment regarding its right to continue to use the services during the transition period,
• the right to the immediate return of its data in the contractually agreed format so that it can be utilized by any subsequent cloud provider,
• an agreement on a rate card establishing the rates for any transition assistance fees, and
• a commitment to cooperate with any new cloud provider, preferably for a specified duration.

At the same time, prudent customers will want to require the cloud provider to retain their data for some period of time (30–60) days while they are identifying a new cloud provider or in transition. Cloud providers are hesitant to store data for any length of time due to the cost of storage unless they are compensated for doing so.

In the event the cloud provider is also providing a license to a specific application, the agreement should address ownership and use of the license after termination of the agreement. From the cloud provider’s perspective, the underlying agreement between the cloud provider and the customer should clearly state that the customer does not receive any rights for future use of the application and that upon termination, the customer’s only right is to port its data to a new cloud provider. If the customer purchased a software license as part of the services, the customer should be contractually entitled to transfer the license to the new cloud provider. At the time the agreement is negotiated the customer should understand its rights, including its transfer rights, if it is “purchasing a license.” Although the customer may have paid to “purchase” a license and the cloud provider granted the customer access to use software through a license, the license may terminate with the agreement and prohibit the customer from taking the software to the new cloud provider.

(xiv) Compliance Obligations

Customers often seek to transfer their compliance and regulatory obligations to the cloud provider. Prudent cloud providers will reject the customer’s efforts to do so, as the obligation legally rests with the customer, and the customer cannot escape its liability by contractually requiring the cloud provider to assume such obligations. Agreeing to assume such responsibility is very risky for the cloud provider as, in most cases, the cloud provider lacks the requisite industry knowledge to fully understand the risk it is assuming as well as the cost to comply with such obligations. This is especially true with consumer data laws such as HIPAA, where the cloud provider may not know the type of data being stored by the customer or the citizenship of the data owners.

(xv) Acceptable Use Policies (AUPs)

Acceptable Use Policies (AUPs) are used by cloud providers to establish the parameters of the customer’s access and use of the cloud provider’s network and services. The customer’s failure to abide by these requirements may result in the suspension of the customer’s ability to access the cloud provider’s network and services and in extreme cases the termination of such rights. Cloud providers usually set forth a list of prohibited activities which may include:

• Any activities that are illegal, that violate the rights of others, or that may be harmful to others.
• Content that infringes or misappropriates the intellectual property or proprietary rights of others.
• Content that is defamatory, obscene, abusive, or invasive of privacy.
• Content that may damage, interfere with, surreptitiously intercept, or expropriate any system, program, or data, including viruses, Trojan horses, worms, and time bombs.
• Actions that violate the security or integrity of any network, computer or communications system, software application, or network or computing device.
• Accessing or using the cloud provider’s network without permission, including attempting to probe, scan, or test the vulnerability of the cloud provider’s network or to breach any security or authentication measures used by the cloud provider’s network.
• Forging TCP-IP packet headers, e-mail headers, or any part of a message describing its origin or route.
• Monitoring or crawling of the cloud provider’s network that impairs or disrupts the cloud provider’s network being monitored or crawled.
• Inundating a target with communications requests so the target either cannot respond to legitimate traffic or responds so slowly that it becomes ineffective.
• Interfering with the proper functioning of the cloud provider’s network, including any deliberate attempt to overload a system by mail bombing, news bombing, broadcast attacks, or flooding techniques.
• Using manual or electronic means to avoid any use limitations placed on the cloud provider’s network, such as access and storage restrictions.
• Distributing, publishing, sending, or facilitating the sending of unsolicited mass e-mail or other messages, promotions, advertising, or solicitations (“spam”), including commercial.