SaaS Agreement

If you offer a software as a service (SaaS) app, it is likely easier for you to combine all your legal agreements into one: the SaaS Agreement.

Many SaaS apps contain a number of legal agreements including Terms and Conditions (T&C) or Terms of Service (ToS), a Privacy Policy, Disclaimers, and other additional notices.

This article will break down in detail what content should go into a SaaS Agreement and show real world examples for each type of content.

What is a SaaS Agreement?

A SaaS Agreement is a legal contract between a developer of the app and user using the app. It's basically a Terms and Conditions or Terms of Service or Terms of Use for SaaS apps.

Similarly to a Terms and Conditions agreement, it contains the rules and limitations to how the SaaS app is to be accessed and used.

Many SaaS apps have this kind of legal agreement but still call it a "Terms and Conditions" or a "Terms of Service" agreement.

The name does not matter as much as the content. You just need to be sure the document covers the elements unique to SaaS apps and elements unique to your business.

Many of these agreements integrate elements of the Terms and Conditions, Privacy Policy, and Service Level Agreement (SLA) covering subjects like:

• Warranties
• Restrictions of use
• Licensing details
• Billing terms

Most SaaS Agreements are more extensive than standard Terms and Conditions agreements because there are often more rules involved in using SaaS and cloud services.

Users should accept your app's SaaS Agreement the same way they would with others: through clickwrap. You should make the acceptance of the agreement a condition to proceeding to create an account.

What to Add in a SaaS Agreement

Now let's take a look at some clauses and content that should go into your SaaS Agreement.

Termination

Users need to know when service (the SaaS app) availability starts and ends. That includes listing circumstances that could result in immediate termination of user accounts or the service.

Soffront offers online and on-site client relationship management and marketing services. Its termination clause within its SaaS agreement is fairly general in that failure to follow the terms outlined in the agreement will lead to termination.

Also, it allows for termination with written notice from a user:

Other companies contain more detailed descriptions of their termination clauses.

Axosoft, a scrum software service, includes information about when services begin and what can happen when they end, including what happens in the event of non-payment for services. It also indicates that payment for any services performed is due at termination:

Billing and Payments

Payment terms are also important for SaaS Agreements. It is a way to be upfront with users about how much they need to pay, when, and how.

Like termination clauses, these tend to vary in length.

Soffront states that payments are due either in advance or as agreed to by both parties, and that services don't start until payment is received. After a 7 day notice of a missed payment, services will be terminated:

SailPoint offers identity governance services and its payments are accepted through individual invoices and schedules. There are also terms allowing for the company to demand reimbursement for expenses from users and the requirement of tax payments:

This is yet another area where there is extensive customization.

Companies do not have identical billing practices. If the payments you receive from users are automated, you likely require less content in this section since many times, service is programmed to terminate when a payment fails.

Present payment terms clearly so users know what to expect but also be sure to have an out in case payments stop.

Licensing and Restrictions

The user does not own the app like an app where an EULA is involved. A SaaS app gives a license to use the service in order to avoid any terms regarding ownership over the app.

For most SaaS apps, you need to draft your agreement so that the license is for the services - not the software.

The problem with allowing a software license is it can allow the user to reverse engineer your product and possibly create a superior one that competes against you in the market.

Also, if your product suffers appreciable downtime, you can be held liable for the loss of the software and the service.

Offering a license for both the software and the hosting service exposes you to legal risks that you may wish to avoid.

SailPoint licensing takes this approach by making it clear that it offers services and does not deliver software:

Soffront's licensing provision includes the software. However, unlike other examples, it offers both cloud and on-site services.

Under those circumstances, it likely has to license the software so in-house IT departments can make adjustments. For that reason, it assumes the risk:

You likely want to do the same in order to protect the proprietary interest in the software you are developing.

Axosoft takes this approach in a section on "Restrictions of Use." Not only are users not allowed to copy or reverse-engineer the software but they cannot license or sell their interest in the service to anyone else:

Sailpoint includes the same restrictions in its SaaS Agreement and makes it clear that it maintains an ownership interest in the software, services, and documentation:

Warranties

If you have any warranties on your SaaS app, include those in the SaaS Agreement too. The same is true if you disclaim warranties.

Sailpoint offers a general warranty regarding good services but does not guarantee that it will run the software error-free all the time. It offers some reassurance but does not take responsibility for elements beyond its control:

Soffront offers multiple detailed warranties. It offers the usual service guarantees while also refusing to take responsibility for user misuse of its services:

The trick to warranties is to offer reassurance of good functioning without making too many promises. Taking a general approach and then adding disclaimers is likely your best approach here.

Any additional promises can be set out in a Service Level Agreement.

SLA Terms

A Service Level Agreement (SLA) sets out the specific services provided along with the rules for using them. It generally includes:

• The hosting of SaaS software and customer data
• Support services
• And software maintenance services.

While it can raise expectations with your users, it is also a selling point.

The SLA can also describe what happens when there's downtime. These terms often address the amount of money compensated or measures taken to minimize damage to users.

Your SLA can be a separate document or you can include the terms of your SaaS Agreement.

Axosoft is very specific in its promises. In its SaaS section on service level commitments, it guarantees that its services will remain accessible 99.5 percent of the time during any given month.

However, it also waives liability if network availability decreases due to the actions of a third party:

Privacy Terms

Privacy terms can also be included in the SaaS agreement, as well as a link to your full Privacy Policy.

Sailpoint has a separate Privacy Policy which it references directly in its SaaS Agreement:

Other companies would rather not deal with this issue at all.

Axosoft warns against submitting confidential information and indicates that it is not bound by all privacy laws, including HIPAA in the United States. However, this is not essential to its services and it also offers a separate Privacy Policy page:

Include references to your Privacy Policy in the SaaS Agreement, but provide a separate Privacy Policy agreement to comply with international privacy laws.

Whether you call the "SaaS Agreement," a "Terms and Conditions" or a "Terms of Service," legal agreements regarding the use of your SaaS app are important.

Be careful to not only define your rules (including payment terms) but to take steps to reduce the possibility of liability.