Cloud Contracts 2.0

Cloud based service delivery is not a new phenomenon; whilst marketeers work hard to continue to expand the lexicon of “X as a Service” offerings, “Application Service Provision” (as it was once known!) has a long history, and remotely hosted services have been around since the 1990’s at least. However, increasing bandwidth and telecom capabilities and the growth in the breadth and sophistication of cloud based offerings has undoubtedly resulted in a rapid take up of cloud based services in recent years. Initially, many of these cloud offerings were for more “commodity” style services, in that they were for lower value, non business critical functions, which would therefore not have a disastrous impact upon the relevant customer entity, were the cloud services to encounter issues and become unavailable or unstable. However, as the cost and flexibility advantages of cloud based solutions become ever more apparent, organisations have begun to migrate ever more substantial and business critical elements of their functions and operations into the cloud, and increasingly into both public (ie one to many service provision) and private clouds (or hybrid solutions involving bits of both).

How then have cloud contracts adapted to reflect this shift…..or indeed, have they adapted at all?

From one point of view, the contract provisions regarding the use of software products that go up to make a pure SaaS solution may not have needed to change that much; the major software players have long had strong bargaining positions , and accordingly their base licence terms in relation to on-premise licence grants would ordinarily be relatively restricted when it came to matters such as scope of warranties and related remedies, liability limits and the like, and the possibility for negotiating such provisions would ordinarily be relatively limited. However, in moving to a cloud based solution as opposed to a traditional on-premise licensing arrangement, such providers are also now taking on a wider scope of service style obligations, associated with the provision and support of the associated infrastructure on which their software products will sit, so as to provide the full “end to end” service associated with a cloud offering. This necessitates the consideration of an additional new set of contract requirements which they would not ordinarily have had to grapple with, such as IT security, business continuity and disaster recovery, data protection and the like. On top of that, there are more significant data issues to be considered, especially in the light of the recent advent of GDPR in the EU.

This challenge is exacerbated by the fact that the larger customer organisations (such as Banks, pharmaceutical companies and the like) will ordinarily have their own sets of expectations as to what kinds of contract terms would apply to such services, and indeed will usually have precedent contracts of their own that they would expect to use when they are procuring them. Many forms of “X as a Service” solutions could also be seen as a form of outsourcing, and so the customers (and/or their regulators, in the case of the financial services sector in particular) may expect to see the kinds of contract provisions which would ordinarily be included in an outsourcing agreement, including for example service level regimes (with associated service credit provisions, linked also to termination rights in the event of serious or persistent non performance), wider scoping of service obligations to include those “reasonably” or “necessarily” implied as part of the relevant functions, longer lists of warranties and indemnities, and prescribed processes that a supplier must follow in order to itself get relief from its own obligations (often known as “relief event” or “excused performance” clauses).

Whilst some of these provisions may be simply matters of commercial negotiation between the parties (and therefore influenced by the degree of bargaining leverage that each party has), there are a number which can create challenges from a practical perspective, particularly in the context of a public cloud offering. These include:

1. Liability clauses. Many XaaS contracts will have relatively wide ranging limitation and exclusion clauses; a fairly typical example would be wording to the effect that whilst a supplier will use “reasonable endeavours” to correct non performance of the cloud solution, it will not have an absolute obligation to fix the problem and the sole remedy of the customer in the event that it fails to do so will be terminate the contract and recover any advance payments for the remainder of the relevant subscription period (ie so as to leave the customer with no recompense for the resulting impact upon its business, and/or costs of then having to migrate to a new solution. Whilst such restrictive provisions may have been acceptable for the lower value, more commodity style cloud offerings mentioned above (or – more likely – may have escaped serious assessment or negotiation by the customers’ legal teams!), they will be challenged when a customer faces a very different risk profile when utilising the cloud for more significant services (which may indeed be ones upon which their business will genuinely rely).
2. Audit Provisions. For a business critical function, a customer would ordinarily want to have a right of audit in order to satisfy itself – on a proactive basis – that things are working as they should. Whilst this works fine when the supplier in question is providing its services from a dedicated site (and so may still be do-able in the case of a private cloud offering), it becomes challenging in the context of a public cloud solution, where the supplier in question will likely be utilising the same infrastructure and facilities to service multiple clients, and so will be concerned as to the possibility of service interruption and/or breaches of confidentiality that may arise, were one client to undertake an audit and thereby impact upon service provision to the supplier’s other customers.
3. Changes to the Services. Customers are used to the position whereby they acquire a software product or service on the basis of an agreed service description or specification, which does not then change without their consent. However, in the SaaS world, the supplier will ordinarily want to maintain a common code base across all of its customers, and will want to reserve the right to make changes if it believes this is necessary to enable it to maintain overall market competitiveness. Although such changes should generally be to add additional functionality, there is always a possibility that the developments go in directions that an individual customer does not agree with or is not in its interests. Suppliers may then be willing to grant the customer a right to terminate, but that is something of a phantom remedy for the customer, if it would then be put to the potentially not insignificant cost of having to migrate to a new cloud platform (and undertake a whole set of fresh integration efforts with the rest of its technology estate)
4. Compliance with Policies. Larger customer entities in particular will have become used to imposing obligations upon suppliers to comply with their policies, particularly in relation to matters such as IT security. However, cloud providers will ordinarily push back on such requirements, given the fact that their various clients will potentially have very different and even potentially conflicting requirements. The onus therefore switches to the customer and its internal teams to make practical assessments as to the delta between its own policies and what the cloud supplier offers to its customer base at large
5. Termination Rights. When utilising business critical outsourced services, the market norm has become for suppliers to have very limited termination rights, often limited solely to non payment of material amounts of undisputed fees. However, the expectations of the major cloud providers are diametrically opposed to this, with their contract terms usually providing for the supplier to have extensive termination and suspension rights, often linked to even non-material breaches of acceptable use policies which they impose upon their customers’ use of their cloud services

These kinds of disjuncts in expectations may have been easier for customers to live with in the context of the early days of cloud services, eg when the functions being entrusted to the cloud service providers were less substantial in terms of value, and less critical to the overall operations of the customer entity. However, as noted earlier, we are seeing a dramatic increase in the range and size of cloud based offerings, with deal values at times extending into the hundreds of millions and covering services which most definitely are business critical. In those circumstances, the ability of the customer entity to “take a view” on the risks associated with the kinds of contract terms on offer from the cloud suppliers is far more restricted (especially in more heavily regulated sectors such as financial services, where regulators such as the FCA, EBA and Monetary Authority of Singapore have been very specific as to the kinds of contract clauses that they expect their regulated entities to be including in their cloud related contract terms). We are therefore in an interesting time in terms of market dynamics, when we can expect past expectations and standards as to “normal” contract positions to be regularly challenged and to develop quickly; indeed, it may be fair to say that for larger scale cloud services in particular, there has rarely been a time when contract positions have been more in flux than they are now.