Published on the 25/03/2021 | Written by Heather Wright

Negotiate hard and early…

Yes, you can negotiate your SaaS agreement – and you should, particularly around security and data privacy and termination clauses.

Luke Ellery, Gartner senior director analyst says he’s hearing from plenty of clients who are having challenges understanding what is negotiable in software-as-a-service agreements, with some signing agreements that are putting their organisations at risk.

Ellery says despite vendors’ frequent claims that SaaS agreements are non-negotiable, vendors are actually likely to negotiate in some areas, and there are some ‘deal breaker’ clauses customers should be putting under close scrutiny and negotiating hard on.

Perhaps surprisingly, Ellery says what should be key clauses in agreements – particularly around security, privacy and termination – are often not there, or are not being considered, up front.

“Most SaaS agreements don’t have clarity in regards to termination.”

“Most SaaS agreements that come across my desk don’t have clarity in regards to termination or transition assistance and in the security clauses they might talk about SOC reports or ISO but they don’t tie them in as provisions that have to be continually monitored and upgraded.”

Why the lack of clauses?

“I think the main reason is that the vendors aren’t selling to the security or procurement team. They’re selling to the business and they don’t have that at the front of their mind,” he says.

”It’s something that could be better articulated as a going in position and communicated throughout organisations to say if you’re buying SaaS these are the key prerequisites the SaaS vendor has to have.”

While it should go without saying that security and data privacy should be front of mind for companies moving to SaaS, Ellery says that’s not always the case.

He cautions customers to check vendors SOC 2 or ISO-27001 compliance and certifications to demonstrate a vendor’s security controls, and to push back on SaaS vendors giving infrastructure provider compliance reports.

Ellery cites the example of a company whose SaaS system went down. The provider was meant to back up data but when the system came back up after two days, they had lost six weeks of data.

“There was an obligation in the contract, but it was around ensuring the obligations in the contract have been implemented and that’s why you need those audited reports or the ability to audit.”

He says understanding the controls a vendor has in place and the associated risks is just one aspect, with companies also needing to ensure they are matching that with what they’re using the system for – and monitoring both.

That includes monitoring how a vendor’s security posture is changing, including whether they’re increasing security, any breaches and whether they’re up to date with penetration testing, but also ensuring that your own business hasn’t changed the way it is using the SaaS offering in a way that increases exposure. He uses the example of a company initially using the SaaS offering to handle scheduling of social events, but later on using it to also send board reports.

“That is one of the areas risk programs fail to update – how the use cases of organisations change. And that’s just as much or more risk than vendor having deteriorating security controls potentially.”

There’s another key area Ellery says is often not looked at at the start of agreements, or even included in many agreements, yet is one of the most important clauses to look for: Termination clauses.

“You really need to have clear termination provisions that outline how you get data back, how you ensure data they store is deleted once you get it back and also whether you need transitioned assistance – that is assistance to continue using the system until you migrate to a new system – even after the agreement terminates.”

Organisations in highly regulated markets, such as financial and government often seek 18 months in transition assistance given the amount of time it can take to find another vendor, get budgets organised and move somewhere else.

A lack of transition assistance clauses can result in a loss of negotiation leverage, making it very difficult to renegotiate if you’re facing the end of a contract and want to negotiate something else in.

“Often the vendor will just stonewall you and not engage although you need additional security controls – say your use case has changed.”

Ellery says requirements should, as much as possible, be put up front with vendors at the start of the procurement process so they’re aware of the security controls you need implemented and any termination requirements before you get to the pointy end of negotiations.

And, he says, customers – no matter what the size – need to be prepared to walk away if vendors won’t met the obligations.

“If they say the deal is too small to make the changes needed, then walk away. It is totally reasonable to do that and have that position.

Clauses around third parties are also crucial he notes.

“Your SaaS vendor is your third party but they typically rely on many other providers – infrastructure providers, different software or services. And it’s important to understand whether security controls, or at least the contractual obligations, are flowing down to those fourth and fifth parties.”

He says many SaaS vendors will put in their contract that their own third party failures are force majeure – or unforeseen – events, relieving them from the contract.

It’s clause that provides the get out of jail for a SaaS provider whose infrastructure provider fails, and it’s one that has tripped many a company up.

“You’re looking for your SaaS provider to have thought about these things and to do regular backups and have mechanisms to ensure they have continuity of supply and redundancy in there.”

These, he says, are negotiable clauses. “If you get your own security team to talk to their security team you can understand what controls and mitigations they have in place for these types of failures and that enables you to determine if it makes sense whether those force majeure events are actually force majeure events or could be anticipated and as a result you can rely on their own internal team to describe the system rather than what is written in the contract.

“Often what I see is that the contract has been written by a legal team and they are somewhat divorced from the product, so it’s important to understand technically what’s going on and then just ask for the contract to reflect what is technical being set up.”

Service levels are also an area to be negotiated hard, he says with companies needing a right to terminate for repeated failure.

He cites one client who had a failure with their system and kept raising tickets. The issue was escalated up to the accounts team who promptly told the customer they were meeting the terms of the contract. And they were. Because it had a response SLA but not a resolution SLA and no termination of contract for repeated failure.

“You have to make sure the contract is there to help you and protect you in those circumstances.”

And don’t just assume your vendor’s contract is fit for purpose. Ellery says sometimes SaaS contracts are based on a software agreement or something else and just don’t make sense.

“We do see challenges with clients trying to negotiate sensible clauses in those types of agreements, and we also see challenges in regards to meaningful service credits. Often SaaS vendors will try to maintain as much of their revenue. If they have a large at-risk amount they can’t book that revenue, so if there is a lot at risk from the service credits perspective they are unlikely to want to sign up for that.

“That’s why clauses like termination can be more powerful and more likely to be accepted.”