The Cloud

5 Sneaky Tripwires in Your SaaS Contract

Most CFOs today know all about security risks, and the importance of data privacy in the cloud. But it’s what you don’t know that can hurt you.
Rob LivingstoneSeptember 18, 2012

In 10 Things You Just Gotta Have in Your Cloud Contract, I covered a range of things (10, as a matter of fact) that CFOs should think about when they sign a cloud contract.

But the subject is hardly exhausted, especially when it comes to software-as-a-service (SaaS), the most popular flavor of cloud computing and (not coincidentally) the one with the lowest barrier to entry.  

Drive Business Strategy and Growth

Drive Business Strategy and Growth

Learn how NetSuite Financial Management allows you to quickly and easily model what-if scenarios and generate reports.

The risks in cloud computing are more concentrated at the software layer than the platform and infrastructure layers (the other cloud-computing flavors). The software layer contains all your application and business logic, which supports and runs your business. In a multitenant SaaS environment, you’re sharing the database with everyone else who has signed onto the service. You are also absolutely dependent on your SaaS provider for writing its applications well, securing its databases, architecting and managing the platform and infrastructure layers effectively, taking care of security, and so on. These are all factors over which you have little or no operational control, so it’s important that you understand the implications of your SaaS contract as they apply to your business and try to negotiate a contract that mitigates some of the risks inherent in that lack of control.

That’s assuming you can negotiate with your cloud provider, which is a big assumption if you are using some of the major global cloud providers. Should the contract put in front of you be nonnegotiable, and if the known risks cannot be effectively mitigated, you may want to keep shopping. At the end of the day, it’s your brand at stake, not the cloud vendor’s.

The most-often discussed SaaS contract considerations typically include data privacy, information security, data jurisdiction, vendor lock-in, accessibility (for auditing), and compensation for failure to meet service-level agreements.  But everyone knows (or should know) about those. However, there are a few other lesser known but potentially no less important considerations let’s call them tripwires  that you may not be familiar with.

1. Who said anything about integration?
Integrating a SaaS application with other systems, cloud-based or on-premise, can make things a lot more complex, and quickly. According to Gartner’s predictions for 2012, cloud consumers should budget for integration expenses that can range from 10% to 30% (and sometimes as high as 50%) of the initial purchase and implementation cost. Make sure your SaaS project is well scoped and architected, and then budget accordingly. This means understanding your integration plans before you implement. That’s something some SaaS vendors prefer you not do. Land-and-expand (close the deal and then add on) may be their default sales strategy. The question you need to ask is what (if anything) is in the contract that will ensure that your SaaS provider will assist you in the integration of their applications with others within your computational ecosystem?

2. Where’s my software?
Depending upon the way in which your SaaS provider has designed its system, software escrow (in which a copy of the vendor’s code  and how it was architected  is held by a trusted third party to guard against the code’s loss or the vendor’s inability to continue to offer the service) may not be technically feasible due to the multitenanted nature of its infrastructure.

If the SaaS system is important to you, satisfy yourself that you have a mechanism for protecting your business should your SaaS vendor suffer a misfortune such as a catastrophic failure of service, bankruptcy, a lawsuit that results in an injunction forbidding it from providing the service  anything is possible. How are these eventualities covered, if at all, in your contract?

3. Who did I sign that contract with?
What is your position if the ownership of your SaaS provider changes three months into a three-year contract? What rights do you have to terminate the contract? Is this a real concern? Well, let’s imagine that your U.S.-owned SaaS provider has just been acquired by a major Chinese corporation, with likely ties to the Chinese government. Unlikely, perhaps; impossible, no. If your data, systems, and business are of such a nature that this scenario would be a problem for you, then ask about your rights to terminate and your ability to move the service (and your data) to another provider.

4. How can an upgrade be a downgrade?
One of the advantages of the SaaS model is that all the messy work of upgrading the software is done for you, over the Web, automatically. But software vendors have a way of dropping features that are not in their best interests. What if your provider drops its support for interface software to nominated third-party systems? If that’s discontinued, you might end up having to write your own integration software or look for yet another provider to deliver it. Naturally, both solutions will add cost to that initially low-cost SaaS solution. So, if there are specific aspects of the SaaS application that are critical to your organization, get a commitment from the vendor that the critical functionality will not be removed during the course of your contract.  

5. Who’s in charge here?
Change control goes to the heart of the SaaS value proposition. If your SaaS instance is stand-alone, and not integrated with any other systems, this is unlikely to be a problem for you as software change control is fully within the domain of the SaaS provider. If, however, your application is integrated with other software systems, and especially in cases where key data is transferred between systems within your application ecosystem, the impact of changing one part of that ecosystem may not be trivial. A core aspect of effective change control is rollback (the ability to return the system to its previous, prechange state) in the event of an upgrade failure. Know how you will manage this because you may not be in control of the rollback process in your SaaS environment. Section 404 of the Sarbanes–Oxley Act, if relevant to your business, would still apply whether you are implementing SaaS or not. How is change control  backup and rollback in particular  handled in your contract, if at all, and if so, what SLAs are offered?

As the cloud brings CFOs ever-more into IT’s orbit, expanding their responsibilities due to the transactional nature of SaaS agreements, it’s important to come to grips with some of the less frequently discussed aspects of a SaaS implementation. It may not be what you signed up for as a finance executive, but it’s now part of the job. You have to be able to ask the right questions when those SaaS contracts hit your desk. If you don’t, you may be surprised by the consequences.

Rob Livingstone, a former CIO, is the author of Navigating Through the Cloud. He runs an IT advisory practice and is also a Fellow at the University of Technology Sydney (UTS), Australia, where he teaches strategy and innovation in UTS’s flagship MBITM program. Visit Rob at or e-mail him at [email protected].