The rapid digitization of business operations across all industries has made software as a service (SaaS) products increasingly popular. In exchange for these services, however, companies take on the risk of having their proprietary and customer data managed by a third party in the “cloud.” Negotiating a sound SaaS contract is an essential part of managing the risks involved in this arrangement. To discuss strategies and key provisions in negotiating these contracts, we recently brought in Priori network attorney Kevin Kuzas, a veteran technology and IP attorney. Here is what he had to say about both the provider and customer sides of negotiating SaaS agreements.
Asking the Right Questions
First, not all SaaS contracts are the same. There is a significant difference between a company whose entire business relies on the functional operation of the SaaS product and one that uses the product to simply funnel data into their company’s data storage bank – in other words, one that has nothing stored in the SaaS product. As a SaaS customer, understanding the role SaaS will play in business operations and the risks involved is essential. Sample questions to ask at the beginning of the negotiation process include:
What data will the SaaS vendor receive and process?
Does the shared data contain personally identifiable information such that privacy laws would apply? Is it competitively sensitive data such that a breach could be very expensive for the company? Does the SaaS provider retain copies of customer data? Does the customer intend to keep copies of its own data, or is it entrusting the data to SaaS providers? Answering these questions at the beginning of the process can help companies better understand contract value and negotiation strategy.
Does data cross-national boundaries?
The EU, for example, has a very different set of privacy protections from the US. Accordingly, any company that collects data that crosses national boundaries should understand whether the potential SaaS vendor is equipped to handle this.
What security does the potential vendor have in place?
Depending on the importance of the data and whether the SaaS provider is storing data, there can be significantly more variability here than companies often think. If relatively low-value data is going through a SaaS provider (in and out) companies can be relatively more flexible regarding security provisions. On the other end of the spectrum, if the data is the crown jewel of the company and will be stored by the SaaS provider, companies should expend significantly greater resources ensuring sufficient security.
One basic step all companies should consider is asking for a service organization control (“SOC”) report. Any reputable vendor should be able to provide a SOC 1 report (a financial audit). If the potential SaaS provider will store very valuable data, reviewing a SOC 2 report (a security assessment, which usually includes a technology security assessment) is a good idea. Finally, companies should ask whether the vendor has performed penetration tests.
What is the business situation of the potential vendor?
Understanding the business and financial situation (e.g., how long the vendor has been in business, company size, and its basic financials) of the vendor can help companies understand whether the vendor has the financial means and insurance coverage to back up negotiated indemnity clauses.
What are the specifics of the data center?
As an initial matter, it’s important to understand whether data will have a dedicated server or will be comingled with data belonging to other customers (comingling increases the risk profile of the contract – which may or may not be acceptable depending on the sensitivity of the data). Further, companies should know where the data center is located; whether there is more than one data center; whether the SaaS vendor’s system includes redundancies; and whether the SaaS vendor outsources its cloud. On this last point, while there is nothing wrong with the SaaS vendor outsourcing to a large company like Amazon or Microsoft, customers should be aware that such outsourcing will likely mean reduced negotiation power.
Moving Onto the Platform
The complexity of SaaS platform migrations varies – some are simple processes, others require significant development work. In this latter context, the SaaS contract morphs into a professional services contract as well because it contemplates the creation of intellectual property. Such an agreement needs to address payment for the customization service, IP ownership, and deadlines for these deliverables. Customers should also determine whether they can test out the product before committing to a five- or ten-year contract – particularly if there is any kind of customization contemplated.
Locking in Security Commitments Contractually
A company’s data might be worth $10 million, but that does not mean a SaaS provider will accept $10 million in liability for handling that data. Instead, companies can seek to lock-in contractual commitments for how SaaS providers operate, with corresponding remedies if such agreements are breached. One straightforward way to begin this portion of the negotiation is to request the potential SaaS provider’s security exhibit specifying how they protect data and what they do in the event of a breach. If the provider does not have an exhibit, the customer may need to write one (though customers writing their own security exhibits should take care that the stringency of their security exhibit is proportional to the value of the data being secured).
Handling Breaches: Notification and Fixes
Topics to be addressed regarding breach include: notification, timing, and remedies. How these are addressed will vary depending on how important the data is, but they should not be neglected. At a minimum, contracts should require the vendor to notify the customer promptly in the event of a data breach. The clause should specify who notifies those whose data was breached, who notifies press if necessary, who will work to stop the leakage, and the timing of these procedures. Further, depending on the type of data stored/breached and the customer’s particular industry, a variety of state and federal regulations may be implicated, so in some cases it may make sense to require the provider to notify customers even upon the mere suspicion of a breach to maximize time available to address the problem.
Negotiating remedies is also essential. This can be a tricky issue because in many cases, harm is reputational and, therefore, not measurable. Typical limitations of liability clauses exclude consequential damages, lost profits, and a laundry list of other items, including lost data. Whether this last exclusion is appropriate in a SaaS contract is up for debate, but in any case, the customer should try to be indemnified for third party claims, particularly when the breach is caused by a vendor’s non-compliance with an agreed-upon security exhibit. A breach to the security exhibit should be an exception to the typical cap on liability or consequential damages.
Service Level Agreements
When drafting service level agreements, customers should assess what is important to their operations – response to processing time, response to queries, ability to handle volume of queries – and create an SLA that is reflective of that. Additional elements to consider include:
Infringement Claims. In most cases, SaaS products operate through a cloud service as opposed to software installed on a computer. Despite this, there are still certain warranties, such as infringement claims, that carry over from software license agreements. A SaaS customer can infringe a patent by using, making, or selling an invention. Using is the obvious risk here, and it is the part of the provider’s cost of doing business to defend customers from claims against patent infringement. That said, if a newer provider does not have significant financials, the warranty is not worth very much. In such cases, or if the financials aren’t strong, the customer should secure insurance of their own.
Exit strategies. Related to SLAs are exit strategies. The first key step here is that SaaS users should define what is catastrophic. This could be a gigantic outage or a series of minor annoyances, but beyond a certain point, the customer should have a no-harm-no-foul exit strategy where the product is not working. Once a company has defined the exit moment, it’s important to remember that SaaS has a lot of stickiness to it as a product, so when things go wrong, customers are often stuck wondering what to do next. Exiting one of these contracts is not as simple as going from one product to the next; the process requires time, particularly because competitors are not always apples to apples. Companies may need to convert their data into a useful format in order to move from provider one to provider two. A good strategy here is to negotiate a wind-down period or transition services into the contract (including, potentially the provider’s obligation to port the data).
