[ad_1]
Companies procuring or providing Software-as-a Service (SaaS) technology need some form of contract to govern the relationship between the SaaS provider and customer. As with many intellectual property (IP) and technology contracts, SaaS contracting has unique considerations. Both customers and providers should understand and appreciate the key components of any SaaS agreement to efficiently finalize the procurement and sales cycle and streamline negotiations.
Understanding the intellectual property framework that underlies cloud-based technologies and the basic data ownership and management issues that must be addressed to engage in cloud contracting is a critical starting point. From there, companies providing or leveraging cloud-based services should be prepared to negotiate the key issues that, while relevant in many technology contracts, become front and center in nearly all cloud contracting agreements. Understanding the four concepts in this article will provide customers and providers in the SaaS space with a meaningful understanding of the challenges and opportunities around SaaS contracting.
Streamline the Structure
Cloud Services Agreements, Software-as-a-Service Agreements, Platform Subscription Agreements, Terms of Service, and even Master Services Agreements. It is likely that companies procuring SaaS and other cloud-based technology on a regular basis have agreements with these names that cover, largely, the same form of technology: access to and use of software applications via the Internet.
When companies first began procuring software, they did so under shrink-wrap, provider-favorable license agreements that were never negotiated (or even reviewed). With time, technology contracting shifted substantially in the customer’s favor and companies procuring any form of software or technology-related products and services did so under their own agreement templates with immensely detailed, customer-favorable terms. As remotely hosted, or cloud-based, software gained increasing market share, there was a period when companies continued to push their standard form agreements on technology providers, including shoehorning SaaS offerings into template master agreements for either software licenses or professional services.
Now, most large companies agree – with targeted exceptions for large scale outsourcings and in highly regulated markets – to use provider template agreements for entering into cloud-services engagements. The name and means of forming each cloud agreement varies substantially, including:
- Click-accept, online terms of service
- Ordering documents or quotes, with referenced online terms, or attached terms and conditions
- Traditional pen-and-ink (or, more likely, DocuSign) master subscription agreements with linked and/or attached exhibits, appendices, and addenda
Each of the contracting styles above are frequently littered with cross references to online service level agreements, support policies, privacy notices, terms of service, acceptable use policies, information security policies, and data processing addenda. The various cloud agreement documents generally cover the same subject matter, but lack the kind of consistent structure that can be found in most commercial agreements for professional services and on-premise software licenses.
From a cloud provider perspective, supplemental online terms can provide flexibility that aligns with the evolving nature of the cloud offering, while from a customer perspective, the combination of paper (or .pdf) terms with tiered systems of floating, online links to wade through can feel burdensome and unnecessarily complex. Cloud providers can achieve streamlined contracting in several ways without overwhelming customers and would be wise to make their contracting as simple as possible to expedite their sales process. Similarly, those customer business, procurement, and legal teams reviewing cloud services agreements need to be skilled in identifying the relevant contract documents and be adaptable to the varying approaches used by cloud providers in order to take advantage of the most innovative solutions for their industries.
Do a Deep Dive on Data
The data in play in any cloud contract is critical for evaluating the risk associated with the contract, establishing the parties’ respective obligations and responsibilities, and identifying the important – and sometimes legally required – contract terms related to providing, accessing, processing, analyzing, sharing, storing, and returning data. Companies providing and procuring any cloud service should be prepared to ask, and answer, the following questions:
What data is implicated as a result of the cloud service? Data may include publicly available information; business confidential, competitive, and operational data; consumer or employee personal information; and/or highly regulated data such as protected health information, financial account numbers, data relating to children, and government identifiers. The nature and source of the data will often be key for determining the appropriate risk profile and contractual terms.
Which party owns the data? The answer may not always be clear. Cloud services may rely on or include data from individual customers, aggregated customers, third party data providers, or data that the cloud provider creates or aggregates itself as part of the service. The most common and straightforward approach is that customers own the data that they input into the cloud service, and any data provided by third parties or the service provider is subject to a specific, limited license use.
How will the data be used? Commonly, data used by a cloud service serves different purposes. One purpose is where a particular business function is the subject of a cloud service, and the service processes data in connection with performance of that function. Another purpose is where the cloud service relates to data itself, and the cloud solution aggregates, analyzes, and/or stores the data in connection with that purpose. Cloud providers often obtain a license to use that data to provide the service. Customers, however, need to understand and be cautious of any supplemental licenses that cloud providers receive in return, to both individualized usage data (i.e., how the customer uses and interacts with the functions of the service) and aggregated customer-provided data (i.e., the individual data elements that the customer processes through the service, aggregated with similar data provided from all other customers of the cloud service). Aggregated data provisions may violate specific regulatory requirements, such as HIPAA, or grant a cloud provider with access to and commercial use of strategic, competitive information about a business. Many cloud providers are using artificial intelligence and machine learning when exercising their rights to analyze customer data, and customers need to understand, assess, and, perhaps, prohibit that use when critical IP and sensitive data are involved. Once an artificial intelligence system has learned from and incorporated data or intellectual property from a customer source, those learnings cannot be undone or exfiltrated from the system.
The questions above are not exhaustive, and the answers often spark more nuanced discussions about data ownership, access, use, retention, return, location, and security in connection with the cloud service.
Align on Availability
The availability of a cloud service is arguably one of the most important terms of any SaaS contract and yet it is rarely included in the proposal, quotation, ordering document, or even the body of the cloud agreement. Instead, availability commitments – if made as commitments at all – are relegated to attachments or online terms called service level agreements (SLAs). Availability is typically stated as a percentage or, more casually, as a number of “9s” – commonly 99.9% (“three nines”) or 99.99% (“four nines”) and is a critical business and operational component of any SaaS contract.
Under a reasonably standard and easily understood approach, a SaaS offering may be “available” when it is capable of being accessed and used by customers in accordance with its documentation and may be “unavailable” when it is not. Availability is then calculated based on the number of minutes during which the service is unavailable out of the total potential number of minutes in the measurement period (typically one month and occasionally one quarter). There are standard exceptions, such as scheduled and emergency maintenance and failure of customer-side internet access or equipment that are removed from the calculation of whether a service is available. There are also an increasing number of creative alternatives and exceptions to the definition and calculation of availability, including requiring multiple attempts by a customer to access the service, segmenting availability based on various components of the service, and providing that a service cannot be considered “unavailable” unless a customer affirmative seeks to use it, cannot do so, and formally reports the outage to the provider. Longer measurement periods, lower availability percentages, more nuanced definitions of “available,” and a greater number of exceptions tend to favor suppliers, making the availability more achievable, while higher availability percentages, transparent reporting on ongoing availability, and crisp definitions of “available” tend to favor customers. Customers and suppliers should consider which party is responsible for tracking and reporting on service level failures, particularly where an SLA provides for no remedy unless the customer identifies and reports the outage within a specified period.
SLAs often provide a remedy for failure to meet the availability percentage in the form of service credits. Service credits are not typically intended as a penalty to the supplier, but rather a means of capturing the value of the degraded availability of the service. Customers reviewing SLAs should be cautious on whether and how service levels are described as the sole and exclusive remedy for an availability failure and, in particular, whether the language in the SLA could be interpreted as foreclosing any opportunity to terminate an underlying agreement where the SaaS technology is not operating.
While SLAs, or portions of SLAs such as the set availability percentage, are often drafted and supplied on a “non-negotiable” basis, it remains important for customer and supplier teams to understand the intended use case for the service and whether there is any specific use case for an individual customer that is impacting service level discussions. When software is accessible only through the internet, it can be critical for customer-side business teams to understand and consider the operational risks to the organization if the cloud service becomes unavailable for any meaningful period.
Capture Critical Contracting Concepts
While there is often focus on the structure of SaaS contracts, availability metrics, and – rightfully so – the rights and protections around data, core contracting concepts are still highly relevant to the SaaS world. The critical focus areas for legal teams drafting and reviewing SaaS contracts include the license or permitted use of the service, and the core legal terms such as warranties, indemnities, limitations and disclaimers of liability, and confidentiality. Providers in the cloud-services space using creative or layered approaches to SaaS contracting will find the most success when they also provide clear, meaningful protections to customers that address the key legal and operational risks that arise in any technology supply agreement.
To read additional articles from the Clear Skies Through the Clouds series, please click here.
[ad_2]
Source link