Kit Burden applies his unrivalled expertise and experience to an analysis of developments in cloud computing contracts, identifying the key emerging challenges
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:
(a) 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)
(b) 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 would frequently be based on the customer’s proposed contract terms
Both of these models do, of course, still exist and indeed 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:
(i) ‘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
(ii) 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 data centres and using shared networks, which can impact upon the supplier’s ability to meet the specific service requirement of the customer whilst also necessitating a few supplier mandated requirements too
So, in the light of these developments, what forms of contractual challenges are we seeing?
Key Contractual Challenges
· Warranty Protections
In the context of standard contract terms sent out by vendors of public cloud solutions (eg 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 approach is often applied to alleged IP infringements.
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.
· Compliance with Laws
As the customer will be dependent upon the cloud services provider 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).
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, the service provider can commit to maintenance of compliance with laws, and 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 which the service provider wants to keep in line with its ‘core’ product), the willingness of the service provider to commit to compliance with laws may be limited to those which are specific to it as a service provider, or potentially to the laws of a particular sector or function which the cloud services are particularly focused upon. The customer may then face a difficult challenge in the event that sector- specific requirements proceed in a direction which is potentially at odds with the cloud solution it has commissioned.
· GDPR/data protection compliance
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.
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 the GDPR). However, many customers are wise to this and will at least push back to get 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 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 advent 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!
· Decommissioning and Disposal Costs
A customer organisation will in the past 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. However, the reality is that the pace of decommissioning and disposal will be 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 in 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.
· Supplier Mandated Changes
For truly public cloud services, it is usually the case that the contract terms will 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, eg by committing only to 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.
On some larger deals, we have also seen SaaS providers willing to commit to maintain set functionality for minimum periods, and/or to continue with an agreed upgrade/development path.
· 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, in some cases so low that even the slightest mis-step may give rise to a loss of service for the customer. However, as the size and reach of cloud service offerings has expanded, customers have increasingly focussed on the breadth of such rights and sought to narrow them; after all, 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 agreed that the customer's degree of reliance upon a cloud based service may actually be greater than for a ‘traditionally’ outsourced one (where there may be assets, contracts and staff who can be more readily re-transferred back to the customer or a replacement supplier).
· Liability Exclusions
Liability provisions is another key area of the contract where standard cloud services seem to have ‘dialled back’ the extent of risk that they are willing to take on. Aside from attaching the liability limits to the fees paid for just the part of the services which 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 reprocuring replacement services (which must surely be amongst the most direct of direct losses, in the context of a termination event). A typical justification for this approach from a public cloud service provider would be that it would not be able to take on more significant degrees of liability as, if something went ‘wrong’ with its solution, then the problem would probably affect multiple customers (if not all of them) and accordingly the provider would be exposed to multiple related claims which could literally bankrupt the service provider by reason of a single default.
· Prime Contractor/Supply Chain Challenges
We have seen a number of deals which in previous times may have been approached as outsource-style contracts with a service-orientated prime contractor, who may 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 flow down to the cloud service provider (eg in terms of warranty or service-level commitments, liability caps etc). The second scenario may equally pose more of a challenge for the customer, who may have an unpleasant surprise when comparing the proposed SaaS contract terms against those it is used to achieving for similar, non-cloud based services. By way of example, we recently advised a major client who was considering a cloud services deal valued (potentially) in the hundreds of millions of pounds, and who was then shocked to find the potential suppliers refusing to respond to their draft contract terms, and directing them instead to a web link to their standard cloud services terms, 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
An organisation which entrusts its core functions and data to the cloud will be understandably concerned to ensure that all of the contractually promised safeguards are in fact being implemented. Having an effective audit right is key to this.
In a private cloud environment which is dedicated to a single client, this is easy to accommodate. However, the moment one ventures into environments which are used to support multiple clients, difficulties can emerge. The service provider will understandably 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.
This is sensible and reasonable. However, recent regulatory guidance in the UK (eg the FCA's FG 16/5 note on Cloud Contracts) suggested that ‘unrestricted’ audit access might be required … and it remains to be seen quite how literally this requirement/guidance will be interpreted.
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, albeit that it is fair to say that 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. However, at the same time, we are seeing a rapid development of the contracting models for such solutions, and particularly for private and/or hybrid cloud models, and we can expect this state of flux to persist for some time to come.
Kit Burden is Head of the Technology and Sourcing Group at DLA Piper and an SCL Fellow.
If you are interested in contributing an article to SCL please read these guidelines: https://www.scl.org/about/contributing