What’s in this SaaS agreement?
The fundamental obligation of the provider under the SaaS agreement is to make its software accessible to the customer via the internet as a service. The customer is granted a licence to use that software, subject to a set of restrictions and prohibitions that can be tweaked for each individual case.
The provider may also be obliged to provide support services, and to ensure that it complies with certain requirements in relation to the maintenance of the software (for example, notice requirements).
The data supplied by the customer are the property of the customer and, insofar as such data are personal data, are subject to a standard GDPR-friendly data processing clause. The customer data may be specified to be confidential.
In consideration for the undertaking to provide the services, the customer agrees to pay to the provider the relevant charges and to ensure that the customer data will not create any liabilities on the part of the service provider.
What legal documents do I need for my SaaS or cloud service?
There are five main classes of document you should consider:
- terms of service;
- privacy policies;
- terms and conditions of website use;
- end user documents; and
- intra-customer and intra-user documents.
First, you need terms of service – although they might be called something else. They might be called the “user agreement” or the “cloud service contract” or something different entirely. This SaaS agreement, our SaaS terms and conditions and our cloud services terms and conditions are all examples of terms of service documents. Whatever the document is called, its function is to regulate the legal relationship between a service provider and its customers. The terms of service will contain provisions covering the core services obligation, the payment of charges, the term of the contract and its termination, the parties’ liability to one another, and so on. In some cases, the terms of service will be supplemented by additional subject-matter specific documents, such as data processing agreements and service level agreements.
Third, if your website is not coterminous with your service, you will need terms and conditions to cover the use of the website. See our free website terms and conditions for more.
Fourth, for many B2B services and for some B2C services, there may be users of the service who are not your customers and therefore not directly bound by the terms of service. In these cases, you may want to introduce additional documents which are binding upon both customers and non-customer users. Examples of this type of document include end user licence agreements and acceptable use policies.
Fifth, a minority of SaaS and cloud services allow users to create contractual relationships with others – for example marketplaces for services, physical goods or digital goods. In some cases, it may be advantageous to provide standard documentation to govern these relationships. The documentation can be provided as mandatory or default documentation. In all cases, you should carefully circumscribe your liability in relation to the provision of any such documentation: you are not acting as your customers’ lawyer.
Who should prepare my SaaS or cloud agreement?
The core Docular business is the sale and supply of templates. Nevertheless, we think that there are many circumstances where you should use a lawyer rather than a template legal document.
In one sense a template isn’t a substitute for a lawyer. Lawyers also work from precedents. By opting to use a template, you are taking on the lawyer’s role.
Before using a template, businesses should ask themselves: is the use of a lawyer commercially justified?
Deciding whether it makes commercial sense will involve balancing risks and costs. Ask yourself the following questions.
- What are the risks associated with this contract?
- To what extent would a good lawyer help me to mitigate those risks?
- Do I have access to a lawyer with the right experience?
- Do I have access to appropriate templates?
- Will a lawyer help smooth the contracting process?
- What legal fees will I have to pay?
- How much time would it take me to prepare the document?
Only by considering these and other relevant factors will you be able to make a sensible assessment.
If you do decide to use a template, you should keep that decision under review. For example, it might make commercial sense to use a template for a new and untested service. However, if the service starts making significant amounts of money, you should engage a lawyer to review, advise on and update the document.
How should I go about choosing a template document?
Once you have decided to use a template for your cloud service or SaaS contract, you need to decide which template. There are three main aspects to suitability: execution style, structure and content.
Execution style: will your document be agreed online or offline or both? How, specifically, will it be executed or agreed? Our SaaS agreement documents (including this free template) assume offline agreement, whereas our SaaS terms and conditions documents are agnostic, allowing for both online and offline agreement via a services order form. Our cloud services terms and conditions assume there will be an online sign-up process.
Structure: will your document create a single contract with each customer, or could there be multiple contracts? In the case of a single contract, are different elements of the services independently terminable?
Content: what is actually covered by your document? The types of clauses you might find in a long-form SaaS contract are listed below. Ensure that the template you choose covers all or most of the necessary subjects.
- Definitions of special terms
- Contract term and termination
- Set up / configuration services
- Development services
- Hosted / cloud services
- Support and maintenance
- Service levels
- Acceptance procedure
- Acceptable use
- Customer obligations, data and systems
- Mobile applications and other installed software
- Representatives, management and change control
- Charges, expenses, timesheets and payment processes
- Confidentiality and publicity
- Data protection
- Warranties and indemnities
- Limitations of liability
- Insurance requirements
- Force majeure
- Effects of contract termination
- Export restrictions
- Non-solicitation / non-compete
- Contractual notices
- Assignment, waivers, severability, third party rights, entire agreement
- Law and jurisdiction
- Alternative dispute resolution
How is liability limited in SaaS / cloud terms of service?
The essence of cloud services is efficiency through standardisation: all customers using a single instance of an application, with uniform support and maintenance arrangements. This standardisation is reflected in the contractual sphere by the use of non-negotiable terms of service. Where terms of service are non-negotiable, they will usually say a good deal about the protection of the interests of the services provider, and relatively little about the protection of the interests of customers.
However, if you run a small services provider selling to enterprise customers, you will know that even if an enterprise customer’s procurement team are interested in purchasing a standard product, their legal team may be unwilling to accept standard legal documents. They will give particular attention to the provisions of your terms and conditions dealing with liability.
In this category – liability provisions – I would include the following.
- Warranties, which assert that particular facts are true, and if proven false may ground a claim for damages. For example, a services provider may warrant that its software does not infringe any person’s intellectual property rights.
- Limits of liability, which seek to reduce the amount of a claim in the event of a breach of warranty or another breach of contract. These may restrict recovery of particular types of loss (for instance, reputational damage) or losses arising from a particular cause (for instance, losses caused by third party services providers). In addition, they may apply one or more caps to the amounts which may be claimed. Commonly, such caps are set by reference to charges under the contract and/or available insurance coverage.
- Indemnities, which seek to extend the indemnifier’s liability beyond that arising out of a breach of contract. For example, a services provider may be asked to indemnify the customer in relation to any allegations and claims that software infringes intellectual property rights, whether or not it does in fact infringe. The indemnifier will often seek control of any claims as a quid pro quo for this type of indemnity.
What alternative SaaS-related legal documents are available?
We publish a range of SaaS and hosted services contracts.
The SaaS agreements are designed to be used in situations where the parties will sign the documents. In many cases, however, a SaaS contract may be entered into by the parties agreeing a services order form, whether online or offline. In those cases, the “terms and conditions” versions of the SaaS documents will be more suitable.
Where do service level agreements fit in?
A service level agreement (SLA) or service level schedule may specify:
- particular measurable standards which services should meet;
- means of measuring whether the standards have been met;
- exceptional circumstances where a failure to meet the standards does not constitute a breach of the service level commitment; and
- the consequences of a failure to meet the standards, often involving the payment of service credits.
In the SaaS / cloud context, service levels will usually relate to the availability of the service. They may also relate to support query response and/or resolution times.
SLAs are commonly used for B2B services, but rarely used for B2C services.
SLAs can be used as shields for services providers rather than swords for customers. It’s not uncommon to see weak service level commitments, full of exceptions, backed by derisory service credit offers. Accordingly, customers should take no comfort from the existence of an SLA – it all depends upon content.
Our standard and premium SaaS agreements and terms and conditions include SLAs covering availability and support.
Do I need a separate data processing agreement?
If you provide a B2B SaaS or cloud service, and the provision of that service involves the collection, storage or other processing of personal data, then you will likely be a data processor with respect to some of that personal data.
If you are a data processor, then both you and your controller have an obligation under the GDPR to enter into a written agreement concerning the ways in which you handle the personal data. That written agreement must comply with the specific, often awkward, requirements of Article 28 of the GDPR.
A SaaS or cloud services agreement should include data processing clauses meeting these requirements. All of our SaaS agreements, SaaS terms and conditions and cloud services terms and conditions include appropriate clauses.
There’s no legal requirement that the data processing clauses are in the same document as the main services provisions, however, and many services providers do use separate data processing agreements. Good reasons for doing so are: (a) only some of your customer processing is subject to the GDPR, but you want to use the same services terms and conditions for all customers; (b) it will be difficult to negotiate new legal terms and conditions with existing customers, but you need to introduce data processing clauses into their contracts.
How should I handle termination of the SaaS agreement?
The pure SaaS / cloud model is easy come, easy go. Customers can usually terminate on short notice periods. Where charges are paid in advance, customers may be permitted to terminate at any time – although without any refund. Where payment is in arrears, a notice period of 30 days or so is typical. Termination rights may be aligned with billing periods to avoid the need to calculate partial charges.
If, however, you are dealing with enterprise customers, the costs of negotiating and entering into a contract may represent a significant up-front investment. Moreover, enterprise customers are more likely to require set-up, configuration, training and/or custom development services before using your application. Whatever the nature of the up-front investment, if you are not being directly remunerated for this you and are intending to cover your costs through subscription charges, you may need to insist upon a contractual minimum term. For instance, customers may be prohibited from terminating in the first 12 months of the contract.
SaaS and cloud service providers should ensure that they also have rights to exit contracts for convenience, even if they never plan to exercise these rights.
You should also consider rights of termination that apply where one of the parties is in default, for instance, if:
- the customer fails to pay the charges;
- the services provider fails to provide the service or meet the agreed service levels;
- either party becomes insolvent.
In addition to rights of termination, you should also say something about the effects of termination. The key questions here revolve around customer data. Will the customer be able to download all its data from the platform? Does the services provider have an obligation to provide the data to the customer? If so, when and how? And at what point must the services provider delete the customer data from its live and back-up databases? (If the database contains personal data, and the services provider is a processor of that personal data, it will need to be deleted after the completion of the services to comply with the GDPR.)