Cloud computing contracts

Types of contract

What forms of cloud computing contract are usually adopted in your jurisdiction, including cloud provider supply chains (if applicable)?

It follows from the answer to question 1 that, in the UK, contracts cover the full range of cloud service and deployment models and reflect the UK’s large and sophisticated cloud business ecosystem, including CSP supply chains.

One aspect of cloud contracting that tends to cause difficulties for cloud customers is where, as is typical, cloud contract formats are modular. This means that the provisions of the contract must be located from a combination of offline and online sets of terms or - more typically - from a combination of multiple online sets of terms, policies, etc, which users must access by clicking on different hypertext links. These sets of terms are then assembled and stipulated by the CSP to form the entire contract. In my experience, these formats and contract processes make it difficult even for sophisticated corporate customers to ascertain the full extent of cloud contracts and, in some cases, to determine what terms will govern them. In B2C contracts, and possibly where B2B cloud customers are negotiating on CSP standard terms of business, this difficulty in ascertaining applicable contractual terms could in certain circumstances ultimately result in the legal ineffectiveness or unenforceability of certain contract terms and lead to regulatory intervention.

The answers to questions 17 to 22 are based on a review and knowledge of a limited, but meaningful, range of B2B public cloud service agreements (CSAs) and related documents proposed by the major international CSPs that are available from public resources. It is beyond the scope of this work to survey a much wider range of such contracts or to segment them by deployment model, service model or specific cloud services within each service model. (Readers are referred to the work of leading UK academics, including Cloud Computing Law, Christopher Millard (ed), (Oxford University Press 2013), noting that, inevitably there will have been changes to CSA practice and terms since. I also wish to acknowledge the excellent reports and other deliverables produced by the (now decommissioned) SLALOM Project teams, which I used to sense-check my own review of the CSAs referred to above. SLALOM documentation is recommended reading for this area and may be downloaded from the links at: https://cordis.europa.eu/news/rcn/134076_en.html, using ‘slalom’ as a search term.

The answers below do not identify CSPs by name;: they reflect a composite, high-level, view of the CSAs and related materials reviewed. Moreover, they do not attempt to assess the reasonableness, fairness or validity of the terms outlined. Here, I adopt the approach taken by the SLALOM Project team: readers will be aware that, in assessing these matters, much will depend on the context of the service and deployment and service model or models adopted, the relative bargaining strength of the parties, the economic basis of the cloud arrangement, cost or no-cost, and whether it is a beta product or service, etc.

The European Commission actively promotes the development and use of fair standard cloud computing contracts and there will be further developments under this initiative (see https://ec.europa.eu/digital-single-market/en/cloud-select-industry-group-service-level-agreements).

Finally, the role of international standards will be ever more important as applied to cloud computing services, service level agreements (SLAs) and CSAs (see for cloud computing and distributed platforms ISO/IEC JTC1 SC38, https://www.iso.org/committee/601355.html).

Typical terms for governing law

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering governing law, jurisdiction, enforceability and cross-border issues, and dispute resolution?

With limited exceptions, the governing law of the CSP’s home jurisdiction or a chosen regional location will apply. For certain purposes, for example, EU data protection SCCs, the choice of governing law and jurisdiction may be those of the customer’s location. Courts (rather than arbitral tribunals) competent in the CSP’s jurisdiction are most commonly chosen. US CSPs usually require all customers to commit to compliance with applicable US export controls, sanctions and related laws and regulations.

Typical terms of service

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering material terms, such as commercial terms of service and acceptable use, and variation?

Pricing and payment

Pricing will, of course, vary depending on the deployment and service model offered, and whether the contract is formed on- or offline. Some CSPs reserve the right to vary charges for existing services. There are usually remedies for late payment, including interest and, in some cases, the right for the CSP to suspend service for payment defaults. If the customer defaults on payment when due, all CSAs reviewed entitle the CSP to terminate them (see question 22).

Suspension of service by the CSP

It is common to see suspension rights in addition to specific termination rights (and sometimes for the same or overlapping triggering events). The most typical cause for suspension is where there has been a breach by the customer or an end user of the acceptable use policy (AUP - see below), which will usually include the customer or an end user causing security risks to the cloud service, the CSP or other cloud service users, or infringing third-party rights. Suspension may be on notice or, where urgent (as in the case of security risks), without notice. In some cases, the customer will remain liable to pay the charges during the suspension period, while service credits (see below) will not accrue.

Acceptable use policy

The CSAs of all the major CSPs contain an AUP: it has become one of the defining features of CSAs in the UK as elsewhere. Readers will be familiar with the standard terms of AUPs, which address conduct by both customers and their end users in using the cloud services, and will include prohibitions on:

  • illegal activities of any kind;
  • violation of any third-party rights;
  • gaining or attempting to gain unauthorised access to any networks, systems, devices or data;
  • unauthorised disruption of any networks, systems, devices or data;
  • sending unsolicited messages or marketing; and
  • distributing malware.

As stated above and under question 22, breach of the AUP may entitle the CSP to suspend or terminate the CSA - in some cases, the breach of a single end user could result in suspension or termination. Other CSAs contain indemnities for AUP breaches. Where the AUP has been breached, or the CSP suspects it has been breached by illegal conduct, the CSP may report those activities to the authorities or interested third parties and reserve the right to cooperate with them.

Variation

One of the more disquieting terms of CSAs in the UK as elsewhere is that CSPs may without the customer’s consent vary cloud services, SLAs and other terms of the CSA - usually without any justification and in some cases even without the obligation to notify customers beforehand. Typically, when exercised, variation does not entitle the customer to terminate the CSA.

Typical terms covering data protection

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering data and confidentiality considerations?

To reflect the entry into force of the GDPR, all the major CSPs operating within, or providing services to, the EEA introduced detailed data protection and processing terms for incorporation into their CSAs, in some cases in separate addenda or supplements.

Typically, the GDPR-related terms include:

  • the allocation of processor and controller roles and functions between the customer and the CSP, with the CSP as processor and with the right for the CSP to appoint sub-processors (subject to the customer’s right to object to the appointment of new sub-processors and with concomitant sub-processor obligations);
  • the application of technical and security features provided to the customer to enable it to comply with the technical and organisational measures required by the GDPR;
  • deeming of ‘documented’ customer instructions to the CSP with regard to the CSP’s processing of customer data in accordance with the GDPR;
  • confidentiality obligations of the CSP in relation to customer data;
  • terms for the handling of data subject access requests;
  • detailed operational security provisions, including security breach notification obligations on the CSP;
  • CSP data security certification and audits;
  • provision for the transfer of personal data outside the EEA, with the incorporation of the SCCs accordingly;
  • the return or deletion of customer data on termination of the CSA;
  • obligations relating to record keeping of all processing activities; and
  • terms ensuring the processor’s cooperation with the relevant regulator in the performance of their duties.

As at the time of writing, there have been no reported legal challenges emanating from the UK to CSP GDPR terms.

Typical terms covering liability

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering liability, warranties and provision of service?

Liability

Understandably, all CSAs contain limitations and exclusions of liability: some are written from a US perspective, while others are localised. The CSP’s liability is commonly limited (sometimes mutually) to the amount of charges paid by the customer - usually during the 12 months preceding the event giving rise to liability. Liability caps of this kind are sometimes tiered by reference to different services, for example the greater of a specified monetary amount or the total charges paid, depending on the service.

Some CSAs exclude from this limitation the CSP’s liability for third-party IPR infringements (whether under an indemnity or otherwise), and for confidentiality and data protection breaches.

It is common for CSAs to exclude liability:

  • in general for indirect, consequential, incidental, exemplary, punitive or special losses or damages (even if some of those kinds of loss or damages are not recognised in the UK jurisdictions); and
  • for a range of specific losses, including loss of revenue, loss of profits, loss of customers or goodwill, loss of use of data, loss of anticipated savings, loss of the use of the cloud service, etc.

Some CSAs disclaim liability for unauthorised access to, and for loss or destruction of, uploaded content and data. In other cases, CSAs will acknowledge the CSP’s liability for content or data loss where the CSP has failed to meet its own security obligations. Many CSAs require customers to take responsibility for making backup copies of their own content and data or otherwise mitigating their own risks in using the cloud service.

Warranties and provision of service

Some CSAs contain a CSP warranty that it will deliver the services in accordance with the SLA or some other service description. Some CSAs state that cloud services are provided ‘as is’. Almost invariably, any other express or implied warranties (eg, as to fitness for purpose, satisfactory quality, non-infringement) are disclaimed to the extent permitted by law. Some CSPs specifically exclude any express or implied warranty that the operation of the cloud service or software made available through it will be uninterrupted or error-free.

Also, typical of many CSAs is that customers will not be entitled to claim for service unavailability for scheduled or unscheduled downtime or other service interruptions.

Indemnities

It is common for the customer to have to indemnify the CSP against the customer’s and any end user’s:

  • act or omission or use of the cloud service that infringes any third party’s rights;
  • breaches of the CSA generally and the AUP specifically;
  • infringement of applicable law;
  • creation or use of uploaded content; and
  • in each case where the act, omission, use, etc, gives rise to claims, costs, losses, and so on.

Where there are detailed data processing provisions, including data transfer agreements (see question 19), some CSAs will provide for customer indemnification of the CSP against breach of data protection law caused by the customer or an end user.

For the CSPs’ obligations to indemnify or (quite commonly) to defend the customer against third-party IPR infringement claims or final judgments, see question 21.

Service availability, quality, service levels and service credits

Many B2B public cloud CSAs contain or incorporate by reference specific SLAs as applicable to the service modules provided to the customer. (For an example of CSA service levels applied by the major CSPs (and some others), readers are referred to the SLALOM Project’s documentation available from the links at: https://cordis.europa.eu/news/rcn/134076_en.html, using ‘slalom’ as a search term.

The application of specified service credits is usually expressed to be the sole and exclusive remedy for service-level breaches. Some CSPs make specific claims or promises about their levels of service and are willing to enable the customer to terminate the CSA for stipulated breaches of those service levels, subject to following mandated procedures for doing so, with repayment of any prepaid charges. Many CSAs contain caps on the maximum amount of service credits allowable in a specified period.

Commonly, CSAs do not provide specific SLA breach reporting mechanisms, which would of course make monitoring and enforcing the SLA or service credit regime difficult for the customer. In other situations, customers are required, within stipulated deadlines, to follow specified procedures to report the service level breaches, as well as providing details of them for verification by the CSP, who may retain the option of rejecting the customer’s claim.

Some CSAs entitle the CSP unilaterally to vary the SLAs and service credits.

It is usual for CSAs to exclude the operation of the SLA, where for example:

  • there is a force majeure event;
  • the customer or an end user is in breach of the AUP or other terms of the CSA;
  • the services have been lawfully suspended;
  • the service outage is attributable to technology not provided by the CSP; and
  • the CSP’s systems are down for maintenance.

See also question 20 under ‘Warranties’.

Business continuity and disaster recovery

In general, unless the CSP is providing a cloud-based business continuity service, CSAs do not contain any, or in any detail, business continuity or disaster recovery terms - although it is typical for CSAs to contain force majeure provisions excusing the CSP’s performance in such cases. This is a feature of CSAs in the UK, US and elsewhere (see the useful report, Public Cloud Service Agreements: What to Expect and What to Negotiate Version 2.0 produced by the US Cloud Standards Customer Council, www.cloud-council.org/deliverables/CSCC-Public-Cloud-Service-Agreements-What-to-Expect-and-What-to-Negotiate.pdf, which may at the time of publication have been updated and available online).

Usually, the customer is expected or obliged to make its own backup arrangements to ensure continuity. Sometimes, CSAs will refer to CSPs having their own disaster contingency plans for their data centres, using redundant processing and storage capacity to back up data held in those data centres, but without any contractually binding commitment to implement such plans.

Typical terms covering IP rights

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering intellectual property rights (IPR) ownership in content and the consequences of infringement of third-party rights?

Typical terms are as follows.

  • The customer usually warrants that it owns or has all necessary rights to use its content (eg, software, data) processed by the cloud service or to grant any licences to the CSP under the CSA, and that its content or end users’ use of the customer’s content will not breach the AUP (which may entitle the CSP to suspend or terminate the CSA).
  • The customer retains IPR in the contents uploaded or created by it in using the cloud service. The CSP may use the contents to provide the cloud service or to comply with regulatory or governmental directions or orders.
  • The CSP may use without restriction any suggestions for improvements to the cloud service made by the customer, in some cases, with an obligation to assign ownership in such suggestions to the CSP.
  • The CSP reserves rights in all IPR relating to its cloud services, including IPR in the applications and infrastructure used in providing the services.
  • If the cloud services are found, or understood by the CSP, to infringe any third-party IPR, the CSP may at its discretion, and usually as a preferred remedy, procure the necessary rights for customers to continue using the services, modify the services so that they become non-infringing without any material loss of functionality, or provide equivalent services in substitution for the infringing services - or failing that, to terminate the cloud services concerned. In some cases, instead of the above ‘work around’ language, the CSP will undertake to defend or indemnify the customer against the claims, costs, losses, etc, arising from final judgments. Where CSAs are governed by the laws of a US jurisdiction, customers may find that the obligation to defend does not include the obligation to indemnify - though this is, of course, to be determined under the relevant US jurisdiction if validly chosen.
Typical terms covering termination

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering termination?

CSAs may allow termination for convenience on specified notice for both the customer and the CSP.

Either party will usually have a right to terminate for the (unremedied) material breach of the other, change of control of the other, or the insolvency of the other. There is often also a range of specific rights of termination by the CSP, including:

  • non-payment by the customer of due invoices;
  • where the cloud service is dependent on third-party IPR (eg, software) licences, when a relevant third-party licence expires or is terminated;
  • for a specified period of customer inactivity;
  • where the customer or an end user’s use of the cloud service presents a security risk to the CSP or any third party (typically contained in the AUP);
  • contravention of export and sanctions controls laws and regulations; and
  • one or more (other) breaches of the AUP or any other term of the CSA by the customer or an end user.

The consequences of termination may include:

  • the customer’s obligation to cease using or to return any proprietary material (eg, software), or to destroy any content provided by the CSP;
  • that the CSP will not erase the customer’s data for a specified period after termination, and in some cases that the customer will be entitled to retrieve its data (usually also subject to a charge by the CSP);
  • where the CSP has terminated for cause, that the customer must pay all unpaid charges for the remainder of the term; and
  • where the customer has terminated for cause, that the CSP will refund any prepaid charges for the remainder of the term.
Employment law considerations

Identify any labour and employment law considerations that apply specifically to cloud computing in your jurisdiction.

There are none that apply specifically to cloud computing.

However, depending on the cloud deployment model or service model adopted and the circumstances of the migration to cloud or the termination of the cloud service, cloud customers and CSPs should consider the application of the Transfer of Undertakings (Protection of Employment) Regulations 2006 (www.legislation.gov.uk/uksi/2006/246/contents/made), as amended by (among others) the Collective Redundancies and Transfer of Undertakings (Protection of Employment) (Amendment) Regulations 2014 (www.legislation.gov.uk/uksi/2014/16/regulation/1/made#regulation-1-2) (together, TUPE). TUPE implements in the UK the EU Acquired Rights Directive 2001/23/EC (ARD).

The application of the ARD and TUPE to, and their effect on, outsourcing are now widely understood in relation to the UK, where the government has expanded TUPE’s application to outsourced services with the intention that TUPE should generally apply to outsourcing transactions. It is worth reiterating that TUPE is mandatory law: parties cannot ‘disapply’ or contract out of TUPE.

In broad terms, where TUPE does apply, it transfers automatically by operation of law the staff from one organisation to another. Their terms and conditions of employment and continuity of service are preserved, and there are other procedural and substantive protections for the staff before and after a ‘TUPE transfer’, for example protection against dismissal and protection against changes to the transferring staff’s terms and conditions of employment. There are also prescribed consultation processes before any transfer (see generally www.acas.org.uk/index.aspx?articleid=1655). Accordingly, if TUPE applies to a cloud computing arrangement (in which one of the key drivers is cost-reduction) the financial implications for both the cloud customer and more particularly the CSP may be significant and could undermine the economics of the arrangement.

In the UK, the most relevant trigger for TUPE in the context of cloud computing will be where an in-house IT service ceases to be provided by the customer itself and is then provided by the CSP - or is migrated to another CSP after the initial cloud migration, or back to the original customer, if it wishes to resume the IT service in-house. This can constitute a service provision change under TUPE Regulation 3(1)(b). The workforce (organised grouping) carrying on the activities liable to transfer must be based in Great Britain and the principal purpose of that workforce must be to carry out those activities for the customer. In broad terms this means they must be ‘essentially dedicated’ to the customer; although they may still do work for others (TUPE Regulation 3(3); and see generally www.gov.uk/transfers-takeovers). More significantly for cloud computing arrangements, the activities to be carried out by the CSP must be ‘fundamentally the same’ as those undertaken previously by the customer’s staff (TUPE Regulation 3(2A) www.legislation.gov.uk/uksi/2014/16/regulation/1/made#regulation-1-2).

So, the threshold question in cloud computing migration is most likely to be: will the activities to be undertaken by the CSP be ‘fundamentally the same’ as those undertaken previously by the customer’s IT staff? This will come down to an analysis of fact and degree. One - and only one - factor will be a reduction in the volume or scope of work, which is likely to be the case in migration from ‘traditional’ IT activities to the cloud (see Department for Education v Huke and another UKEAT/0080/12, https://www.bailii.org/uk/cases/UKEAT/2012/0080_12_1710.html; OCS Group UK Ltd v Jones and another https://www.bailii.org/uk/cases/UKEAT/2009/0038_09_0408.html).

At first glance, IT activities or services migrated to, say, a public or hybrid cloud, from which the customer may then receive very different cloud services (at least by reference to scope and possibly volume) to the services or activities previously provided in-house, simply do not intuitively look and feel ‘fundamentally the same’ in the cloud. And - if they addressed the question at all - it would be understandable if the customer and CSP considered that the activities to be carried out by the CSP are not ‘fundamentally the same’ as the original in-house IT activities, so that TUPE would not apply. This could be a very costly mistake.

There will, of course, be other questions about which of the customer’s staff members and how many of its IT workforce are in scope for TUPE, if it is likely to apply (see www.gov.uk/transfers-takeovers).

And it is worth reiterating that TUPE can apply equally to the subsequent move by the customer from one CSP to another, or back in-house to the customer, subject to the rules referred to above.

In cloud computing arrangements, it is quite likely that the CSP will be based outside the UK or that the cloud services will be provided from an offshore location. If there is an assigned workforce based in Great Britain, TUPE can apply to such arrangements, even if the service is provided from offshore.

In outsourcing transactions, because the application of TUPE is so well settled in the UK, it has become customary for the customer and outsource provider to provide specifically and in some detail in the outsourcing contract for the legal, regulatory and financial implications of TUPE - allocating duties, risk, costs and liabilities between them. In public and hybrid cloud contracts, the issue is often simply not considered and, therefore, is not provided for, most probably because the parties do not expect that TUPE will apply to such cloud arrangements or because CSPs that are based outside the EU are unaware of the ARD and TUPE.

For the reasons given above, neither CSPs nor their customers should assume that TUPE cannot or does not apply in relation to any of the cloud deployment models or service models. They should at least consider the question and take advice accordingly.