Key Provisions in a "Software as a Service" Contract: What Every Customer Should be Negotiating
ISSUE: Cloud computing is very tempting: cheap and flexible. But it has risks, some of which you can guard against in your SaaS contract.
SUMMARY: The key points to address are uptime, service standards, and related remedies and data security.
Software as a Service (or "SaaS"), also referred to more generically as "cloud services" or "cloud computing," allows an enterprise to store its data and/or its applications on a network and other resources owned and administered by someone else. The advantages of this approach are obvious: your business won’t have to maintain and pay for its own hardware, data and applications can be accessed anywhere in the world, and the cost-savings are dramatic. In fact, according to a recent survey, six out of ten U.S. companies already have at least one application in the cloud. Translation: if you aren’t currently utilizing cloud services, you likely will be in the very near future. However, before signing on the dotted line, it is critical that you address several key terms in the SaaS contract.
The SLA
Most contracts for services include at least a minimal performance warranty (e.g., “services will be performed in accordance with the highest standards of the vendor’s industry”). However, cloud services, especially when supporting a business critical function, should be provided with a definitive service guarantee. This guarantee is usually described as a service level agreement or an “SLA.”
Up – and down - times
Every SLA should specify when the customer’s data or application will be available for access by the customer (and any third parties if applicable). Typically referred to as “availability” or “uptime,” an SLA obligates a service provider to meet a minimum standard of availability as a percentage of time (e.g., 99%) measured against either a 24/7 commitment or a certain lesser period of time (e.g., between 6am ET and 10pm ET). Further, uptime guarantees are usually qualified by exceptions for scheduled and emergency maintenance.
Response times
In addition to guaranteeing availability, frequently an SLA will establish time frames during which a vendor will respond to customer complaints about performance. The response times usually correlate to the seriousness of the reported problem, so the more serious the problem (usually measured as a “severity level”), the quicker the response time. For example, an SLA should require the vendor to respond more quickly when a payment application is not processing credit card payments than to a customer complaint that the background color of the user interface is orange instead of red.
“Fix” times
Of course, simply responding to a complaint is less useful than to the vendor’s promise to fix reported problems within a specified time frame. If you can get it, an SLA for problem resolution would require the vendor to fix a problem within an agreed upon period of time that correlates to the severity level (e.g., a severity level 1 problem must be fixed within three hours while a severity level 4 problem has to be fixed within thirty days). However, for obvious reasons, vendors typically won’t agree to guaranteed fix times. An alternative is for the vendor to agree to continuously exercise “commercially reasonable efforts” during certain time frames to make certain fixes within an agreed upon period of time. As a practical matter, you may be comforted by the fact that the vendor is likely going to be anxious to fix any major problems as soon as possible, especially if other customers are facing the same problem.
Remedies
What happens if the vendor doesn’t meet its service obligations? Unless you negotiate something different in the SLA, your sole remedy typically will be termination for breach, which is problematic for two reasons. First, the typical breach provision includes a cure period, and most cure periods, unlike SLA obligations, are measured in days, not minutes or hours, rendering the termination threat moot. Second, even if you have the right to terminate, frequently termination is not your best option: you will have to rush to find a new provide and negotiate a new SLA, all while suffering from additional downtime. And to add insult to injury, your first provider’s help will be needed during the transition for which it will happily charge a hefty “standard” hourly rate.
For these reasons, your SLA should define remedies that are something short of the crude “nuclear option” of termination. For instance, consider setting fines to be credited against future payments, or, if the vendor has been paid up front, used for a prorated refund. These financial damages could be based on a formula tied to the applicable level of severity and the length and/or frequency of the failure.
Another option is to define your right to terminate upon the occurrence of a certain number of SLA breaches within a certain time period (e.g., five severity level 1 breaches in a single thirty day period) and then require the vendor to provide free assistance or a certain number of hours of free assistance during your transition to a new service provider. In fact, try pushing for a provision that requires the vendor to provide free or discounted transition assistance if you need to terminate for any vendor breach (SLA-related or otherwise).
Process
Even though most vendors do have a standard SLA (and may even provide in it for customer remedies), they usually don’t include the SLA in the first draft of the contract they send you. So, even before reviewing the service provider’s contract, ask for the standard SLA.
Once you get it, feel free to negotiate. Like any form document in a complex industry, the “standard” SLA was written to benefit the vendor, not the customer, so read it carefully. Of course, as in any negotiation, the more money you are committing to spend, the greater flexibility the vendor will have. In other words, you should not expect to get a strict, tightly structured SLA with financial penalties if the agreement is for $1,000 / month, terminable at any time you choose.
Data Security and Privacy
Before you even get to the contract and service terms, a key area of investigation is the level of security the provider uses to protect customer data and applications. If the vendor has a good reputation and good systems generally, then you can focus in the service contract on getting the security commitments in writing.
- First, the vendor should warrant that
- it has a security plan (which the vendor should provide during customer due diligence and agree to provide any time it is updated)
- it will abide by the security plan
- the services are audited on a regular basis in accordance with a particular standard (e.g., AICPA’s Statement on Standards for Attestation Engagements No. 16), and
- the services are provided in compliance with all applicable laws -- note that applicable law should not be limited to federal law because almost every state has its own data security breach laws as well.
- Also, the vendor should agree to provide you immediate notice of any security breach (although many service providers are reluctant to notify customers until the vendor has performed its own investigation); and a written copy of the results of the investigation of the breach. Ideally from the customer perspective, the vendor also will agree to grant you access to the vendor’s network to the extent necessary to perform your own breach investigation.
- Finally, if third parties, such as your customers or other vendors, will access the data or application, you need to be sure that the agreements with those third parties governing their access reflect the relevant terms of your agreement with the service provider. In other words, your commitment to your customers about service levels and security should not be greater or more stringent than those your vendor provides to you.
Other provisions
In addition to traditional contract provisions, such as indemnification and limitation of liability, cloud services raise a host of other unique legal considerations, including privacy issues (e.g., what type of data is being stored and for how long and who is accessing it); and export and jurisdictional matters arising out of the location of the cloud servers, which can trigger export control laws (e.g., if the provider servers are located outside of the U.S., storing of data abroad may trigger a legal obligation) and subject your data to the laws of the jurisdiction in which a server is located.
Of course, the term “cloud services” encompasses a variety of other offerings as well, including the provision of computing capability (Infrastructure as a Service or “IaaS”), computing platforms (Platform as a Service or “PaaS”), and data for access by applications (Data as a Service or “DaaS”), and while this article focuses on key SaaS agreement provisions, many of the concepts described herein are transferable and applicable to these and other “as a Service” cloud models.
Conclusion
The SaaS platform presents potential risks (and rewards) to a customer as well as a broad range of legal and business issues. Therefore, it is essential that your technical personnel understand the SaaS offering and that your lawyers carefully review and negotiate the SaaS contract. If the vendor will not negotiate the terms, the customer should consider another vendor, or, at the very least, enter into the contract with eyes wide open to all of the associated risks.