What’s Missing from My Software as a Service (SAAS) Agreement? (Part 2)
As customers continue to embrace Software as a Service (SAAS) solutions that are hosted in the cloud, rather than traditional software solutions that are loaded onto and hosted on the customer’s own environment, they should closely review the contract that will govern their relationship with their SAAS provider. Frequently, we see SAAS contracts that are missing certain basic (and key) requirements that serve to protect SAAS customers.
In Part 2 of our two-part series, we continue our list from Part 1 of the critical contract protections that SAAS customers should keep in mind, before signing any SAAS agreement. Alternatively, if a customer already has a SAAS agreement that omits any of the following terms, the customer should explore amending its current agreement to include these protections, during its next contract renegotiation.
Who May Use the SAAS Solution? SAAS customers should think about who they need to access and/or use the SAAS solution. SAAS agreements frequently place limits on those who are allowed to access the solution. Make sure that the contract allows access and/or use by all of the necessary categories of users. Will the persons accessing the solution only be employees of the customer? What about employees of a customer’s affiliates? What about a customer’s customers – are there any VIP, downstream customers who need access rights? And what about agents, subcontractors and independent contractors, whether they work for the customer itself, an affiliate, or a customer’s customer? (More about the last category directly below).
Don’t Forget Technology Partners and Outsourcing Suppliers Many companies currently rely on a third party supplier to provide and/or support their IT services. Many times, those third party IT suppliers need the ability to access a customer’s technology solutions (including SAAS solutions), not necessarily to use the functionality per se, but in order to provide technology support to the customer. For example, a third party and/or outsourced technology provider may need to access all solutions that interact with the customer’s core IT suite of services, in order to perform troubleshooting or problem analysis and resolution with respect to the customer’s IT environment. SAAS customers should keep this in mind, if applicable, and make sure that the SAAS contract allows such access by the customer’s third party IT provider, in its role supporting the customer.
Virus Protection Since the SAAS solution will be hosted in the cloud on technology and servers that are external to the customer’s standard IT environment, customers should make sure that the SAAS agreement includes clear protections against viruses. Make sure the SAAS provider will utilize necessary virus-prevention software and/or technology solutions. Make sure that the SAAS provider agrees to attempt to prevent viruses from being loaded into the SAAS solution and into the customer’s own standard IT environment. And make sure that if a virus is introduced, that the SAAS provider will take appropriate steps to reduce the effects of the virus. SAAS contracts occasionally include language limiting the steps a SAAS provider must take to respond to a virus, until it is clear that the virus originated from the SAAS provider itself. Customers should think carefully about any such provision – is it more important to respond to the virus quickly or to spend time attempting to identify a root cause? Many customers expect immediate steps to be taken to respond to the virus, and for root cause analysis to be performed later, after the effects of the virus are reduced.
Protection Against Infringement Although a SAAS customer does not host and operate the SAAS solution like traditional software, the same concerns exist with respect to infringement that arise when analyzing software contracts. If the SAAS solution is found to be a solution that infringes upon a third party’s intellectual property (or if a third party alleges that the SAAS solution infringes its intellectual property), the SAAS provider should protect the SAAS customer against any resulting damages. Confer with legal counsel for specific protections, as these concepts are complicated. However, as a high-level matter, the SAAS provider should clearly guarantee to the customer that the SAAS provider owns (or appropriately licenses) the SAAS solution, and that it will indemnify and make whole its customer for any infringement claims related to the SAAS solution.
Are Limitations on Subcontracting by the SAAS Provider Necessary? SAAS customers should consider whether limits on the SAAS provider’s ability to subcontract its services are necessary, whether because of regulatory restrictions or policies internal to the customer. Are there restrictions on who may host the customer’s data? If yes, then the customer does not want to realize two years after signing its contract that the SAAS provider is no longer hosting the servers that support the SAAS solution, but it has turned over that function to a third party that presents problems for the SAAS customer. Are specific restrictions against subcontracting necessary? Or is it simply that the customer needs the right to review and provide reasonable approval over any new subcontractors? If “approval” over a future subcontractor is nor realistic (for example, a SAAS provider may not want to obtain the approval of all 1000 of its customers, just because it is changing a particular subcontractor), then is it possible for the customer to walk away from the contract, if a newly proposed subcontractor presents significant problems for the SAAS customer?
Protect Customer Data Stored Within the SAAS Solution If the customer’s confidential information, sensitive data and/or personally identifiable information will be stored within the SAAS solution, a whole host of data protection issues arise. At a high-level, the customer should make sure that the contract (1) makes clear that the customer owns its own data, (2) includes strong protections against the release or transfer of that data, (3) describes the specific steps that will be taken if a security breach occurs or is suspected, and (4) includes guarantees that the customer will receive its data back, at the end of the contract. Customers also should consider if they need the right to audit the security and privacy procedures implemented by the SAAS provider. Finally, if the SAAS provider is backing up the customer’s data, the contract should make clear how quickly it takes to load backed-up data, after a disaster occurs (the “Recovery Time Objective”).
The topics explored in Part 1 and Part 2 are addressed at a high-level and not particularly nuanced, but SAAS customers should raise these issues with their supplier and their legal advisor so that the necessary provisions and contract language can be inserted into their SAAS agreement to appropriately protect their business.