One of the reasons I set up Quarterback Law is to provide clear, useful advice. Here, I share some of my observations on the issues to consider when procuring software as a service (SaaS).
You can’t really do business today without using Saas. As a lawyer I’m frequently asked to draft or review the contract between the customer and the service provider. SaaS contracts are notoriously difficult to negotiate. Service providers tend to be in a strong bargaining position, and concessions on the contract language are few. That’s quite convenient if you’re the service provider and can be daunting if you’re the customer.
At a minimum, you should understand the contents of the licence agreement and identify where the risks are. If the agreement is negotiable, focus on the areas that will mitigate the most risk. The service provider is more likely to entertain a few changes to key provisions, rather than a document marked up with trivial, stylistic changes. I’ve seen these types of changes, and always suspect that the lawyer making them is demonstrating their “value” to their client by making the maximum number of changes possible!
Here are a few pointers in the right direction.
Know what you’re buying It sound a little bit basic. You wouldn’t buy a machine without knowing what it does, and your SaaS should be the same. For smaller software providers, you should do your due diligence on them. Where they are from, how stable is their company and are they likely to remain solvent? Some startup software companies get taken over by giants, others go broke. You don’t want your data tied up with the latter. Also understand what your software does, how it performs and what it does with any data you input into it. It’s also important to know where the data centres are. Does a business continuity plan involve storing your data in different jurisdictions? The “cloud” is relatively safe compared to on-premises servers, but the location of your data can be relevant for privacy assessments, data protection and trade sanctions issues.
Be clear on what you will do with the software Consider what you and your employees will do with the software. It’s important not just to consider the immediate anticipated use, but what other potential uses could it have. Future use of the software could impact your data protection strategy as well as the number of user licences you’ll need.
Be sure to accurately indicate the number of individual users (if the software is charged on a per-user basis). Most contracts have robust audit rights for the software provider, and excess users will generally incur hefty fees. On a side note, SaaS providers that charge on a per-user basis are limiting their growth. Software companies charging “per-user” are like lawyers charging in six-minute blocks – outdated and on the decline. There’s a great article about SaaS pricing here, if that’s your thing.
The Service Level Agreement is important – read it! You’ve probably read all the reviews and had the marketing team show you all the bells and whistles. Maybe you’ve even done some reference checks. But for all the marketing hype, the SLA is going to tell you what the software provider contractually commits to. It should refer to speed and availability. These days for a core service you would expect availability to be no less than 99.9xx%.It’s up to you to negotiate the xx!
Closely related to the service levels are the consequences for the software provider breaching them. These usually include rebates, which if it’s a core service will be unlikely to come anywhere near compensating you for losses if the service goes down. You should also consider termination rights. Most providers will claim that the rebates in the SLA are the sole and exclusive remedies for failure to meet the service levels – think carefully about potential damages if you agree to this!
Many licence agreements go for several years, and if the provider persistently fails to meet the service levels you may wish to terminate. The costs associated with termination and transitioning to another supplier may form a point of negotiation. Both of these points will depend on your overall bargaining power.
Limitations of liability
Almost all SaaS providers will limit their liability under the contract. This is sensible from the provider’s perspective if they are providing a core service to a number of clients. Each client may suffer considerable financial loss if the service goes down or there is a data breach. From the customer’s perspective, you have a legitimate expectation to be compensated for your losses if the provider is negligent.
Generally, I prefer to have multiple heads of damage in the limitation of liability clause. You might see liability limited to 12 months of the fees for general breaches of contract and negligence. You might also see a higher cap for more serious damages such as a data breach or misappropriation of data.
This is why I started off this article suggesting that you consider what you are buying, who you are buying it from and how you will use it. This should influence your assessment of potential damages, and inform you on whether the supplier’s proposed caps are adequate. I believe a supplier should be liable for data breaches that are caused by failure to comply with industry standards or negligence. However, it’s a tough ask from most providers and you’ll usually see this form part of a super cap on liability.
In a competitive market, you may need to walk away from the software provider if they are not willing to accommodate your risk appetite on liability. However, where there’s only a limited number of suppliers in the market (or in many cases, one supplier), it’s going to be a difficult negotiation. Consider other avenues to share the risk, such as upgrading your cyber insurance.
Intellectual Property Rights – know what happens to your data
It’s standard for a software provider to have unlimited liability for infringing third party IP rights in the product. Though that is not the only IP-related issue that you need to consider. If you’re uploading data into the service, your service agreement should be very clear that you retain the IP rights to that data.
It becomes more complicated when the provider processes or modifies your data. In these cases, being familiar with the terms of the agreement can be vital to protecting your IP rights. Did you know that when you upload a document into Google Translate, you grant Google a licence to use that document to develop new technologies and services? That’s probably no issue if it’s a simple document that you’re translating for personal use. It becomes an issue if it’s your product designs or confidential memo!
Be realistic
Unless you’re a very large company spending a lot of money on SaaS, or you’re dealing with an upcoming SaaS provider who is keen to gain market share, there’s no point redlining a SaaS contract to the point of being unrecognisable. Your software provider is unlikely to entertain large scale alterations and you’ll be met with a firm “no”. Even worse, you may be told that “we’ll send it to Legal for review”. Instead, pick a few key issues that present a real risk to your company. If you don’t identify any, that’s fine – go ahead and sign on the dotted line (or more likely, click “I accept”)!
Mandatory Pun
Apparently, I must use at least one pun in every article that is written about SaaS. As a lawyer, I’ve had many occasions where a client will send me a SaaS contract for review, with no context, and ask me to “approve” it (I can feel the in-house lawyers nodding). It’s exSaaSperating, but instead of getting frustrated we run through some of the above issues and discuss the risk. See what I did there?
