Last month, Priori network attorney Rich Vicenzi led a roundtable discussion for SaaS providers on tips for negotiating SaaS agreements with SaaS customers. Here is a recap of what he discussed.
A Service, Not a Software
Customer rules of engagement are different when working with service providers versus software providers – and SaaS providers should see themselves as service, not software providers. SaaS providers tend to see this perspective play out in the checklists customers use during negotiations. In such negotiations, SaaS providers should expect to face service-type questions, including customization, data security, compliance with regulations applying to customers, and liability.
The specifics of Service Level Agreements (SLAs) in SaaS agreements depend on the type of application or software provided. For a product that demands high availability on the part of the vendor, customers generally ask for so-called “five nines availability” (99.999%). Other products, such as a password management software, can often get away with lower levels of availability – particularly in cases in which a local version of the software remains operable and useful even when the broader system encounters a problem.
Customization is a frequent area of negotiation for SaaS providers. Though it’s understandable that customers want a customized SaaS product or assurances that no changes to the product will be made absent affirmative consent, it’s generally unrealistic for SaaS providers to accommodate these kinds of requests. SaaS is inherently a one-to-many model; the provider delivers the same product and service to every customer. This keeps the price consistent and the product efficient for all users, but also means that customization, if any, should generally increase the price of the product. Further, anything that restricts the provider’s ability to deliver the service – for example, any limitations on which personnel are authorized to work behind the scenes under the agreement – should generally be excluded.
All this said, certain areas of customization may be inevitable – for example, a customer requirement that the provider put the source code to its software in escrow to protect against the eventuality that the company goes out of business overnight. Though this is an impractical request (source code without the appropriate environment is essentially useless), it has become an absolute requirement of some customers that providers must accommodate.
Requiring compliance with the regulations applicable to the customer’s (rather than the provider’s) industry should also be considered within the category of customization. Generally, it is not the SaaS provider’s responsibility to have in-house expertise regarding the rules and regulations applicable to each customer’s industry and within each customer’s jurisdiction. From this perspective, providers should be wary of contracts that allocate liability to the SaaS provider for a customer’s noncompliance stemming from use of the vendor’s product. One generally successful negotiating technique here is to have a conversation with the customer detailing what will be required for the provider to gain the necessary expertise of industry laws and explain what risks the customer would be adopting by allowing a non-expert outsider to the company to assume the company’s duty of compliance. If the customer nevertheless insists on such a liability shift following this discussion, the SaaS provider can, in turn, require a clause stating that the customer will advise the provider on every law, rule and regulation applicable to such customer. As with other forms of customization, in such cases, vendor price increases should be considered given the additional work and liability assumed under such a contract.
A few areas of contractual liability merit particular scrutiny by SaaS providers:
The legality of customer data. Because SaaS providers host customer data, there are situations in which providers may be held liable for the content of that customer’s data. For example, if a customer’s data contains illegal or infringing content, the vendor could take on contributory liability, particularly if the website hosting the product is publically accessible. A simple way to reduce this risk is to require a customer representation that its content doesn’t infringe third party rights and to include an indemnification clause for the benefit of the provider covering cases in which the provider is brought into an action because of the content of the customer’s data.
Breaches. It’s simply not possible to make a SaaS product 100% secure. Accordingly, contracts should indicate that SaaS providers will take reasonable safeguards to protect the customer’s data, but guaranteeing security is unrealistic and shouldn’t be included. While security breaches may be contractually defined as any breach to the system, whether or not at the fault of the SaaS provider, remedies should only apply when the SaaS provider is at fault and has breached their contractual obligations. Instead of taking on unconditional liability for breaches, SaaS providers should consider a clause stating that in the event of a breach, the provider will take steps to find out what caused or allowed the breach and commit to take steps to fix the problem or vulnerability.
Liability caps. Another difficult topic to address in SaaS agreement negotiations is limitation of liability. Frequently, customers agree to a liability cap with respect to breaches for which the vendor is not at fault, but insist on uncapped liability for breaches where the SaaS provider is at fault. Certainly, breaching a contract should have ramifications, but such uncapped liability puts the company at risk of bankruptcy simply due to one mistake. Here, it’s important to remind the customer that SaaS providers are not insurance companies. Providers do the best they can, but mistakes happen. Setting liability caps for data breaches at various multiples of fees paid by the customer has become more common, but companies should never agree to unlimited liability – especially in the data breach context because everything can be hacked. Note that data breach insurance can help mitigate the cost of liability, but if a data breach occurs, it’s likely to impact many customers simultaneously, and liability – particularly uncapped liability – can easily exceed insurance policy limitations.
Data backup and restoration. Liability around data backup and restoration depends on how your system is set up and how the customer gets their data. For systems in which the customer can download its data anytime, there is less liability. If the SaaS provider, however, is the only source of the data, customers may want assurance of periodic data backups so that if the system goes down, the data exists somewhere relatively accessible. Here, the important thing is for SaaS providers to agree only to whatever level and frequency of backup is permitted by such provider’s systems. Often once customers understand a provider’s system capabilities, they become comfortable with those measures.
Insurance. Cyber security insurance is a good way to handle many of these risks – and, increasingly, SaaS customers are beginning to require such insurance.
About Rich Vicenzi: Rich Vicenzi has over 20 years’ experience in corporate and commercial matters. An ex-IBM attorney and the former general counsel at MakerBot Industries, Mr. Vicenzi’s practice spans a broad range of legal areas, including 3D printing, software/SaaS, information technology, cloud/e-commerce/internet of everything, media/publishing, content/microcontent & data licensing, intellectual property, data privacy & security, product development & marketing, procurement, litigation, mergers & acquisitions, financing (debt & equity), employment, contract negotiation, and real estate matters.