Written by Annabel Ashby

Cloud computing is no longer new (and indeed can be seen as itself being rebadged from earlier forms of remote hosted/ASP style offerings). However, what is apparent is the continuing growth in size and sophistication of cloud deals, both in the private and public cloud space. With this comes an increased focus on the contractual and commercial terms, and a continuing challenge for perceived norms on both the customer and supplier side of the fence.

The Developing Market

For a long time, deals appeared to mostly fall into two categories:

  1. Public cloud offerings on a “one-to-many” basis, where suppliers showed little appetite to depart from standard terms of business, whether because of the need to have the contract terms reflect the common delivery model or simply by reason of a reluctance to take on additional contract risk; or
  2. Private cloud arrangements which were bespoke/specific to one (usually larger) client, where the contract terms would be fully negotiated in much the same way as a managed service/outsource style contract would be, and frequently based on the customer’s proposed contract terms.

Both of these models do, of course, still exist and have increasingly replaced more traditional forms of on premise licence and support arrangements. However, we have also seen variants which can create more of a challenge when it comes to the negotiation of contract terms. These include:

  1. “ERP in the cloud” style deals, where far more business-critical systems are proposed to be run remotely, and where the relevant software licensor is taking on both implementation and hosting services/responsibilities for the first time; and
  2. Private cloud services which – whilst “dedicated” to the relevant customer in the sense that there will be discrete instances of the relevant software and very often segregated servers/racks as well – will nonetheless be provided from shared datacentres and using shared networks, which can have an impact upon both the supplier’s ability to meet the specific service requirement of the customer, whilst also necessitating a few supplier mandated requirements as well.

Key Contractual Challenges

In the light of these developments, what forms of contractual challenges are we seeing?

  • Warranty Protections

Whilst such an approach might pass muster for a “take it or leave it” commodity-style cloud offering, it would clearly not be acceptable for a customer who is seeking to use the cloud for more business critical applications and services. Accordingly, we now commonly see the acceptance of an obligation upon the service provider to correct warranty defects as being independent of any separate right to claim compensation for related losses.

In the context of standard contract terms sent out by vendors of public cloud solutions (e.g., the likes of AWS, Microsoft Azure, etc.), it would be common to see provisions whereby the service provider would warrant only to use “reasonable endeavours” to correct any non-compliance with specifications, and on the basis that if such non-compliances could not be readily resolved, then the sole remedy of the customer would be to terminate that aspect of the cloud service and receive a pro rata refund. A similar approval is often applied to alleged IP infringements.

  • Compliance with Laws

We have seen a considerable deviation in approach in this regard, depending on the nature of the cloud services (where bespoke modifications can be more readily accommodated). For private cloud services, where the service provider can commit to maintain compliance with laws, the key area of debate is instead centred on who has to monitor and interpret the new requirements, and thereafter bear the cost of any resulting changes. For public cloud services – and even for “private” cloud services, which are based on distinct instances of a particular product that the service provider wants to keep in line with its “core” product – the willingness of the service provider to commit to compliance may be limited to those laws that make specific reference to it as a service provider, or potentially to the laws of a particular sector or function on which the cloud services are particularly focused. The customer may then face a difficult challenge in that sector if specifying requirements proceed in a direction potentially at odds with the cloud solution it has commissioned.

As the customer will be dependent upon the cloud services provided to ensure that the relevant services are provided in such a way as to enable the customer to comply with its legal obligations, it is not surprising that the contract terms related to compliance with law and regulation are increasingly subject to negotiation (despite many cloud service providers initially arguing that all they offered was “a service” and that it would then be for the client to do the mapping against its relevant obligations).

  • GDPR/data protection compliance

Many of the cloud services standard terms we have seen are very carefully crafted by the service provider so as is to emphasise their role as data processor rather than controller, and to thus emphasise the fact that the majority of statutory obligations remain with the client (at least until the advent of GDPR). However, many customers are wise to this and will at least push back to force the service provider to take on the relevant security obligations vis-a-vis appropriate technical and organisational measures to safeguard data from unauthorised access or alteration.

Service Providers can point out that in this regard, that they will not necessarily know what data the customer is asking them to host or process via the relevant cloud service, and so they are in no position to judge what measures should be taken. Indeed, it is possible that the advert of GDPR may add a new twist in this regard, with service providers instead asking the customer to warrant that the security arrangements are adequate for the customer’s purposes, and to indemnify the service provider against any future claims if they are ruled not to be.

With data being so central to cloud based services, data protection-related provisions receive a significant degree of attention when it comes to negotiating the associated contract terms.

  • Decommissioning and Disposal Costs

However, the reality is that the pace of decommissioning and disposal was likely to have been relatively steady in the past (and indeed many organisations will have delayed decommissioning and “sweated their assets” for longer than might be ideal). If, therefore. there is to be a “spike” in decommissioning as a supplier implements a cloud solution instead as part of a more root and branch transformation programme, the costs associated with that will have to be carefully considered, and budgeted for accordingly. For example, might the supplier incur the costs initially, but on the basis of amortising them across the lifetime of the contract thereafter to mitigate against the customer’s cashflow hit?

Even deals thought to be “private” cloud-based there may still be elements of this requirement. For example, if a service provider is servicing multiple clients from a single datacentre, then any changes to such datacentre’s generic infrastructure or networks would need to be adhered to by all of the relevant customers.

In the past, a customer organisation would have had to deal with the costs of decommissioning and disposing of redundant hardware. In the context of a cloud transformation programme, therefore, it may be tempting to leave the associated effort and cost of this out of the equation, when calculating the business case.

  • Supplier Mandated Changes

On some larger deals, we have also seen SaaS providers willing to contractually commit to maintain set functionality for minimum periods, and/or to continue with an agreed upgrade/development path.

For truly public cloud services, it is usually the case that the contract terms reserve for the service provider the right to make changes to the service descriptions. Where the services are delivered communally to multiple clients and need to evolve to remain competitive, this makes eminent sense. However, we have increasingly seen service providers willing to modify/mitigate this approach, e.g., by committing to only improve the services offered, or at least to not make any “material” reductions in what has gone before, and/or to offer termination rights for the customer if it does not agree with the changes being made.

  • Suspension and Termination Rights

In many forms of standard cloud services deals promulgated by service providers, we have seen both termination and suspension rights drafted so as to set the bar at a very low level; so much so that in some cases, even the slightest mis-step may lead to a loss of service for the customer. However, as the size and reach of cloud service offerings have expanded, customers have increasingly focused on the breadth of such rights and sought to narrow them. It has become the norm in outsourcing contracts for the service provider’s sole right of termination to be non‑payment of fees, and it could be argued that the customer’s degree of reliance upon a cloud-based service may actually be greater than that of a “traditionally” outsourced one (where there may be assets, contracts and staff who can be more readily transferred back to the customer or a replacement supplier).

  • Liability Exclusions

Liability provisions have been another key area of the contract where standard cloud services seem to have dialled back the extent of risk that they are willing to assume. Aside from attaching the liability limits to the fees paid for only those services that proved defective (rather than the charges as a whole), we have seen blanket exclusions of data related losses, applications of the cap to (traditionally unlimited) IP and confidentiality related claims, and even exclusions of losses relating to the costs of procuring replacement services. A typical justification for this approach from a public cloud service provider might be that it would not be able to take on more significant degrees of liability if something went “wrong” with its solution. In such a case, it is likely that such a malfunction would affect multiple customers, if not all. Accordingly, the provider might then being exposed to multiple related claims, which, by reason of a single default, could ultimately lead to bankruptcy.

  • Prime Contractor/Supply Chain Challenges

We have seen a number of deals which previously may have been approached as outsource-style contracts with a service-orientated prime contractor, who could, in turn then subcontract or sublicense elements of the overall solution. However, many SaaS providers are either reluctant to accept the flow down of contract risk from the prime contract, or seek to position themselves as the first point of contact with the customer. The risk scenario for the former option is problematic for the prime contractor, who may then feel trapped between the contract expectations of the customer and what it can pass down to the cloud service provider (e.g., in terms of warranty or service level commitments, liability caps, etc.). The second scenario may pose a similar challenge for the customer, who may be unpleasantly surprise when comparing the proposed SaaS contract terms against those typically used for achieving similar, non-cloud-based services. For example, we recently advised a major client who was considering a cloud services deal potentially valued in the hundreds of millions of pounds. This client was shocked to find potential suppliers refused to respond to their draft contract terms. Instead, the client was directed to a web link containing the supplier’s standard cloud services terms, which were available to the world at large and where, for example, the sole remedy for the customer in the event that the SaaS solution did not work (after the customer would have spent tens of millions of pounds on implementation, etc.) would be to get a refund of pre-paid fees.

  • Audit Rights

In a private cloud environment which is dedicated to a single client, this is easy to accommodate. However, the moment one ventures into environments used to support multiple clients, difficulties can emerge. The service provider would then want to ensure that any audit undertaken by Client A does not impact upon the services it provides to Clients B, C and D from the service data centre. For public cloud services, it is unlikely that any customer-specific audit right will be granted at all. However, customers can still expect the service provider to undertake regular generic audits using an independent third party, such that the resulting audit report can then be made available to all customers. We have seen this approach taken on occasion, although many service providers are still resistant to it.The business benefits of cloud solutions are so manifest and substantial that there is ever greater momentum in favour of their implementation, and for more and more substantial and business critical functions. At the same time, however, we are also seeing a rapid development of the contracting models for such solutions, particularly for private and/or hybrid cloud models, and we can expect this state of flux to persist for some time to come.

Conclusion

This is sensible and reasonable. However, recent regulatory guidance in the UK (e.g., the FCA’s FG 16/5 note on Cloud Contracts) suggested that “unrestricted” audit access might be required, and it remains to be seen how literally this requirement/guidance will be interpreted.

An organisation that entrusts its core functions and data to the cloud will be understandably concerned to ensure that all of the contractually promised safeguards are being implemented. Having an effective audit right is key to accomplishing this.