Software as a Service (SaaS) providers need a well-drafted SaaS Agreement to properly set up their relationship with their customers. At its core, the SaaS Agreement serves as the linchpin of the relationship between the SaaS provider and its customers. It outlines the terms and conditions governing the customer’s access to and use of the SaaS platform.
But the standard SaaS Agreement may not be sufficient to fully encapsulate the relationship between the SaaS provider, the customer, and the customer’s authorized users.
This article is the first in a series of articles to dive into key terms of the typical SaaS Agreement, as well as the additional documents that can address important topics not traditionally covered by the SaaS Agreement. Read on for an introduction to the set of documents that round out the SaaS Agreement.
Users often ignore terms of service (TOS) by quickly scrolling and clicking "I accept." However, the TOS can be a vital link between SaaS providers and the individual authorized users of SaaS platform customers.
The TOS details the rights and responsibilities of authorized users. For example, the TOS may identify the types of actions that are prohibited on the SaaS platform (uploading obscene content, abusing other users, etc.). The TOS may also confirm the licenses granted by the authorized users to the SaaS provider if, for example, authorized users are able to upload and share content. Perhaps most importantly, the TOS clarifies that the SaaS provider’s liability to authorized users is limited, and any disputes should be handled through the customer.
Some SaaS providers prefer to forego the TOS and rely just on the SaaS Agreement with the customer. Under this strategy, the SaaS agreement requires the customer to ensure all of its authorized users comply with the SaaS Agreement. The SaaS Agreement will include many of the restrictions/obligations on authorized users you would typically see in a TOS.
This strategy can work, but the TOS enables the SaaS provider to “speak” directly to the authorized users and tailor the language for that audience. This can be really beneficial, especially if there are unique rules that the SaaS provider wants authorized users to acknowledge.
In certain instances, the TOS may serve a dual purpose as the traditional TOS for authorized users, as well as the SaaS Agreement for customers. We regularly see this as SaaS providers evolve from catering to individual users to accommodating enterprise-level customers. This dual structure can be an enticing way for young SaaS providers to dip their toes into enterprise-level contracts.
However, this hybrid document, while efficient, can blur the lines between authorized user obligations and customer obligations. Any SaaS provider going this route should ensure that their ToS/SaaS Agreement hybrid is clear about the audience for each provision. Many highly experienced SaaS providers choose to retain this hybrid structure, even once they have sufficient resources to manage different contracts for authorized users and customers.
SaaS providers are required by data privacy laws (in the United States and internationally) to have a privacy policy for their platform. The privacy policy outlines how the SaaS provider collects, uses, discloses, and protects user personal data.
In the US, data privacy laws exist at the federal and state level. They cover different industry sectors, categories of users, and jurisdictions. Data privacy laws are not always consistent about what information should be included in a privacy policy.
In addition, the requirements for a privacy policy may vary depending on whether the SaaS provider has a direct relationship with individual users or only has an indirect relationship with individual users as a result of an agreement with the customer. As a result of all of these factors, the simple concept of a privacy policy can actually be easy to mess up for a new SaaS provider.
Privacy is an increasingly important concept to today’s individual consumer, and many data privacy laws impose significant fines for violations, so the policy should not be dismissed by a SaaS provider as an afterthought.
Just as data privacy laws require SaaS providers to provide a privacy policy, those same laws may also require for SaaS providers to sign a “Data Processing Agreement” with customers. The DPA typically arises in scenarios where the SaaS provider is processing user information on behalf of its customers. Personal data collected will vary depending on the nature of the
SaaS platform, but might include email addresses, phone numbers, photos, social security numbers, IP addresses, payment information, etc.
The customer is legally required to ensure the SaaS provider guarantees the customer about the SaaS provider’s handling of personal data. Those guarantees are typically handled in the DPA. For example, the SaaS provider typically promises to only use the personal data as necessary to provide its products or services to the customer. Providers also often promise to only engage vendors that agree to similar contractual promises.
As with the privacy policy, data privacy laws vary in what they expect the DPA to cover. Some DPAs are written to cover only what is required by law. But, some DPAs are written to be incredibly protective of the customer and go beyond what is required by law, which can be unnecessarily onerous on the SaaS provider.
Ideally, the SaaS provider has its own DPA that its customers can sign. But, to the extent any customer requires the SaaS provider to sign the customer’s version of the DPA, it should be carefully reviewed to ensure the SaaS provider is not agreeing to anything that it can’t actually commit to.
Some SaaS providers offer custom development services for customers. These services, which go beyond the standard SaaS platform services, are sometimes referred to as “professional services”. Any SaaS provider that offers professional services should ensure their SaaS Agreement contemplates the possibility of professional services, and includes sufficient protections for the SaaS provider.
At a minimum, the SaaS Agreement (or a separate agreement) should set up a “Statement of Work” structure in which the parties can clearly agree on the scope of the professional services, the expected deliverables, the timeline for development, and any fees.
Professional services within the SaaS platform context raise interesting questions.
For example, who owns the rights to the deliverables that result from the professional services? If the deliverables consist of unique functionality built into the SaaS platform, perhaps the SaaS provider should own the rights to those deliverables, since they can’t exist outside of the context of the SaaS platform.
However, if the deliverables are independently viable outside of the SaaS platform, the customer may expect to own the rights. Ownership should be made clear either in the SOW or in the overarching agreement.
The SOW structure provides a lot of flexibility for the parties to address any unique considerations that apply to the professional services. The SaaS provider should take the time necessary to think through all of those considerations and any risks that may need to be addressed.
Without a properly customized SaaS Agreement and associated documentation, the risks of disagreements with customers and violations of applicable law (especially on the privacy front) are much higher. These disagreements can impede business operations and strain relationships with customers.
SPZ can work with you to tailor your SaaS agreement and related documents to your specific needs, so that you can spend more time focusing on growing your business and keeping your customers happy. We have other articles in this series that do a deeper dive into the SaaS agreement and the other documents mentioned here.
If you need help creating SaaS agreements and related documents for your startup, get in touch with us.