Bip 0117-2015

Cloud Computing
A Practical Introduction to the Legal Issues

Cloud Computing
A Practical Introduction to the Legal Issues
Renzo Marchini
First published 2010
Second edition 2015
by
BSI Standards Limited

389 Chiswick High Road
London W4 4AL
© The British Standards Institution 2015
All rights reserved. Except as permitted under the Copyright, Designs and Patents
Act 1988, no part of this publication may be reproduced, stored in a retrieval
system or transmitted in any form or by any means – electronic, photocopying,
recording or otherwise – without prior permission in writing from the publisher.
Whilst every care has been taken in developing and compiling this publication, BSI
accepts no liability for any loss or damage caused, arising directly or indirectly in
connection with reliance on its contents except to the extent that such liability
may not be excluded in law.
While every effort has been made to trace all copyright holders, anyone claiming
copyright should get in touch with the BSI at the above address.
BSI has no responsibility for the persistence or accuracy of URLs for external or
third-party internet websites referred to in this book, and does not guarantee that
any content on such websites is, or will remain, accurate or appropriate.
The rights of Renzo Marchini to be identified as the authors of this Work have
been asserted by them in accordance with sections 77 and 78 of the Copyright,
Designs and Patents Act 1988.
Typeset in Great Britain by Letterpart Limited, www.letterpart.com
Printed in Great Britain by Berforts Group, www.berforts.co.uk
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
ISBN 978 0 580 82246 9

Contents
Acknowledgements ix
1 Introduction 1
1.1 Preliminary comments 1
1.2 History and development 2
1.3 What is cloud computing? 4
1.4 Cloud service types 5
1.5 Deployment models 7
1.6 Technological terminology 9
1.7 Comparisons with other types of IT services 10
1.8 Why now? 11
1.9 Overview of this book 12
1.10 Contracting for the cloud 13
2 Which law of the cloud? 15

2.1 Introduction 15
2.2 International disputes as to applicable (cloud) law 16
2.3 Which law applies to the cloud? 18
2.4 Law enforcement agencies’ ability to obtain data 21
2.5 Key points 27
3 Information security 28
3.1 Introduction 28
3.2 What is a security breach? 29
3.3 Security breaches – some examples 29
3.4 Due diligence 33
3.5 Introduction to security standards 37
3.6 ISO/IEC 27000 series 38
3.7 SSAE 16 (previously SAS 70) 46
3.8 Contractual issues in information security 48
3.9 Key points 53
4 Data protection: basics 55

4.1 Introduction 55
4.2 The basic structure of data protection law 55
4.3 A new data protection regime 56
4.4 Personal data 57
4.5 Data controllers and processors 59
4.6 Jurisdictional issues 65
Cloud Computing v
4.7 The eight data protection principles 69
4.8 Legitimization of processing 69
4.9 Notification to the Information Commissioner’s Office 71
4.10 Enforcement 72
4.11 How does all this apply to the cloud? 76
4.12 Key points 76
5 Data protection: appointing a cloud provider 78

5.1 Introduction 78
5.2 European regulators and cloud services 79
5.3 Cloud provider as a data processor 79
5.4 Cloud provider as a data controller 81
5.5 Can personal data be put into the cloud? 81
5.6 Pre-contract due diligence 82
5.7 Ongoing monitoring requirements 84
5.8 Is there any obligation to tell data subjects? 85
5.9 Key points 85
6 Transfers of data to non-EU cloud providers 86

6.1 Introduction 86
6.2 Onward transfers by the cloud provider 87
6.3 Countries (or sectors) deemed automatically ‘adequate’ 88
6.4 The US Safe Harbor scheme 89
6.5 Standard clauses 97
6.6 Self-assessment 101
6.7 Binding corporate rules 105
6.8 Authorization 112
6.9 Other derogations 112
6.10 Key points 113
7 Data security breach notification in the cloud 114

7.1 Introduction 114
7.2 The US position 114
7.3 Data breach notification in the UK and Europe 115
7.4 ICO guidance on data security breach management 116
7.5 Specific UK sectors 117
7.6 Application to the cloud 119
7.7 Key points 120
8 Data protection: the proposed reforms and the cloud 122

8.2 Consent 122
8.3 Territorial scope 122
8.4 Main establishment 123
8.5 The right to be forgotten and to erasure 123
8.6 The right to data portability 124
8.7 Data protection by design and by default 124
vi Cloud Computing
8.8 Representatives of controllers not established in the European
Union 125
8.9 Data processors 125
8.10 Documentation 125
8.11 Notification of personal data breaches 126
8.12 Data protection impact assessment 126
8.13 Data protection officers 126
8.14 General principles for transfers to third countries 127
8.15 Sanctions; fines 128
9 Software licensing and the cloud 129

9.2 Moving existing licensing structures to the cloud 129
9.3 Open source and the cloud 132
9.4 Software escrow in the cloud 136
9.5 Key points 139
10 Customer data: the provider’s use of data, access to

data and lock-in 140
10.2 The provider’s use of its customers’ data 140
10.3 Access to data on exit 142
10.4 Key points 149
11 Service definition – the provider’s ability to change the

service 151
11.2 A comparison with software licensing 151
11.3 From the provider’s perspective 152
11.4 From the customer’s perspective 153
11.5 How to deal with service change in a cloud contract 153
11.6 Key points 156
12 Service levels 157

12.2 Typical service metrics 159
12.3 Availability 160
12.4 The consequences of missing service levels 162
12.5 Standard exceptions 164
12.6 Drafting issues around SLAs 167
12.7 Termination for failure to achieve service levels 170
12.8 Standardized SLAs? 171
12.9 Key points 171
13 Liability issues 173

13.2 Exclusions of liability 174
Cloud Computing vii

13.3 Limitations of liability 175
13.4 Chains of liability 176
13.5 Statutory and judicial control on liability exclusions 176
13.6 Key points 181
14 Specific sectors 183

14.2 Financial services 183
14.3 Cloud services in the public sector 189
14.4 Consumer cloud 192
14.5 Key points 201
15 Tax considerations 203

15.2 Possible tax benefits of using the cloud 204
15.3 Determining the nature and source of the supply 204
15.4 VAT and sales taxes 206
15.5 Withholding tax 208
15.6 Permanent establishments 208
15.7 Transfer pricing 209
15.8 International tax developments 210
15.9 Key points 212
16 The future of cloud law 213

16.2 Open cloud 213
16.3 Development of industry standards and codes of practice 214
16.4 Developments in data protection law 215
16.5 The European Commission cloud initiatives 216
Glossary 219
References 222
Index 227
viii Cloud Computing

Acknowledgements
I am grateful to my colleagues Daniel Hawthorne, a tax specialist at

Dechert LLP in London, for contributing Chapter 15 (Tax considerations)
and Richard Heffner, a financial services regulatory expert also at Dechert
London, for his contributions to the section on cloud in financial services
that appears in Chapter 14. Thanks also to Alexis O’Farrell, Amy Rees and
Madeleine White, trainee solicitors at Dechert, who provided valuable
assistance.
Cloud Computing ix
1 Introduction
1.1 Preliminary comments

There is no universally accepted definition of ‘cloud computing’ and the
term means various things in different contexts and indeed to different
people. It is a paradigm shift in how computer resources are acquired.
Some doubt that there is anything new about the cloud, pointing out the
fact that many of the features which are said to be part of this paradigm
have in fact existed for quite some time in other (non-cloud) technologies
and services.
A fuller definition of the terminology necessary to serve the aim of this

book is set out further on. However, in summary, cloud computing refers
to the delivery of computing capability (whether of an application
software variety, an infrastructure delivery, or otherwise) by a provider
remotely over a communications link, allowing for no actual installation
(of the software or the infrastructure) at the customer site.
It is not only enterprises that are using cloud services. The history of the
consumer cloud is intimately linked to the history of the internet. Many
common and well-established web services, such as email services (e.g.
Outlook.com) and photo-sharing services (e.g. Flickr), have existed since
the early days of the web, but over the past few years the willingness of
consumers to trust often quite sensitive personal information to social
networking sites (Facebook, LinkedIn, Twitter and others, all of which are
‘cloudy’ in nature) has taken the trust to a new level.
This book attempts to identify, discuss and elucidate many of the

common legal issues that arise from this paradigm shift. It is intended to
be practical and assumes very little by way of legal knowledge. In respect
of the more difficult legal issues (such as perhaps data protection and
security), a practical understanding necessarily depends on a fuller
exposition of the underlying law – which is provided – but again it is
hoped that the end result is nonetheless useful to those not legally
qualified.
One of the problems with analysing cloud issues from a legal perspective
is the multinational aspect: the fact that many countries may be involved
in a particular cloud provision. A customer in country A, for example,
may use a SaaS (software as a service) offered by a provider in country B,
which in turn acquires infrastructure capacity in countries C, D and/or E
Cloud Computing 1
1 Introduction
(depending on the current price in each). Whilst this book is based on

English law, many of the issues that arise (in particular in relation to risk
allocation and service provisions in contracts) will be common across
different legal systems. The issues surrounding data protection discussed
in Chapters 4 to 7 are very similar throughout Europe as a result of the
adoption of harmonized data protection rules (contained in the
European Data Protection Directive [1]). Issues such as service description
(Chapter 11) and service levels (Chapter 12) are matters of technical
capability, business assessment, negotiation and risk, and are largely
independent of the law of the country in which either the customer or
the provider reside. As such, non-UK readers may also find them
interesting.
Whilst this book is intended as a practical guide to these issues, it goes

without saying that it is no substitute for considered legal advice.
1.2 History and development

For present purposes, the history of computing could perhaps be
summarized as follows:
• 1940s to 1950s: early beginnings in isolated research centres;

• 1960s to 1970s: mainframe computers and dumb terminals; bureau
processing;
• 1980s: the rise of the PC and Microsoft; standardization of hardware;
the rise of independent software vendors; commencement of
large-scale outsourcing;
• 1990s: the advent of networking and the internet; dot-com boom;
application service provision;
• 2000s: dot-com bust; the distribution of ever-increasing accessibility
through broadband and Wi-Fi; the rise of Google and the consumer
cloud;
• 2010s: virtualization; green computing; the rise of the business cloud.
As this very approximate timeline is examined, it is possible to detect a

number of characteristics relevant to why the cloud is happening now.
First, it is notable that in the early days of computing, hardware
manufacturers were the dominant players, and software languages were
tailored for specific machines. Computing power was concentrated in the
few and the idea of processing data through a remote service (a bureau
service) was not controversial (as it is now), simply often a necessity. As
time progressed, it was possible for entities to handle internally their
own IT requirements and the in-house IT department was born. Time
moved on again and it was recognized that that is not often very
efficient. Computing could be left to the experts and outsourcing (in
many guises) began. Cloud computing can be seen as just one type of
outsourcing, and indeed there are some who consider there to be little
2 Cloud Computing
1.2 History and development
difference between what is now labelled ‘cloud’ and what went before,
and that there is simply a hype surrounding it.
In the first edition of this book we pointed out that Larry Ellison, the
CEO and founder of Oracle, for one, had been very critical of the hype
surrounding cloud computing. He had given a number of widely quoted
interviews, including one in 2008 in which he made the point that the
definition is so wide that it includes everything that Oracle actually does,
comparing it disparagingly to women’s fashion and referring to it as
‘complete gibberish’.1 At the time of writing, however, even Oracle gives
pride of place on its website to its cloud offerings.
Others, implicitly recognizing that there was something new happening,

have been critical of the movement. Richard Stallman, the founder of the
GNU project and open-source software pioneer, has called cloud
computing ‘stupidity’2 – a means for the gullible to be locked into
particular providers (once those providers have the user’s data in a
proprietary format). The issue of provider lock-in is explored in Chapter
10.
Whether or not there is a real paradigm shift might depend on the type
of cloud service that is being talked about. As the brief timeline above
shows, the idea of obtaining use of a software application remotely is as
old as computing; early software use involved access to mainframes with
distributed dumb terminals or to data-processing power through bureau
services. So, in a sense, at least one of the types of cloud services (SaaS)
might be nothing particularly new from what has gone before but with
one important distinction – the distinction of scale. It has simply become
more prevalent. As such there is at least a germ of truth in what Larry
Ellison said: much of it has been done before. Other types of cloud
offering, for example, the idea of acquiring server capacity in a
‘utility-like’ manner (IaaS – infrastructure as a service), paid for as you go
and scaled as you need, may well represent a fundamental shift in the
acquisition of technology motivated by many concerns: cost pressures,
economies of scale, energy efficiency.
More pertinent perhaps is the issue not so much of whether this is hype,
but rather – even if it is hype – why it is happening now. Arguably, it is
happening now because it is a real phenomenon driven by a desire to
minimize computing costs, have flexibility and be more efficient – a
desire matched by IT providers tailoring their offerings on the back of
easily accessible high-speed connectivity through the internet and
otherwise.
It seems likely that, new or not, the cloud is here to stay.
1
Larry Ellison, Oracle OpenWorld, 25 September 2008.
2
The Guardian, 29 September 2008.
Cloud Computing 3
1 Introduction
1.3 What is cloud computing?

There are many different views on the question, including much
academic, technical and business disagreement as to what the salient
features are. For present purposes, broadly, cloud computing refers to the
delivery of computing capability by a provider remotely over a
communications link. It comes in many different varieties, serving a wide
variety of computing needs, and there are inevitably arguments and
discussion over what are the essential elements of a cloud offering. The
following are the most important features that trigger the application of
legal issues dealt with in this book. A typical cloud offering will involve
(some if not all of) the following features:
• there will be no actual requirement for software installation at the

customer site (except for a standard internet browser);
• the customer will be using software operated by the provider on
servers controlled by the provider (or by a subcontractor on behalf of
the provider);
• the customer can pay on a usage basis;
• the delegation to the provider of responsibility for keeping software
up to date;
• the delegation to the provider of responsibility for keeping data
secure; and
• the delegation to the provider of responsibility for managing the
hardware.
This list is not set in stone and not all of these features are essential;
many offerings that are properly called cloud may omit one or more.
Some would argue that the list is too short and, for example, that an
important feature of a genuine cloud offering is that there is in fact no
clearly allocated server for a particular customer and/or that different
customers are serviced using the same ‘instance’ of the software in a
multi-tenancy model. Where a particular feature’s presence or absence is
important to a particular issue that is covered in this book, then that will
be made clear.
A basic categorization is between, on the one hand, a cloud service that

provides use of software remotely and, on the other hand, a cloud
service that provides use of hardware or other infrastructure components.
The next sections explain expressions that are frequently used to describe
some of the different aspects of cloud. Some identify the type of service,
others the deployment models of the service, and, lastly, some identify
different technologies involved.
4 Cloud Computing
1.4 Cloud service types
1.4 Cloud service types

A number of terms are frequently used to describe the cloud service
types, as follows.
1.4.1 SaaS – software as a service

The quintessential cloud offering: application software is no longer
downloaded or installed onto the user’s computer (server or PC) but
instead is provided remotely by the provider, perhaps through a web
interface. It is subscribed to, not licensed.
It can be provided to enterprises (the main focus of this book) or to

consumers.
There are a myriad of examples. An extremely common enterprise

solution is Salesforce.com’s customer relationship management (CRM)
service. Microsoft Office 365 allows the remote usage of the Microsoft
Office suite of programs (by both enterprises and consumers). Google
provides Gmail (again, for use by either enterprises or consumers). There
are online storage services such as Dropbox, Microsoft OneDrive and
others (often built on Amazon’s IaaS solutions).
There are, of course, also SaaS solutions tailored to very specific

industries, such as supply chain or financial services.
Many of the most successful consumer-facing applications (Facebook,

iCloud, Twitter and so on) are SaaS.
1.4.2 IaaS – infrastructure as a service

The idea here is that the hardware (or other infrastructure) needs of an
organization are met remotely by the provider. The provider takes
responsibility for the customer’s processing needs, normally of servers but
perhaps also of storage devices. Web hosting services (where a company’s
websites would be hosted by a specialist company) have always been, in
a sense, a very simple type of IaaS – a server being provided for the
specific need of giving the customer a web presence. However, that
concept has now evolved so that the servers on which the site is being
hosted will be ‘virtual’ and ‘scalable’. In this regard, a term that is often
seen is ‘cloud hosting’, a type of IaaS, providing the benefits of scalable,
on-demand and – say the providers – low-cost web hosting to many
companies.
IaaS is wider than simply web hosting. The widest variety of hardware,
and for the widest range of uses, is available. Amazon’s cloud offerings
are prominent examples: the Amazon Simple Storage Service (Amazon
Cloud Computing 5
1 Introduction
S3) provides a cloud storage service, whilst Amazon Elastic Compute

Cloud (Amazon EC2) provides server capacity.
1.4.3 PaaS – platform as a service

This offering allows users to develop their own applications based on a
cloud infrastructure acquired as an IaaS offering. The application can be
either used internally by the user for their own needs or provided
externally to others as a SaaS. The latter is the common use. A potential
provider of a SaaS will of course still need infrastructure upon which it
can operate its software for its customers. It could take a two-step
approach: first, develop its own software in a traditional manner and
then, secondly, deploy it on an IaaS offering acquired from elsewhere. A
PaaS solution brings these two steps together. An additional layer (the
‘platform’) of software is provided over and above the infrastructure that
appears in IaaS. This platform allows the customer to develop its own
software application (with the provider’s development tools) and deploy
that software application through the infrastructure. Whilst clearly of
immense use to smaller businesses keen to set up a cloud business with
minimal effort and investment in more traditional development tools, an
overriding issue for many in using this type of offering is the fact that
the application thus developed will then only be capable of running on
that particular cloud platform. There is therefore a particular and
pronounced issue of vendor lock-in. Prominent examples are Google App
Engine and Microsoft Azure.
1.4.4 Utility computing

The idea behind utility computing is that computing technology can be
switched on and off in much the same way as electricity and other
utilities. For the purpose of this book, the term adds little to what is
included within the term ‘IaaS’.
1.4.5 Grid computing or distributed computing

This is a type of computing network where the capacity of a large
number of computers accessed through a network is available to
particular types of users. University and scientific computing capacity is
often structured in this manner so that heavy processing tasks (e.g.
meteorology) can make efficient use of vast computing resources when
they might otherwise be idle. Another example of this, which has
captured the popular imagination, is the Search for Extraterrestrial
Intelligence (SETI@home) project, where a great quantity of data from
radio telescopes gathered by astronomers is sent out to numerous home
computers. The software on the home computers runs when the screen
6 Cloud Computing
1.5 Deployment models
savers are on (or the computers are otherwise idle) to try and detect
patterns in the data that might indicate extraterrestrial life.
1.4.6 Other cloud service types

The computing industry seems to know no bounds in creating new ‘as a
service’ (‘aaS’) terms, and the following are all beginning to appear in
literature: business (or business process) as a service (BaaS), storage as a
service (StaaS), security as a service (SECaaS), desktop as a service (DaaS)
and so on.
1.4.7 A stack of services

Figure 1 illustrates how different types of providers can in fact ‘sit on top
of each other’. An understanding of the existence of this stack is
important as it determines, for example, where in fact the customer’s
data might be. The customer will ordinarily only contract with one party;
when it is acquiring a SaaS, it will only contract with the person at the
top of the diagram. The data might, however, be in the actual possession
of the IaaS provider (and, to complicate matters, there could be a
subcontractor below that provider).
1.5 Deployment models

There are terms that define the type of person to whom a particular
service is deployed (whether SaaS, PaaS or IaaS), as follows.
1.5.1 Public cloud

Most cloud services are used by anyone willing to acquire them, and this
is what is meant by a ‘public cloud’ offering.
1.5.2 Private cloud (sometimes called an ‘internal cloud’)

Some aspects of cloud computing can be adopted without involving an
external provider. A private cloud is when cloud-like services are deployed
within a large group, say, by a dedicated service company providing
software or infrastructure services remotely, that is usable by any of the
members of that group. Some commentators would add a requirement
that there must also be dynamic availability (depending on demand) of
applications or resources before the offering is truly a private cloud. For
some organizations, a private cloud may initially be a stepping stone on a
transition path to use of a full cloud offering.
Cloud Computing 7
1 Introduction
Figure 1. Different types of offerings built on top of each other
1.5.3 Community cloud

A cloud service used by a specific group of persons (the members of a
particular community).
1.5.4 Hybrid cloud

When an organization uses more than one type of cloud (or more than
one offering from different cloud providers), it is using a hybrid.
1.5.5 Consumer cloud

Many of the services used by consumers on the internet are cloud
services. Social networking sites involve the consumer storing their
(sometimes very) personal data on services under the control of
Facebook, LinkedIn and the like. Likewise, email services such as Gmail
are true cloud services. Of course, consumers do not use those expressions
and might not consider such issues as data security and server location.
8 Cloud Computing
1.6 Technological terminology
1.6 Technological terminology

The cloud model brings with it a number of technical terms (describing
particular technologies that may feature in different services or
deployments), which will need to be understood by those navigating the
legal issues.
1.6.1 Virtualization
This term normally describes a technology under which software that an
enterprise needs runs not on a specific server, but on a ‘virtual’ server.
Many IaaS depend on this technology (but they are not synonymous). The
virtual server might be spread across a number of different physical
servers, and the IT infrastructure manages the load (dynamically and
invisibly to the applications themselves and certainly the users) to ensure
that the most efficient use of the underlying physical computing power is
made. The term can also cover the reverse situation where a number of
different virtual servers operate on one physical server. Whilst common in
IaaS offerings, a virtualized infrastructure can also be implemented by
the enterprise’s own IT department (perhaps as part of a private cloud,
even if that term is not used).
Virtualization software exists for home consumers’ use also, allowing the
host desktop to appear as a number of different virtual PCs.
1.6.2 Multi-tenancy
This is a term that describes how a particular ‘instance’ of software
running on a server (or servers) is used by the cloud provider to provide
services to many of its customers. It is an important concept as it appears
time and time again in contract negotiations in relation to cloud
offerings; in particular, it will often be used by service providers to justify
many of the stances they take in their contract terms.
The basic idea is that the same copy of the software is running data for
many customers at the same time (which would clearly not be the case if
each of those customers installed its own copy of the software on its own
hardware).
Given the importance of the concept, a further word of explanation

might be helpful for the non-technically minded. In a traditional
deployment of software, when software is run on a computer internal to
an organization (this is a simplification), one copy of the software is
brought into the memory of the computer (from the hard drive) and that
copy accesses and processes that organization’s data. That is one
‘instance’ of the software in memory. Another customer using the same
software may well be using the identical software (in the sense of the
Cloud Computing 9
1 Introduction
same version number) but it will be a different instance (not least

because it is on a different computer).
Now assume that the software is provided remotely by a SaaS provider.

The provider might run the same program a number of different times
(multiple instances) concurrently on the same server; each instance would
process different data for different clients. However, it would also be
possible for the provider to run just one instance to simultaneously
process two different sets of data (for two different clients). Each set of
data in this scenario is a ‘tenant’ in the instance, hence ‘multi-tenancy’.
Naturally, as the two sets of data might belong to separate clients,
security and a proper segregation of data within the one instance is
paramount. It should be noted though that the segregation of data here
would be ‘logical’, not physical.
1.7 Comparisons with other types of IT services

Cloud computing may well be new, but various aspects of this model do
feature in other more traditional types of IT offerings – from the recent
past (out of which cloud computing may have in part evolved) but even
from the more distant past. As such, many of the legal issues that arise in
cloud computing will be familiar from these other scenarios. With that in
mind, and with a view to applying legal principles that have been
applied to these other types of IT offerings, it will be useful to identify
similarities and differences between cloud computing and those offerings
with which cloud computing shares features.
1.7.1 Outsourcing
Outsourcing involves the handing over of an IT function previously
provided internally to an external provider. It might involve the
outsourcing of the whole IT department (data centres, all support staff,
in-house development teams and so on) but might be more limited. It
can be similar to IaaS (as the provider will manage the infrastructure) and
to SaaS (as software functionality may be served to the customer
remotely). The provider will of course have to handle security. It might
also (depending on what is outsourced) involve the creation of
applications and the delivery of software to users and so be similar to
PaaS.
1.7.2 Managed services

This is a type of outsourcing where servers and software are managed
remotely from the customer by the service provider. Similar in some
instances to an IaaS, the provider will provide remote access to the
10 Cloud Computing
1.8 Why now?
service, manage the infrastructure, and have actual possession of data. It

does not necessarily involve (but can have) virtualization. When there is
virtualization, it can have usage charging models. The location of the
data centre is usually known.
1.7.3 Batch computing/service bureau

An example from the earlier days of computing, this is the provision of
remote data processing by dedicated software on servers. Customer data
is input, processing is carried out, and data is returned to the customer
(or action is undertaken). Similar in some instances to a SaaS, data is held
by the provider and the provider keeps software up to date. Again, the
location of the data centre is usually known.
1.7.4 ASP – application service provision

A term (from the late 1990s and early 2000s) that is not used often now,
but in essence is simply SaaS. An application is provided as a service
remotely.
1.7.5 Client/server
A software architecture that divides processing between a client (or
clients), which requests the service, and a server, which fulfils it (or them).
It is similar (and an early precursor) to SaaS, at least when the
architecture is used externally. When used internally, it is similar to SaaS
on a private cloud. Normally, the server and client side are managed by
the same person and that is perhaps a distinction to be drawn.
1.7.6 Conclusion on differences

As can be seen, therefore, many cloud computing features existed in
pre-cloud computing days. The one feature that is definitely new is that
which – as we will see – presents the greatest difficulty: the customer
does not necessarily know where the data is. Other parts of the paradigm
are familiar from, and the legal issues that arise are similar to, what has
gone before. Data in outsourcing, for example, is held by a provider that
takes care of security, service level commitments are necessary, and so on.
1.8 Why now?

Whilst it is probably true that SaaS has been around for a while, there
are a number of reasons as to why the concept of cloud computing has
Cloud Computing 11
1 Introduction
attracted such traction recently. First, the size of the players involved
means that anything they do will have serious and widespread
repercussions. Amazon (and its like) has built such large data centres,
literally the size of many football pitches, to fulfil its requirements.
Naturally, its requirements for IT resources vary over time, with peak
demand, in particular, around Christmas (in common with many retailers).
But it is not just around the holidays; demand varies throughout the day
and over the week. Amazon identified that it had to do something with
its spare capacity and began in 2006 to offer that capacity to other
businesses through its Amazon EC2 service, allowing them to acquire
infrastructure on a pay-as-you-go model. Where Amazon led, many other
IT giants (for example, Google and Microsoft) followed.
A second reason as to why there is at present such an acceleration into

the cloud is the recognition by many users of technology of the wastage
in their own server capacities, and thus a drive towards the saving of
costs. Linked to the cost saving is the current green agenda and a move
towards ‘green computing’. This latter term aims to identify an
imperative to be more eco-friendly in sourcing computing power. It has
been estimated that a typical business using its own infrastructure is
wasting at least 75 per cent of the capacity it has for storage and 85 per
cent of the capacity it has for processing power. Sharing resources is a
way of more efficiently using computing technology.
Thirdly, the cloud computing model allows for a very large economy of
scale and that too has had a major impact as IT budgets increasingly take
a bigger share of a company’s cost base.
Lastly, it is quite simply becoming technically possible. Broadband is

widespread and now reliable, leased lines are prevalent, and it is ever
easier for businesses to make the leap and trust the remote provision of
services.
1.9 Overview of this book

This book is intended to be a practical introduction on legal issues in
cloud computing suitable for those either providing such services or
considering an acquisition. It is hoped that it will be of interest to anyone
navigating the difficult legal issues that might arise, lawyers and
non-lawyers alike. Where the legal issues that arise depend on some
background knowledge, not much is assumed. Instead, a short
introduction is provided so as to make the discussion as self-contained as
possible.
In any cloud situation, in order to navigate the various legal issues that
might arise, it is important first to identify the relevant body of law that
applies. We address this issue in Chapter 2.
12 Cloud Computing
1.10 Contracting for the cloud
The next series of chapters deal with information security (Chapter 3) and
then data protection in Chapter 4 (basics), Chapter 5 (putting personal
data into the cloud), Chapter 6 (moving personal data outside of Europe)
and Chapter 7 (data breach notification). Chapter 8 highlights a
potentially significant reform of European (and therefore UK) data
protection law that is expected over the next couple of years.
We then move onto issues that arise as a result of contracts. Chapter 9

deals with software licensing issues (including issues around moving
legacy systems onto cloud infrastructures and open source). In Chapter 10
we deal with a number of issues relating to customer data. Sometimes
providers want to use data for their own purposes; this can be
controversial and is explored here. It also covers the critical issue of
provider lock-in and access to data. Chapter 11 covers issues relating to
definition of the service and the ability of the provider to change the
service, whilst Chapter 12 deals with service levels and service credits. A
provider’s ability to limit its potential liability by contractual language is
dealt with in Chapter 13. In Chapter 14 we move to issues that arise in
specific sectors (financial services, the public sector and consumers).
Chapter 15 (contributed by my colleague Daniel Hawthorne) deals with
tax issues. Finally, in Chapter 16 we look to the future of cloud law.
1.10 Contracting for the cloud

One further point should be noted at this stage. Throughout this book
we discuss how a contract might deal with a particular issue to address a
concern of the customer and how the customer might want to critically
review language suggested by the provider. Implicit in this discussion is
the idea that the provider will entertain a request that the contract be
negotiated. It is worthwhile exploring, therefore, the extent to which
contracts are being negotiated.
One aspect of cloud computing that is often cited as being different from
other outsourcing deals is the take-it-or-leave-it aspect of the provision.
In keeping with the commercial and technical advantages of the solution
being easy to set up, easy to scale and easy to control charges, it is also
equally easy to contract: a customer simply accepts the provider’s terms
without question. This is very true in relation to many services available
at relatively low cost and possibly without any interaction except through
the provider’s website. It is not however true of substantial acquisitions
by enterprises. Contracts are still individually negotiated. Many cloud
providers may present their contracts as standard and not invite
negotiation. Nonetheless, customers can request changes to the
‘standard’. Whether the provider agrees to those requests will depend on
the negotiating power of the customer. Consumers and most small
businesses, each acquiring a very standard cloud offering, will have no
scope for negotiating terms. That is not the case for substantial
Cloud Computing 13
1 Introduction
enterprises negotiating as equals with a cloud provider. The bigger the

potential contract, the greater the scope for the cloud provider to move
from its standard position to secure the deal.
14 Cloud Computing
2 Which law of the cloud?
2.1 Introduction
Laws differ from country to country. The nature of the cloud is that it is
extremely likely that more than one country is involved in a particular
cloud deployment (unless a customer can be confident that its provider
and the underlying data centre, which may be that of a subcontractor,
are all in the same country). Therefore, whenever the legality of any
activity is questioned, or consideration is given as to how to roll out a
service or acquire a compliant service, it is important to first identify the
relevant law that applies, in order to make an assessment as to what the
law says. More than one law may apply. For example, to answer the
question ‘What are the legal requirements relevant to security?’ or ‘Is my
data in danger of being disclosed to a law enforcement agency?’, you
first need to identify the legal system to apply. In the cloud, not only may
activities take place across a number of borders, but also it may not even
be possible to identify the country in which some aspects of the activity
take place. So, for example, if the customer is in the UK, but the provider
is in California, is security assessed under UK standards or Californian3
standards?
In a typical cloud scenario (to the extent there is such a thing) there are
at least four legal systems contending for consideration. The law to
consider might be the legal system of the country where the cloud
customer is, where the cloud provider is, where the data is stored, and
perhaps (where that data is personal data about an individual, such as an
employee or a client of the cloud customer) that of the individual.
In any field (not just cloud computing) such questions are frequently
resolved by reference to one of a number of international treaties often
– from the perspective of a UK company – passed at the European level
(but some have wider reach or are bilateral). Two prominent examples
are the European instruments known as ‘Rome I’ [2], dealing with the
law that is to apply to a contract, and ‘Rome II’ [3], dealing with the law
to apply to non-contractual obligations (‘torts’, such as negligence). These
instruments are general in the sense that they apply to all types of
activities and not only to cloud computing. In relation to any complex
issue involving more than one country (and therefore a ‘choice of law’), a
two-stage approach is needed to the analysis of the issue. First, these and
3
The US has different legal systems in each of its 50 states.
Cloud Computing 15
other such instruments will need to be consulted to determine which

country’s laws are involved. Only then can that country’s laws be applied
to the issue. It goes without saying that the laws are not created
specifically with cloud services in mind and therefore given the character
of the cloud it is not always possible to give definitive answers to the
issues that may arise. A discussion of these issues (even as they apply to
the cloud) quickly gets very technical and as such is beyond the scope of
this book. But a brief description may be helpful.
In addition, there are some international legal instruments that are

specifically tailored to specific activities. Two such instruments that are
relevant in this context are the Ecommerce Directive [4] and the Data
Protection Directive [1].
We begin, however, with some examples that show how these issues are
not theoretical. Disputes as to applicable law have already arisen.
2.2 International disputes as to applicable (cloud)

law
Although there are few real incidents of such ‘conflicts of law’ in the
business cloud area, there have already been a few prominent cases in
the consumer cloud field. Amongst the stories that made the news in the
past few years are Yahoo! in Belgium and Google in Brazil, which are
both examples of US cloud providers being compelled to give up data
(which was outside that country) by the courts of a country into which
they are selling services. Most recently, Facebook successfully argued in a
German court that Irish law should govern its activities to the exclusion
of German law. Google, however, was recently found to be subject to
Spanish data protection laws.
2.2.1 Yahoo! in Belgium

Belgian fraud investigators were investigating people who used the
Yahoo! mail service (a consumer cloud offering) in order to engage in an
online crime. The service was sold from the US into Belgium. The
investigators asked Yahoo! to help identify the criminals by giving up
whatever data it had relating to their registration on the service. Yahoo!
refused. It argued that as it was a Californian company the investigators
should proceed through a formal treaty and seek the assistance of the US
authorities (who definitely had jurisdiction over Yahoo!). Yahoo! had no
actual presence in Belgium and did not actively market in Belgium. Its
service is open to people in any country of the world and it has no means
of verifying in what country the user actually resides. The Belgian law
enforcement agencies responded that Yahoo! was also a Belgian
company as its services are available in Belgium. Whilst in March 2009
16 Cloud Computing
2.2 International disputes as to applicable (cloud) law
Yahoo! was fined for failing to hand over the details, this was overturned
on appeal in June 2010. It was widely reported in the press that the
Belgian Court of Appeal in Ghent broadly agreed with Yahoo!’s
arguments.4
2.2.2 Google in Brazil

In August 2006, a Brazilian court ordered Google to release information
on its social networking site (Orkut), and stated that it would face a
$23,000 a day fine until such data was released. The information was said
to be useful in finding criminals who had been using the service for
criminal activities (child pornography and selling drugs). Similarly to the
Yahoo! case just mentioned, Google argued that it could not do so on
the grounds that the requested information was in the US and was
therefore not subject to Brazilian laws. Despite arguing this point,
Google negotiated with the relevant Brazilian authorities and eventually
it provided the Brazilian police with access to data by means of a special
administration tool for deleting or blocking illegal content.5
In July 2008, it was widely reported in the press that the Brazilian
authorities and Google reached an agreement to try and prevent illegal
material on Orkut. The agreement, which may well have been the first of
its kind internationally, stated that Google would employ filtering
technology to block and remove illegal content on Orkut; it would also
provide evidence in suspected crimes against minors when presented with
a Brazilian judicial order, without requiring international legal
manoeuvring.
2.2.3 Facebook in Germany

Facebook is of course a US-headquartered company doing business all
over the world. Within Europe it has a subsidiary in Ireland. In 2013 a
German court ruled,6 contrary to the argument of a German data
protection regulator, that Irish data protection law applied and not
German. Facebook had a policy requiring users to register with live data.
The data protection authority for Schleswig-Holstein ordered Facebook to
permit registrations with pseudonymized data (which was a requirement
of German data protection rules).
4
The judgment is only available in Flemish.
5
http://www.cio.com/article/2444750/security-privacy/brazil-judge--google-must-hand-over-
orkut-user-data.html and
http://www.theguardian.com/technology/blog/2006/aug/23/googleturnsdo
6
Facebook Ireland Ltd. and Facebook Inc. v Data Protection Commissioner for
Schleswig-Holstein, Administrative Court of Schleswig-Holstein, file no. 8 B 60/12 and 8 B
61/12
Cloud Computing 17
Facebook pointed at the fact that the service in Europe was offered by its
Irish affiliate and that as such it was only subject to Irish law (applying
the specific jurisdictional test for data protection which we summarize –
from a UK perspective – in 4.6). The data protection authority in turn
pointed towards the existence of a German Facebook company. However,
this company was only involved in marketing activities (and not in the
collection of data) and so its presence was irrelevant. The regulator also
argued on the basis of ‘Rome I’ [2] (see 2.1) that Facebook’s standard
terms of use included a provision that German law was to apply in
relation to dealings with the user. This too was disregarded by the court
in that a contractual choice cannot override ‘mandatory’ rules of law. The
authority appealed the court’s decision but lost that appeal.7
2.2.4 Google in Spain

In May 2014,8 the Court of Justice of the European Union (CJEU), the EU’s
highest court, sitting as a ‘grand chamber’ of 13 judges found in a
landmark decision (that will be discussed in greater detail in subsequent
chapters) that Google Inc. (the US company) was subject to Spanish data
protection laws. As a result, Google was obliged to remove from its
search databases certain information about the Spanish national who
brought a complaint against Google to the Spanish data protection
regulator.
This was despite Google Inc. (a separate company from its Spanish
subsidiary) not having any direct presence in Spain. The CJEU felt able to
find jurisdiction in this case on the basis of the sales and marketing
activities of Google Inc.’s Spanish subsidiary. Crucially, the search engine
operated by the US company was funded by the advertising revenue
resulting from the activities of the Spanish company.
2.3 Which law applies to the cloud?

2.3.1 Introduction
The determination of which country’s law applies to a particular cloud
situation depends on the type of issue about which there is concern. For
each legal topic (data protection, contract, liability issues, criminal law
and so on), the answer may – unfortunately – be different. This chapter
considers the main areas of law that need to be considered and gives an
outline of how an English court would answer the question.
7
Administrative Court of Appeals of Schleswig-Holstein, file no. 4 MB 10/13 and 4 MB 11/13.
8
Google Spain SL and Google Inc. v Agencia Española de Protección de Datos and Mario
Costeja González, Case C-131/12, 13 May 2014.
18 Cloud Computing
2.3 Which law applies to the cloud?
2.3.2 Data protection

The European Data Protection Directive [1] contains its own separate
rules for deciding which country’s data protection rules apply. This is
examined in detail in 4.6, but for now it is worth noting that the rules
look not at the residency or nationality of the individuals concerned, but
rather at where the person ‘controlling’ the data (who is likely to be the
cloud customer) is based.
We should also mention at this juncture that European data protection

law is in the process of being revised. Whilst the details of any revision
are not clear at the time of writing, one point that is being discussed at
the European level is to have a wider jurisdictional test based also on
targeting of European citizens (see 8.3).
2.3.3 Contract law

The rights and obligations of parties to a contract (including rules such as
whether a contract is formed, whether provisions limiting liability are
‘reasonable’, and how a contract can be terminated) need to be judged
against a body of contract law. These laws differ, sometimes remarkably,
from country to country. The UK is subject to the rules on the choice of
law in contracts that are set out in ‘Rome I’ [2] (see 2.1). This states,
broadly, that subject to certain exceptions, a court should apply the law
chosen by the parties. Of course, well-drafted contracts will always be
explicit about the law the parties agree should govern their relationship.
When a cloud contract involves entities in more than one country, there
is an obvious choice to be made between the law of the country where
the provider is based and that where the customer is located. Of course,
it is possible for the contract to stipulate that the law of a completely
unrelated country should govern it, and some US cloud providers will
choose, say, English law to apply to all their European contracts. If no
choice was made by the parties, Rome I provides a set of rules for
common situations including the following, which is likely to be
applicable to a cloud situation: ‘a contract for the provision of services
shall be governed by the law of the country where the service provider
has his habitual residence’ [Rome I, Article 4 1.(b)]. A cloud provider is
therefore likely to be able to argue that its ‘home’ law applies.
A cloud provider cannot, however, be absolutely certain that its choice of

law will prevail as there are exceptions to the general rules. In particular,
consumers are protected. A choice of law must not deprive the consumer
of protection afforded to them by provisions that cannot be excluded by
agreement, for example, the Unfair Contract Terms Act 1977 [5] (see
13.5). In addition, and not only for consumers, the parties cannot agree
to remove the operation of certain ‘mandatory’ provisions relevant in a
particular country. These are defined as provisions that are regarded as
crucial by a country for safeguarding its public interests, to such an
Cloud Computing 19
extent that they are applicable to any situation falling within their scope,
irrespective of the law chosen by the parties. Lastly, the application of the
law chosen by the parties may be refused if such application is manifestly
incompatible with the public policy in a particular country.
2.3.4 Liability issues

Liability to persons with whom there is no contractual relationship is
mostly covered by a body of laws called ‘tort’. Tort issues might arise
when the cloud service is accessible by members of the public (such as
consumer cloud services being accessed not just by users who have
registered but by general internet users). There might be libels
committed, negligent advice, infringement of confidential information
and so on. Torts can cross borders (the innocent party can be in a
different country from the perpetrator and from the cloud provider) and
in attempting to answer what law is to apply in such a situation, the UK
courts will look to another European instrument: Rome II [3]. This states
that, subject to a number of exceptions (which are outside the scope of
this brief introduction), the applicable law to non-contractual obligations
is the law of the country in which the damage occurs irrespective of
where the events giving rise to the damage occurred or where the
indirect consequences of that event occur. However, where the person
claimed to be liable and the person suffering damage both have their
habitual residence in the same country at the time the damage occurs,
the law of that country will apply.
2.3.5 Ecommerce Directive’s ‘country of origin’ rule

The European Ecommerce Directive of 2000 [4] is intended to ensure that
European businesses operating online do not have to worry whether
their online activities comply with legal requirements throughout the 28
different countries that are members of the EU, but instead only have to
ensure that their activities are lawful in the ‘country of origin’. The scope
of the legislation covers such things as requirements to get licences from
particular regulators, sales promotion and advertising laws, and so on. In
other words, issues that enforcement authorities (rather than, say,
contracting partners) might take an interest in. It does not cover issues
relating to data protection or to contracts that might be entered into
online, or other ‘private law’ issues (all of which are dealt with by the
areas of law just mentioned). Unfortunately, the legislation is far from
easy to decipher and there remains much controversy throughout Europe
as to the exact scope of the rules.
This will be more of interest to cloud providers with a web presence

open to the public. In relation to non-contractual activities, they should –
in theory – only have to worry about regulation and law in their home
20 Cloud Computing
2.4 Law enforcement agencies’ ability to obtain data
jurisdiction; more accurately, in the country in which they are established.

They need not worry about other European laws. (However, the Directive
says nothing about the laws of other non-EU countries to which the
provider might be selling services.)
To decide on where a provider is ‘established’, the focus is on where ‘an

economic activity’ is being undertaken on an ongoing basis. It is clear
that the location of the servers is not determinative of the issue
(although it may be a relevant factor). A cloud provider with offices and
staff in the UK providing a service based upon a foreign IaaS or PaaS
offering would likely be considered to be established in the UK (and not
where the IaaS/PaaS has its data centre).
Practical tip
Even if a cloud provider supplying services to the public complies

with all laws in the country in which it is ‘established’, it may still
have to consider the laws of other countries in the EU, as some
countries (e.g. France) interpret the Ecommerce Directive [4]
differently. Whilst checking all countries is impractical, a provider
might focus on those countries where there might be a risk of real
enforcement action.
2.4 Law enforcement agencies’ ability to obtain

data
2.4.1 Introduction
Most countries have wide-ranging powers for law enforcement agencies
to obtain intelligence for criminal investigatory and anti-terrorist
purposes. Nonetheless, it is the US’s power to do so that particularly
causes controversy and is often mentioned in cloud commentary. Since
the emergence of cloud computing, the USA Patriot Act [6]9 (passed in
the wake of the terrorist atrocities of 11 September 2001) has often been
mentioned as a reason to be wary of using US-based cloud services. For
example, in September 2011 the Dutch government took a hard line
against US cloud providers: government departments were severely
restricted in using such providers to process government IT data. The
9
The full name of the legislation is ‘Uniting and Strengthening America by Providing
Appropriate Tools Required to Intercept and Obstruct Terrorism (USA Patriot Act) Act of
2001’ (hence, ‘USA Patriot’ Act).
http://www.gpo.gov/fdsys/pkg/PLAW-107publ56/pdf/PLAW-107publ56.pdf
Cloud Computing 21
Dutch government’s reasoning was that the USA Patriot Act requires US
companies to provide data to the US authorities if requested under the
Act.10
This debate has recently increased in intensity with the 2013 disclosures
about ‘PRISM’ and other programmes operated by the US National
Security Agency (NSA). A whistleblower, Edward Snowden, disclosed that
the US agency (and its UK equivalent, GCHQ, through its ‘Tempora’
programme) had been collecting bulk and non-specific data about
telephone and internet use. These agencies were able to do this since
most of the world’s communications traffic passes through the US or the
UK. That they had done so was news enough, but the revelations also
disclosed that they had done so with the participation of various major
US telecoms and internet companies. This has added to the distrust felt in
Europe around use of US cloud services.
Before exploring a little further the position in the US, and the
application of all these powers to cloud computing, it should be
remembered that all countries have laws allowing their law enforcement
agencies to obtain data. As already noted above, the UK certainly does
and the Snowden revelations also concerned UK programmes. Specifically
within the UK, there are wide powers to obtain data for national security
reasons and the prevention and detection of crime. We mention three
examples. The Regulation of Investigatory Powers Act 2000 [7] allows the
Secretary of State to issue a warrant authorizing or requiring the person
to whom it is addressed to intercept communications in the course of
their transmission. The Intelligence Services Act 1994 [8] allows the
Secretary of State to issue a warrant authorizing the otherwise unlawful
entry into, or interference with, someone’s property – for example, for
the purpose of eavesdropping or conducting a secret intelligence search.
Lastly, the Police Act 1997 [9] contains similar provisions to the
Intelligence Services Act 1994 and provides for the authorization of
interference with property and wireless telegraphy in the course of
intrusive surveillance operations conducted by, for example, the police,
the Office of Fair Trading and HM Revenue & Customs within the UK.
It is probably the case that cloud users instinctively trust the laws and
enforcement agencies of their own country more than they do those of
foreign countries, especially the US and especially in light of the PRISM
disclosures mentioned above, irrespective of whether or not there is any
substantive difference. Arguably, some European regulators have
contributed to the acceptance of this view. Some cloud providers have, of
course, seen a marketing opportunity in this distrust of a ‘foreign’
regime; they actively promote the fact that their servers (unlike those of
their competitors) will be in a ‘safe’ place. A complexity here though is
that it is not the location of the servers that is necessarily determinate on
10
http://www.washingtontimes.com/news/2011/oct/28/preventing-digital-trade-war-in-the-
cloud/
22 Cloud Computing
the issue. Rather, if the servers (even if in, say, Europe) are operated by a
European subsidiary of an American company, then that European
subsidiary may well be compelled by its American holding company to
give up that data on a legal request. In 2011, in fact, Microsoft admitted
that cloud data on its servers, regardless of where the data was located,
would not be protected from disclosure to American agencies. During the
launch of Office 365, a Microsoft director was asked if Microsoft could
guarantee that EU-stored data, held in EU data centres, would not leave
the European Economic Area (EEA) under any circumstances even if
Microsoft was faced with a request under the USA ‘Patriot Act’ [6]. The
director explained the obvious truth that, as a US company, it has to
comply with local laws (in particular, US laws). He said that they could
not give the guarantee that data would remain within Europe and
added, ‘Neither can any other company.’11
2.4.2 The position in the US: the USA Patriot Act

Even before the recent PRISM revelations, there has been distrust of US
laws and the abilities of government agencies to obtain data from service
providers. The reason the focus in cloud discussions has been so often on
US laws and the USA Patriot Act [6], in particular, might be more to do
with a greater distrust of foreign laws (compared to the laws of one’s
own country) than any substantial difference in the scope of the powers
that the authorities have. Nonetheless, it is the suspicion of
untrammelled access to cloud data that frequently raises European
concerns.
The USA Patriot Act is a piece of anti-terrorism legislation that was a

response to the events of 11 September 2001. Amongst other things, it
expands the intelligence-gathering and surveillance powers of US law
enforcement agencies. The first point to note though is that many
powers already existed and – in the area we are concerned about – the
changes were incremental. The second point to note is that it is not even
the most important piece of legislation covering the US authorities’
abilities to access records.
The most significant piece of US legislation in the cloud area is the Stored
Communications Act, which was first enacted in 1986 [10]. The scope of
this piece of legislation is to govern access to communications data in
storage (as opposed to communications in transit); for example, in a
cloud provider. Under this legislation, a government agency can apply for
a search warrant or a court order (the latter having less stringent
requirements) to get access to cloud data. Which will apply will depend
11
WHITAKER, Z. ‘Microsoft admits Patriot Act can access EU-based cloud data’, ZDNET, 28
June 2011.
http://www.zdnet.com/blog/igeneration/microsoft-admits-patriot-act-can-access-eu-based-
cloud-data/11225
Cloud Computing 23
on a number of complex rules, such as whether the data is more or less

than 180 days old or whether the provider is classed as a provider of an
‘electronic communication services’ (i.e. services that send or receive wire
or electronic communications) or of ‘remote computing services’ (i.e.
services that provide computer storage or processing services). The rules
also depend on whether the access is to actual content or only
‘metadata’ (i.e. information about the content, such as when and to
whom an email was sent, rather than the message itself).
The other main piece of legislation in the US in this context is the

Foreign Intelligence Surveillance Act of 1978 [11] (FISA). FISA provides the
foundation for foreign intelligence surveillance, including establishing
procedures for the collection of this intelligence against non-US nationals
(there can be no targeting of US citizens within the US). It created a
court that operates behind closed doors (the Foreign Intelligence
Surveillance Court or ‘FISA Court’) and is not subject to public oversight.
FISA allows the US government to authorize electronic surveillances by
seeking an order from the FISA Court. The government must set out the
facts that give rise to ‘probable cause’ to believe that the proposed
target is a foreign power, and must describe the premises or property
that is the proposed subject of the search or surveillance.12
FISA especially has been significantly amended over the years, including
by the USA Patriot Act (and subsequently). The USA Patriot Act allows US
authorities to obtain records (i.e. data) to protect against international
terrorism. The threshold for such gathering is now that foreign
intelligence need only be a ‘significant’ purpose, rather than the only
purpose, of the searches or surveillance.
The USA Patriot Act also expanded the circumstances under which the FBI
can compel financial institutions, phone companies and internet service
providers (ISPs) to secretly disclose information about their customers.
The FBI is required only to establish that the information it seeks is
relevant to an authorized intelligence investigation. Thus, although
enacted primarily for anti-terrorism purposes, its provisions allow use for,
and are reported to have been used in, ordinary criminal investigations
that have no terrorism feature. In summary, the USA Patriot Act has
made changes to the regime in the US but in many ways these are
changes of detail (although of course they are legally important). In
practice, in the author’s opinion, it does not really seem as if the changes
in themselves justify the extensive recent criticism of the USA Patriot Act
in European discussions on cloud computing.
Another form of US law enforcement evidence-gathering is ‘national

security letters’, which are administrative subpoenas that allow the FBI to
compel the recipient (when sent to an ISP) to divulge subscriber and
billing information relevant to a national security investigation. These
12
USA Patriot Act, section 218 (Foreign Intelligence Information)
24 Cloud Computing
letters require no judicial review and the recipient is prohibited from

revealing the contents or existence of the letter.
It is not only European data protection regulators that have a distrust for
such wide-ranging powers; the USA Patriot Act has certainly caused
problems for authorities outsourcing in Canada.
The laws of two Canadian provinces (those of British Columbia and Nova
Scotia) contain restrictions on public bodies transferring personal
information outside Canada, including to the US. In 2004, the British
Columbian government (as part of its privatization of aspects of health
provision) announced that it was contracting with two US companies.
There was an immediate public outcry in relation to the possibility that
sensitive, private medical information could find its way – through the
USA Patriot Act – into the hands of US law enforcement agencies (even
when the data never in fact left Canada). The British Columbia
Government and Service Employees’ Union (BCGEU) commenced legal
action to prevent this outsourcing. It argued that the possibility of access
by the US authorities would contravene the province’s data protection
legislation [the Freedom of Information and Protection of Privacy Act [12]
(FOIPPA)]. (As it happens, the court disagreed and found that there was
sufficient privacy.) The local law was in the end changed, prohibiting any
access to data except from within Canada.
2.4.3 Application to the cloud

The fear is that US legislation (as can be seen above, it is not only the
USA Patriot Act [6]) would allow the US authorities to obtain data
belonging to a UK cloud customer residing in a server farm of a US cloud
provider.
In the following chapters we describe how data protection law (and in

particular the restrictions on transferring data abroad) impacts upon
cloud computing. In brief, a cloud customer sending data to the US
should undertake due diligence and take into account the legal regime in
the US, and, therefore, the potential impact of the USA Patriot Act. The
UK data protection regulator, the Information Commissioner’s Office
(ICO), has referred to this issue in its Guidance on the use of cloud
computing [13]. Earlier guidance (applicable to traditional outsourcing)
referred to the possibility of the application of the USA Patriot Act. This
advised the company taking up the service to take the USA Patriot Act
into account in the necessary risk assessment.13 The recent cloud-specific
guidance refers only to the more general situation of a foreign law
enforcement agency (rightly removing the focus upon US agencies) and
13
See, for example: (1) The eighth data protection principle and international data transfers,
Version 3.0, 17.12.08 and (2) Data Protection Good Practice Note, Outsourcing – a guide for
small and medium sized businesses, version 2.1, 09.04.09.
Cloud Computing 25
reminding customers that such an agency ‘may have the power to require
cloud providers to give them access to personal data’ [13].
Needless to say, this does not necessarily mean that a provider in the US
(or any foreign provider) should never be used. In many and, perhaps,
most circumstances, there will be no real problem. Greater care will
perhaps be needed when the data is particularly sensitive.
The ICO guidance goes on to state:
If a cloud provider is required to comply with a request for

information from a foreign law enforcement agency, and did comply,
the ICO would be likely to take the view that, provided the cloud
customer had taken appropriate steps to ensure that the use of the
cloud services would ensure an appropriate level of protection for
the rights of data subjects whose personal data would be processed
in the cloud, regulatory action against the cloud customer (in respect
of the disclosure of personal data to the foreign law enforcement
agency) would not be appropriate as the cloud provider, rather than
the cloud customer, had made the disclosure.[13]
In short, the existence of these law enforcement powers are factors to be

taken into account in a risk assessment, but need not stop the use of a
US (or other foreign or even a UK) cloud provider.
Nonetheless, measures might be put in place to deal with any such

requests. These might include a requirement to refer any law authorities’
requests for the data to the customer. Whilst this might be difficult to
negotiate in the context of a typical cloud deal (with a customer
contracting for a standard service on standard terms), it might be
possible in deals where the customer has negotiating power. The ICO
suggests including these types of provisions in its guidance on
outsourcing,14 but the point is equally applicable to cloud computing.
The ICO guidance contains a reminder that there is also the possibility of
regulatory action against the cloud provider. If the cloud provider is
disclosing its customer data to law enforcement agencies, it is likely in
the context of that disclosure to become a ‘data controller’ (see 4.5). If
this were to happen, though, provided there was a legal compulsion to
disclose, the ICO has stated that it would not take regulatory action.
14
See footnote 13.
26 Cloud Computing
2.5 Key points
Practical tip
Cloud customers should consider including obligations in a contract

that require the provider to refer (where legally able to do so) to the
customer any requests for data from external agencies.
If a cloud provider accommodates such a suggestion in the contract,

it will need to include an exception. The cloud provider should not
be obliged to refer the request to the customer when to do so would
put the provider in breach of legal requirements.
2.5 Key points

In this chapter we have explored issues surrounding the identification of
the relevant body of law to apply to a cloud situation. Key points are as
follows.
◆ Given the cross-border nature of cloud computing, it may be difficult

to identify which legal system will apply to any given situation.
Disputes as to which law applies to a particular situation have
already arisen, and will continue to arise.
◆ A cloud provider and a customer can choose which law is to apply to
govern their contract. A provider will normally (in its standard terms)
make a choice that is convenient to it (normally, of its own
jurisdiction). This choice only impacts the relationship set out in the
contract and does not remove the need to comply with more
generally applicable rules.
◆ Other legal principles (such as requirements to comply with sales
promotion laws or liability to third parties) cannot be avoided by
contract and any entity wishing to sell internationally will need a
strategy to decide in which country it will be legally ‘cleared’. A
practical and risk-proportionate approach is necessary.
◆ The USA Patriot Act [6] has received much publicity, but the law
enforcement agencies of many countries have wide powers to obtain
data within the relevant borders. When putting data into the cloud,
a customer risks that data being accessed by such agencies not only
in its country, but also in the provider’s country.
Cloud Computing 27
3 Information security
3.1 Introduction
Survey after survey indicates that security of data or information is the
biggest worry of customers contemplating moving to a cloud
environment. They have an understandable fear of putting their data
into the hands of a third party.
The fear customers have, say cloud providers, is often misplaced. No IT

infrastructure is perfectly secure. Any corporate network, and therefore
the stable of servers a potential customer enterprise might itself operate
in a traditional IT department, is connected to the internet. This leads to
the risk of malicious attack by hackers. No body of employees is
completely trustworthy. There is always a threat of breach of protocol by
employees (even assuming that the enterprise does have robust
processes). Whilst there is no denying that the customer is losing direct
control, the best-placed people to navigate the risks are often the cloud
providers whose job it is to keep data secure and who have a massive
commercial incentive to keep abreast of the latest security developments
and the latest solutions to the ever-changing security threats. There is of
course much truth in this, certainly for the larger providers with
reputations to safeguard. Cloud security is still in flux and it remains to
be seen whether the smaller cloud providers achieve and maintain
respectable levels of security. What is certain is that security will become
a factor in the competition in the market, both in respect of what
security is in place and in respect of how open a provider is willing to be
in relation to that security when confronted by customer queries.
This chapter explores aspects of the various security issues that arise in
the cloud. We make no pretence of comprehensively dealing with the
technical issues around security (and existing standards); these are topics
worthy of their own books and reference should be made to specialist
texts. However, we do introduce the security standards to which providers
are claiming adherence in order to reassure customers. We discuss the
legal obligations in this area, including issues such as due diligence and
audit. Lastly, we discuss liability issues that arise when security goes
wrong. Some of the issues discussed here are very closely linked to other
issues covered elsewhere in this book. For example, when the data being
entrusted to the provider is ‘personal data’ or the customer is a regulated
financial services company, then the regulatory overlay of data protection
rules (discussed in Chapter 4) or financial services regulation (14.2) comes
28 Cloud Computing
3.3 Security breaches – some examples
into play. Reference should also be made to Chapter 13 where we deal

with contractual issues relating to liability generally.
3.2 What is a security breach?

Security breaches can take many forms, but all of them involve a
compromise of the underlying data. There are many ways of
characterizing them but it is sometimes useful to sort them into one of
the following different groups.
First, a security incident could arise out of human error. Examples of this
are when information is sent by an organization to those to whom it
should not have been sent, or when a laptop containing data is not
encrypted and is then lost.
Secondly, and related to that, is when the organization has not put in
place appropriate security controls. This might allow the human error
type of incident (by not enforcing a requirement to always encrypt data).
But it might also be a systemic failure in the technology; for example, not
operating with the appropriate latest updates and security techniques. It
could also be a simple failure of technology (a bug, say) that leaks the
data.
Lastly, it could be due to a malicious attack. Hackers, for want of a better

term, might break into an organization’s systems either to steal the
information for gain (such as selling credit card or other details in a
nefarious market) or simply to cause embarrassment or malicious
damage. This could be facilitated by the second type of breach
(non-appropriate security), but not necessarily. A malicious attack could
even be instigated by a member of staff (for gain or revenge or other
motive).

There have already been some high-profile security incidents involving
cloud services. As will be seen from the examples that follow, all of which
were widely reported in the press, some arise as a result of technological
errors and others because of malicious action by hackers.
3.3.1 Sidekick
Sidekick is a smartphone marketed by T-Mobile. In the usual way, the
device can store user data such as contacts, calendar entries, to-do lists
and photos. However, unusually, the data was stored on servers in the
cloud and not on the devices themselves. The servers are operated by
Cloud Computing 29
Microsoft. In October 2009, the servers failed, data was lost, and users of
these phones could not access their data. It was initially believed that the
data was permanently lost. As a result, various legal claims were fairly
promptly launched against both T-Mobile and Microsoft alleging that the
companies had been negligent in looking after data. Microsoft later
announced that the data had all been recovered. Microsoft then claimed
that it was not a loss after all, simply an ‘outage’.15
3.3.2 Gmail
Google has not been immune to cloud service problems. Gmail is a free
webmail service provided by Google (and a high-profile example of a
cloud application) and is used by both consumers and businesses. Since it
became available to the public in 2007, Gmail has experienced a number
of outages. On 24 February 2009, Google’s Gmail service went offline for
about 2.5 hours affecting the service’s 113 million users worldwide.
During this time users could not access their Gmail accounts and were left
seeing only an error when trying to login. However, Gmail’s IMAP
(Internet Mail Access Protocol) service continued to work during this time
allowing users to send and receive emails from some devices. The outage
was caused by a routine maintenance event in one of Google’s European
data centres where new code, designed to try to keep data
geographically close to its owner, caused another data centre in Europe
to become overloaded and the problem spread across its data centres. It
was quickly dubbed by bloggers as ‘the great Gmail outage of 2009’.
Another outage occurred on 1 September 2009 resulting in the service

being down for approximately 100 minutes, although users could
continue to send and receive emails using POP (Post Office Protocol) and
IMAP during this time. It was reported in various blogs that the outage
was caused by overloaded routers, triggered by a routine configuration
change that added more router load than expected.
3.3.3 Google Docs

In March 2009, Google discovered a bug that caused some Google Docs
users to share their documents without their knowledge. The documents
were only shared with people with whom the user had already shared
documents rather than with the world at large. Google took immediate
action when it found the error by stripping all sharing privileges from the
affected documents and notifying the affected users that they would
need to re-share their documents. It said that the problem only affected
0.05 per cent of documents stored on the Google Docs site.
15
http://news.microsoft.com/2009/10/15/microsoft-confirms-data-recovery-for-sidekick-users/
30 Cloud Computing
3.3.4 Twitter breach

In 2009, a hacker reportedly broke into a Twitter employee’s personal
Gmail account using the password recovery feature that sends a reset link
to a secondary email. In this case the secondary email was an expired
Hotmail account which the hacker simply registered then clicked the link
and reset the password. The hacker then read the employee’s emails to
guess the original Gmail password successfully and reset the password so
the Twitter employee did not notice the account had changed. The
hacker then used the same password to access the employee’s emails on
Google Apps and was able to download sensitive company information
from emails and, particularly, email attachments. The hacker then took
over the accounts of at least three senior executives, which enabled him
to access more sensitive data. The hacker then used the same
username/password combinations and password reset features to access
AT&T, MobileMe, Amazon and iTunes, amongst other services. A security
hole in iTunes gave the hacker access to full credit card information in
clear text. He also had control of Twitter’s domain names at GoDaddy. At
this point, Twitter had absolutely no idea it had been compromised. The
hacker then forwarded hundreds of pages of confidential Twitter
documents to websites, including TechCrunch, which in turn published
some documents and referred to others.
3.3.5 Hotmail breach

In October 2009, Microsoft confirmed that thousands of users of
Windows Hotmail had had their usernames and passwords posted on a
third-party site. According to Microsoft, this information was likely to
have been swiped in a phishing scheme and was not a breach of internal
Microsoft data.
3.3.6 Dropbox breaches

Dropbox is an online storage service used by both consumers and
businesses. In 2012, a security breach led to many Dropbox users receiving
unsolicited emails. Hackers gained access to an employee’s account using
a stolen password. Once in the account, they gained access to a
document containing usernames and email addresses, to which the
hackers then sent a barrage of emails. This is not the only problem
Dropbox has experienced; it suffered an outage in 2011 when it admitted
to inadvertently publishing code on its website that allowed anyone to
sign in without credentials. More recently, in May 2014, Dropbox was in
the news again when users were warned that they may have been
inadvertently leaking their own files.
Cloud Computing 31
3.3.7 PlayStation breach

In April 2011, a hacker used Amazon Elastic Compute Cloud to attack
PlayStation in what turned out to be the second-largest online data
breach in US history at that time. The hacker concerned attacked the
online element of Sony’s PlayStation mobile gaming products and gaming
console, which allows customers to chat and play against each other
online as well as purchase games and rent films with credit cards. This
Playstation Network Platform was hacked in a targeted and concerted
denial of service attack. The attacker accessed personal information
within 77 million accounts, including customer names, addresses, email
addresses, dates of birth and account passwords. Customers’ payment
card details were also put at risk, although there is no evidence that
these were accessed.
In response to the attack Sony was forced to turn off the network for a
total of 24 days. During the outage, users of PlayStation 3 and
PlayStation portable consoles were unable to play online. In addition to
the PlayStation Network, it transpired that the Sony Online
Entertainment system was also affected. Sony was forced to take this
system offline, which affected PC and Facebook gamers. Sony admitted
that names, home addresses, email addresses, dates of birth, phone
numbers and gender information were stolen. Sony warned customers to
look out for any contact claiming to be from Sony and to change their
usernames and passwords. The estimated cost of the outage was $171
million.16
3.3.8 Adobe breach

In October 2013, the software company Adobe announced a
sophisticated attack on its network, involving the illegal accessing of
customer information, as well as source code, for numerous Adobe
products. The hackers accessed customer IDs and encrypted passwords
and removed from the system information relating to 2.9 million users.
This information included names, encrypted credit or debit card numbers,
expiration dates and other details of customer orders. Users were advised
to change their passwords in response to the attack. For users whose
payment information was exposed, Adobe offered access to a one-year
credit monitoring programme paid for by the company.
3.3.9 Snapchat breach

Snapchat is a popular photo-sharing application, through which users can
send photos that, once viewed, are automatically deleted within a certain
time frame. In early 2014, Snapchat suffered a major security breach. A
16
Sony was also fined within the UK – see 4.10.3.
32 Cloud Computing
3.4 Due diligence
hacker group exposed the phone numbers and usernames of

approximately 4.6 million users. The hackers used a website called
SnapchatDB.info to expose the phone numbers of the users, with just the
last two digits missing; they also offered to expose the full numbers to
anyone who contacted them directly. The hackers claimed that the
motivation behind the attack was to raise awareness about the
weaknesses in Snapchat’s security.
3.3.10 eBay breach

In May 2014, eBay fell victim to hackers. eBay discovered that hackers
had compromised employee login information, which had given them
access to eBay’s corporate information network, containing customer
information and encrypted passwords. Reports suggest up to 145 million
accounts may have been compromised. Details accessed included dates of
birth, addresses, phone numbers and email addresses. eBay contacted
customers, warning them to change their passwords for the site and also
for any other sites on which they used the same password.
3.3.11 iCloud leaks of celebrity photos

In August 2014 the leaking of celebrity photos raised questions about the
safety of cloud storage facilities. Private photos of a number of
celebrities, including Jennifer Lawrence and Kate Upton, which those
celebrities had stored in the well-known iCloud service provided by
Apple, were posted on the sites 4chan and reddit, before spreading
across the internet. At first it was unclear whether the leaked photos
were a result of a security flaw within iCloud or a targeted attack on
individual accounts. After investigating the incident, Apple confirmed
that certain celebrity accounts had been specifically targeted in an attack
on usernames, passwords and security questions, and reassured users that
none of the cases resulted from a breach in any of Apple’s systems,
including iCloud. In response to the incident, Apple urged users to use a
strong password and to take advantage of the two-step verification
process. Some sources suggested the incident was part of a larger
underground hacking ring that traded in celebrity photos.
3.4 Due diligence

3.4.1 Introduction
Any entity outsourcing control of its data to a third party (whether cloud
or otherwise) is always well advised to undertake some level of due
diligence prior to signing the contract, to ensure that security standards
are as high as it is reasonable to expect given the commercial worth (or
Cloud Computing 33
personal sensitivity) of the data. As will be seen later, when personal data
is involved or when the customer is operating in the financial services
sector, due diligence in relation to security is not just commercial
common sense, it is a regulatory requirement. Due diligence in an
outsourcing situation might traditionally have involved site visits and
detailed technical investigation of the organizational and technical
processes in place. Clearly, this is easy to do when there is a specific data
centre to be examined but less easy to do when a cloud is envisaged. In
the cloud, a customer may simply have to resort to examining a
provider’s security policies.
The customer will want to be comfortable with what it finds out.

However, this is not just an issue for customers. Providers are starting to
appreciate that customers are becoming more security aware and
recognize that they will increasingly need ready responses to these
investigations.
3.4.2 Security policies

A typical security policy might cover the following areas:
• physical security – level of security of the servers, including the policy

on access restrictions;
• network security – including such things as the firewall technology to
be deployed, and policies on employee access to customer data;
• server security – including how servers have been hardened against
attack and policies for continual improvement;
• data segregation policies – clearly, physical segregation is not part of
the model, but things such as how to achieve logical segregation still
need to be considered, and user (client) authentication policies, etc.;
• encryption – what algorithms and what strength; key management;
what data is covered;
• backup/replication policies – how often this is to be done.
Under each of these headings there might be any of a number of

different levels of description. Technical expertise is needed to assess the
security offered. If that is not available in-house to a customer,
consultancy services could be considered.
3.4.3 The customer’s enquiries

The first and most important thing for the customer to do is to ask
questions. This may take the form of a detailed questionnaire to be
completed as part of a tender package, or meetings between technical
staff, or even simply by studying public announcements on the security
pages of the provider’s website. The enquiries made will depend on the
particular service. It is also important that full records are kept about the
34 Cloud Computing
3.4 Due diligence
enquiries made and the responses received. This is particularly important

for regulatory reasons as it serves as evidence to demonstrate that data
protection, financial services or other regulations have been complied
with.
It is impossible to be absolutely prescriptive as to what a customer should

look into but a typical due diligence exercise for the cloud may include
enquiring into:
• who owns and controls the cloud infrastructure;

• the deployment and delivery models;
• the underpinning architectural framework;
• the security controls in place;
• the physical location of infrastructure elements;
• the service provider’s reliability reports (not only in respect of security
but also in respect of availability, the latter being essential to
determine whether these meet the requirements of the business).
Where the customer is considering acquiring a cloud service that might

be built upon a third-party cloud service (as many SaaS solutions are),
diligence should of course also be directed towards the sub-provider
(which will, naturally, be the entity that has actual possession of the
customer’s data). Adherence or certification to a particular standard by
the SaaS provider, for example, is all well and good, but largely irrelevant
if the data is held by a third-party subcontractor.
Practical tip
Cloud customers need to consider undertaking due diligence into the

information security processes of the provider. The enquiries made
should be tailored to the particular solution being considered and
the nature and sensitivity of the data being put into the cloud.
In undertaking a due diligence exercise, it is important that the customer

insists upon detailed, technical responses to the questions. A customer
should be wary of a cloud provider that simply replies with generalities
such as ‘We use encryption.’ A response should elaborate: encryption to
what standard? Is all data encrypted (both in transit and at rest)? How
does authentication material get exchanged? What key management is in
place?
The ICO, in its guidance on cloud computing [13], stipulates that

encryption using recognized industry standards should be used for
personal data in transit between the customer and the provider, and that
there should be appropriate assurances on security (not necessarily
encryption) for data in transit within the cloud service, such as between
Cloud Computing 35
two of the provider’s data centres. Depending on the nature of the data
being stored (for example, if it is ‘sensitive personal data’), says the ICO,
it may be appropriate to encrypt data ‘at rest’. A lot will, of course,
depend on the type of service. For example, if it is a SaaS, where the
provider has to process the data, data may have to be unencrypted at
rest to allow this. Security of the key is also important.
3.4.4 The provider’s response

In being asked these due diligence questions, how should a cloud
provider respond? Of course, it wants the business, but much of the
security it has in place is understandably confidential. Not only does such
information perhaps constitute a commercial advantage, but also the
disclosure of too much detail may compromise security. There is a natural
reticence amongst information security experts to disclose.
Providers may well feel free to disclose the fact that they have a security
policy and that it has had approval at the highest level (to the extent
that is true). If the policy is an attempt to be compliant with an external
standard such as BS ISO/IEC 27001 [14], that is certainly a good point to
make – better still a certification to that effect. Beyond compliance or
certification, however, a provider might well want to supply the customer
with further detail. A customer may want to see the full ‘statement of
applicability’ (see 3.6.2) or otherwise some detail as to each of the 14
‘control clauses’ set out in BS ISO/IEC 27002 [15] (see 3.6.3). A provider
will of course wish to steer clear of disclosing anything that is in fact
proprietary or might in fact exacerbate security risks. A balance needs to
be struck. Too much information can be dangerous as it might lead to
liability issues if the information at some stage is no longer current. The
less detail, the less likely the information will become dated.
Some providers are willing to provide more security information (such as

disclosing a level of detail around their architecture). However, before
doing so they are likely to want to have the customer sign a
confidentiality agreement (non-disclosure agreement or NDA).
Practical tip
Providers should consider how much they need to disclose to reassure

a potential customer as to the security measures in place. If
confidential information is being disclosed, that should only be done
under the umbrella of an appropriate NDA or confidentiality
agreement.
36 Cloud Computing
3.5 Introduction to security standards
Many customers will insist upon their own standard form of security
questionnaire. Whilst this is all well and good from the customer’s point
of view, it does increase the burden upon the provider as part of the
sales process. The economics of the cloud are dependent on it being easy
to set up and use, and there must also be easy contracting. If too many
customers send in too many questionnaires (all focusing on their own
concern in their own form), this may detract from those economics.
Providers fearing being inundated will need to educate their customers
and this may include being very open about security up front (rather
than simply reacting to questionnaires).
Practical tip
Cloud providers that find themselves bombarded with questionnaires

might look at being more open on their websites. Frequently asked
questions (FAQs) on security could be a useful tool.
3.5 Introduction to security standards

Given the difficulty of undertaking physical due diligence, customers are
likely to rely more and more on an assessment as to whether a cloud
provider adheres to a particular security standard. Of greater comfort still
is when the adherence is certified by a third party (in particular, one that
is accredited). A detailed summary of the various standards is outside the
scope of this book, as is a discussion of how cloud providers might obtain
certification against them. Nonetheless, a description of the major
standards will be useful to those navigating legal aspects of the cloud.
Compliance with and/or certification to these standards will often be
cited by providers. A cloud customer needs to understand whether such
compliance or certification is sufficient for it to satisfy its own commercial
needs and risk appetite (as well as its regulatory and compliance
obligations).
There are a number of international standards that (either directly or

indirectly) tackle the security of IT systems or the management of
information security. Whilst none focuses on cloud computing, they are
of general application and many [in particular, BS ISO/IEC 27001 [14],
BS ISO/IEC 27002 [15] and SSAE 16 [16] (previously SAS 70) [17], all of
which we discuss further on] are applicable to the cloud.
There are many benefits to a cloud provider of implementing sensibly

chosen security standards. First and foremost, it can itself be more
confident that it is approaching the issue of security in a robust manner.
Second, it can demonstrate that confidence to its customers. This will go
some way to bridging the fear mentioned previously, that too much
control is being given to a provider over such important assets. Thirdly, it
Cloud Computing 37
may provide some defence to claims for breach of regulatory compliance

requirements, including the obligation to use appropriate technical and
organizational means to safeguard security set out in data protection
rules. To illustrate one aspect of this latter benefit, the UK ICO has
powers to issue fines for certain serious breaches of UK data protection
rules (which we will explore more fully in 4.10.3). Amongst other things,
the power arises if the data controller knows that there is a serious risk
and has failed to take reasonable steps to prevent it. In its guidance on
these powers, the ICO has stated [18] that it is more likely to consider
that the data controller has taken the required reasonable steps if it has
implemented any relevant code of practice and an example of this
(expressly mentioned) is if the data controller can demonstrate
compliance with BS ISO/IEC 27001 [14].
3.6 ISO/IEC 27000 series

3.6.1 Introduction to the series
The ISO/IEC 27000 series comprises information security management
system (ISMS) standards published jointly by the International
Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC). It was derived from earlier British
Standards Institution (BSI) series (BS 7799 [19] and BS ISO/IEC 17799 [20]).
The series, for present purposes, has two main components. First,
BS ISO/IEC 27001 [14]:17 a standard that provides a specification for ISMSs
and sets out a foundation for third-party audit and certification. It aims
to ensure that information security management is established and
maintained through a continual improvement process. It is possible to get
third-party certification (by accredited organizations) against this
standard.
Practical tip
It is important for a customer to note that a cloud provider claiming

to comply with BS ISO/IEC 27001 is only self-assessing. This is very
different from being certified against the standard.
The second principal component in the series is BS ISO/IEC 27002 [15],18

which establishes the guidelines and general principles for initiating,
implementing, maintaining and improving information security
17
The current edition, BS ISO/IEC 27001:2013, replaces the earlier BS ISO/IEC 27001:2005.
18
Again, the current BS ISO/IEC 27002:2013 replaces BS ISO/IEC 27002:2005.
38 Cloud Computing
management in an organization. Many cloud providers claim that they

are ‘compliant with’ BS ISO/IEC 27002, but depending on the
circumstances this may not necessarily be very meaningful. As with
claiming compliance with BS ISO/IEC 27001, that would simply be a
self-assessment (and indeed there is no third-party accredited certification
for this standard as there is for BS ISO/IEC 27001). A proper effort to
achieve compliance though is nonetheless laudable and would go some
way to showing the provider to taking security seriously.
In addition, there are a number of sector-specific standards in the

BS ISO/IEC 27000 series. These include BS ISO/IEC 27011 [21], which
provides guidelines for telecommunications organizations, and BS ISO/IEC
TR 27015 [22], which sets out security techniques and guidelines for
financial sectors.
3.6.2 BS ISO/IEC 27001

BS ISO/IEC 27001 [14] provides a model for establishing and operating an
ISMS. By following this standard, any organization can adopt, in a
controlled fashion (and continually monitor and improve), processes to
improve information security (in particular, the preservation of
‘confidentiality, integrity and availability of information’
(BS ISO/IEC 27001:2013, 0.1)). It is possible to be certified against this
standard (see 3.6.4).
This standard is designed for use by all types of organizations and for
different aspects of their processes. The organization must consider the
identity and requirements of the interested parties that are relevant to
the ISMS. The organization must consider these requirements in addition
to other factors, for example, the type and size of the organization and
the risks faced, when determining the scope of the ISMS, which must be
made available as documented information. Given the potential for
application by all types of organizations for different types of processes,
there is scope for much variety in the content of ISMSs and as to how the
various requirements are in fact met.
Where a cloud provider claims adherence to BS ISO/IEC 27001, a customer

will be concerned to explore two separate issues. First, is the scope of the
ISMS relevant to the cloud solution under consideration? Secondly, how
has BS ISO/IEC 27001 been applied in that ISMS?
We will take these two issues in turn. In going through a

BS ISO/IEC 27001 compliance project (whether ultimately certified or not),
the organization will have first defined the scope and boundaries of the
ISMS. Accordingly, the first thing for a customer to do, when presented
with a statement that the provider is BS ISO/IEC 27001-compliant, is to
satisfy itself that the scope of the ISMS said to be so compliant is in fact
relevant to the data it will be entrusting to the cloud provider. A
Cloud Computing 39
provider being BS ISO/IEC 27001-certified in relation, say, to the ISMS

operated by its HR department (for its own personnel data) will not be of
much comfort to the customer.
Likewise, as another example, a compliance scope relating to data centres

located within the US will not be helpful if the customer’s data is not to
leave Europe.
Practical tip
Where a provider claims adherence to BS ISO/IEC 27001 (or

certification to it), the customer should understand the scope of the
ISMS and ensure the cloud solution it is considering acquiring is
properly covered.
Ensuring that the scope of the ISMS covered by the compliance statement
is in fact relevant to the cloud offering being contemplated is not
enough for the customer, however. A provider will have had many
choices to make in implementing an ISMS even when it is properly
compliant with BS ISO/IEC 27001. Whilst third-party certification (see
3.6.4) will go some way to giving an assurance that sensible decisions
have been made, a customer may well want to be directly satisfied that
the controls actually in place are adequate and may want to explore
some detail around those controls.
BS ISO/IEC 27001 sets out (in Annex A) a list of 114 control objectives and
controls, which originate from BS ISO/IEC 27002 [15] (see 3.6.3).19
Not all of the control objectives and controls will be relevant in any
particular situation and so BS ISO/IEC 27001 permits the exclusion of a
control objective or control provided the exclusion can be justified. In
summary, an organization can exclude the application of a control
objective or control whenever it addresses risks the organization can
accept, that are not relevant, or that can be passed onto others, such as
customers or suppliers. The assessment of which control objective or
control can be dispensed with is undertaken with reference to the
organization’s documented risk assessment and risk treatment profile
(which it sets itself). The organization must retain documented
information about the security risk treatment process.
The application of a control objective or control (or reasons for its

exclusion) should be set out in a statement of applicability (SoA). In
essence, the SoA is a record of which of the various control objectives
19
The number of controls has reduced to 114 from 133 from the earlier edition of 2005.
Some of the controls have merged, some have been deleted and some are new.
40 Cloud Computing
and controls in BS ISO/IEC 27001, Annex A have been applied (and how
they have been applied) and which have been dispensed with. A certified
provider would have had the SoA assessed and the decisions made by the
provider will have been challenged. If there is no third-party certification,
a customer will likely be more interested in this level of detail.
Practical tip
Where a provider claims adherence to BS ISO/IEC 27001, a customer

relying on this should consider reviewing the statement of
applicability. This is more important when there has not been an
independent certification of compliance.
As mentioned in 3.4.4, however, a provider may wish to resist full

disclosure of the SoA if it does contain detail that is in fact proprietary or
that might exacerbate security risks.
3.6.3 BS ISO/IEC 27002

BS ISO/IEC 27002 [15] is a code of practice for information security
controls or, in other words, an information security standard. It is
designed to complement BS ISO/IEC 27001 [14] by setting out many of
the controls that can be utilized within an ISMS to help achieve
certification under BS ISO/IEC 27001. The standard is structured by
reference to 14 security ‘control clauses’ further split into 35 security
categories. Each of the 35 categories contains a statement of the
objective for the particular control clause, with one or more controls (a
total of 114) that can be applied to achieve that objective. The standard
then provides for detailed information to support the implementation of
the control and meeting the control objective.
The 14 main control clauses (set out in sections 5 to 18 of

BS ISO/IEC 27002) are:
1. Information security policies
An information security policy document should be approved by

management, and published and communicated to all employees and
relevant external parties. The policy should be reviewed regularly.
2. Organization of information security
This control requires the establishment of a management framework to

initiate and control the implementation and operation of information
security within the organization. It also requires the development of a
Cloud Computing 41
policy and supporting security measures to manage the risks introduced

by using mobile devices as well as a policy to protect information
accessed, processed or stored at teleworking sites.
3. Human resource security
Adequate screening should be stipulated. Responsibilities for information

security should be defined for employees. Information security awareness,
education and training should be provided and a formal disciplinary
process should be established. Responsibilities should be in place to
ensure an employee’s exit from the organization is managed, and that
the return of all equipment and the removal of all access rights are
completed.
4. Asset management
Responsibility for the security of any asset should be clearly set out.
Information should be appropriately classified so as to ensure an
appropriate degree of security is applied to it. Labelling procedures
should be developed. Procedures should be in place for the management
of removable media to prevent unauthorized disclosure, modification,
removal or destruction of information stored on media. The procedures
should cover the management, transfer and disposal of removable media.
5. Access control
This is another important control and includes requirements that:
a) access to information, facilities and business processes should be

controlled on the basis of business and security requirements;
b) formal procedures are in place to control the allocation of access
rights to systems and services;
c) users are made aware of their responsibilities for maintaining
effective access controls, including in relation to passwords and
the security of their equipment;
d) access to information and application system functions should be
restricted in accordance with the access control policy;
e) use of utility programs capable of overriding controls should be
tightly controlled;
f) access to source code should be restricted.
6. Cryptography
This control requires the development and implementation of a policy on

the use of cryptographic controls to ensure effective use of cryptography
to protect the confidentiality, authenticity and/or integrity of
information. There should also be a policy on the use, protection and
lifetime of cryptographic keys.
42 Cloud Computing
7. Physical and environmental security
Information-processing facilities should be housed in secure areas,

protected by defined perimeters, with security barriers and entry controls.
They should be physically protected and commensurate with the
identified risks. Equipment should be protected from physical and
environmental threats and the electrical supply and cabling infrastructure
safeguarded.
8. Operations security
This control sets out requirements (amongst other things) in each of the
following areas:
a) the establishment of operational procedures and responsibilities

for all information-processing facilities;
b) the protection of information and information-processing
facilities from malware;
c) backup copies of information, software and system images in
accordance with an agreed backup policy;
d) the logging and monitoring of user activities, exceptions, faults
and security events;
e) the control of operational software;
f) the management of technical vulnerability; and
g) information systems audit considerations.
9. Communications security
This control sets out requirements in the following areas:
a) for the secure management of networks, including any

additional controls to protect sensitive information passing over
public networks;
b) information transfer policies, procedures and controls to protect
the transfer of information through the use of communication
facilities;
c) agreements on information transfer addressing the secure
transfer of business information;
d) the protection of information involved in electronic messaging;
e) confidentiality or non-disclosure agreements.
10. System acquisition, development and maintenance
This control requires that:
a) security requirements of information systems are identified at

the requirements phase of a project and documented as part of
a business case;
b) development and system change procedures are strictly
controlled;
Cloud Computing 43
c) test data should be selected carefully, protected and controlled.
11. Supplier relationships
This control requires control of information security in supplier

relationships. Information security requirements for mitigating the risks
associated with supplier’s access to assets should be agreed with the
supplier and documented. This also requires organizations to monitor,
review and audit supplier service delivery.
12. Information security incident management
This control requires that formal event reporting and escalation

procedures for security breaches are in place, as well as responsibilities
and procedures to handle events once they have been reported.
13. Information security aspects of business continuity management
A business continuity management process should be implemented to

minimize the impact of a security breach on the organization and recover
from the loss of information assets to an acceptable level, through a
combination of preventative and recovery controls.
14. Compliance
This control deals with the organization’s obligation to comply with

relevant legal requirements (including as to security and data protection),
that it regularly reviews its compliance with its own security standards,
and that it maximizes the effectiveness of, and minimizes interference
from, any audit process.
3.6.4 Certification
Customers of any company who are dependent on the provider keeping
data (or other assets) properly secure are free to take on trust a
statement that it keeps data secure to an appropriate standard (whether
BS ISO/IEC 27001 [14] or another). Any such statement (if untrue) may
well have legal consequences. This would certainly be the case if the
statement is part of a contract. Nonetheless, in many instances, a
customer does not need simply to rely on such a statement.
BS ISO/IEC 27001 (for example) has a mechanism for certification by a
third party. The third party will audit the controls in place and then (if it
is found that compliance has been achieved) certify as much.
44 Cloud Computing
Practical tip
A customer should not simply rely on a statement that a cloud

provider adheres to a standard on security. Rather, a customer should
ask for evidence of independent verification or certification.
Certification against BS ISO/IEC 27001 is provided by a number of bodies,

both accredited and unaccredited, including BSI. In the UK, the United
Kingdom Accreditation Service provides accreditation to organizations
(such as BSI) wishing to provide the service to clients who want to have
their compliance with a standard certified. An increasing number of
cloud providers are certified.
Practical tip
A customer should ensure that the certification is by a body of

standing, ideally (but not essentially) an accredited body.
To obtain certification against BS ISO/IEC 27001 is no mean feat and a

real measure of the seriousness with which the cloud provider takes
security. Indeed, there are many consultancies in the market that provide
services to companies to get them to the standard where they can be
certified. Ever increasing numbers of organizations are becoming certified
and there are a number of reasons for this. First, certification is
increasingly being required by customers. Secondly, enterprises feel a
competitive pressure to get certified; their competitors have it, so they
need it, too. Lastly, in the cloud environment, as a result of difficulties in
permitting audits by customers, certification is one way of perhaps
allowing customers to comply with the monitoring requirements required
by regulation such as data protection law (see 5.7).
A company relying on its intended cloud provider having certification

should certainly ask to see all documentation relevant to it (including the
full certificate issued) and perhaps the underlying documentation (such
as, with BS ISO/IEC 27001, the SoA).20 We mentioned in 3.6.2 that when a
customer undertakes its own due diligence in relation to BS ISO/IEC 27001
compliance, it needs to ensure the scope document covers the relevant
part of the organization. A similar consideration applies here.
20
Although, see the considerations of confidentiality mentioned in 3.4.4.
Cloud Computing 45
Practical tip
A customer should ensure, when relying on certification by a third

party, that the scope of the certificate includes that part of the
organization which is relevant to the solution the customer is
acquiring.
3.7 SSAE 16 (previously SAS 70)

3.7.1 Replacement of SAS 70
The Statement on Standards for Attestation Engagements (SSAE) No. 16,
Reporting on Controls at a Service Organization [16] (SSAE 16) is a
standard developed by the American Institute of Certified Public
Accountants (AICPA). It replaced the Statement on Auditing Standards
No. 70: Service Organizations [17] (SAS 70) in June 2011. The intention of
drafting and issuing SSAE 16 to replace SAS 70 was to update the US
service organization reporting standard so that it mirrors and complies
with the new international service organization reporting standard: ISAE
3402 [23].21
Although often referred to (in particular by cloud providers) as a security

standard, SAS 70 was in fact an accounting process for an audit, setting
out standards for fieldwork, quality control and reporting. SAS 70 was
never designed for certain service organizations that offer collection,
managed dedicated servers or cloud hosting services. It could be used to
audit many different types of controls and not only security controls or
security management controls. Whatever the sphere of application, it says
nothing about the substance of any controls or requirements; it only sets
out how those controls should be audited. In particular, even if an
organization’s security controls are said to be compliant with (or more
accurately, audited against) SAS 70, the standard says nothing about the
security in place. SAS 70 was not a technology or security standard, it was
an auditing standard.
SSAE 16, however, goes further than SAS 70 by not only verifying the
controls and processes, but also requiring a written assertion from the
management of the service organization regarding the design and
operating effectiveness of the controls being reviewed, which is included
in the final service auditor’s report. Despite going further than its
predecessor, it is still not true to say that an organization becomes
21
ISAE 3402 was developed to provide an international assurance standard for allowing
public accountants to issue a report for use by user organizations and their auditors on the
controls at a service organization that are likely to impact or be a part of the user
organization’s system of internal control over financial reporting.
46 Cloud Computing
3.7 SSAE 16 (previously SAS 70)
certified after undergoing an SSAE report. The report is still primarily an

auditor to auditor communication, albeit with more stringent
requirements.
Practical tip
Although SSAE 16 is more comprehensive and expansive than SAS 70,

it is still not a security standard and cloud customers should make
further enquiries.
3.7.2 Auditing customers

The starting point is that an audit will be taken (in accordance with SSAE
16 [16]) of an entity’s control objectives and control activities. The auditor
will then issue a ‘service auditor’s report’ at the end of that process. Any
organization could be subject to an audit requirement, that is, not only a
cloud provider but also a user of cloud services. When a customer is
subject to an audit in relation to its controls, the audit will have within
its scope a requirement to also look at the customer’s use of service
providers (and that includes any cloud provider, as well as more
traditional data centres or outsourced service providers). If a service (as is
likely) impacts upon the customer’s own controls, then the auditor, as
part of its responsibilities, will also want to check the internal controls of
that provider.
As a service provider will naturally have many customers, it would be

incredibly wasteful to have all the auditors of all those customers
separately examine the controls of the service providers. The SSAE 16
structure (like SAS 70 [17] before it) allows this waste to be avoided. A
service provider can – of its own initiative – obtain its own SSAE 16 audit,
which should also satisfy its customers’ auditors.
3.7.3 Two types of reports

As with SAS 70 [17], there are two types of service auditor’s reports under
SSAE 16 [16]. A ‘Type 1’ report focuses on the auditor’s opinion of the
accuracy and completeness of the data centre management’s design of
controls, system and/or service. The service auditor expresses an opinion
on whether the description is fairly presented and whether the controls
included in the description are suitably designed. Controls that are
suitably designed are able to achieve the related control objectives if
they operate effectively. The controls themselves are not tested. A ‘Type
2’ report contains all that is in a Type 1 report and an audit on the
effectiveness of controls over a certain time period, normally between 6
Cloud Computing 47
months and a year. Controls that operate effectively do achieve the

control objectives they were meant to achieve.
Practical tip
When examining a cloud provider’s statement that it has been

audited to SSAE 16, it is important for customers to:
• ask for the actual report and written assertion from

management;
• ensure it is a ‘Type 2’ report; and
• examine the controls that are in place and have been described
and commented on.
3.8 Contractual issues in information security

In this section, we explore a number of issues that arise in contracts for
cloud services relating to security and data. Much will depend on the
nature of the relationship between customer and provider. For a small
customer contracting with a substantial provider for a modest offering,
there will, of course, be no negotiating power and the customer will
simply have to accept the standard contractual terms of the provider.
However, in the largest of contracts, to which this section is more likely
to be relevant, there will be scope for negotiating on these, as well as
other, important provisions.
3.8.1 Contractual security schedule

The contract should set out an obligation upon the provider to comply
with a particular security standard. It could be in general terms (such as,
‘the provider will use reasonable efforts to keep data secure’), but it
would be better, as far as the customer is concerned, to set out some
level of detail about what security will actually be provided. This would
often be in the form of a security schedule.
Any customer, particularly one that is new to cloud computing, may

attempt to insist (at least initially, in the earliest stage of negotiations)
that the provider complies with the customer’s own security policy. This is
especially true of a more sophisticated customer, which may have its own
in-depth and detailed security policy, which might be generally applicable
across the enterprise, approved at the highest level, and not easily
departed from. Indeed, customers with the highest level of information
security policies may have dedicated teams and units whose sole role is to
48 Cloud Computing
audit and vet their critical suppliers from an information security

viewpoint. Such customers will need much persuasion to depart from
their own policies.
A provider is likely to make a number of points in response to a request

from a customer that the customer’s security standard should prevail.
First, its service enjoys the benefits of cloud computing (low cost,
elasticity, on-demand availability) precisely because it is a standard
offering, perhaps in a multi-tenanted architecture. As such, the provider
is not able, cost-effectively, to tailor its security policy for specific
customers. If one customer insists upon, say, 256-bit symmetric key
encryption for data in transit when the standard offering is 128-bit, the
provider has the option of adopting the higher standard for all customers
or of diverging the offering so that this insistent customer’s needs are
fulfilled whilst the others remain on the different standard.22 Neither is
ideal. The first option requires the expenditure of money that may not
be necessary or useful for other customers. The alternative detracts from
a proposition of the offering – to keep customers on the same playing
field. Secondly, the provider, of course, is the expert in data security, or at
least should be. If the provider, to continue the previous example,
considers that 128-bit encryption is adequate for the purpose of this
particular offering, given that the customer has decided to entrust its
data to that provider, the customer might reasonably be expected to
trust the security standards that are recommended. This is not to say that
the customer should do so blindly, however. The customer does need to
ensure that the policy is robust. The customer that is so well versed in
security matters that it sets its own, higher, standard is more able to
assess the provider’s proposition. (And it is not inconceivable that some
education takes place, with the customer looking again at whether its
own, more stringent, policy is necessary.)
3.8.2 Right to audit

A customer might insist upon a contractual right to audit the security of
the data by undertaking a physical visit to the data centre. Such a right
is, of course, very common in a managed services or outsourcing
agreement, where there are dedicated servers or even dedicated premises
for a particular customer, and only a ‘single-tenancy’ instance of the
system. However, in a cloud environment, this presents many difficulties.
First, it is not always clear where the data and servers are. In a true
virtualized cloud environment the data could be anywhere, and, indeed,
the location could be changing frequently and continuously. The data is
indeed likely to be at more than one location at any given time (for the
22
A further option, which may well emerge, is for a stratification to occur where different
levels of security are available at different prices, although the point remains that these
are always going to be ‘standard’ offerings in any case.
Cloud Computing 49
purpose of fail-safe provision of recovery services). Accordingly, in

practice, it is often not likely to be possible for a customer to inspect the
security of its own data. Secondly, the cloud provider with which the
customer is dealing may not, in fact, have direct control of the
underlying servers; it may be, for example, a SaaS provider built upon a
third-party IaaS or PaaS solution. Thirdly, even if that is not the case, an
audit of the provider’s systems will necessarily involve an inspection of
the systems of all other customers in the same installation. And what is
good for one customer is likely to be equally applicable to others. A
customer insisting upon a real, physical audit of data security might be
reminded that the infrastructure is a shared one. If the provider was to
agree that that customer should have access rights, it might be difficult
to resist a request by other customers, and that is something which this
customer may not welcome. Lastly, unless there is actual internal access to
the systems, all that is really being inspected by a physical audit is
physical security to the premises and the servers themselves. That is not
to belittle an audit of physical security, which is a crucial part of an
information security regime.23 However, more often than not, physical
security of premises is not part of a modern-day security breach or the
most pressing concern of the customer.
3.8.3 Constraints on location of data

A customer may well, for reasons explored elsewhere,24 wish to put
contractual constraints on the location of data. Most vendors will want to
have complete flexibility. Some vendors recognize the restrictions of the
regulatory environment (such as restrictions on data flows outside of
Europe where personal data is involved; see Chapter 6) and are willing to
give that assurance (perhaps for additional fees). Some of the major IaaS
providers, for example, will tell their European business customers that,
for at least some of their products, data will reside only in European
server farms. It may well be important for a European customer to have
this type of assurance.
If it is not possible for the cloud provider to give its European customer
an assurance that data will remain in Europe, then, as discussed in
Chapter 6, one of the various mechanisms to legitimize that transfer for
the purpose of overcoming that restriction may need to be put in place.
23
It is, of course, one of the controls dealt with by BS ISO/IEC 27001 [14] (see 3.6).
24
See Chapter 6
50 Cloud Computing
Practical tip
If data is to flow out of Europe, a customer should seek a contractual

assurance from its provider that the mechanism chosen (if any) will
be kept in place, for example that the provider will remain in the US
Safe Harbor scheme or maintain its (approved) ‘binding corporate
rules’ (see 6.4 and 6.7).
3.8.4 Provider liability for data

One of the most difficult issues to address in a cloud contract is the issue
of the provider’s liability for data. Data could be lost (in the sense of
being deleted or irretrievably corrupted) or the security of data could be
breached (in the sense of it being inappropriately disclosed to or accessed
by third parties). Both issues are frequently dealt with together in the
contract. A provider will often, in its starting standard terms, present
carefully crafted language allowing it to avoid any or most liability for
data. Often lost in the midst of a long exclusion clause detailing a
disparate set of items for which the provider will not be liable (such as
loss of profit or of goodwill) is the crucial phrase: ‘loss of data’. This may
be acceptable to the customer if the data is not critical, if it is backed up
elsewhere by the customer and if there is little risk of liability to third
parties (such as under data protection legislation).
On the other hand, such a stance may be unpalatable to a customer. First,

the purpose of the cloud service might well be as an alternative (and
perhaps only) storage solution. The customer may in effect be paying for
the service primarily to have the provider look after the data and such
exclusions can be seen as fundamentally undermining the deal. Secondly,
the customer might find itself with a very large bill for rectifying a
problem that was not of its own making. To further explore this issue, it
is useful here to briefly summarize some of the possible consequences of
a hypothetical data breach, and to discuss what types of loss the
customer might suffer (and therefore seek to pass onto the provider).
1. Notification costs
The customer may want to notify the individuals who are the subject of
the data that the security of the data has been breached. There is not (at
present) a general obligation under UK law to do so25 (see Chapter 7),
but nonetheless there might be a desire to do so and, indeed, in some
circumstances the Information Commissioner would recommend that it is
done as best practice. The US experience, under its comprehensive ‘data
25
As discussed in section 8.11, the position is likely to change as part of a general reform of
data protection law.
Cloud Computing 51
breach notification’ laws, shows that this can be very costly, as notices
must be prepared in accordance with legal requirements, which differ
between states.
2. Assistance to individuals
Companies that suffer a breach may be faced with concerned customers.

Help desks might need to be set up in order to deal with enquiries and
reassure customers. There is a burgeoning industry of security experts
who will assist in undertaking these activities. The cost of this might be
significant.
3. Compensation to individuals
There might be financial damage suffered by individuals (for example, as

a result of identity theft, fraud on their bank accounts and so on). These
individuals will seek redress against the customer (not the cloud provider
with whom they have no contract and of whom they may not even be
aware).
4. Damage to goodwill
There might be damage to reputation following a catastrophic breach so

that custom is lost. This type of claim is notoriously hard to prove in
court, but it might be possible if sales or share prices plummet.
5. Data might be lost or corrupted
If data is ‘only’ lost or corrupted, and not compromised, some of the

costs just mentioned would not arise. However, there might be two types
of claim here: first, the cost of reconstituting the data and, secondly, the
financial consequences of not being able to use the data or of relying on
the wrong data.
A starting point for many providers is to exclude liability for loss that is
of a purely financial type (such as damage to goodwill, inability to use
the data, lost profits and so on).26 It is difficult for a customer to
persuade a provider to move from its usual stance in relation to these
types of losses. Where there might be movement, however, is in relation
to ‘direct’ types of losses, such as the cost of reconstituting the data
(where it is the provider’s breach of contract that caused a loss or
corruption), or the cost of notifying individuals and setting up help desks.
It might also be possible to have the provider take the financial
consequences of claims brought by individuals against the customer (and
this is normally covered by an indemnity against the claim).
26
See also 13.2.
52 Cloud Computing
3.9 Key points
Whatever is, in principle, recoverable, it will still likely be subject to a

contractual cap on liability.27
Practical tip
A customer needs to look very carefully at liability language. It is not

uncommon for there to be an absolute exclusion of liability for ‘loss
of data’, sometimes hidden in a more general liability exclusion
provision.
3.9 Key points

In this chapter we have explored issues relating to information security.
Key points are as follows.
◆ Information security and confidentiality is a big concern for

customers. Security breaches have already occurred and will continue
to occur.
◆ A customer entrusting its data to a cloud service will want to get
some comfort (before contracting) that the provider addresses
security in a sensible fashion. It may seek to do so by undertaking a
due diligence process. Alternatively, or in addition, it may rely on a
claim by the provider that it complies with a recognized standard.
◆ A due diligence process will involve the presentation by the customer
of a list of questions and a response to that by the provider. Cloud
providers are beginning to pre-empt the process by providing more
information on their websites.
◆ As part of the due diligence process, a cloud provider will be
concerned not to disclose trade secrets, which are its competitive
advantage or which, if disclosed, compromise the integrity of its
security.
◆ The BS ISO/IEC 27000 series of standards addresses information
security management and includes a certification process in relation
to ISMSs (BS ISO/IEC 27001 [14]). Certification, when achieved, is a
real measure of commitment by a provider. However, a customer
should not rely on certification without, at the very least, checking
that the scope of the ISMS covered by the certificate includes all
aspects of the cloud solution the customer is considering acquiring.
◆ The SoA required by BS ISO/IEC 27001 sets out how each of the
control objectives and controls that the standard requires the
organization to consider are applied (or why they have been
excluded). A customer should consider reviewing this (although the
provider may be reluctant to disclose it for reasons of
confidentiality).
27
See also 13.3.
Cloud Computing 53
◆ A customer should be comfortable that any external certification

body is properly competent (and accreditation gives some assurance
in this direction).
◆ SAS 70 [17] was a standard often mentioned (as an encouragement)
by cloud providers (especially those based in the US). It has now been
replaced by SSAE 16 [16]. SSAE 16 (like SAS 70), though, is not a
security standard (nor an information security management standard
– such as the ISO/IEC 27000 series); it is only an auditing standard,
albeit a more comprehensive one than its predecessor. The cloud
provider is free to set whatever controls it wishes and the audit
describes those controls and the objectives they are intended to
achieve. This is accompanied by a written assertion from the
management regarding the design and operating effectiveness of the
controls.
◆ A SSAE 16 ‘Type 1’ report reports only the controls (chosen by the
entity) and the objectives. The ‘Type 2’ report reports on the auditor’s
test of the controls. Given the lack of prescription as to the controls
to be included in any information security system, great care is
needed by a customer in relying on the existence of even a Type 2
report. Any report will certainly need careful scrutiny.
◆ Irrespective of any compliance with any external security standard,
the contract should nonetheless contain a contractual agreement as
to the standard to be applied to the customer’s data. Given the
‘standard’ nature of the service (and its multi-tenancy aspects), it is
unlikely that a cloud provider can agree to modify its standard
security controls to adhere to any required by a specific customer, at
least not without additional cost.
◆ A right for the customer itself to audit security arrangements may be
irrelevant or inappropriate in a cloud situation given a possible lack
of certainty as to the location of the data and the fact that servers
will in any case be shared with many customers.
◆ Whatever the security standard agreed to, a cloud provider will seek
in its contractual language to limit liability (or exclude it in entirety)
if anything should go wrong. A security incident will likely impact all
its customers, and that will inform its attitude to limitation language.
54 Cloud Computing
4 Data protection: basics
4.1 Introduction
One of the principal legal issues that arises in cloud computing is that of
data protection law. Data protection legislation governs the treatment of
certain types of information, broadly, information about individuals,
known as ‘personal data’ in the legislation. These laws aim to impose
minimum standards on those handling such information with a view to
protecting the privacy of the individuals involved. It is inevitable, in most
instances, that, in providing cloud services, the provider will be handling
personal data on behalf of the customer. The UK data protection regime
(presently set out primarily in the Data Protection Act 1998 [24] (DPA))
will be a prominent legal issue in any cloud provision.
Given the fundamental importance of this issue, it merits introducing

some of the underlying data protection principles before applying them
to the cloud scenario. This chapter therefore commences with such an
introduction.
4.2 The basic structure of data protection law

UK data protection law stems from the European Data Protection
Directive [1] (the ’Directive’). As is usual, once the EU has adopted a
directive, the UK (in common with other member states of the EU) has to
‘transpose’ those directives into its national law. In theory, therefore,
there should be much commonality between the data protection regimes
across the EU. However, as the member states have some discretion as to
how to implement directives, there are 28 different implementations of
this Directive. Some member states have ‘gold-plated’ the requirements
(which set minimum standards). Other member states, such as the UK,
have changed little substantively and adopted a more minimal approach.
This variety of approach, coupled with the fact that each country has its
own enforcement regime and court system interpreting the rules, can
(and does) lead to inconsistency in the interpretation of the rules. To
avoid too much inconsistency between what the different member states
are doing and saying on common problems, the Directive set up an
institution to provide guidance: the Article 29 Data Protection Working
Party (the ‘Article 29 Working Party’). There are 28 members of the
Article 29 Working Party: the principal data protection regulators in each
of the member states. It issues opinions and other papers. It does not,
Cloud Computing 55
however, authoritatively interpret the law, which is a function reserved

for the national courts, with the CJEU as ultimate adjudicator on issues of
interpretation of European law, including directives.
It is important to introduce the Article 29 Working Party as it provides

much guidance on the fundamentals of data protection law, some of
which will assist businesses using or providing cloud services to determine
either how particular data protection requirements will apply to their
situation or (equally importantly) how the regulators might apply those
rules to the cloud. In July 2012, the Article 29 Working Party issued its
opinion on cloud computing [25]. The ICO has also issued guidance on
cloud computing [13]. Both of these will be referred to as we proceed to
discuss data protection issues.
4.3 A new data protection regime

Before proceeding, however, it is pertinent to mention that data
protection law is in the process of being reformed. In January 2012, a
proposal was made by the European Commission for the replacement of
the Data Protection Directive [1] with a regulation (the ‘Proposed
Regulation’). Unlike a directive, a European regulation would be directly
applicable across Europe and thus, in theory, should remove the
possibility of inconsistent or different requirements. The DPA [24] will
have to be amended or replaced as a result. At the time of writing, the
timing of any change is uncertain,28 as is the precise scope itself. There is
much political manoeuvring on the issue, not helped by European
parliamentary elections in 2014 and changes to the European
Commission. The Edward Snowden revelations about NSA surveillance
techniques (see 2.4) have also affected the debate and have served to
prevent a speedier resolution of the political negotiations that always
accompany new European legislation.
Given the above, it is beyond the scope of this book to deal extensively
with all the provisions in the Proposed Regulation, but a flavour of the
main changes (as they might apply in the cloud) may be useful and for
this see Chapter 8.
28
There might be the final adoption of a regulation in 2015, but then there will likely be
two years before it is effective. Although there can be no certainty, the earliest substantive
changes will come in would be 2017. Many businesses, though, will be preparing well in
advance of that date.
56 Cloud Computing
4.4 Personal data
As we discuss data protection requirements in the cloud we comment

also on relevant changes that might come about as a result of the
proposal (assuming that it progresses in a form near the proposed
draft).29
We turn now to the substance of data protection law and commence

with a discussion of some fundamental definitions.
4.4 Personal data

The DPA [24] (and the Data Protection Directive [1]) apply to the
processing of ‘personal data’. ‘Data’ is information that, broadly, is stored
electronically.30 This includes not only information that is within what
one might consider to be a traditional ‘database’ – although that
certainly is covered – but also any information in any electronic
document. ‘Data’ is wide enough to include documents that are scanned
into electronic form, CCTV footage, photographs uploaded onto
photo-sharing sites (of course, cloud services) and so on.
‘Personal data’ is any
data which relate to a living individual who can be identified—

(a) from those data, or
(b) from those data and other information which is in the possession
of, or is likely to come into the possession of, the data controller
[DPA, s.1(1)]
There are two parts of this definition that cause difficulties.
1. ‘relate to’
To be personal data the information must ‘relate to’ an individual. This

captures the idea that not all information which may be connected with
an individual is necessarily covered by the rules. The issue becomes: when
is the connection between the information and the individual sufficiently
close so that data protection rules are engaged?
2. Identification
The information must relate to an ‘identified’ or at least ‘identifiable’

individual. A name and address, national insurance (NI) number, passport
number or other standard identifier is not necessary and what is required
29
At the time of writing, there were, in fact, three main texts of the Proposed Regulation:
the original proposal from the European Commission of January 2012, a version produced
by the European Council in June 2013, and a version approved by the European Parliament
in October 2013.
30
Certain manual files are also within the definition but that is outside the scope of this
book.
Cloud Computing 57
is a means (which can be indirect) of singling out an individual. Difficult

issues arise in the technology world: when is an individual ‘identifiable’ in
a world of IP addresses (which some argue only identify computers),
radio frequency identification (RFID) tags, cookies tracking behaviour and
so on? What happens if the data is anonymized? (Answer to this latter
question: data protection rules no longer apply.)
To fully explore the nature of the debate on these concepts is outside the
scope of this book. Regulators generally take a very expansive view of
these definitions31 so that, essentially, most cloud services will involve the
processing of ‘personal data’ and so, if they have a UK (or European)
element, the data protection rules will likely apply. There have been a
number of cases in the UK explaining this definition, which perhaps
indicates that the courts were inclined to give a narrower view of the
definition than the regulators. In the 2003 case of Durant v FSA,32 the
Court of Appeal stated:
not all information retrieved from a computer search against an

individual’s name or unique identifier is personal data....Mere
mention of the data subject in a document held by a data controller
does not necessarily amount to his personal data.
Auld LJ (giving the main judgment) set out ‘two notions’ to assist in
deciding whether information was sufficiently relevant and proximate to
an individual to ‘relate to’ that individual. The first notion is that to
constitute ‘personal data’ the information should be ‘biographical in a
significant sense’. Auld LJ set out that the recording of an individual’s
‘involvement in a matter or an event that has no personal connotations’
is not biographical in a significant sense; privacy must be compromised.
The second notion is that the focus of the information should be the
individual (rather than another person, transaction or event). This was
interpreted by many commentators as limiting the definition from the
European norm by always requiring a ‘focus’ or ‘biographical
significance’. A 2014 case of the same court, Edem v Information
Commissioner,33 explained that these notions were only guidance in
difficult cases. In Edem, a lower tribunal had applied them to reach the
conclusion that names of individuals were not personal data since they
were not ‘biographically in a significant sense’ and the context did not
‘focus’ on the individual. This was deemed wrong; those tests had ‘no
relevance whatever’. The court said that the data there was obviously
personal data and more often than not it will be obvious when data
‘relates to’ an individual. Nonetheless, the Durant ‘notions’ will still be
applied in borderline cases.
31
Both the Article 29 Working Party (in Opinion 4/2007 on the concept of personal data (WP
136) [26]) and the ICO (Data Protection Technical Guidance Determining what is personal
data [27]) have issued guidance on this topic.
32
[2003] EWCA Civ 1746. See: http://www.bailii.org/ew/cases/EWCA/Civ/2003/1746.html
33
58 Cloud Computing
4.5 Data controllers and processors
The Proposed Regulation [65] will maintain a wide definition of personal

data, but will also clarify that the term will include online identifiers
(such as IP addresses) and similar technological constructs (such as RFID
tags).
Practical tip
In practice, any data that refers to an individual (even indirectly

through key codes, IP addresses and the like) has the potential to be
deemed to be personal data (by some regulators) and so cloud users
should (except for the clearest cases, such as pure financial data or
statistical data) consider the potential application of data protection
laws.
The DPA makes a distinction between personal data and sensitive

personal data. Sensitive personal data is personal data that consists of
information as to a person’s racial or ethnic origin, political opinions,
religious beliefs, whether he or she is a member of a trade union, his or
her physical or mental health, his or her sexual life, and his or her alleged
commission of a criminal offence or related proceedings (see Section 2 of
the DPA).34
The individual (to whom the data relates) is referred to as a ‘data subject’
in both the DPA [24] and the Data Protection Directive [1].

4.5.1 Introduction
Data protection law in Europe distinguishes between the concepts of
data ‘controller’ and data ‘processor’. Broadly, the controller ‘owns’ the
data, and the ‘processor’ is an agent handling the data for the controller.
More specifically, the Data Protection Directive [1] defines controller as:
‘the natural or legal person, public authority, agency or any other body
which alone or jointly with others determines the purposes and means of
the processing of personal data’ [Data Protection Directive, Art. 2(d)].
A processor is: ‘a natural or legal person, public authority, agency or any

other body which processes personal data on behalf of the controller’
[Data Protection Directive, Art. 2(e)].
34
The Proposed Regulation may well add to this list, certainly by adding ‘genetic data’
(which is not obviously captured by the existing ‘health data’ reference). Various drafts
being discussed include other possible expansions, such as: ‘philosophical beliefs’, ‘sexual
orientation or gender identity’ and ‘biometric data’.
Cloud Computing 59
‘Processing’ is given a wide meaning. It includes maintaining, recording

or holding data, retrieving or using data, disclosing the data or the
information, or carrying out any operations or set of operations on data
(which – in the end – covers almost any activity). Manipulating or even
simply storing personal data through a cloud service will be processing
that will engage the DPA [24].
The interpretation of these concepts plays a vital role as they determine

the responsibility for compliance with data protection rules and how the
individual data subjects can exercise their rights in practice. As will be
seen further on, a data controller has statutory responsibilities to data
subjects and is subject to scrutiny of the regulatory regime and,
ultimately, sanction through the courts; the processor presently has no
such responsibility or real scrutiny (although the position may well
change as a result of the Proposed Regulation [65] referred to in 4.3).
The controller (and not a processor) is also liable for any damage to data
subjects that might arise out of breaches of its statutory obligations. It is,
of course, possible for a controller to ensure (by means of a well-drafted
contract) that the processor takes the ultimate financial pain due to the
processor’s failures, for example, by means of an indemnity from the
processor to the controller. However, the regulatory burden and the
initial primary target for any compensation claim will even then fall upon
the controller.
4.5.2 What is the status of different players in the cloud?

Accordingly, determining whether or not an entity involved in the
processing is a controller or processor is fundamentally important. We are
not concerned here with the situation where the cloud provider is
providing a consumer-facing service directly to individuals: in that case,
the provider is, of course, in relation to dealings with its customers or
subscribers, a data controller. The position we are concerned about is
where a business uses a cloud service to process personal data of which
(leaving aside the nature of the technology used to process the data) it is
a data controller. The personal data might be about its employees (if the
service being used is a payroll or HR system, or similar) or perhaps its
customers (if a customer relationship system is used or if all IT
infrastructure is put on an IaaS system). On the face of it the position
would seem fairly clear. A business owns the data and is therefore a
controller. It entrusts the data to a service provider, which must therefore
be a processor (and not a controller). There was, however, initially some
doubt as to how to apply these concepts in the cloud situation as a result
of actions by regulators.
In 2006, Belgian data protection regulators determined the Society for

Worldwide Interbank Financial Telecommunication (SWIFT), which is a
member-owned co-operative conducting payment-processing activities for
60 Cloud Computing
the financial world, was a data controller and not a processor as had
been believed by SWIFT and member banks. SWIFT transports messages
between financial institutions. Each SWIFT message contains personal
data, including the names of the beneficiary and the ordering customer
of a payment transaction. SWIFT had two data centres: one in the EU, the
other in the US. All messages processed in one centre were automatically
stored and mirrored in the other centre.
Although not a cloud service, there are some features of the service that
are cloud-like: the service is distributed, data (messages) are stored in
multiple data centres of indeterminate location, and the service is usable
on a standard and highly scalable basis by its customers.
In June 2006, it came to light that, since the aftermath of 9/11, SWIFT
had been subpoenaed under US anti-terrorism law to provide certain US
agencies with personal data collected and processed by the SWIFT
network for international money transfers. In September 2006, the
Belgian data protection authority issued an opinion affirming that
SWIFT’s processing activities were in breach of data protection rules. A
little later, in November 2006, the Article 29 Working Party agreed [28].
SWIFT was found to be not a processor, as it always professed, but a
controller. In reaching this view, the regulators and the Article 29
Working Party considered that many of the actions taken by SWIFT (such
as complying with US authorities without informing the financial
institutions concerned) were actions of an autonomous controller, not
those of a processor. There were other features that are present in cloud
situations, such as the fact that the service was designed by the service
provider that also set the security standards.
The view expressed by the Article 29 Working Party was certainly

controversial. All service providers (cloud or otherwise) determine their
own security standard, the functionality of the service provided, the
contracts to which they wish to be bound (either to their customers or to
their suppliers) and the location of data centres, and these are all
features identified by the Article 29 Working Party as relevant to it
reaching its view.
Further, any service provider, located anywhere, may find itself under
legal compulsion to give up data in its possession (see 2.4); and that
alone – surely? – cannot make the provider a ‘controller’.
Fortunately, the view that more often than not a cloud customer is the
controller and the cloud provider is only a processor has now been
confirmed by specific regulatory guidance.
Cloud Computing 61
4.5.3 Regulatory guidance

The ICO issued guidance in 2012 addressing many practical issues relating
to cloud adoption by companies [13]. This guidance discussed the issue
very briefly, stating that:
In cloud computing it will be the cloud customer who will determine

the purposes for which and the manner in which any personal data
are being processed. Therefore it is the cloud customer who will most
likely be the data controller and therefore will have overall
responsibility for complying with the DPA.
The guidance does go on to discuss the position of the cloud provider

and that this will have to be assessed on a case-by-case basis. It envisages
the possibility that a cloud provider could in fact be a data controller but
only where the ‘cloud provider plays a role in determining the purposes
for which the personal data are processed, i.e. it uses the personal data
for its own purposes’.
It will be a rare situation where the provider does undertake such

processing (not least because the customer will hesitate to allow this).
The Article 29 Working Party has also issued guidance on cloud

computing [25] and agrees that in the usual situation the cloud provider
will be the data processor. However, it, too (as well as the ICO),
recognizes that a cloud provider may be a joint controller where it
processes data for its own purposes.
Both the ICO and the Article 29 Working Party emphasize that the fact of
putting the data into the cloud will not absolve the cloud customer from
its data protection obligations: it remains a controller with all the
responsibilities attaching to that [including, in particular, in relation to
security (see Chapter 5)].
4.5.4 A cloud provider as a controller – issues

As the guidance points out in 4.5.3, if the cloud provider commences to
process data for its own purposes, it will become a data controller.
Commercially, in the enterprise cloud, this will be rare as many cloud
customers would be concerned if this type of ‘reuse’ of data was to
occur.35
If the provider is a data controller, however, then difficult issues arise as

to how the provider can comply with data protection requirements in
any case with individuals with whom it has no contact or contract (Figure
35
Indeed, there may well be difficulties for the cloud customer in ‘legitimizing’ the transfer
to the cloud provider (see 4.8) if the former knows (as it should) that the cloud provider
will use the data for its own purposes. See 10.2 on commercial aspects.
62 Cloud Computing
2). There are obligations to provide information (including the identity of

the data controller) to the data subject about the fact that the controller
is processing the data.36 But this is in the context of individuals who have
no contact or contract with the cloud provider and the cloud customer is
likely not to have informed the data subject of the outsourcing. There
are similar difficulties with the data subject’s rights to access data.37
Figure 2. If the cloud provider is a controller, how does the provider

comply with data protection rules?
36
Paragraph 2 of Part II of Schedule 1 to the DPA [24], which implements Article 11 of the
Data Protection Directive [1].
37
Section 7 of the DPA, implementing Article 12 of the Data Protection Directive.
Cloud Computing 63
4.5.5 Multiple controllers

The definition of ‘controller’, in using the phrase ‘which alone or jointly
with others’ [Data Protection Directive, Art. 2(d)] [1], clearly envisages
that there might be more than one controller in relation to the
processing of a set of data. A cloud provider and its customer could well
both be a data controller. If this is the case, it leads to the possibility
(recognized by the Article 29 Working Party) that there might be joint
and several liability for failures to comply with the rules. In other words,
if there is a damages claim brought against the customer for a breach by
the provider (or vice versa) both are equally liable. However, this
situation is no different from when the provider is only a processor; the
customer in that situation (as controller) also takes responsibility for the
processor’s acts.
Practical tip
Cloud providers and their customers should agree in a contract which

party takes financial responsibility for the failure of the other to
comply with data protection law. Reciprocal indemnities may well be
appropriate.
4.5.6 ‘Disclosing’ personal data to a processor

Data protection rules apply to ‘processing’ of personal data and that
expression has a wide meaning, including carrying out any operation and
specifically ‘disclosing’ the personal data. A difficult issue that should be
considered is whether a data controller, in appointing a processor (a
cloud provider or otherwise), is ‘disclosing’ the relevant data (or
otherwise the carrying on of an operation on that data). If so, then this is
an incident of ‘processing’, which will have a number of repercussions.
On the normal use of the word ‘disclosing’, the answer would seem to be
that it does; after all, the data is entrusted into the possession of the
processor. However, this interpretation leads to some unfortunate
conclusions. If the handing over of the personal data to a processor is
‘processing’, then according to the first data protection principle, that
will need to be assessed as to whether it has been ‘processed fairly’38
and, in particular, a DPA, Schedule 2 ‘legitimizing basis’ would need to be
found (see 4.8.1). Whilst it is possible to argue that at least the condition
in paragraph 6 of the DPA, Schedule 2 will apply to permit a fairly
innocuous appointment of a processor, a difficulty will arise if the
personal data is sensitive personal data. In those circumstances, a
condition in the DPA, Schedule 3 will also need to be found and none is
38
DPA, Sch. 1, Pt I, para. 1 [24].
64 Cloud Computing
4.6 Jurisdictional issues
readily available as there is no equivalent of paragraph 6 of DPA,

Schedule 2. In other words, if the handing over of data to a service
provider is an act of ‘processing’ this is unlikely ever to be lawful when it
includes ‘sensitive personal data’.
Accordingly, the better understanding of the word ‘disclosing’ in this

context is that it does not cover the entrusting of personal data to a
service provider. It will be recalled from paragraph 4.5.1 that the data
controller will retain responsibility for compliance with data protection
law in these circumstances (and, in particular, responsibility for the
default of the processor) and, accordingly, this analysis is not detrimental
to ensuring good data protection for data subjects.

4.6.1 Introduction
As discussed in Chapter 2, one of the main issues with the cloud is that of
knowing precisely where the data is and thus determining which legal
regime would in fact apply. UK data protection law does have
international reach. In particular, the DPA [24] applies to a data controller
if:
• the data controller is established in the UK and the data is processed

in the context of that establishment; or
• the data controller is established in neither the UK nor the EEA but
uses equipment in the UK for processing the data other than for the
purposes of transit through the UK.
We consider these separately and apply these tests to typical cloud

scenarios.
4.6.2 Established in the UK

There are two aspects to this jurisdictional test. Most easily, the DPA [24]
applies if the data controller is established in the UK. The DPA says that
the following are established in the UK:
• an individual who is ordinarily resident in the UK;

• a UK company;
• a UK partnership or other UK unincorporated association; and
• any person or entity that nonetheless maintains in the UK an office,
branch or agency, or a regular practice.
The second aspect is that the data needs to be processed in the context
of that establishment. This requirement was an important feature of a
truly momentous decision from 2014.
Cloud Computing 65
In a landmark ruling on 13 May 2014,39 the CJEU, the EU’s highest court,
found that Google was obliged to remove from its search engine
databases the personal data of an individual, even though that
information was accurate and not ‘prejudicial’. The decision has
generated much publicity and comment, especially concerning the
(supposed) creation (or at least confirmation) of a ‘right to be
forgotten’.40
The case concerned a Spanish citizen about whom a Spanish newspaper,

La Vanguardia, had published two articles in 1998. The articles were
factually accurate but embarrassing to the individual (concerning debt
proceedings). A Google search against his name resulted in links to
archived copies of these two articles being displayed. He could not get
the newspaper to remove the articles,41 so he tried to get Google to
remove links to the articles, since the appearance of the links in the
search database involved the processing of his personal data. The case
went from the regulator and then through the courts and ended up at
the CJEU.
Whilst it is this ‘right to be forgotten’ that attracted all the headlines,

there was another aspect of the case that is important in the present
context and of potentially far-reaching effect. In order to apply this ‘right
to be forgotten’, the CJEU had to rule that Google Inc. was subject to
Spanish data protection law, despite it being a US company with no
direct presence in Spain. It did so, in short, because Google Inc. had a
sales and marketing affiliate operating in Spain and the activities of
those two entities were sufficiently close. It discussed Article 4 of the
Data Protection Directive [1], which is in similar terms to the Section 5 of
the DPA.
As is well known, the Google search service is offered through a number

of domain names throughout the world. Although the Google group has
a Spanish member, even the Spanish language version of the search
engine (www.google.es) is operated by Google Inc.. So there was a
problem here for the application of the European rules. Google Inc. was
processing personal data in the search engine42 but was not itself
incorporated in Spain or the EU. By contrast, Google Spain was
39
Google Spain SL and Google Inc. v Agencia Española de Protección de Datos and Mario
Costeja González, Case C-131/12, 13 May 2014.
40
Such a right has been suggested in the Proposed Regulation (see 4.3). The European
Commission in June 2014 stated that this judgment shows a ‘right to be forgotten’ exists
anyway under current law and including an express reference to it in the Proposed
Regulation is simply a matter of ‘clarification’ [29].
41
The press has special protection under the Data Protection Directive [1] and the DPA – but
this is outside the scope of this book.
42
This aspect was also very controversial. The CJEU had overruled its adviser, the Advocate
General, who gave an opinion that building a search engine which contained personal
data was not the ‘processing’ of personal data within the Data Protection Directive.
66 Cloud Computing
incorporated in Spain (and, thus, the EU) but did not operate the search
engine and was not processing personal data.
The CJEU found its way out of this dilemma by highlighting that even
though Google Inc. was not incorporated in the EU, given the
‘inextricable link’ between the search engine activities of Google Inc. and
the sales and advertising activities of Google Spain it could nonetheless
be said that there was an establishment of Google Inc. in Spain. The CJEU
drew attention to the fact that the search engine activities were in the
‘context of the activities of’ Google Spain since the latter sells the range
of advertising services (sponsored advertisements, keyword acquisition
and so on) that fund the search engine service operated by Google Inc..
In other words, Google Inc.’s processing was subject to the jurisdiction of
Spanish data protection law (and, by extension, the data protection law
in all other member states of the EU in which Google has an affiliate
undertaking similar activities to Google Spain).
This approach will likely be applied generally. Any internet (or other
data-processing) business that has a sales or advertising arm within
Europe used to fund that business could be within the reach of EU data
protection rules. In particular, it can easily be seen how this might apply
to cloud services, especially those that are targeted to consumers (e.g.
social media sites).
The judgment is not without difficulty. If a US data controller was within

EU data protection rules on the basis of the establishment of a sales arm
in a country, then what is the position if there is such an establishment in
many countries (as is the case, for example, with Google)? Does this
non-EU activity then need to comply with the data protection rules in
every country in which it has a sales affiliate? Does it need to make a
filing in all the countries (that require filings)? Put another way: can an
individual disgruntled with the activities of such a controller bring a claim
in any country where there is such a presence, that is, can they ‘forum
shop’ for the most assertive regulator or amenable court? It will no
doubt take some time to work through these issues, although the
Proposed Regulation [65] (see 4.3) may well make some of them
redundant. In the meantime, US cloud providers will have to be aware
that EU rules may well apply to them.
4.6.3 Established outside the UK

An entity that is not established within the EU is subject to the DPA [24]
merely if it is using equipment within the UK. Accordingly, and perhaps
surprisingly, the DPA will also apply to data controllers that are outside
Europe but which use servers located within the UK (including, arguably,
those which are operated by service providers). The Article 29 Working
Cloud Computing 67
Party’s Opinion on applicable law43 confirms that, in its view, this is all
possible and, indeed, correct. It discusses the possibility in the context of
outsourcing generally, rather than cloud services. It makes the point that
this should certainly be the case when there is a non-tenuous connection
with Europe. It is then only when the connection is tenuous (as it puts it:
‘inadvertent, rather than intentional, use of equipment’) that the Data
Protection Directive [1] (or in the UK, the DPA) should not be applied. Of
course, even when the UK rules apply, if the controller never in fact
‘comes into’ the UK (i.e. if it never has an office or assets here), the data
controller being within the jurisdiction of the UK for data protection
purposes may mean nothing in practice except for a theoretical
application of the rules, and a possibly theoretical transgression. The
application of the DPA on such a theoretical basis is one thing; the ability
of the ICO or courts to enforce the rules is another. Another point is that
the ICO is unlikely to have any appetite to enforce against a non-UK
controller merely within the DPA on the grounds that it is using the
services of an entity that has servers within the UK.
4.6.4 Application of jurisdictional rules to cloud services

As has just been seen, the main test for the application of UK data
protection law is the place of establishment of the data controller. A
British customer using the services of a cloud provider that is outside the
UK, or which might be using servers outside the UK, remains nonetheless
within the ambit of the UK data protection regime. Many non-European
(in particular, US) entities selling cloud services to UK or European
customers will come across these issues on a regular basis. They will be
aware of the European rules, will be familiar with security requirements
and issues around transfers of data out of Europe (discussed in Chapter 6)
and, indeed, may well have signed up (if they are in the US) to the ‘Safe
Harbor’ scheme.
However, the fact that a non-European-based customer might find itself

within the European rules on the basis that it uses a cloud service within
Europe will take many by surprise. Nonetheless, this is a possible
consequence of the rule which states that using equipment within the EU
is sufficient to found jurisdiction. A cloud provider within Europe (using
equipment within Europe) risks ‘exporting’ the jurisdiction of European
data protection rules to its non-EU customers (see 4.6.3). However, if the
European cloud service is in fact built upon a non-European IaaS (where
data is not held within Europe) then this rationale does not apply, as
there is no use of equipment within Europe. As can be seen, determining
which law applies to data in the cloud can be very difficult indeed.44
43
Opinion 8/2010 on applicable law , WP 179 [30], in particular, paragraph III.4.
44
It is not only the EU data protection law that causes these types of difficulties. See 7.6.2 for
a discussion of how US data breach notification laws are also ‘exported’ to non-US
providers.
68 Cloud Computing
4.8 Legitimization of processing
4.7 The eight data protection principles

The fundamental requirement of UK data protection law is that a data
controller must process data in compliance with certain guiding
principles, the ‘data protection principles’, which are set out in Schedule
1 to the DPA [24], and reflect provisions of the Data Protection Directive
[1] (although they are not called ‘principles’ in the Directive nor grouped
in the same manner). The schedules to the DPA also contain
interpretative guidelines. Nonetheless, the principles are set at a very
high level and there is much scope for variation as to how they might
apply in a particular context. The ICO provides useful guidance on many
common issues faced by data controllers.45
The eight data protection principles are as follows.
1. Data must be fairly and lawfully processed. This principle will not be
satisfied unless one of the conditions set out in Schedule 2 to the
DPA is met. In the case of sensitive personal data, one of the
conditions in Schedule 3 must also be met. We discuss these
schedules further on.
2. Data must be obtained and only processed for the purposes
specified.
3. Data must be kept adequate and relevant, and must not be excessive
in relation to its purpose.
4. Data must be accurate and up to date.
5. Data must be kept for no longer than is necessary.
6. The rights of the data subject must be respected.
7. Data must be safeguarded by technical and organizational measures
against unauthorized access and loss or damage.
8. Data must be safeguarded and not transferred to countries outside
the EEA46 unless adequate safeguards are in place.
It is the last two principles that present the biggest challenge in a cloud
environment, but the others remain important for both customer and
provider alike.
4.8 Legitimization of processing

4.8.1 Personal data generally
The first data protection principle (that processing must be fair and
lawful) requires that one of the following six conditions (set out in
Schedule 2 to the DPA [24]) must be fulfilled.
1. The data subject has given his consent to the processing.
45
Including one on cloud computing: Guidance on the use of cloud computing [13].
46
The EEA is the EU together with Iceland, Liechtenstein and Norway.
Cloud Computing 69
2. The processing is necessary—

(a) for the performance of a contract to which the data subject
is a party,…
3. The processing is necessary for compliance with any legal
obligation to which the data controller is subject,…
4. The processing is necessary in order to protect the vital interests
of the data subject.
5. The processing is necessary—
(a) for the administration of justice, or for other public
functions…
6. (1) The processing is necessary for the purposes of legitimate
interests pursued by the data controller or by the third
party…to whom the data are disclosed, except where the
processing is unwarranted in any particular case by reason of
prejudice to the rights and freedoms or legitimate interests
of the data subject...
The latter requirement (paragraph 6 of Schedule 2 to the DPA) is very

important in practice and allows businesses to get on with unobtrusive
activities. It is sometimes called the ‘balance of interest’ condition or the
‘legitimate interest’ condition. It allows an activity to be undertaken if it
is in the legitimate interest of the controller. Legitimate interests include
such activities as marketing its services, organizing itself efficiently,
outsourcing its operations (including into the cloud) and so on. The only
caveat is that it must not prejudice the rights or interests of the data
subject (and if it does, such prejudice must not be unwarranted).
4.8.2 Sensitive personal data

Sensitive personal data (see 4.4) has an extra level of protection under
data protection rules. It includes information about racial or ethnic
origin, political opinions, religious beliefs, trade union membership,
health, sexual matters and information about crimes or alleged crimes.
The main extra level of protection in relation to such sensitive personal
data is that, in addition to having to satisfy one of the requirements set
out in Schedule 2 to the DPA [24] (applicable to personal data generally),
a data controller has also to satisfy one of a number of more stringent
requirements in Schedule 3 to the DPA. The following is a summary of
the more important of the conditions set out or referred to in that
schedule.
• The data subject has given his explicit consent to the processing of
the personal data.
• The processing is necessary for compliance with employment law.
• The processing is necessary to protect the vital interests of the data
subject or another person (where consent cannot be obtained).
70 Cloud Computing
4.9 Notification to the Information Commissioner’s Office
• The processing is by a not-for-profit body existing for political,

philosophical, religious or trade-union purposes and relating to
individuals who either are members or have regular contact with the
body.
• The information contained in the personal data has already been
made public by the data subject.
• The processing is for legal proceedings, obtaining legal advice or for
the purposes of establishing, exercising or defending legal rights.
• The processing is necessary for the administration of justice, or for
other public functions.
• The processing is part of the operation of certain anti-fraud
organizations.
• The processing is necessary for certain medical purposes by medical
or other professionals under a duty of confidentiality.
• The processing is for monitoring equality of treatment or
opportunities related to racial or ethnic origin.
4.9 Notification to the Information

Commissioner’s Office
A data controller is required to ‘notify’, to the ICO, the fact that it is
processing personal data. There are exemptions that apply to certain
common activities which do not generally include any data protection
concerns. The main exemptions can be summarized as follows.
• Staff administration exemption: the processing is for HR purposes

and is of data relating to staff of the data controller.
• Advertising, marketing and public relations exemption: the
processing is for the purposes of advertising or marketing the data
controller’s business and is of data of customers and suppliers.
• Accounts and records exemption: the processing is for the purposes
of keeping accounts of business dealings and is again of data of
customers and suppliers.
Many small users of data, in particular, which do not process personal

data in a particularly adventurous or aggressive manner, will fall within
these exemptions. It is a requirement of each of these exemptions that
the data controller does not disclose the personal data to any third party.
As discussed at 4.5.6, putting data into a cloud service (where the cloud
provider is a processor) is not likely to be an act of ’disclosing’ the data
to a third party.
The other issue likely to occur in relation to a cloud offering concerns the
details that the controller is obliged to file. The controller, in its
notification, should state the names of the countries outside the EEA (see
6.4 and 6.7) to which the data is to be transferred.
Cloud Computing 71
Practical tip
Unless there is a contractual commitment from the cloud provider

that the data will remain within Europe or stay in a particular
country, the registration should make it clear that the data could be
anywhere in the world.
4.10 Enforcement
A feature of the UK implementation of the Data Protection Directive [1],
and in marked contrast to other European member states, is the
relatively benign consequences of breaching the rules: there are very few
criminal sanctions (and none directly relevant to a cloud situation), it is
hard for individuals to claim compensation, and there are relatively
limited powers for the regulator to fine. The position may well change,
however, in the not too distant future (see 8.15).
4.10.1 Damages claims

An individual may be able to claim compensation if they have suffered
damage or distress because of a breach of any of the requirements of the
DPA [24] by the data controller. As mentioned previously, a controller has
compliance responsibilities and a processor does not. Whilst there is some
doubt as to whether or not a cloud provider will necessarily be deemed a
processor (see 4.5), however it is characterized, a breach of security by
the cloud provider resulting in the data subject suffering damage or
distress will result in liability for the customer.
Practical tip
Customers in the cloud may want to ensure that the contract

contains a suitable indemnity clause in relation to any claim from a
data subject as a result of wrongful processing (including breach of
security) by the processor.
4.10.2 Enforcement notices

Enforcement of the DPA [24] remains primarily through administrative
action by the regulator. The ICO has the power to serve ‘enforcement
notices’ against data controllers breaching the data protection principles.
These notices require the data controller to take, or refrain from taking,
certain steps in relation to processing. If the ICO considers a customer to
72 Cloud Computing
4.10 Enforcement
have breached the data protection principles in undertaking a cloud

transaction, for example, it could serve a notice requiring the
transgression to cease.
4.10.3 Monetary penalties

Since 2010 the ICO has had the power to impose fines upon certain,
particularly grave, breaches of the principles. A power to fine a data
controller arises if:
• there has been a serious contravention of the data protection

principles by the data controller;
• the contravention was of a kind likely to cause substantial
damage or substantial distress; and
• either the contravention was deliberate or the data controller
was (in a defined sense)47 careless. If the contravention was not
deliberate, there is no power to fine unless the data controller
knew (or ought to have known) both that there was a risk that
the contravention would occur and that such a contravention
would be of a kind likely to cause substantial damage or
substantial distress, and nonetheless had failed to take
reasonable steps to prevent it.
(Section 55A, DPA.)
It should be noted that there is no requirement that the damage or

distress has actually occurred, only that the contravention was of a kind
likely to lead to that damage or distress. Sloppy handling of security,
through which no one has in fact suffered this type of loss, will be
sufficient. This hurdle is high enough, but the legislation does not stop
there. In order to fine:
• the ICO must be satisfied as to the matters just mentioned;

• it must first serve a ‘notice of intent’, which invites the controller to
make written representations and contains certain timing details; and
• it may then (after the expiry of time for the making of
representations) serve a ‘monetary penalty notice’ setting out the
penalty proposed.
The fine cannot be more than £500,000. The ICO has issued guidance [18]
on how the power to fine will be exercised. The guidance deals with the
‘Circumstances in which the Commissioner would consider it appropriate
to issue a monetary penalty notice’, and how it will determine the
amount of the penalty. This makes it clear that the ICO will take into
account the sector and the size, and the financial and other resources, of
47
Namely, the controller must have known (or ought to have known) that there was a risk of
a contravention occurring and failed to take reasonable steps to prevent it (Section 55A(3),
DPA).
Cloud Computing 73
the controller and, indeed, that it is not the purpose of the monetary
penalty notice to impose undue financial hardship on an otherwise
responsible controller.
In relation to cloud services, security (the seventh data protection

principle) is the most important to consider. Security is entrusted to the
provider, but if there is a breach then the question of whether the ICO
can fine the customer arises. Many of the fines levied so far are in
relation to breaches of security.
Whilst there have been some fines directed at the private sector, by and
large most substantial fines to date have been against public bodies. One
difficulty the regulator has in using these powers is to be satisfied that
the threshold requirement, that there has been ‘substantial damage’ or
‘substantial distress’, has been met, which for much commercial activity is
perhaps a hard test to meet.
In the public sector, the largest fine at the time of writing was a £325,000
penalty imposed upon Brighton and Sussex University Hospitals NHS
Trust48, following the discovery of highly sensitive personal data
belonging to thousands of patients and staff on hard drives sold on an
internet auction site – a fairly clear breach of the security principle.
A large fine in the private sector arose following the well-publicized

security breach that afflicted the Sony PlayStation Network Platform in
2011 (see 3.3.7 above). An ICO investigation found that Sony failed to
ensure that the Playstation Network Platform service provider kept up
with technical developments and the attack could have been prevented if
the software had been up to date.
The ICO found that there was a serious contravention of the seventh
data protection principle, namely, that Sony failed to ensure that
appropriate technical measures were taken against unauthorized or
unlawful processing of personal data. The measures taken by Sony did
not ensure a level of security appropriate to the harm that might result
from a breach. The notice served on Sony was made public but (for
obvious security reasons) with much of the detail of the transgression
redacted. From the publicly available details, though, it is clear that the
ICO considered that Sony had not kept up with the latest technological
developments, such as additional cryptographic controls to protect
passwords.
The ICO was also satisfied that the breach was of a kind likely to cause
substantial damage or substantial distress, in particular, that Sony’s users
suffered considerable distress knowing that their personal data had been,
or may have been, accessed by third parties and could have been further
disclosed. Lastly, the ICO ruled that Sony knew, or ought to have known,
48
Monetary Penalty Notice, dated 28 May 2012, served by ICO.
74 Cloud Computing
4.10 Enforcement
that there was a risk that the contravention would occur unless
reasonable steps were taken to prevent the contravention, such as
additional cryptographic controls.
Taking into account some mitigating factors, such as a voluntary

notification of the breach and the substantial commercial damage to the
Sony brand in this area, the fine imposed in January 2013 was £250,000
(reduced to £200,000 for prompt payment). Sony commenced an appeal
but subsequently dropped it, stating that to fight it would risk exposing
sensitive information about its own networks.
The largest private sector fine was £300,000, imposed in January 2012
against Christopher Niebel, the director of Tetrus Telecoms, a company
responsible for sending thousands of unlawful spam messages. However,
this fine was successfully appealed when the Information Rights Tribunal
ruled in October 2013 that insufficient damage or distress had been
caused to recipients to merit the penalty.49
It remains to be seen how the ICO will apply these requirements in a

purely cloud environment. In particular, how will the requirement that
there needs to be a ‘deliberate’ or ‘careless’ contravention of the security
rules apply, when security is entrusted to a cloud provider? Might a
controller be fined because the provider was ‘deliberate’ or ‘careless’? As
discussed in 5.3, the requirement in relation to security when a processor
is used is for the customer to ensure the provider gives ‘sufficient
guarantees’ on security, and for the customer to take ‘reasonable steps’
to ensure compliance with the security measures. If the controller has
taken ‘reasonable steps’ to ensure compliance but, despite taking those
steps, has failed to notice a deliberate or careless breach of the
contractual security requirements by the cloud provider, it is arguable
that there may, in fact, be no breach of the security principle.
Practical tip
Whatever the compliance responsibility, a cloud customer will most

certainly wish to be indemnified against any monetary penalty
imposed upon it as a result of a breach by the cloud provider.
49
http://www.informationtribunal.gov.uk/DBFiles/Decision/i1106/Niebel,%20Christopher%20
EA.2012.0260.pdf
Cloud Computing 75
4.11 How does all this apply to the cloud?

In Chapter 5 and Chapter 6, we consider the two principle issues arising
from data protection law in the cloud context.
1. Are there any regulatory requirements in putting the data into the
cloud (irrespective of the issue of which country the data is in)?
The use by a cloud customer of a provider to process its data invokes

issues of whether the provider is a processor or a controller. If the
provider is a processor, the main compliance concern is for the customer
to ensure it satisfies the seventh data protection principle (to keep data
secure). If the provider is a controller, the additional concern arises as to
how that appointment can be made ‘fairly and lawfully’ as required by
the first data protection principle.
2. What are the requirements if data is not within Europe?
Inevitably, there is the possibility that data will be transferred outside of

Europe and so the eighth data protection principle needs also to be
considered, namely, that personal data cannot be transferred outside
Europe unless the data controller assures an adequate level of protection
of the personal data.
4.12 Key points

In this chapter we introduced data protection, including some of the
fundamental concepts and principles necessary to apply data protection
law to the cloud. Key points are as follows.
◆ Data protection law applies only to personal data. The definition of

personal data is so wide that most (if not all) cloud implementations
will involve, to some extent or other, the processing of this type of
data by the cloud provider, and so the application of data protection
law.
◆ Data controllers have responsibilities under data protection law, but
data processors do not. Ordinarily, the cloud customer is the data
controller.
◆ However, the more discretion a provider has in a contract to
determine how the data is processed and for what purpose, the
more likely that a regulator will take the view that the provider is
also a data controller.
◆ The core of data protection law in the UK (and Europe) is the eight
data protection principles. Security (the seventh principle) and
transfer restrictions (the eighth principle) are particularly relevant in
cloud computing and are discussed separately.
◆ The ICO now has a power to levy monetary penalties for certain
serious breaches of data protection law. Data subjects also have a
76 Cloud Computing
4.12 Key points
right to sue for damages for certain breaches. Even if caused by the
cloud provider, a customer would be the target of any such
regulatory action or data subject claim. A customer should include
appropriate indemnities in the contract so that any liability that is
properly the fault of the provider can be fully passed on.
Cloud Computing 77
5 Data protection: appointing a
cloud provider
5.1 Introduction
We are discussing the situation where the cloud service involves the
processing of ‘personal data’. If the data is, say, purely scientific or
financial or similar in nature, and does not relate to or identify any
individual, then data protection rules will not apply. There is often a
focus in discussions on data protection, which arises when a cloud
customer wishes to put into the cloud personal data of which it is data
controller, on issues around the transference of data out of the UK or
Europe (in particular to the US). We address these issues in Chapter 6.
This chapter explores a preliminary issue, namely, requirements that arise
when personal data is put into the cloud, independent of those that arise
when data is transferred outside national borders. In other words, it
explores the compliance issues that arise when a UK company entrusts
personal data to a UK cloud provider using only UK-based servers.
We discussed in Chapter 4 the importance of determining whether the

cloud provider is a processor or a controller. Most cloud providers would
be considered to be a processor by regulators. As such, at present, they
would have no direct data protection responsibilities.50 Nonetheless,
following the Article 29 Working Party’s SWIFT decision and subsequent
opinion [31] (see 4.5.2), it is possible that this will not always be the case
in the eyes of regulators and enforcement agencies. Accordingly, while
the usual situation would be a controller entrusting data to a processor,
it is also worth briefly considering the position under the other
possibility. The situation where a provider is properly considered to be a
processor is considered in 5.3 and the situation where the provider is
found to be a controller is considered in 5.4. Subsequent sections will
detail considerations that apply however the provider is properly
characterized.
We begin, though, with a short discussion of European data protection

regulators’ attitudes to cloud services.
50
The position may well change as part of the imminent reform of data protection law (see
Chapter 8 and, in particular, 8.9).
78 Cloud Computing
5.3 Cloud provider as a data processor
5.2 European regulators and cloud services

Some European data protection regulators are finding it hard to accept
use by public authorities and their customers of cloud services.
Fortunately for cloud take-up in the UK, the ICO is not one of these
regulators. In the ICO’s opinion on cloud computing [13], it gave practical
guidelines as to how data protection issues could be navigated. However,
other regulators are more sceptical.
In February 2011, the Danish Data Protection Agency rejected Odense

Municipality’s application to use the cloud service Google Apps to store
data in relation to its public schools. Odense Municipality stated that
data would be transferred initially to Google Ireland Limited; Google
subsequently informed the Agency that it holds all data in numerous
data centres worldwide, including in the US and Europe. Thus, data
would be shared between Denmark and Ireland, then between Ireland
and potentially every other country in which Google operates data
centres (be it the US, the EEA or others). The Agency’s view was that any
Google data centres in the US would be covered by Safe Harbor (see 6.4),
thus Odense Municipality was permitted to store data there as well as in
Ireland.
However, the Agency decided it must assume that data would be

transferred not only to Ireland and the US, but also to all the other
countries in which Google maintains data centres, including those neither
in the EEA nor the US (and covered by Safe Harbor). It therefore
determined that Odense Municipality would not comply with current
legislation because it was not proposing to enter into a contract based
on the European Commission’s standard contractual clauses with Google’s
individual data centres.
A second recent example of current strictures comes from the attitude

taken by the Dutch government. In September 2011 it took a hard line
against US cloud providers: government departments were severely
restricted in using such providers to process government IT data. The
Dutch government’s reasoning was that the USA Patriot Act [6] (see 2.4.2)
requires US companies to provide data to the US authorities if requested
under the Act.
More generally, the EU issued an opinion on cloud computing in 2012

[25], which also seemed to cast doubt as to whether Safe Harbor was
sufficiently robust (see 6.4).
5.3 Cloud provider as a data processor

In this section, it is assumed that a cloud provider is a processor, and not
a controller. The UK data protection rules deal with the appointment of
processors only in one place: the security requirements set out in the
Cloud Computing 79
5 Data protection: appointing a cloud provider
seventh data protection principle (and explanatory text). The requirement

is that data must be safeguarded by appropriate technical and
organizational measures against unauthorized access and loss or damage.
Leaving aside the appointment of a service provider, in order to decide
what measures are ‘appropriate’, a controller is obliged to take into
account the sort of data being processed, the harm that might result
from its misuse and, also, the technology that is available to protect it.
There is no requirement to buy ‘best of breed’ security; the DPA [24]
makes clear that a controller may have regard to the cost of providing
security.
The explanatory provisions around this principle deal only with processors
generally and not cloud providers. Paragraph 11 of Part 2, Schedule 1 of
the DPA [24] requires that when personal data is entrusted to any
processor (and so therefore also any cloud provider), the controller (the
cloud customer) must:
• ensure the provider gives ‘sufficient guarantees in respect of the

technical and organizational security measures governing the
processing to be carried out’, and
• take ‘reasonable steps to ensure compliance with those measures’.
The security requirement is not to be considered as fulfilled unless there

is a written contract in place (which is likely to include an electronic
contract) and under that contract the processor is obliged to:
• act only on instructions from the customer, and

• comply with obligations equivalent to those imposed by the seventh
data protection principle. (See paragraph 12 of Part 2, Schedule 1 of
the DPA [24].)
These requirements are, on the face of it, not hard to fulfil. The
contractual language required by the DPA is language that a customer is
likely to want in any case for commercial reasons – to only use the data
on the customer’s instructions (that is, for the customer’s benefit) and to
keep the data secure. The only potential difficulty is the level of security
that is required by the seventh data protection principle and which the
DPA requires the customer to impose upon the provider. Will the
provider, having reached a view as to what is, in fact, appropriate,
necessarily agree with the customer? We discussed the issue of the
customer imposing its security requirements onto the provider in
Chapter 3.
We have already considered above (see 4.5.6) whether the act of a

controller putting personal data into the possession of a processor (that
is, a data processor) is in itself an act of ‘processing’ and discussed why
that is not the case. The position, though, is different when the provider
is a controller, a position to which we now turn.
80 Cloud Computing
5.5 Can personal data be put into the cloud?
5.4 Cloud provider as a data controller

If the provider is a data controller or a joint controller with the customer,
which, for reasons discussed above (see 4.5), is unlikely unless the
provider starts using the data for its own purposes, then the act of the
customer in putting the personal data into the hands of the provider will
be a disclosure to a third party and, therefore, an act of processing that
needs to be undertaken ‘fairly and lawfully’, in accordance with the first
data protection principle (see 4.8). Both the customer, in handing over
that data, and the provider, in processing (which includes holding) that
data, would need to comply with this principle and find a legitimizing
basis (that is, satisfy one of the requirements in Schedule 2 to the DPA
[24]). The customer is likely to be able to rely – in most circumstances –
on paragraph 6 of Schedule 2: the ‘balance of interest’ condition.
This condition allows processing to be undertaken when it is necessary

for the purposes of ‘legitimate interests’ [DPA, Sch. 2, para. 6(1)] pursued
by the customer. It is certainly arguable that using a cost-effective,
commercially sensible cloud service is a legitimate interest of the
customer. The condition also contains the proviso that the processing
must not be ‘unwarranted in any particular case by reason of prejudice to
the rights and freedoms or legitimate interests of the data subject’ [DPA,
Sch. 2, para. 6(1)]. In order to undertake this balancing act it is submitted
that the customer should undertake a risk assessment in relation to the
cloud service, which will involve a measure of due diligence into the
offering itself, the legal status of the provider, the contractual protection
for the data, and, naturally, the security measures in place. Only if the
customer is satisfied in relation to such matters can it truly be sure that
the rights of the individual are not being unduly prejudiced by the
decision to put the data into the cloud. It should, of course, also put a
written contract in place limiting the ability of the provider to process
the data. In other words, the customer should undertake the same type
of pre-contract exercise as it would undertake if the provider was
considered a ‘processor’.
5.5 Can personal data be put into the cloud?

A data controller should always assess whether it needs to put personal
data into the cloud and, indeed, whether it is able to. For example, it
may have given a contractual assurance to the supplier of the data (if not
the data subject itself), or in a privacy policy or notice to the data
subject, that data will only remain in the EU. Certainly, whilst hindsight is
always a wonderful thing, privacy policies should always be drafted with
a view to allowing flexible processing of data by the data controller
(within reason). However, it is not unheard of for an attempt by a data
Cloud Computing 81
controller to provide data subjects with full information as to how the

data will be processed, in the interest of transparency, to inadvertently
create a problem going forward.
Practical tip
Ensure that there is no restriction in a contract or a privacy policy

which impacts upon a desire to move data into the cloud.
The ICO in its guidance on the use of cloud computing [13] reminds data
controllers that they should attempt to minimize the amount of personal
data they move into the cloud (or the same cloud service). A risk
assessment should be carried out in that some types of personal data
have a greater impact upon privacy than others. The outcome is often
going to be an assessment of how risks should be mitigated (rather than
a block on the use of the cloud services altogether).
5.6 Pre-contract due diligence

As we have just discussed, it is at least arguable that the level of due
diligence legally required to be made of the provider’s circumstances by
the customer is broadly the same whether the provider is a processor of
the customer’s data (which is most often the case) or rather a controller.
And whether or not a legal requirement, it will clearly be commercially
sensible from a security standpoint not to make such distinctions. In
either case, there needs to be an enquiry into the legal position of the
provider and the security position of the data.
Practical tip
The customer needs to undertake some due diligence in relation to

security, not least to satisfy its regulatory requirements.
A recap: the seventh data protection principle requires that ‘Appropriate’

security measures are taken [24].
The ICO in its opinion on cloud computing [13] reminds potential cloud
customers that they need to assess the risks which might arise and take
appropriate steps to mitigate those risks. In some circumstances,
especially when there are complex services, a formal ‘privacy impact
82 Cloud Computing
5.6 Pre-contract due diligence
assessment’ might be called for.51 The guidance goes on to suggest that

part of the assessment of the processor’s security is an assessment of the
assurances the provider is willing to provide in respect of availability,
confidentiality and integrity.
In traditional outsourcing, the security measures used by a data processor

might be assessed by a physical inspection of the premises. In its opinion
the ICO recognizes that this is unlikely to be practicable in a cloud
situation or be welcomed by cloud providers (even those in the UK).
Instead, the ICO suggests that a provider might
arrange for an independent third party to conduct a detailed security

audit of its service and to provide a copy of the assessment to
prospective cloud customers. The assessment should be sufficiently
detailed to allow the cloud customers to be able to make an
informed choice as to whether the provider’s security is appropriate
and will, in turn, help the cloud customer to comply with its data
protection obligations.[13]
Third-party certification to the BS ISO/IEC 27000 series of standards (see

3.6) would be one means of doing that.
In earlier guidance relating to outsourcing [32], the ICO was of the view
that the customer should take into account the legislation in place in the
country where the provider is located (when the data centres are outside
Europe). The customer should consider whether the provider’s country
has any particular security risks associated with it, including whether
there is any data protection legislation in that country and whether any
other legislation may affect the security of the data. (We are not
considering here the issue – which arises separately under the eighth
data protection principle and we discuss in the next chapter – of how a
customer can legitimize the transferring of data abroad. Having said that,
some of the factors relevant to an assessment of the seventh data
protection principle will also be relevant to an assessment of the eighth
principle.)
In its more recent cloud computing guidance, however, the ICO does not
go so far. There is express recognition in two examples of the use of
non-European sites by providers. It contains a reminder that the customer
should identify where the data centres are located and enquire as to how
the data would be protected there. In a layered service, the enquiry
should extend to all sub-processors.
51
These type of assessments (generally, not only for cloud services) might shortly become a
legal requirement as a part of the data protection reform package currently being
discussed (see 8.12).
Cloud Computing 83
Practical tip
A customer should ask the provider to identify where the servers

upon which data will be stored are located. It should ask the
provider about the safeguards that are put in place and be satisfied
that they are appropriate to the nature of the data.
5.7 Ongoing monitoring requirements

A further requirement of the seventh data protection principle is to ‘take
reasonable steps to ensure compliance with those [security] measures’
[DPA, Sch. 1, Pt II, para. 11(b)] [24]. In the context of traditional
outsourcing, this was often interpreted to require the ability (which must
then be included in the contract) physically to inspect the provider’s
facilities. If that really was an absolute requirement it would make it well
nigh impossible for any European customer to acquire cloud services
when personal data is involved (at least in a lawful manner); so the issue
is very important.
The recent ICO guidance on cloud computing [13] does not refer to this
requirement explicitly. However, it does, as we have seen above, deal
with the related issue of assessing security as part of pre-contract due
diligence, where it clearly states that physical inspection is not needed
(see 5.6). Given the recognition that it is impractical to require physical
inspection at that phase, it is safe to assume that the ICO would feel you
could comply with the ongoing monitoring requirement other than by
actual inspection.
In practice, there are other methods to ensure proper security on an

ongoing basis, for example, by having an external auditing of security,
perhaps as part of standard certification (see Chapter 3). Part of
monitoring may include being kept informed by the provider of any
changes in any sub-processors that are used. This will need to be
reflected in the contract.
Practical tip
A cloud customer should consider, in the specific circumstances of a

particular deployment, how it can monitor the cloud provider
sufficiently to comply with its data protection obligations. Is it
appropriate to require a certification audit; and for that to be
updated at particular regular intervals? In cases of highly sensitive
data, the ICO (or other regulator) could be approached for its views
(which are often willing to give them on a ‘no-names’ basis).
84 Cloud Computing
5.9 Key points
5.8 Is there any obligation to tell data subjects?

The question arises as to whether there is an obligation to inform a data
subject that his or her personal data is in the cloud. The DPA [24] requires
a data controller to give certain information to data subjects, including
‘any…information which is necessary...to enable processing in respect of
the data subject to be fair’ [DPA, Sch. I, Pt II, para. 2(3)(d)]. This needs to
be assessed in context. There would seem to be little point, from a
‘fairness’ perspective, in informing an employee, say, that HR data is
being stored in the cloud. The ICO in its cloud computing guidance does
state:
The cloud customer may need to take appropriate steps to inform

the end users of the cloud service about the processing arrangements
that the controller has put in place. As a matter of good practice,
cloud customers should be as open as possible about this.[13]
If the assessment points towards informing the data subject that their
personal data is stored in a cloud service, then this can be communicated
via a privacy policy or notice or for employees via an employee handbook
or similar.
5.9 Key points

In this chapter we have delved deeper into the data protection issues
that arise when personal data is put into the cloud. Key points are as
follows.
◆ A cloud provider might be either a data controller or a data

processor under data protection law; and it may not be possible to
be absolutely certain which is the case.
◆ The customer should ensure that there is no restriction (contractual
or otherwise) on use of the cloud service.
◆ Whatever the proper characterization of the provider, the customer
(in order to satisfy its regulatory obligations) needs to undertake
some due diligence in relation to security, to impose security
requirements upon the cloud provider and to prevent the cloud
provider from using the data for other purposes. These regulatory
requirements coincide with commercial concerns in any case.
◆ The ICO will – on any investigation – want to see that a risk analysis
in relation to the cloud solution has been undertaken. This should be
documented.
◆ The customer should consider whether the obligation to handle
personal data fairly necessitates informing the individuals that their
data is stored in a cloud service.
Cloud Computing 85
6 Transfers of data to non-EU cloud
providers
6.1 Introduction
We now consider the other principal issue for cloud structures under UK
and European data protection law: the restriction on data flows out of
Europe contained in the eighth data protection principle (Schedule 1 of
the DPA [24]). It is important to bear in mind that the discussion in this
section is separate from the discussion in relation to security set out in
the seventh data protection principle. There is overlap, of course, in that
both compliance obligations will necessitate an assessment of security
and may require an assessment as to the local laws that might impact
upon the security.
Under the eighth data protection principle (reflecting Article 25 of the

Data Protection Directive [1]), personal data may not be transferred
outside the EEA unless the data controller assures an ‘adequate level of
protection’ for the rights of data subjects, such transfers being subject to
very limited exceptions (but see 6.4 and 6.7). The rationale behind these
rules, albeit perhaps difficult for non-Europeans to appreciate (especially
when the laws of their countries are adjudged not to be ‘adequate’), is
logical: a data controller subject to the jurisdiction of European rules and
safeguards imposed upon personal data within Europe should not be
able to send the data outside its borders without ensuring that an
equivalent level of protection is afforded to citizens’ privacy. Otherwise,
the protection offered to the privacy of its citizens is severely limited (it
would fall away by the controller simply sending the data abroad); and,
indeed, it is not only the European member states that have such rules –
most jurisdictions that have data privacy laws have such rules (the US,
China and Japan being important exceptions). Whilst this stance may well
be logical, however, the way in which the European rules apply, and the
bureaucracy attendant on putting in place compliance methods, is – in
the view of many commentators (even regulators) – in serious need of
modernization. The rules were developed when large-scale data transfers
happened rarely and perhaps when it was clear that a certain set of data
was in fact moving on a particular date from one destination to another
– an analysis of ’data flows’ in a particular business, system or transaction
was relatively easy. Of course, in the modern age, where data can be
86 Cloud Computing
6.2 Onward transfers by the cloud provider
anywhere, and, indeed, in many places simultaneously, and can be

accessed from anywhere else with the greatest of ease, that type of
analysis breaks down.
This restriction has proved problematic for many international businesses

with a genuine need to share data throughout the world, and has
implications for many standard business activities, leaving aside cloud
computing. It impacts upon the freedom to send data amongst members
of an international group, or even simply appointing an outsourced
service provider outside Europe. It has obvious implications for cloud
scenarios where the provider (or its data centres) may not be within
Europe, but the customer is.
We consider the impact of these rules, both from the cloud customer
viewpoint (where it is attempting to comply with UK or European data
protection rules) and from the provider viewpoint (where it is trying to
accommodate the customer’s compliance concerns).
6.2 Onward transfers by the cloud provider

Before we consider the different ways of ensuring compliance with the
eighth data protection principle, we begin with a brief discussion of an
issue that arises with whatever solution is available, namely, the ability of
the cloud provider to transfer the data on from its country to another
country, sometimes referred to as an ‘onward transfer’.
A realistic scenario to illustrate these issues would be where a European

customer contracts with a SaaS provider based in the US, but where the
SaaS provider has built its service on an IaaS or PaaS offering of a
subcontractor. The subcontractor will have possession of the data in its
own data centres. This is considered to be an ‘onward transfer’ by EU
regulators. If the customer has ensured compliance with the eighth data
protection principle [by ensuring that the cloud provider is in the Safe
Harbor scheme (see 6.4), or by putting in place one of the sets of
standard clauses with its SaaS provider], what is the position if that
provider then undertakes an onward transfer?
As we go through the different solutions on transfer, we also discuss this

situation.
Cloud Computing 87
6 Transfers of data to non-EU cloud providers
6.3 Countries (or sectors) deemed automatically

‘adequate’
6.3.1 Generally
So, the requirement of the eighth data protection principle in Schedule 1
of the DPA [24] is that the controller sending data out of the EEA (the
‘data exporter’) ensures that there is an ‘adequate level of protection’ for
the data. The Data Protection Directive [1] allows the European
Commission to make a finding in relation to the adequacy of the
protection offered by a specific country (in general or perhaps in relation
to a specific sector).52 Transfers of personal data to the countries in this
‘safe list’ would automatically meet the adequacy standard. The process
involves an analysis of a foreign country’s laws by the European
Commission and then a public assessment made as to their adequacy. It is
internationally controversial as, by and large, the European Commission
will not find adequate laws that do not have about them the ‘flavour’ of
the Data Protection Directive. In other words, it operates in practice as a
way of exporting European data protection sensibilities across the globe,
even if that is not the main purpose for the rule.
At the time of writing, only a small number of countries have been the
subject of adequacy findings (including Argentina, Canada, Israel,
Switzerland, Uruguay and Jersey, Guernsey and the Isle of Man). The US,
the source of many of the most prominent cloud services, is a notable
omission from this list.
Accordingly, if the cloud provider is in one of these ‘adequate’ countries,

and can give an assurance that data remains in that country, no more
needs to be done by the customer to satisfy the eighth data protection
principle.
Practical tip
If a European controller is relying on the cloud provider being in one

of the ‘adequate’ countries, it should make sure that the data is
transferred to (and remains in) that country and that it is not simply
the location of the provider’s headquarters.
It will still be necessary to obtain a contractual promise from the

provider to keep data in that country.
52
For example, ‘adequacy findings’ in relation to passenger name record (PNR) information
that is transferred to the US pursuant to an agreement made between the EU and the US.
88 Cloud Computing
6.4 The US Safe Harbor scheme
6.3.2 Onward transfers by the cloud provider

The issue of whether a cloud provider in an ‘adequate’ country is able to
transfer the personal data to a sub-processor in a third country is a
question of the law in the provider’s country. Part of the European
Commission’s deliberations on assessing ‘adequacy’ involves an assessment
of whether the country’s laws have provisions on onward transfer. In
practice, the law of each of the ‘adequate’ countries also contains
provisions that correspond to the protection offered in the eighth data
protection principle (even if substantively different). So the provider
should only be able to appoint a sub-processor where the data that is to
be transferred on will remain protected.
In any case, this is not an issue for the cloud customer, but one for the
provider.

6.4.1 Introduction
The US is not on the list of ‘adequate’ countries. The US does have often
very stringent privacy laws but it takes a different approach to the EU. It
has adopted a sectoral approach to privacy laws, relying on a mix of
legislation at a state and federal level. There are, for example, a number
of federal laws in relation to specific sectors, including health data
[Health Insurance Portability and Accountability Act of 1996 [33] (HIPAA)],
financial data [the Gramm–Leach–Bliley Act 1999 [34] (GBL)] and child
online data [Children’s Online Privacy Protection Act of 1998 [35]
(COPPA)]. At a state level there are robust data breach notification
regimes (see further at 7.2), as well as specific pieces of legislation
varying from state to state (such as California’s Online Privacy Protection
Act of 2003). Nonetheless, the approach is not sufficient in European eyes
given its lack of generality for protection of all classes of data across all
sectors.
As a result many US cloud providers seeking to sell services into Europe

are signing up to a scheme called the ‘Safe Harbor’. This scheme was
negotiated in 2000 between the US and the EU to overcome the general
lack of ‘adequacy’ and a fear that the coming into effect of the new
European data protection regime at the turn of the millennium would
impact upon US–European trade. US entities (in any sector) can sign up to
this scheme and commit themselves to complying with a set of data
protection principles.
There are seven principles, backed up by guidance provided by the US

Department of Commerce (DOC) and a number of FAQs, which together
broadly reflect the contents of the European rules. By complying with the
Cloud Computing 89
Safe Harbor principles, US companies are deemed to have adopted an

adequate level of protection for transfers of personal data to the US
from EU member states. As such, if a US cloud provider is a member (for
the relevant types of data), its UK customer can transfer data to the
provider without fear of contravening the eighth data protection
principle.
Practical tip
If a provider is a US entity, the customer should enquire as to

whether or not the entity has self-certified as to Safe Harbor. A
customer should confirm this independently by consulting the
publicly available list and not rely on publicity material of the
provider.
6.4.2 The mechanics of Safe Harbor

Joining Safe Harbor can be fairly straightforward. A US cloud provider
self-certifies to the DOC that it adheres to the Safe Harbor principles and
makes a public declaration of this adherence. Once accepted, a company
is added to the publicly available Safe Harbor list.53 Whilst there is no
approval mechanism (acceptance being a purely administrative act), a
joining provider should nonetheless ensure that its privacy policy is
compatible with the principles and be prepared to make its privacy policy
publicly available before going ahead with self-certification. A provider
has to verify annually the implementation of its privacy policy (this may
be by self-verification or verification by a third party). It must also file a
self-certification letter once a year.
The Safe Harbor website includes contact details for: handling

complaints, requests for data access and other issues arising, the statutory
body with jurisdiction to hear claims under US law, and the independent
recourse mechanism available to investigate unresolved complaints in
relation to a company.
Importantly, an entity can sign up to Safe Harbor for different types of

data. It might do so, for example, in relation to its own internal data
(such as HR data or data about its own customers – as opposed to data
entrusted to a cloud service by a customer). As such, the customer
wishing to rely on the provider being on Safe Harbor should ensure that
this is the case by confirming with the public list that the relevant data is
covered.
53
Available through http://www.export.gov/safeharbor/
90 Cloud Computing
Practical tip
A customer relying on Safe Harbor as a mechanism for permitting

the transfer of its data outside the EEA should confirm that the
relevant data is covered by the provider’s self-certification.
Despite its broad appeal, the Safe Harbor scheme has some drawbacks.
US providers that wish to benefit from this scheme must take positive
steps to comply with the seven principles. For instance, they must (at
least if they are a controller) (see 4.4) give notice to individuals of the
purposes for which their personal data is collected and used. They must
also disclose any onward transfer (i.e. a transfer to a third party, or using
the data for a different purpose) and give individuals an option to opt
out of the onward transfer, which will make it difficult for a cloud
provider using a third-party data centre (for example, a company at the
SaaS level acquiring infrastructure capacity from an IaaS supplier). More
importantly, providers will need to be aware of the enforcement
obligations.
6.4.3 How are Safe Harbor principles enforced?

The ‘enforcement’ principle of Safe Harbor (the seventh principle)
requires implementation by a provider of a suitable independent
mechanism to deal with complaints or disputes and of a procedure for
periodic verification of compliance with the principles. In addition, in
relation to complaints, a company adopting Safe Harbor must either elect
that a US self-regulatory organization is responsible for dealing with
them, or elect that such complaints fall under the jurisdiction of the
European data protection authorities. Companies are committed to
remedying complaints in accordance with their findings.
The Federal Trade Commission (FTC) and Department of Transportation

(DOT) have the right to file deceptive trade practices charges against a
company failing to live up to its Safe Harbor promises. There remains
much controversy as to how effective enforcement is of Safe Harbor.
There has been no charge brought against a member for failure to
comply with the principles.54 This is despite a report by Galexia (a
management consultancy) in December 2008 concluding that only around
a third of the entities on the list, in fact, comply.55
As well as regulatory enforcement, there is scope for both the

transferring data controller (the cloud customer) and the individuals who
54
Although see 6.4.6.
55
The US Safe Harbor – Fact or Fiction?, Galexia Pty Ltd, 12 December 2008.
Cloud Computing 91
form the subject of the transferred data to make a claim for damages in
relation to a breach of the Safe Harbor principles. To date no such claim
has been made.
6.4.4 Limitations on the scope

Not all US entities are eligible to join. A fundamental requirement is that
the entity is subject to either FTC jurisdiction or the jurisdiction of the
DOT (US air carriers and ticket agents). Two important sectors are not
within those jurisdictions: certain sections of the US financial services
industry (those parts regulated for privacy by the Federal Reserve and
others) and telecommunications carriers (subject to the jurisdiction of the
Federal Communications Commission). It is unlikely that many cloud
providers are in these sectors.
A possible further limitation is whether there is proper coverage for HR

data. Many of the companies that have signed up to Safe Harbor have
done so for the purpose of sending HR data to the US. However, there is
some doubt as to whether it can be used for this purpose. Indeed, in a
Working Document in 200456 the European Commission raised doubts
over the jurisdiction of the FTC to enforce Safe Harbor with regard to
transfers of employee data, even though the Safe Harbor FAQs agreed by
the European Commission and the DOC expressly foresee the possibility
of joining Safe Harbor for this type of data transfer. FTC jurisdiction is for
deceptive trade practices (which would include the privacy aspects of the
relationship between a business and its customers), but is not for
regulating the privacy aspects of the relationship between that business
and its employees. Nonetheless, the fact remains that, despite the doubts
expressed in 2004, the scheme has continued to be used for the purpose
of transferring HR data. Many cloud solutions are used for the processing
of employee data, and the absence of any regulator movement on this
issue (and there has been none since the point was raised in 2004) means
that, practically, this could prove a solution when the customer can be
confident that the provider will keep the data in the US.
6.4.5 European criticism of Safe Harbor effectiveness

Safe Harbor is increasingly under the spotlight from European regulators,
which, in short, have been critical of the US authorities’ seeming lack of
serious policing of the scheme.
In 2010, the Duesseldorf Kreis, a working group comprised of 16 German

state data protection officers that are responsible for the private sector,
issued a resolution requiring German data exporters to exercise
additional diligence when transferring data to safe harbor-certified
56
http://ec.europa.eu/justice/policies/privacy/docs/adequacy/sec-2004-1323_en.pdf
92 Cloud Computing
organizations. They pronounced that German companies should not

merely rely on Safe Harbor membership but should undertake proper
checks as to compliance in relation to US recipients of their data.57
Revelations in 2013 about the surveillance programmes of US intelligence

agencies, which emerged as a result of the Snowden revelations (see 2.4),
resulted in intensified concern amongst European data protection
authorities. There have been further questions about the efficacy of the
Safe Harbor regime and, in particular, the way it is enforced.
In November 2013 the European Commission released a communication

asserting the need to reassess Safe Harbor in light of the rapid growth of
the digital economy, the ‘critical importance’ of data flows for the
transatlantic economy, the growth in number of companies affiliated to
Safe Harbor and revelations about US surveillance programmes.58
The European Commission criticized the limited scope of the DOC’s

evaluation of privacy policies. It called upon the DOC to assert a greater
scrutiny of Safe Harbor members’ compliance with the principles and to
intensify its periodic controls of companies’ websites. In addition, the
European Commission criticized as weak the way in which the Safe
Harbor principles are enforced by the FTC. It set out 13 recommendations
for strengthening the Safe Harbor principles themselves (including a
reassessment of the extent to which US authorities can access data
transferred under the Safe Harbor framework).
Piling on the pressure, a draft report on US and European surveillance by

the European Parliament Committee on Civil Liberties, Justice and Home
Affairs (LIBE), which was leaked in January 2014, asserted that Safe
Harbor provides inadequate protection for EU citizens.59 The draft report
recommended that the European Commission immediately suspend the
Safe Harbor framework and suggested that the transfer of personal data
from the EU to the US should be carried out using alternative methods.
It is expected that the Safe Harbor system will survive the EU reform
package on data protection that is currently progressing (see Chapter 8),
the original draft of the Proposed Regulation [65] expressly stating that
existing ‘adequacy’ findings would be recognized. The European
57
http://www.datenschutz-berlin.de/attachments/710/Resolution_DuesseldorfCircle_28_04_
2010EN.pdf?1285316129
58
Communication from the Commission to the European Parliament and the Council on the
Functioning of the Safe Harbour from the Perspective of EU Citizens and Companies
Established in the EU, 27 November 2013.
http://ec.europa.eu/justice/data-protection/files/com_2013_847_en.pdf
59
Draft Report on the US NSA surveillance programme, surveillance bodies in various
Member States and their impact on EU citizens’ fundamental rights and on transatlantic
cooperation in Justice and Home Affairs (2013/2188(INI)), Committee on Civil Liberties,
Justice and Home Affairs, 8 January 2014.
http://www.scribd.com/doc/198068763/EU-LIBE-Committee-Report-on-NSA-GCHQ-
Untargeted-Secret-Illegal-Programs-Prohibit-Mass-Surveillance-Bulk-Processing
Cloud Computing 93
Parliament had (as part of its suite of amendments to the original text)
suggested that all existing ‘adequacy’ findings, including Safe Harbor,
would expire after two years. If this were enacted, then, in practice (just
as the original directive prompted a US–EU deal: Safe Harbor), it would
result in a substitute method, which may then require a wholesale
‘re-certification’ exercise by many US companies. It is hard to see how this
is a desirable outcome and, at the time of writing, the European
Commission and the European Council did not seem inclined to agree
with the European Parliament.
6.4.6 US enforcement action

In autumn 2013, in the midst of European criticism, the FTC promised
more enforcement actions and asserted that it would actively engage
with companies whose membership of Safe Harbor was due to lapse to
discuss the companies’ options and obligations.
The result of this was soon apparent. In January 2014, the FTC announced
that it had entered into settlement agreements with 12 companies that
had allegedly falsely represented that they were current certified
members of Safe Harbor.60 The 12 companies represented, in their privacy
policies or by displaying the Safe Harbor certification mark on their
websites, that they adhered to Safe Harbor principles or had current Safe
Harbor certifications, despite the fact that their memberships had, in fact,
lapsed.
Importantly, the FTC did not allege that any of the companies in question
had inadequate procedures in place concerning personal data or that any
individuals or entities were harmed. Since the FTC found no substantive
violations of the Safe Harbor principles by any of the 12 companies, the
FTC’s actions focused solely on the fact that they had not properly
renewed their annual self-certification with the DOC.
Whilst, from a European perspective, it is encouraging to see the FTC

take some action, this is likely to do little to stem the European criticism.
What European regulators have been calling for is the investigation by
the FTC of Safe Harbor members that are committing substantive
violations of the Safe Harbor principles rather than focusing on those
that have failed to renew their self-certification – a not particularly
egregious administrative oversight.
60
Press release: FTC Settles with Twelve Companies Falsely Claiming to Comply with
International Safe Harbor Privacy Framework, 21 January 2014.
http://www.ftc.gov/news-events/press-releases/2014/01/ftc-settles-twelve-companies-falsely-
claiming-comply
94 Cloud Computing
6.4.7 Safe Harbor and cloud computing

The Article 29 Working Party issued an opinion on cloud computing in
2012 [25] that seemed to cast doubt as to whether Safe Harbor was
sufficiently robust. It expresses the concern that Safe Harbor fails to
address cloud computing appropriately (not surprisingly, since the
principles were conceived in the pre-cloud era). Specifically, there is – the
Article 29 Working Party believes – a lack of control over the location of
the data and insufficient transparency on security measures offered.
This opinion reminds the data controller (the cloud customer) that it
should not merely rely on a statement as to self-certification. On the
contrary, the customer should check that the cloud provider is in fact on
the Safe Harbor list (a trivial check) and also request evidence that the
principles are being complied with. It does go on to state ‘that the Safe
Harbor principles by themselves may also not guarantee’ appropriate
security measures are being applied by the cloud provider in the US. And
so it concludes with a statement that ‘it might be advisable to
complement’ the Safe Harbor commitment of the cloud provider with
additional safeguards, taking into account the specific nature of the
cloud. Some member states’ laws (but not – at least, not clearly – the
UK’s) may require a processor to inform the data controller of the
location of the data and of any sub-processors. In those circumstances,
the cloud customer is ‘encouraged’ to use other legal instruments for the
transfer of data (i.e. not just to rely on Safe Harbor), such as standard
contractual clauses or ‘binding corporate rules’ (see 6.5 and 6.7,
respectively).
This rather negative portrayal of Safe Harbor resulted in a reaction from

the DOC. In a paper entitled ‘Clarifications Regarding the U.S.-EU Safe
Harbor Framework and Cloud Computing’, which was published in April
2013,61 the opinion of the Article 29 Working Party was put into context.
The paper also dispelled some misunderstandings (many originating from
Safe Harbor criticisms from other European data protection regulators).
The DOC sets out a reminder that if a cloud service provider is in the Safe
Harbor scheme:
• a contract will still need to be entered into to comply with Data

Protection Directive [1] obligations to put in place a written contract
offering sufficient data protection guarantees (see 5.3);
• ‘prior authorization’ by European regulators is not needed (this is
certainly true in the UK, but may not be true in all other member
states);
• if Safe Harbor is certified by a recipient of personal data in the US,
the EU ‘standard contractual clauses’ (which we discuss at 6.5) are
not also needed (contrary to the view of the Article 29 Working Party
61
http://export.gov/static/Safe%20Harbor%20and%20Cloud%20Computing%20Clarification_
April%2012%202013_Latest_eg_main_060351.pdf
Cloud Computing 95
above). These, say the DOC, represent an alternative to Safe Harbor

certification, not an additional requirement. Either option would
allow a service provider to ensure an ‘adequate’ level of data
protection.
The DOC also states that the Article 29 Working Party’s views are
non-binding and recommendations only. The document repeatedly
emphasizes that the Article 29 Working Party’s opinions are all qualified
with expressions such as ‘may not’, ‘encouraged to’ and so on.
In short, although there is some scepticism in European circles as to the

level of protection that Safe Harbor, in fact, offers for personal data,
including the views of the Article 29 Working Party, Safe Harbor remains
a lawful mechanism for dealing with the cross-border data flow issue
within the cloud environment.

We turn now to the issue (introduced in 6.2) of whether it is possible for
a cloud provider that has joined Safe Harbor to appoint a sub-processor.
One of the Safe Harbor principles is ‘onward transfer’, which contains a

statement that where the Safe Harbor member wishes to transfer
information to a third party that is ‘acting as an agent’, it may do so. This
is subject to a condition that the third party is itself in the Safe Harbor
scheme or (if not) there is another way to ascertain compliance with the
‘adequacy’ requirement. Importantly, one of the ways set out in this
principle is that the Safe Harbor member can enter into a written
agreement with the onward recipient, requiring that the recipient
provide at least the same level of privacy protection as is required by Safe
Harbor.
A US cloud provider should find it possible to appoint a sub-processor

and remain compliant with Safe Harbor. If the sub-processor is itself a
member of Safe Harbor, adequacy is assured in that manner. If the
sub-processor is in an automatically ‘adequate’ country, or within the EU
or EEA, then no further steps need to be taken. If no other route is
available, then the cloud provider needs only include a contractual
provision under which the sub-processor agrees to comply with the Safe
Harbor principles.
96 Cloud Computing
6.5 Standard clauses

6.5.1 Introduction
Cloud providers that are located in countries outside the scope of
automatically ‘adequate’ countries and which are not members of the US
Safe Harbor scheme can avoid the data export ban and receive data from
their European customers by signing certain standard forms of contracts
(known as ‘standard clauses’) that will assure ‘adequacy’ for the purpose
of the Data Protection Directive [1]. The Directive contains a mechanism
by which the European Commission can approve standard forms of
contracts between the data exporter in the EU and the data importer
(which can be a processor or a controller) based outside the EU. These
standard clauses are intended to provide self-contained, adequate
safeguards for personal data transferred. There are two sets of clauses
for use when the transfer is from a controller in the EU to another
controller, and one set for use when the transfer is from a controller to a
processor. The original set of data controller to data controller clauses
issued in 2001 (‘Set I’) were not widely used because they were
considered too restrictive and commercially difficult to agree.62 An
alternative and more business-friendly set was eventually adopted in
2004 and has gained much wider currency (‘Set II’).63 A further set of
standard clauses was issued in 2002 for use with processors (and these
were replaced, due to widespread criticism of the original, in 2010).64
Each of the standard clauses must – to satisfy the regulatory requirement
– be used in the precise form approved. Various details (such as the
names and addresses of the ‘data exporter’ and the ‘data importer’, and
the types of data) need to be completed. If other amendments are made,
they are no longer automatically considered to provide an adequate level
of protection.
6.5.2 Standard clauses in the cloud

The use of any one of these sets of clauses (unamended) would
automatically remove any risk of non-compliance so that a European
customer dealing with a cloud provider under a contract that includes
the clauses can proceed; there should, in theory, be no additional
requirements to fulfil. However, in practice, many of the European
regulators review the contracts stringently. Some countries require the
62
Commission Decision of 14 June 2001 on standard contractual clauses for the transfer of
personal data to third countries, under Directive 95/46/EC (2001/497/EC).
63
Commission Decision of 27 December 2004 amending decision 2001/497/EC as regards the
introduction of an alternative set of standard contractual clauses for the transfer of
personal data to third countries, under Directive 95/46/EC (2004/915/EC).
64
Commission Decision of 5 February 2010 on standard contractual clauses for the transfer of
personal data to processors established in third countries under Directive 95/46/EC of the
European Parliament and of the Council (2010/87/EU).
Cloud Computing 97
standard clauses (as executed) to be filed, and even approved, prior to

the initial transfer. Other countries, such as the UK, require no additional
formalities; executing the clauses suffices. Indeed, when a compliance
programme is intended to cover a number of European companies
exporting under broadly the same arrangement, it is not uncommon for
there to be inconsistency between the attitudes of different regulators,
for example, some insisting that the transfer is best characterized as one
to a controller, whilst others taking the view that the recipient is a
processor.
The standard clauses used will not, of course, replace the principal
contract between the customer and a cloud provider; full commercial
terms (including in relation to information security) will be needed. The
clauses are in addition to those terms. The standard clauses chosen can
be simply incorporated as a schedule to the main agreement or be signed
separately; the precise form does not really matter. As noted, however,
whichever set is used, it cannot be amended (at least not without losing
the automatic compliance with the eighth data protection principle,
which is the main benefit).
From a customer’s perspective, persuading a cloud provider to sign one of

the sets of standard clauses is attractive. And when it is used, a customer
will be largely free of any regulatory criticism. In the UK, certainly, there
is no requirement to file the clauses with the ICO.
Practical tip
If a cloud provider is not within Europe and is not on the US Safe

Harbor list, then a customer could request that the provider signs
one of the sets of standard clauses.
From a provider’s perspective, signing the contract has an advantage of

satisfying its customer as to the customer’s regulatory requirements.
Nonetheless, a cloud provider may well hesitate to adopt this solution to
the cross-border data flow issue.65 The standard clauses are contracts and
can therefore be enforced both by its customer and by the data subjects
(who are expressly given rights in the contracts to enforce at least some
of the terms in certain circumstances). Whilst the accompanying main
contract governing the commercial agreement between the parties will
likely have limitation of liability language (see 3.8.4 and Chapter 13),
which would apply if the provider breached, say, the obligation to keep
data secure, none of the different sets of standard clauses contains such
provisions. This leads to the possibility of the standard clauses being used
65
Although some providers openly promote the fact that they are willing to put in place
standard clauses, e.g. Google in relation to its Google Apps offering.
98 Cloud Computing
by a cloud customer to bring a claim against the provider larger than

that which would have arisen under the main contract, thus
‘circumventing’ the contractual limitation language.
The main agreement could include liability exclusion or limitation

language wide enough to cover not only liability under that agreement
but also under any ‘parallel’ set of standard clauses. Whilst this works
contractually, it is unclear whether that would be seen by the regulators
and the courts as departing from the standard clauses in such a way as to
prevent the eighth data protection principle from having been complied
with. If the regulators or the courts did take that view, then the cloud
customer will have been deprived of the benefit of having the standard
clauses in the first place.
Practical tip
A cloud provider outside the EEA may wish to resist signing an

EU-approved set of standard clauses on the grounds that the liability
position which arises is unacceptably inconsistent with the position
which might have been agreed in the ‘commercial agreement’.
The provider should consider drafting the main agreement to

exclude or limit liability under the standard clauses.
A customer should hesitate in allowing an exclusion of liability in the

main agreement applying to the standard clauses as it may mean it is
not then compliant with the eighth data protection principle.
The ICO, though, takes the view66 that if the standard clauses are
amended so that they no longer attract the European Commission’s
‘guarantee’ that they provide adequate safeguards, they may still operate
as contractual arrangements supporting a ‘self-assessment’ by the data
controller as to adequacy (on the basis described at 6.6).
The contract normally chosen by the cloud customer is the

‘controller-to-processor’ contract since, ordinarily, as discussed in 4.5, the
cloud provider will be a data processor and not a controller.

A criticism of all the standard clauses is that they lack any clear provision
dealing with onward transfers or subcontracting by the data importer;
that is, when the receiving party in turn sends data to some other entity.
66
See its guidance Model Contract Clauses, International transfers of personal data, 2012.
Cloud Computing 99
If the customer has put in place one of the sets of standard clauses with
its SaaS provider, say, the clauses need to permit that onward transfer. Do
the standard clauses allow this? Whilst there are a number of potential
scenarios that theoretically can arise, for all practical purposes, the only
set of clauses to consider is the ‘controller-to-processor’ clauses.67
If the cloud provider is a processor, any subcontractor (as just mentioned)

must also be a processor. The new (2010) controller-to-processor clauses
(unlike the earlier edition, which were replaced) enable the non-EU
processor to appoint subcontractors. However, this is subject to very
complex requirements, including the following (in the context we are
discussing).
• The non-EU-based cloud provider must obtain its customer’s prior

consent in writing. This can presumably be obtained in the contract
under which the cloud services are being provided. This is not
without difficulty, however, as the cloud provider may not want to
publicize the fact that it is subcontracting.
• Worse still, the cloud provider must, say these clauses, send to its
customer a copy of the contract under which any sub-processing
takes place. Given that a SaaS provider is likely to want to keep
confidential the commercial aspects of the arrangements with its
subcontractors, it would be advisable to have two separate and
parallel agreements – one dealing with commercially sensitive aspects
and the other dealing purely with the ‘data-processing’ aspects.
• There is then also a requirement that a data subject be provided
with a copy of the contract (at least the ‘data processing’ parts) if it
is requested.
The above analysis assumes that the sub-processor (in the example, the
IaaS) is in the same country as the cloud provider (the SaaS). What is the
position if the sub-processor is in fact in another country? None of the
sets of standard clauses generally (nor the controller-to-processor clauses
specifically) has a requirement that the ‘importer’ keeps the data in a
specified country. However, there is a requirement upon the cloud
provider to at least be aware of the country in which the data is stored.
This is because the cloud provider must give an assurance that it knows
of no legal difficulty which might apply. Specifically, in the
controller-to-processor clauses, the cloud provider must give an assurance
that ‘it has no reason to believe that the legislation applicable to it
prevents it from fulfilling the instructions received from the data
exporter and its obligations under the contract’.68 If it becomes aware of
67
Theoretically, a cloud provider could, in fact, also be a controller (as discussed at 4.5), and
so could the sub-processor. So situations to explore could include whether a cloud provider
as a controller (using either set of controller-to-controller clauses) is able to transfer data
to a sub-provider in a situation when that sub-provider is either a controller itself or also a
processor. We explored more of this in the first edition of this book.
68
See Clause 5(b) of the standard clauses (controller-to-processor).
100 Cloud Computing

6.6 Self-assessment
a change it is to inform its customer. It is arguable at least that these

assurances cannot properly be given if the provider does not know where
the data, in fact, is.
Given the convolutions necessary in the use of model contracts, it is

tempting for any EU-based cloud customer to simply dismiss contracts as
a suitable solution in the cloud space. However, in many member states
(if not the UK) there are limited alternative mechanisms (unless the cloud
provider is in the Safe Harbor scheme or in an ‘adequate’ country) and
there can be serious sanctions for failure to comply. The UK permits a
little more leeway as it allows the security of data to be ‘self-assessed’ by
the controller itself (to which we now turn).
6.6 Self-assessment
6.6.1 Introduction
The ‘self-assessment’ approach to legitimizing transfers of data from EU
member states to third countries is a valid approach in the UK (but not
generally throughout the other member states). The approach is based
on the premise that the data exporter should itself consider and make a
judgement as to whether, in the particular circumstances of a transfer,
that transfer is going to be made to a country that can ensure an
adequate level of protection. The DPA [24] imposes a direct obligation
upon data controllers to ensure, and assess, the adequacy of the
protection of the data when it is transferred. In short, the data controller
should approach the eighth data protection principle in the same manner
as it approaches the other data protection principles. Just as it makes its
own assessment as to whether or not processing is fair (first principle) or
as to security measures to take (seventh principle) and so on, it, too, has
to make its own assessment as to whether there is an adequate level of
protection.
This compliance method can certainly be useful in a cloud situation. The

approach has been endorsed (arguably, even encouraged) by the ICO
generally. The ICO guidance on the use of cloud computing [13] refers to
its guidance on transfers of data and, specifically, the ICO’s practical
guide to ‘Sending personal data outside the European Economic Area
(Principle 8)’.69 This practical guide has in its checklist the question ‘Can
you make an assessment that the level of protection for data subjects’
rights is “adequate in all the circumstances of the case”?’,70 and only
then (i.e. if not) does it suggest that the data controller may consider
69
https://ico.org.uk/for-organisations/guide-to-data-protection/principle-8-international/
70
http://ico.org.uk/for_organisations/data_protection/the_guide/principle_8
Cloud Computing 101

putting in place other compliance methods. This guide then refers to

more detailed guidance on data transfers.71
6.6.2 Undertaking the analysis

The starting point for assessing adequacy under the DPA [24] is
paragraph 13 of Part II of Schedule 1 to the DPA, which lists the criteria
that should be considered in making that assessment. The ICO’s guidance
on assessing adequacy [36] divides these into two groups, which it terms
the ‘general adequacy criteria’ and the ‘legal adequacy criteria’. The
starting point is the first group. If this shows (as will often be the case in
a typical cloud situation) that the risk is low then the ICO says there will
be no need to undertake an ‘exhaustive analysis’ of the ‘legal adequacy
criteria’.
The ‘general adequacy criteria’ include the nature of the personal data,
the purposes for which, and period during which, the data is to be
transferred, the countries involved, and any security measures to be
taken.
Sometimes the nature of the personal data will indicate that there is
little risk (e.g. internal telephone directory information or commercial
partners’ contact details). Conversely, if sensitive personal data (e.g.
health records) is being transferred, risks will clearly be higher. The ICO
places emphasis on the purpose of the transfer. If the transfer is only for
internal purposes, there is less risk than if, say, it is being distributed
more widely for marketing purposes. The period of the transfer is one of
the criteria. Short-term transfers are, again, less risky but still require
proper assessment as to the risks, and appropriate protection.
Where the consideration of the general criteria indicates that there is a

higher risk, the ICO states that the ‘legal adequacy criteria’ should then
be considered. This might be the case (depending on the nature of the
data) where the data controller is intending to make regular, large-scale
transfers to a particular country.
If such an assessment is required, an exporting data controller should

consider the legal background in force in the country that will give
protection to the data (even if not in the same way as in Europe), in
particular, whether that country recognizes general principles of the ‘rule
of law’ and the ability of parties to contract.
The ICO guidance on the use of cloud computing [13] does not expressly
deal with transfers outside Europe. As mentioned in 6.6.1, it refers to the
general guidance on transfers of data. This in turn refers to a separate
guide on data protection and outsourcing, which, amongst other things,
71
Assessing Adequacy, International data transfers [36].
102 Cloud Computing

6.6 Self-assessment
discusses international outsourcing. There is no reason to believe that the

approach (if not the result) set out in respect of this type of service
should not extend to cloud services. In relation to outsourcing, the ICO
makes it clear that the parties do not, in fact, ordinarily have to put in
place standard clauses:
You do not necessarily need to use the model contract clauses when
entering into an international outsourcing arrangement if you have
found an alternative means of complying with, or using an exception
to, the Eighth Principle. For example, ensuring compliance with the
security requirements of the Seventh Principle will go some way
towards satisfying the adequacy requirements of the Eighth Principle
(given the continuing contractual relationship between you and your
processor and your continuing liability for data protection
compliance under the Act).[32]
The reason for this is that, where such a transfer is made, the UK data
controller exporting the data remains the controller and, as such, remains
subject to the ICO’s powers of enforcement. In effect, it remains
responsible for protecting individuals’ rights under the DPA [24] in
relation to the overseas processing of the personal data by the data
processor.
Of course, where there is a transfer to a data processor, wherever that

processor is located, a data controller must still comply with the seventh
data protection principle (security).
6.6.3 Self-assessment applied to the cloud

As mentioned in the last section, the ICO makes little reference to the
cross-border data flow issue in its guidance on cloud computing, but it
does refer to general guidance on data flows, which leads to the general
discussion on self-assessment and the reference there to outsourcing. A
cloud provider is simply one form of outsourced provider and it is clear
that the ICO would look at many cloud acquisitions in a practical manner.
The ICO will expect some attempt at considering the risks of a particular
proposed solution. It might expect the cloud customer to make due
diligence checks in relation to the provider and conduct some
examination of the type of matters usually looked at in relation to
adequacy.
Cloud Computing 103

Practical tip
A cloud customer wishing to rely on self-assessment as its eighth data

protection principle compliance method should, at the time of
making the assessment, document that it has done so and the
assessments made against each of the relevant factors.
One aspect, though, remains difficult. Once the ‘general adequacy

criteria’ have been assessed, there may also be a need to assess the ‘legal
adequacy criteria’ (depending on whether the cloud solution is
considered to be a high-risk one, for example, if health data is involved).
However, undertaking a ‘legal adequacy criteria’ assessment will
necessitate understanding the legal regime of the country of the provider
and, arguably, also of the country where the data will be stored, which
may be different. This may not always be possible (certainly if there are a
chain of providers). No doubt, if pressed, the ICO would say that in such
a risky situation (where the ‘legal adequacy criteria’ assessment becomes
necessary), there should be complete transparency on such matters,
allowing the assessment. Practically, of course, high-risk data transfers will
only be made when there is such transparency.
Practical tip
From the perspective of a cloud provider outside of the EU, it is likely

to be happy with the customer relying on self-assessment as the
customer’s eighth data protection principle compliance method.
Under this method, the provider would accept no liability as it would
do under the standard clauses (or under Safe Harbor). The liability
would only be as set out in the commercial agreement with its
customer.
It should be noted that the position on self-assessment may change as

part of the data protection reform package that is being discussed within
Europe (see Chapter 8). As indicated in 8.14, the original version of the
new data protection law being proposed for Europe (the Proposed
Regulation) [65] would remove the ability of UK data controllers to rely
on this route to comply with the eighth data protection principle, in the
cloud context, since this route would only be allowed where the transfer
is not frequent or ‘massive’.
104 Cloud Computing

6.7 Binding corporate rules

Can a cloud customer that has ‘self-assessed’ adequacy permit a cloud
provider to appoint a sub-processor? The ICO’s guidance on the use of
cloud computing [13] states that in the case of a ‘layered cloud service’,
information relating to the location of each sub-processor involved in the
processing of the data should also be available from the cloud provider.
Accordingly, onward transfers would seem to be permitted provided that
this information is taken into account in the ‘self-assessment’.

6.7.1 Introduction
Yet a further method of legitimizing transfers of data outside Europe is
by having a set of so-called ‘binding corporate rules’ (BCRs) approved by
the European regulators. These are a set of rules applicable throughout a
group, allowing that group to then share data internationally without
regard to the nationality of the recipient of the data.
As initially envisaged, they dealt with the situation where the company
sharing the data was the controller of that data. As such, they were not
applicable in the context of an arm’s length, third-party provision of
cloud services. A cloud provider is normally (as we have seen) a processor
and is not in the same group as the data controller that has the data
protection responsibility to comply with cross-border data flow rules. In
the ‘classic’ BCRs, a controller can share data with other members of its
group but not externally (without some other method being put in
place).
That position changed in 2013 when the Article 29 Working Party

allowed service providers to apply for BCRs for processors (BCR-Ps). The
intention was that BCR-Ps could be implemented by groups of companies
that are providing services to customers outside that group. It would
allow that service provider group to transfer personal data (of which its
customer is the data controller) outside the EU, without the customer
being put in non-compliance of the rules on cross-border data transfers.
This is ideal for companies that are providing cloud services to their
corporate customers. Once they obtain approval of their BCR-Ps, they will
have removed a compliance headache from the cloud customer. The
cloud customer will no longer need to worry about any of the other
compliance methods already discussed (and need not worry about the
location of the data within the provider’s organization). A number of
large, multinational companies (such as Accenture, Atmel and Hyatt), at
the time of writing just over 60, have opted for BCRs as their regime of
choice for complying with the Data Protection Directive [1]. Five further
Cloud Computing 105

companies have also applied for BCR-Ps, including in November 2014

ATOS with a scope including its cloud offerings.
Putting in place BCR-Ps is not a trivial exercise. It involves a number of

steps, which we will now explore. First, the rules need to be prepared
and put in place throughout the group. Then, they will need to be
submitted to data protection regulators where they will be scrutinized
and (hopefully) approved. Thirdly, the provider will need to accept a
contractual obligation to its customers to comply with those rules.
As will be seen, putting in place a policy and (more importantly) practices

compliant with the BCR-P requirements (and then obtaining regulatory
approval) is not a simple process. It is no surprise that only a few
companies have gone down this route.
6.7.2 Drafting the BCR-Ps

The processor must draft the BCR-Ps in line with the requirements set out
in the papers adopted by the Article 29 Working Party.72 The substance of
the BCR-Ps is very involved and the detail in these papers reflects that.
The following is a summary of some of the most important topics that
should be set out:
Description of processing and flows of information
The BCR-Ps must contain a list of the entities that are part of the BCR-Ps
and explain the scope, that is, the nature of the data to be transferred,
purpose and data importers/exporters.
Data protection safeguards
The BCR-Ps must contain a clear description of data protection

safeguards. These, of course, reflect the core data protection principles
(see 4.7), including those to ensure:
• transparency and fairness to data subjects – processors have a duty to

assist the controller to comply with the law;
• purpose limitation – the processor must process personal data only
on behalf of the controller and in line with its instructions;
• data quality – processors will execute measures, when instructed by
the controller, in order to have data updated, corrected, deleted or
anonymized;
• security – processors must comply with the security measures that at
least meet the requirements of the controller’s applicable law, and
72
In particular, Working Document 02/2012 setting up a table with the elements and
principles to be found in Processor Binding Corporate Rules (WP 195) [37], and Explanatory
Document on the Processor Binding Corporate Rules (WP 204) [38].
106 Cloud Computing

other measures in the contract (what the Article 29 Working Party

refers to as the ‘Service Level Agreement’ or ‘SLA’);
• data subject rights – processors will execute measures and
communicate information to help the controller to comply with the
duty to respect the rights of data subjects;
• sub-processing within the group – data may be sub-processed by
other members of the BCR-Ps only with the prior written consent of
the controller (the customer). This should be addressed in the
contract with the customer (the ’SLA’);
• onward transfers to external sub-processors – data may only be
sub-processed by non-members of the BCR-Ps with the prior written
consent of the controller. Sub-processors can only be used if certain
obligations are passed down to them by means of contract.73
The binding nature of the BCR-Ps
The BCR-Ps must contain a clear duty for all members of the group and
all employees to respect the BCR-Ps. The BCR-Ps must expressly state that
all members of the processor’s group and all employees must respect
instructions regarding data processing, security and confidentiality, as
provided in the SLA. A number of mechanisms are available to ensure
that the BCR-Ps are binding, including intra-group agreements (to bind
the companies to the rules) and employment contracts or employee
policies (to bind employees).
How the rules will be implemented throughout the group
The BCR-Ps must state that appropriate training will be available

throughout the global group for all employees who handle relevant
data. The BCR-Ps should also be easily available to these employees (e.g.
by publishing them on an intranet).
Right of recourse
The BCR-Ps must grant rights to data subjects to enforce the BCR-Ps as
‘third party beneficiaries’. These rights allow them to seek recourse
through the courts or through data protection regulators if there is a
breach (even if that breach is outside Europe). If a data subject is not
able to bring a claim against the data controller, they must have the right
to bring a claim against the processor before a regulator or court.
The main European headquarters of the processor group has to accept

liability for the wider group’s breaches, as well as for those of any
external sub-processor.
73
See further at 6.7.5.
Cloud Computing 107

Complaints procedure
The processor group must create a specific contact point for the data
subject. All members of the BCR-Ps have a duty to report any complaint
to its customer. As the customer is the data controller, it will handle any
complaints from data subjects. It is only if the controller has ceased to
exist (e.g. through insolvency) that the processor is obliged to handle the
complaint.
Audit procedure
The BCR-Ps must create a duty for the processor to have data protection
audits on a regular basis (either by internal or external accredited
auditors). The audit programme must cover all aspects of the BCR-Ps. The
result is to be made accessible to the controller. In addition, the
controller can request that it be permitted to carry out an audit (directly
or with a third-party inspection body).
Mechanism for reporting change
The BCR-Ps should set out the procedure for reporting relevant data
treatment changes once a year to the data protection authorities and the
controller. If a change affects processing conditions it should be
communicated to the controller in time to allow it to object or to
terminate the contract before the change is made.
6.7.3 Regulatory approval

Introduction
The early days of BCRs were difficult in that, once they had been
prepared (which we have seen is not trivial), the BCRs then needed to be
approved by all relevant data protection regulators, that is, by the
regulator in each country in which the group had a European presence. If
the applicant group operated in all EU member states, it would have to
liaise with (and seek approval from) 28 different regulators. Moreover,
approval by one regulator did not mean that others would agree that
the safeguards were sufficient.
Over time the process changed. First, it became possible to deal only with
one regulator (the ‘lead authority’), which co-ordinated with the other
regulators on behalf of the applicant. But the process still then needed
the input of the other regulators, which, whilst an improvement, did not
in itself remove the need to deal with the comments and concerns of a
multitude of regulators (and the regulators may disagree with each other
on changes that should be sought from the applicant).
108 Cloud Computing

Finally, in 2008, ‘mutual recognition’ was introduced. This provides a

‘one-stop’ shop for BCR applications covering 21 EEA member states.
Under the scheme, if the regulator in one of the member countries (the
lead authority) approves an application for BCRs, the BCRs are
automatically approved in the other countries that are part of this
scheme. However, note that the regulators in countries that are not part
of the scheme will still expect to be consulted, through the lead
authority.
Identifying a lead authority
A cloud provider wishing to apply for BCR-Ps needs to choose a ‘lead

authority’ within Europe. It is expected not to ‘forum shop’ but to
identify the data protection supervisory authority in Europe with whom it
has most connection. According to the Article 29 Working Party,74 this
decision on which authority should be the lead authority should be based
on objective considerations, such as:
• the location of the processor’s group European headquarters;

• the location of the company within the processor group that receives
the majority of data to be processed;
• the location of the company in the group that is best placed (in
terms of management/administration functions) to deal with the
application process and to enforce the BCR-Ps; and
• the EU state from which most international data transfers will take
place.
The processor must communicate to the chosen data protection authority

that it intends to officially designate it as lead authority. This information
should be set out in a form prescribed for that purpose. The chosen lead
authority will circulate the designation to the other data protection
authorities, which generally have two weeks to raise any objections to
the designation of this authority as the lead.
Submission of the BCR-Ps
The BCR-Ps are then submitted to the lead authority, which reviews them
and provides comments to the processor. The aim is for the authority to
satisfy itself that the documentation matches the requirements set by the
Article 29 Working Party.75
If the lead authority feels that any amendments are needed, it will
inform the applicant. A dialogue may arise and the process is iterated
until the lead authority is satisfied that requirements are met.
74
Article 29 Working Party, Working Document Setting Forth a Co-Operation Procedure for
Issuing Common Opinions on Adequate Safeguards Resulting From ’Binding Corporate
Rules’ (WP 107) and Working Document establishing a model checklist application for
approval of Binding Corporate Rules (WP 108) both adopted on 14 April 2005.
75
See footnote 89.
Cloud Computing 109

The co-operation procedure
When the lead authority is content with the BCR-Ps, it commences the EU
co-operation procedure by circulating the BCR-Ps to the relevant data
protection authorities. These will be the authorities in the countries from
where the group transfers personal data out of the EU (or, more strictly,
where it transfers data to, from these countries to other countries that
do not have an adequate level of protection).
Some of these authorities may be in the mutual recognition system. At

the time of writing there were 21 countries76 that are part of the mutual
recognition procedure; these are: Austria, Belgium, Bulgaria, Cyprus,
Czech Republic, Estonia, France, Germany, Iceland, Ireland, Italy, Latvia,
Liechtenstein, Luxembourg, Malta, the Netherlands, Norway, Slovakia,
Slovenia, Spain and the UK.
The authorities there will only have to acknowledge receipt (since they
do not undertake a substantive scrutiny).
If some relevant authorities are not part of the mutual recognition

system,77 those authorities will have to review the BCR-Ps themselves.
They can also suggest amendments to be made. In normal circumstances,
the period for comments on the consolidated draft should not exceed
one month. The co-operation procedure will close after those countries
have considered the BCR-Ps substantively and satisfied themselves as to
their contents. If they are not satisfied, then revisions might be needed.
6.7.4 Service Level Agreement

The Article 29 Working Party expects (as is inevitably the case) that the
processor and the data controller will enter into a written contract, which
it calls a Service Level Agreement (’SLA’). The BCR-Ps are then to be made
binding, for the benefit of the data controller, through a specific
reference in the SLA, and are to be annexed to the SLA.
The SLA should specify if a general prior consent given at the beginning
of the service is sufficient for processing within the processor’s group, or
whether specific consent will be required for each new sub-processing.
When general prior consent is given, controllers should – says the Article
29 Working Party – retain the right to object to any new sub-processor.
Contracts between processors and sub-processors must impose on the

sub-processor the same obligations resting on the main processor under
the SLA and BCR-Ps.
76
The BCR rules apply throughout the EEA and not only in the EU.
77
The following countries were not, at the time of writing: Croatia, Denmark, Finland,
Greece, Hungary, Lithuania, Poland, Portugal, Romania, Sweden and Switzerland.
110 Cloud Computing

6.7.5 BCR-Ps and the cloud

At the time of writing, no cloud provider has adopted BCR-Ps.
A US provider of cloud services (e.g. Google, Amazon or Microsoft) might

well consider Safe Harbor a more viable option (and these three
companies are all members of that scheme), certainly if data remains in
US data centres. It will likely be cheaper to obtain Safe Harbor
certification than navigating the BCR-Ps application process.
However, BCR-Ps may well be something that some of the larger cloud
providers move towards. In circumstances where Safe Harbor is being
criticized within Europe and some regulators are discouraging the data
controllers over which they have jurisdiction from relying on it (see 6.4.5),
BCR-Ps may well become more attractive.
One difficulty that will arise, though, is that of appointing sub-processors,

which many smaller cloud providers (such as those that are a thin SaaS
layer built upon a PaaS, or using external IaaS) may well need to do.
Whilst subcontracting is permitted (with consent of the customer
according to these rules), it is a requirement of the Article 29 Working
Party documents78 that certain data protection obligations are passed
down to the sub-processor:
• an obligation to process personal data only on instructions;

• an obligation to keep data appropriately secure [the equivalent of
the seventh data protection principle or Article 17 of the Data
Protection Directive [1] (see Chapter 5)]; and
• the granting of third-party beneficiary rights to data subjects
(mirroring the BCR-Ps requirement referred to in 6.7.2);
• the granting of rights to the data controller (the cloud customer) to
bring actions against the sub-processor for the latter’s breaches;
• a duty upon the sub-processor to co-operate with European data
protection regulators;
• the acceptance of core data protection principles around
transparency, purpose limitation, data quality and security.
With all these considerations in mind, unless the cloud provider is

completely self-contained in terms of infrastructure (so, is not built upon
external cloud offerings), BCR-Ps are likely to be unrealistic. It will be
hard, if not impossible, to impose all these types of requirements on an
external provider of subcontracted services. The customer simply may not
have the commercial negotiating power to do that.
78
See footnote 72.
Cloud Computing 111


This is essentially the same point as just discussed. BCR-Ps recognize the
ability to undergo onward transfers. BCR-Ps are country agnostic: a
sub-processor can be in any country and can be appointed as long as it
has the customer’s consent (obtained in the SLA), and as long as the
sub-processor agrees to the provisions referred to in 6.7.5 above.
6.8 Authorization
In some countries, although not in the UK, there exists an obligation
upon the data controller to obtain authorization from a data protection
authority. This takes a number of forms. Some countries, such as
Luxembourg, require a prior authorization (which can take some months
to obtain) before the data is permitted to be transferred. Other
countries, such as France, simply have a requirement for the regulator to
be notified of the transfer.
This remains the case even if the non-EU cloud provider to which the EU
controller is entrusting data has complied with one of the methods set
out in this chapter, such as having joined Safe Harbor or having in place
BCR-Ps. The local regulator may scrutinize the method and require
changes.
6.9 Other derogations

There are other methods of transferring personal data to third countries.
A transfer can take place without ensuring adequacy of protection by
means of one of the methods just discussed, if one of a number of
conditions is satisfied, including:
• the data subject giving their consent to the proposed transfer;

• the transfer being necessary for the performance of certain contracts
between the data subject and the controller;
• the transfer being necessary or legally required on important public
interest grounds, or for the establishment, exercise or defence of
legal claims.
Consent is often discussed in this context, but is not without problems (a

full discussion of which is outside the scope of this book). Whilst it is
superficially attractive, consent must be given freely, be specific and be
informed, and, where sensitive personal data is concerned, must also be
‘explicit’. The Article 29 Working Party suggests that relying on consent
may prove to be a ‘false good solution’, appearing simple at first glance
112 Cloud Computing

6.10 Key points
but, in reality, complex and cumbersome.79 What if one of thousands of

data subjects withholds consent? What if one data subject revokes their
consent? For a European business outsourcing its data processing to a
cloud provider, these questions are largely irrelevant.
6.10 Key points

In this chapter we have explored the additional data protection issues
that arise when European personal data might be stored or otherwise
processed outside Europe. In particular, we looked at the various methods
for a data controller to satisfy the obligation to ensure that data is
adequately protected. Key points are as follows.
◆ If data is sent to an ‘adequate’ country outside the EEA (although

there are very few of these), then no further issue occurs, provided
the customer can be sure the data stays in that country.
◆ A US cloud provider could be on the Safe Harbor list, and, provided
the certification is up to date and relevant to the data being
transferred, it is a good solution for the customer. The cloud
provider, however, is at risk of action by the FTC (or DOT) if it
breaches the principles.
◆ Standard clauses are another solution that generally works well from
a customer’s point of view. However, from a provider’s point of view,
it is at risk of accepting greater liability under the clauses than it
ordinarily would like to do. It is uncertain whether any liability under
these standard clauses can be capped in the same way as liability can
be, generally, in the ‘parallel’ cloud contract.
◆ A UK customer could ‘self-assess’ the adequacy of protection. In
many situations, when
– the data is not particularly sensitive,
– a sensible security due diligence has been undertaken,
– proper contractual language is in place, and
– the cloud provider is a reputable company of substance in a
country with a developed and sophisticated legal system, it
would not be unreasonable for the customer to satisfy itself that
there is adequate protection. There is, however, no guarantee
with this method that a regulator would agree.
◆ A cloud provider could have in place a set of BCR-Ps. This would

allow a European customer of the covered cloud service to transfer
data to that provider (and, if covered, group companies) in full
compliance of the rules on cross-border data flow.
◆ There might still be local filing requirements in some countries (even
if not in the UK).
79
Article 29 Working Party, Working Document on a Common Interpretation of Article 26(1)
of Directive 95/46 of 24 October 1995 adopted on 25 November 2005 (WP 114).
Cloud Computing 113

7 Data security breach notification
in the cloud
7.1 Introduction
This chapter considers whether there are any requirements to inform
individuals or regulators if there is a breach of security in the cloud.
It is all well and good to have a robust and substantive data protection
law, which many countries (certainly, of course, in Europe) do have, but
when those laws are breached and there is a danger of leakage of
personal information to the potential detriment of the individuals
concerned, the issue arises as to whether there is a legal duty upon the
data controller to notify the individuals concerned. These laws are
generally known as ‘data breach notification’ laws and, as we will see,
the position in the UK (and in Europe) is that there is, at present,
generally no such obligation (although the position may change as part
of the Proposed Regulation [65] (see 8.11)). Nonetheless, the data will be
in the hands of a cloud provider that may be in a jurisdiction (notably,
the US) where there are such obligations. The issue which then arises
(even under the current UK and European regimes) is whether the
provider itself might be subject to such a law when it is the provider’s
customer’s data that has been compromised.
7.2 The US position

Given the prevalence of cloud services originating in the US, it is
important to appreciate a sense of the landscape there. The US has been
in the lead in terms of passing data breach notification laws. The laws
are currently at state level, with over 45 US states now having such laws
in place. It is interesting that the US has done this, given its different
approach to data protection generally. Unlike in Europe, there is no
general protection of an all-encompassing class of ‘personal data’.
114 Cloud Computing

7.3 Data breach notification in the UK and Europe
Instead, US legislation generally tends to be very sector specific with

different legal regimes for each of health data,80 financial data,81 online
data about children82 and so on.
The data breach notification laws differ from state to state. They are
concerned only with specific types of data (different in each state). For
example, California (the first state to enact such laws) initially enacted
them for names and addresses together with at least one of the
following: social security number, driver’s licence/ID number or bank
account details (only if a PIN or password was involved). Other states
(now including California) have extended the laws to medical records and
other types of data. Some states only require notification to their own
citizens (not those of other states or non-US citizens). Moreover, the
notification applies to any company (whether located within that state
or, indeed, within the US, or not) that holds the relevant data about one
of the state’s residents. In practice, however, data breach notification in
the US seems to be given to all individuals who might be concerned,
irrespective of residency.
7.3 Data breach notification in the UK and

Europe
There is currently no general data breach notification requirement in the
Data Protection Directive [1], although some individual member states
(notably, Germany in 2009) have enacted such requirements. The UK, as
yet, has not. However, there is such a requirement to those operating in
the communications sector as a result of changes in May 2011 following
the transposition into national law of amendments to the directive
dealing with privacy in the electronic communications sector [39] (the
ePrivacy Directive). The UK law is contained in the Privacy and Electronic
Communications (EC Directive) Regulations 2003 [40] (PEC Regs), as
amended. In addition, the proposed new data protection regulation will
likely contain such an obligation applicable generally (see 8.11).
The data breach notification requirement in regulation 5A of the PEC

Regs applies only to telecoms companies and to ISPs. It does not
generally apply to all activities on the internet. It provides for notification
of any ‘personal data breach’, which is defined as:
80
The Health Insurance Portability and Accountability Act of 1996 [33] (HIPAA) Privacy,
Security and Breach Notification Rules. http://www.hhs.gov/ocr/privacy/
81
The Gramm–Leach–Bliley Act 1999 [34] (GBL).
82
The Children’s Online Privacy Protection Act of 1998 [35] (COPPA).
Cloud Computing 115

7 Data security breach notification in the cloud
a breach of security leading to the accidental or unlawful

destruction, loss, alteration, unauthorised disclosure of, or access to,
personal data transmitted, stored or otherwise processed in
connection with the provision of a public electronic communications
service.83
In the event of such a personal data breach, the covered entity must,
without delay, notify the ICO about the breach. If the breach is likely to
adversely affect the personal data or privacy of an individual then the
provider must also notify them of the breach ‘without undue delay’.
However, where the data is encrypted, the provider is unlikely to be
required to notify the individuals affected.
When the requirement to notify the individual arises, the provider must
at least describe the nature of the breach, provide contact points for
further information, and recommend measures to mitigate the possible
adverse effects of the breach. The notification to the ICO must, in
addition to the above, describe the consequences of, and the measures
proposed or taken by the provider to address, the personal data breach.
Practical tip
Irrespective of the legal position, a customer in whatever sector may

still want to include in its cloud contract an obligation upon the
provider to inform the customer of any security incident. That would
allow the customer to manage its relationship with data subjects (as
well as to consider any breach notification requirements).
7.4 ICO guidance on data security breach

management
Whilst the UK has no express legal requirement of general application,
the ICO has given guidance on when notification should occur.84 This
guidance came about as a result of a number of high-profile security
breaches (including the HMRC breach of 2007 when CDs containing the
unencrypted data of 25 million families receiving child benefit were
lost).85
The guidance states that notifying individuals and organizations that a

data security breach has occurred can be an important element in a
breach management strategy. It recognizes that notification of a breach
is not an end in itself. An organization should have a clear purpose when
83
PEC Regs, regulation 2(1).
84
In the ICO’s Guidance on data security breach management [41].
85
See http://news.bbc.co.uk/2/hi/uk_politics/7128851.stm
116 Cloud Computing

7.5 Specific UK sectors
informing people, whether this is to enable affected individuals to take

steps to protect themselves or to allow the appropriate bodies to
perform their functions, provide advice and deal with complaints. The
guidance suggests that a notification should at the very least include a
description of how and when the breach occurred, what data was
involved and what the organization has already done to respond to the
risks posed by the breach.
In deciding whether or not to notify individuals, the ICO states that an

organization should consider:
• its legal and contractual requirements;

• whether notification will help it to meet its security obligations
under the seventh data protection principle;
• whether notification will help individuals mitigate the risk from the
breach; and
• the dangers of over-notifying.
If there are a large number of people affected by the breach, or very

serious consequences, the ICO states that it (the ICO) too should be
informed.
The nature of the breach will, according to the ICO, determine to a large
extent who should be notified. The organization should consider
notifying third parties such as the police, insurers, professional bodies,
bank or credit card companies and trade unions. When notifying
individuals, the ICO states that an organization should always give clear
and specific advice of the steps that they can take to protect themselves
and what the organization can do to help them. Contact details of the
organization should be provided to allow individuals to contact it for
further information or with specific queries.
Practical tip
Whilst the ICO’s guidance is non-binding, the ICO will likely, when
considering its enforcement powers, look more favourably upon a
controller that follows the guidance than one that does not. Cloud
customers (and providers) subject to UK law should have due regard
to this guidance if there is ever a security incident.
7.5 Specific UK sectors

7.5.1 Public sector
As a result of a number of security breaches in the public sector, it is now
operating a ‘voluntary’ data breach notification regime. Government
Cloud Computing 117

departments and NHS organizations are required to notify the ICO in the
event of a data breach. There is no statute creating this rule – it results
from a report by the Cabinet Office, Data Handling Procedures in
Government,86 which followed the Data Handling Review commissioned
by the then Prime Minister in November 2007 following the HMRC
breach. The report also gives the ICO the power to carry out spot checks
on government departments to ensure that they are complying with the
DPA [24].
7.5.2 Financial Conduct Authority, Prudential Regulation

Authority and other regulatory regimes
The ‘Principles for Businesses’ of the Financial Conduct Authority (FCA)
[42] and the ‘Fundamental Rules’ of the Prudential Regulation Authority
(PRA) [43] each require a regulated firm to ‘deal with its regulators in an
open and cooperative way’, and to ‘disclose to the appropriate
regulator...anything relating to the firm of which that regulator would
reasonably expect notice’.87
The FCA and PRA consider that this requirement extends to ‘any
significant failure in the firm’s systems or controls’.88 This would cover
any serious data breach or where a security lapse indicates a significant
breakdown of proper systems and controls. There is no specific
requirement for firms to notify individuals but the FCA has said that it
has the power to order a company to disclose details of a data breach to
its customers.
In a Financial Services Authority (FSA)89 report, Data Security in Financial

Services [45] (April 2008), the FSA said that consumers affected by a data
breach have a right to know the enhanced personal risk they face so that
they can take adequate precautions. It also stated that it is good practice
for firms to inform affected customers of a data loss in writing, unless the
data is encrypted or there is law enforcement or regulatory advice to the
contrary. Similarly, the FCA’s ‘Financial crime: a guide for firms’ (FC) guide,
forming part of the FCA Handbook, provides as an example of good
practice on data security that ‘A firm’s plans to respond to data loss
incidents are clear and include notifying customers affected by data loss
and offering advice to those customers about protective measures’.90
86
Data Handling Procedures in Government: Final Report, June 2008. Available here:
https://www.gov.uk/government/publications/data-handling-procedures-in-government
87
Principle 11 of the FCA’s ‘Principles for Businesses’ (PRIN 2.1.1R) and Fundamental Rule 7 of
the PRA.
88
FCA Handbook [42], SUP 15.3.8G(2); PRA Rulebook [43], Notification 2.3(2).
89
On 1 April 2013, principal responsibility for UK financial services regulation under the
Financial Services and Markets Act 2000 [44] (FSMA) was transferred from the FSA to the
FCA and PRA.
90
See the FCA Handbook, ‘Financial crime: a guide for firms, Part 1: A firm’s guide to
preventing financial crime’, at Box 5.1, p.39 [42].
118 Cloud Computing

7.6 Application to the cloud
Firms should therefore consider telling affected consumers exactly what

data has been lost, give them an assessment of the risk, and give advice
and assistance to consumers at a heightened risk of identity fraud.
7.6 Application to the cloud

The issue of present concern is where the cloud provider has a security
breach under which its customer’s data is compromised. Does either the
customer or the provider have a duty to notify the individuals concerned
or the relevant regulators? There are two possibilities to consider:
whether the law applicable to the cloud customer requires notification
and/or whether the law applicable to the provider requires notification.
7.6.1 Obligations upon the cloud customer

Taking the first of these, as the cloud customer remains a data controller
for the purposes of UK data protection laws, the fact that its provider has
suffered the breach does not remove its obligations under the DPA [24].
A cloud customer is responsible for its provider’s processing of personal
data of which it (the customer) is data controller. Generally, as we have
seen, there is no duty to notify (unless the controller is operating in the
telecoms sector, or a regulator such as the FCA requires it), but good
practice suggests that the cloud customer nonetheless has regard to the
ICO’s guidance.
Voluntary notification will result in regulatory scrutiny. If a breach is

relatively small and contained, it may, a cloud customer might conclude,
be better to deal with it internally and with its customers. However, if
the breach (despite its size) is likely to become publicly known, then, as
the ICO may become aware of the breach anyway, it might make sense
for a controller to notify the ICO in any case. This assumes, of course,
that the ICO is not only aware of a breach on the part of a cloud
provider, but is also aware of whom that provider’s customers are.
Practical tip
In deciding whether or not to notify the ICO (or individuals)

voluntarily following a breach of security on the part of a cloud
provider, a customer will no doubt assess whether or not the ICO will
in any case become aware of the breach and the fact that its data is
involved.
Cloud Computing 119

7.6.2 Obligations upon the cloud provider

The second possibility is where the provider is in a jurisdiction with data
breach notification laws (say, California or another relevant US state). US
law only applies to the ‘owner’ of the data and so cloud providers are
not within the scope – the laws of the various US states do not regard a
service provider, generally, as an ‘owner’ for this purpose. However, the
typical US state law data breach notification requirement does require
the cloud provider to inform its customer. And the customer may then be
obliged to inform relevant state residents of the fact of the breach.
The US position is, in fact, very much more complex. The data breach
notification requirements of a US state apply to any company that holds
data about a resident of that state, even if that company does not
operate in that state (nor use a cloud or other provider in that state).
Accordingly, a UK company selling services into the US, with its customers
throughout the US, may – in theory – have to look at the laws applicable
in each of those states. In other words, there need be no relation with
the US state in question other than the fact that the customer holds data
about one of its residents, and the state’s data breach notification law –
in theory – then applies.
Practical tip
If a customer’s US-based cloud provider suffers a breach, and informs

the customer (as it is obliged to do), the customer should consider
whether or not to get local advice in relation to each of the various
US states. US law is likely to require the customer to inform US
residents in any case.
7.7 Key points

In this chapter we have explored what requirements might exist to notify
individuals or regulators of security breaches in the cloud. Key points are
as follows.
◆ The UK does not have a mandatory notification requirement

generally applicable to all sectors. There is such a requirement
imposed upon telecoms companies and ISPs.
◆ The ICO has issued detailed guidance specifying the circumstances in
which it thinks a notification should be voluntarily made to it by
data controllers.
◆ The UK government and the NHS are operating such a regime on a
‘voluntary’ basis (imposed by the Prime Minister’s Office).
120 Cloud Computing

7.7 Key points
◆ A cloud customer in the UK using a provider in another country (in

particular, the US) might find that the laws of that other country
apply to a data breach. US law generally requires the provider to
inform the customer.
◆ A cloud customer should still try and include in its contract with the
provider an obligation upon the provider to inform the customer of
any security incident.
Cloud Computing 121

8 Data protection: the proposed
reforms and the cloud
8.1 Introduction
As mentioned in 4.3, in January 2012, a proposal was made by the
European Commission for the replacement of the Data Protection
Directive [1] with a regulation (the ‘Proposed Regulation’ [65]), which
would be directly applicable across Europe. The DPA [24] will have to be
amended or replaced as a result. It is beyond the scope of this book to
deal extensively with all the provisions in the Proposed Regulation (even
as they might apply in the cloud), but we set out a flavour of the main
changes in the proposal.
8.2 Consent91
There would be stricter rules on what constitutes ‘consent’ (an often
important concept in data protection law). Consent under the current
law may sometimes be inferred from circumstance. The Proposed
Regulation would require that consent be ‘informed’ and ‘explicit’ with a
‘clear affirmative action’ or ‘statement’. If a data controller relies on
consent, the controller has the burden of proof on showing that it was
given. Significantly, the Proposed Regulation contains a limitation that
consent could not be used when there is a ‘significant imbalance’
between the data subject and the controller (such as in an employee
context).
8.3 Territorial scope92

The Proposed Regulation would greatly widen the scope of EU data
protection law. The present law does not readily apply to businesses
established outside the EU (unless they use ‘equipment’ or a service
provider within the EU, or fall within the rationale of the 2014 Google
Spain case; see 4.6.2). The Proposed Regulation would apply to the
91
Article 4 and Article 7 of the Proposed Regulation. In this chapter we refer here to the
initial version published by the European Commission in January 2012. There are others;
see footnote 29.
92
Article 3 of the Proposed Regulation.
122 Cloud Computing

8.5 The right to be forgotten and to erasure
processing of personal data of European data subjects even where the

relevant data controller is not established in the EU but where the
processing relates to the offering of goods or services to, or the
monitoring of, EU residents. Even in light of the Google Spain case, this is
a significant widening of the reach of EU data protection law.
This proposal is likely to more clearly bring non-EU cloud providers into
the scope of EU data protection law when they have individual customers
(they will be ‘offering’ services to them) or even when they are only
‘monitoring’ them. These terms are inherently vague: how many
customers need to be within Europe before the services are ‘offered’ into
Europe? What does monitoring mean (does it include tailoring websites
as a result of browsing history)?
8.4 Main establishment93

The Proposed Regulation contains provisions attempting to make sure
that data controllers (or processors) operating in more than one
jurisdiction are regulated by only one national authority. The Proposed
Regulation does this by means of reference to an organization’s ‘main
establishment’. It defines ‘main establishment’ as, for controllers, the
place of the controller’s establishment in the EU, ‘where the main
decisions...are taken; [or] where the main processing activities...take
place’. For data processors, it is ‘the place of its central administration in
the Union’.
Cloud operators selling throughout Europe will likely find this is

preferable to having to deal with many regulators.
8.5 The right to be forgotten and to erasure94

This would be an entirely new provision and its suggestion by the
European Commission has proved controversial. This provides the data
subject with the right to have the controller erase all personal data
relating to them and to abstain from disseminating their data further,
where one of four grounds applies:
1. the data is no longer necessary for the purpose for which it was
retained;
2. the subject withdraws their consent, or the storage period expires,
and there is no legal ground for further holding the data;
3. the subject objects to the processing of their data; or
4. the processing does not comply with the Proposed Regulation.
93
94
Cloud Computing 123

8 Data protection: the proposed reforms and the cloud
The right would also require the data controller to take various steps to
have third parties remove the relevant data relating to the data subject.
To a certain extent, this type of right already exists in the Data Protection
Directive [1]; at least according to the recent Google Spain case (see
4.6.2). Nonetheless, the proposed language is certainly more direct and
arguably much wider, with far-reaching implications. However, at the
time of writing, that judgment, and this whole area, continues to prove
highly controversial.
Cloud providers dealing with consumers will clearly be impacted by this

provision.
8.6 The right to data portability95

This provision seeks to introduce a right for the individual to obtain a
copy of their data from the data controller, where that data is stored in
an electronic and structured format that is commonly used. It aims to
enable the data subject to more easily transfer their data from one
controller to another, or to use their data as they choose.
This is not strictly a ‘data protection’ issue and, therefore, it is perhaps

surprising to see this in the Proposed Regulation. However, if enacted, it
will again clearly apply to consumer-facing cloud providers, which will
have to provide for data portability in an easy fashion in their offerings.
8.7 Data protection by design and by default96

The Proposed Regulation would introduce a basic requirement that data
controllers implement ‘appropriate technical and organizational measures
and procedures’ to ensure that personal data meets the requirements of
the Proposed Regulation (so-called ‘privacy by design’ – which has long
been championed by the UK Information Commissioner and other
regulators). In addition, controllers should ensure that personal data, by
default, is only processed for the purpose for which it has been obtained,
and that, by default, the data is not accessible by an indefinite number
of individuals (privacy by default).
95
96
124 Cloud Computing

8.10 Documentation
8.8 Representatives of controllers not established

in the European Union97
Where a data controller (with more than 250 employees) is established
outside the EU (see Chapter 2) and not in a country adjudged already to
have an ‘adequate level of protection’ (see 6.3), there will be a
requirement for it to designate a representative within Europe.
Therefore, non-EU cloud providers (above a certain size) will have to
consider appointing such representatives within Europe.
8.9 Data processors98

The Proposed Regulation greatly increases the responsibilities of
processors (and so, cloud providers processing personal data for their
customers). Processors that exceed the limits of the contract between
them and the controller would be deemed to be controllers. This brings
with it all of the obligations placed on controllers and the corresponding
contingent liabilities, and potentially has serious implications. This could
be a crucial provision and cloud providers will need to take care in
drafting their contracts to ensure that they are given enough of a remit
to process the data, without being deemed a joint controller.
There are also restrictions on appointing ‘sub-processors’, which may

indeed make it more difficult than under the current directive to use
cloud services: a processor will be restricted from doing so except with
the prior permission of the controller. So, a cloud provider (such as one
operating a SaaS sitting upon an IaaS) should obtain its customer’s
consent to such subcontracting. Again, cloud providers will need to take
care to ensure that that consent is obtained in their contracts.99
8.10 Documentation100
As it stands, the Proposed Regulation will require all data controllers and
processors (with more than 250 employees) to maintain an extensive
amount of documentation. This will include the names and contact
details of data protection officers, descriptions of categories of data
subjects whose data they hold, and so forth. The controller and processor
should make such documentation available to the local data protection
regulator on request.
97
98
99
If enacted as drafted, it remains to be seen whether data protection regulators will accept
this type of ‘blanket’ obtaining of permission. However, not to do so could cause serious
disruption to business.
100
Cloud Computing 125

8.11 Notification of personal data breaches101

The Proposed Regulation mandates that, in the event of any personal
data breach, the controller must notify the relevant supervisory authority
without undue delay, and at any rate within 24 hours. There is no express
triggering threshold (for example, that the breach be particularly severe
or be likely to cause problems for individuals); all breaches are caught.
Where the controller does not notify the authority within 24 hours, it
must provide a reasoned justification for not doing so. Where the data
breach emanates from a processor, it is under an obligation to alert and
inform the controller immediately following the breach.
For certain breaches (where there is likely to be an adverse effect on the

individual), the data subject should also be notified (but after the
regulator).
8.12 Data protection impact assessment102

The Proposed Regulation would mandate the introduction of data
protection ‘impact assessments’. Data controllers (or processors acting on
the controller’s behalf) will be under an obligation to conduct such
assessments where their proposed processing operations present specific
risks to the rights of data subjects by virtue of their nature, their scope or
their purposes (an example is given of where the processing is of
biometric data). The assessment includes not only an internal assessment
of risk but also an obligation to consult representatives of data subjects.
Cloud customers (where these specific risks arise) will likely have to
undertake such assessments prior to acquiring cloud services.
8.13 Data protection officers103

The Proposed Regulation will require both controllers and processors to
designate data protection officers (DPOs) in certain circumstances,
including where:
1. the controller is a public authority;

2. the processing is carried out by an enterprise of 250 persons or more;
or
3. is a ‘core activity’ and involves operations ‘which, by virtue of their
nature, scope and/or purposes, require regular and systematic
monitoring of data subjects’.
101
Article 31 and Article 32 of the Proposed Regulation.
102
103
Articles 35 to 37 of the Proposed Regulation.
126 Cloud Computing

8.14 General principles for transfers to third countries
A DPO must be suitably qualified and they must be appointed for at least
two years – with only very limited rights of dismissal. The DPO is to be
independent and receive proper support from the controller or processor.
The controller or processor must communicate the identity of the DPO to
the relevant regulator, and data subjects will have the ability to contact
the DPO directly.
The requirement will be applicable to both cloud customers and

providers (when the threshold is met).
This will be a new concept under UK law, although many EU countries

already have mandatory requirements for the appointment of DPOs
(although the details – such as the threshold number of employees –
differ). For countries that do not have such roles, the change will be a big
one. Of particular concern may well be the fact that a DPO cannot easily
be dismissed during their two-year appointment.
8.14 General principles for transfers to third

countries104
The Proposed Regulation contains changes to the way transfers of data
out of Europe can be legitimized.105 The substance of the current rules
(and the exceptions) is mainly retained but with one important exception
and a useful addition. So the concept of approving specific ‘adequate’
countries, Safe Harbor and standard clauses are likely to remain: there is
no express ‘saving’ provision (i.e. stating that approvals under the old
regime are sufficient for the new regime) for these mechanisms but it is
expected that any mechanism approved under the current Data
Protection Directive [1] regime will be freshly approved under the revised
regime.
However, the exception to the current rules continuing to apply is the

effective removal of the ability of exporters within the UK to ‘self-assess’
the adequacy of the protection on a transfer (see 6.6). This will now only
be allowed where the transfer is not frequent or ‘massive’. There are also
requirements to document the assessment and to inform the regulator of
a transfer. This is unlikely to be at all useful to a potential cloud
customer, which, under the present law, may well rely on its ability to
‘self-assess’ the adequacy of protection.
The useful addition to the current rules is that the Proposed Regulation
explicitly recognizes BCR-Ps (discussed at 6.7).
104
Articles 40 to 43 of the Proposed Regulation.
105
See Chapter 6 for the current position.
Cloud Computing 127

8.15 Sanctions; fines106

The Proposed Regulation will grant regulators the power to impose
administrative fines. The sanctions are not fixed: they are to be ‘effective,
proportionate, and persuasive’, on a case-by-case basis. The supervisory
body is to take into account the nature, gravity and duration of the
breach, amongst other factors.
There are maximum fines for different types of transgressions. In a cloud

context, perhaps the biggest issue is the fact that a failure to comply
with the security provisions may lead to a fine of up to 2 per cent of the
annual global turnover of the organization in breach. The same also
applies if the customer does not notify a data breach in contravention of
the Proposed Regulation.
Fines can also be levied against a processor for breach of its obligations.
Notwithstanding that cloud providers (as processors) may also be liable, a

cloud customer of course relies on the provider’s security assurances, and
it will be the provider that may first become aware of a data breach.
Accordingly, the customer may itself be subject to a fine as a result of the
provider’s failures. The bigger customers with negotiating power may
well be able to extract appropriate indemnities from a cloud provider in
relation to any fine resulting from such failures.
106
128 Cloud Computing

9 Software licensing and the cloud
9.1 Introduction
The software licensing issues that arise in cloud computing depend very
much on what type of cloud services are being considered. A SaaS
provision should not present too many difficulties (at least for the
customer). In just the same way as a customer would license software in a
traditional ‘on-premises’ acquisition, it obtains rights to use that software
through the SaaS. The provider ensures that it has any third-party rights
it needs to include.
However, when the service being considered is an IaaS provision, say,

with a view to the customer transferring its existing software suite onto a
virtualized infrastructure, the situation can be complicated. Rights need
to be cleared and contracts examined. In this chapter we explore these
issues, as well as open-source issues, in the cloud.
9.2 Moving existing licensing structures to the

cloud
9.2.1 Introduction
In a nutshell, the legal difficulty with moving an existing suite of
software onto an IaaS is that much of that software will have been
licensed in from third parties on terms that did not necessarily anticipate
a cloud service. It should be noted that this issue might arise not only
when a third-party IaaS provider is engaged, but also when the move is
onto a ‘private cloud’.
Software licences vary significantly between providers, but one feature

that is common across virtually all mainstream software houses is that the
terms of use of the software are in some way restricted. It is these
restrictions that present the problem; the move to the cloud may well
take use of the software outside the scope of the licence and lead to the
continuing use being both in breach of contract (of the software licence
terms) and an infringement of intellectual property (IP) (as it will not
have been authorized by the owner).
Cloud Computing 129

9.2.2 Restrictions to be considered

Table 1 sets out common software licence restrictions that may be
relevant for consideration when moving software onto a cloud service.
Table 1. Common restrictions in software licences
(possibly) preventing use in the cloud
Restriction Cloud consequence
Software may be used only That computer will no longer be used

on a specified computer (or in the virtualized environment…
one of a particular
specification)…
…or at a specified location. …and not the cloud!
Software may be used only The processing power of the

on one (but not specified) application may be spread across a
computer. number of different ‘virtual machines’,
or, indeed, even one ‘virtual machine’
that is spread across any number of
physical machines.
Software may be used only The software owner might argue

by the licensee itself. (whether successfully would depend
on the actual language in the licence)
that running the software in a cloud
environment on a platform supplied
by a third party involves use by that
third party (albeit on the customer’s
behalf).
The software is confidential. Giving the software to a third party

may well trigger a breach of
confidentiality provisions (unless
outsourcing – cloud or otherwise –
was expressly envisaged).
The software is warranted The cloud infrastructure may be

and indemnified only against outside the UK. If there are
infringement of UK IP. third-party IP issues outside the UK,
the contract now does not allow the
consequences of that risk to be passed
by the customer to the software
house. Moreover, in some countries
(notably, the US) it is easier for rights
130 Cloud Computing

9.2 Moving existing licensing structures to the cloud
holders to obtain patents – and so, in

any case, there is a greater IP risk in
those countries than in the UK.
The issues on legacy licences arise not only when putting systems into a
public cloud IaaS system, but also when being put onto a private cloud
or, simply, a virtualized service.
Practical tip
Even if not bought with a view to installation in the cloud, software

licences should always be carefully checked to ensure they permit use
by a service provider on behalf of the licensee (whether cloud or
traditional outsourcing).
9.2.3 The provider’s risk

This is not simply an issue for the customer. A cloud provider hosting on
its IaaS system infrastructure software that has been put onto that
infrastructure in breach of the customer’s licence terms will itself
potentially have liability. If it has possession of the software, it is likely to
itself be doing acts that need the proprietor’s permission. It will not then
have that permission and so will itself, in this scenario, be infringing the
third-party’s rights. Whilst an indemnity can be used to pass the financial
risk back onto the customer, and such indemnities are standard in cloud
contracts, it is nonetheless recommended that the provider also
undertakes due diligence, as it may well find itself a bigger target than
the customer. An indemnity is only as good as the financial worth of the
customer. Of course, such due diligence only makes commercial sense for
the biggest and bespoke arrangements.
Practical tip
When moving an existing software suite onto an IaaS, a customer

should undertake an early investigation of the licensing position.
Cloud providers should ask to see software licences (in large
transactions, certainly), and will want to be indemnified in any case
to protect themselves from the risk of a third-party claim from a
proprietor.
Cloud Computing 131

9.2.4 Evolution of new licensing models

Some software vendors are developing new licensing strategies designed
to facilitate use on the cloud. Oracle has partnered with Amazon to
allow its software (either under existing licences or new licences) to be
used on the Amazon EC2 IaaS. Clearly, the problems highlighted above
should then not arise when a specific permission has been given for use
on a cloud infrastructure. However, here, again, is a potential issue of
vendor lock-in. If a package is acquired from a software house for use on
a particular cloud platform, there is the obvious concern for the customer
that the software licence does not permit use on any other IaaS
infrastructure, if and when it wants to change provider.
Practical tip
When acquiring software specifically designed (and on terms

specifically tailored for) an IaaS infrastructure, a customer should
ensure that it fully understands and finds acceptable any limitations
upon changing IaaS provider.
9.3 Open source and the cloud

9.3.1 Introduction
Open-source software (sometimes called free software) is software
created by developers who subscribe to the belief that software which is
open for anyone to fix and improve is inherently more stable. As such,
and in marked contrast to the proprietary software industry, the source
code of the software is generally published and made available to
anyone. Copyright still subsists in that software, but the owner of the
copyright will generally license it on one of an ever-growing number of
standard software terms, the most well known of which are those
published by the Free Software Foundation (FSF) (including the GNU107
General Public License (GPL),108 which comes in a number of versions).
It is a common feature of these licences to require that when the licensed

open-source software is further distributed by a licensee, the source code
of that software must also be made available to the licensee’s users.
Some licences go further and say that when the open-source software is
‘built into’ a bigger piece of software, the source code of the whole of
that bigger piece of software must also be made available to users; this is
107
The name of a particular piece of open-source software published by the FSF, the GNU
Operating System; ‘GNU’ is a recursive acronym for ‘GNU’s Not Unix’.
108
http://www.gnu.org/licenses/gpl.html
132 Cloud Computing

the so-called viral effect (as the open nature of the software ‘infects’
other software) or the ‘copyleft’ principle, and we explore this in the
cloud context in 9.3.2.
However, before doing so, it is worth pointing out that there is another
way in which open source arises in the cloud computing field.
Open-source software might be used as an infrastructure or development
tool by the provider. Much of the software that is being used by
providers of cloud services has been developed and licensed in
accordance with open-source principles. There are already prominent
examples of this in relation to such software as virtualization software,
file storage software, and other software at the infrastructure level.
Except to the extent that, say, use of infrastructure software as part of a
service that is then sold onto users might properly be classified as
‘distribution’, leading to the copyleft problem (as described in 9.3.2),
there are, in fact, no novel legal issues arising, simply because the
applications that might be developed are being built using open-source
components or tools. All that the provider needs to do is the normal step
of ensuring that its intended use is within the scope of the terms of the
licence.
9.3.2 Provision of software to a SaaS customer – the

copyleft problem
Open-source software might be a component of software that is then
provided as a service to a cloud customer. This raises the issue of whether
the larger work, incorporating the open-source component, itself
becomes subject to the terms upon which the original open-source
software is licensed. Such terms could include an obligation on the
licensee that it must distribute the program in source code as well as
compiled form. In other words, it raises the issue of whether the larger
work is ‘infected’ as a result of a viral, copyleft provision.
Each of the many different types of open-source licences deals with this
issue in its own different way, and it is important for any software
developer or reseller to examine carefully the terms of any open-source
software component it wants to use, in particular to determine whether
any new software (or revision to the open-source component) would in
turn be subject to the original open-source licence terms. For example,
one of the most popular open-source licences, the GNU GPL (version 2),
requires that a licensee which modifies and creates a ‘work based on the
Program’ must also distribute the source code of not only the original
open-source software, but also the ‘work based on the Program’109 – the
viral effect. The GNU Lesser General Public License (LGPL), which is
designed for the licensing of open-source libraries, tries to draw a
109
See http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Cloud Computing 133

distinction (not too clear to apply in practice) between a work ‘based on’
the library and a work ‘that uses’ the library.110 The former contains code
derived from the library, whereas the latter must be combined with the
library in order to run. It is only the former that, in theory, is subject to
the viral effect; the source code of a work ‘based on’ the library must be
distributed if the work itself is distributed. However, there is a trap for
the unwary: if the new work is linked to the library before distribution
(which it may be if a fully built executable is distributed) then that is not
a work ‘that uses’ the library; it is instead a work ‘based on’ the library
(because it then contains portions of the library).
Practical tip
In any environment (even non-cloud), use of open-source

components in a proprietary software solution, which is then made
available to customers, needs care. There might (depending on the
terms used and what is done with the software) be an accidental
requirement to make source code of the new software generally
available.
9.3.3 The viral effect in the cloud – the Affero Licenses

The rationale of the open-source movement including a ‘viral’ component
is, of course, to free up all code; if a provider is to distribute the derived
work, then the source code should also be distributed. What the earlier
versions of these licences assumed, however, was that there would be a
‘distribution’: a physical dissemination of the software into the actual
possession of the users. When the software is made available to users as
a service, there is (at least arguably) no distribution of the software.
After all, the software never leaves the server of the provider.
As a result, new open-source licences have emerged designed to fix this

loophole, notably the Affero Licenses. There are, in fact, two such
licences under very similar names. The original Affero General Public
License (Affero GPL),111 which was initially published by Affero Inc. in
2002, was based on the GNU GPL, version 2.112 It was designed to deal
with SaaS issues (although in those days, of course, SaaS was not the
term used – instead the term used was ‘application service provision’).
GNU has itself now published a successor to that, based on the GNU GPL
version 3,113 and known as the GNU Affero General Public License (GNU
Affero GPL).114
110
See http://www.gnu.org/licenses/lgpl.html
111
See http://www.affero.org/oagpl.html
112
See footnote 109.
113
See http://www.gnu.org/licenses/gpl.html
114
See http://www.gnu.org/licenses/agpl-3.0.html
134 Cloud Computing

There is no express mention in either version of SaaS or, indeed, even

application service provision. (The FSF has been very critical of both the
concept of ‘cloud computing’115 and the use of the term, which it
considers to be ‘a marketing buzzword with no coherent meaning’.116)
Instead, the licences focus on users interacting with (not ‘using’) the
software through servers. Specifically, the GNU Affero GPL (clause 13)
states that the source code of any modified version must be made
available to users of the software when the software is offered to ‘users
interacting with it remotely through a computer network’, which is
clearly wide enough to cover use through a cloud service. The source
code has to be provided from the server ‘through some standard or
customary means of facilitating copying of software’, and, of course, at
no charge.
Software that is included within this viral effect is the original software
or any work that is a ‘modified version’ of the software (or, another
expression, as used in 9.3.2, a work ‘based on’ the earlier work). (The
GNU Affero GPL licence here uses terminology that is present in the GNU
GPL licences.)
One difficulty with the GNU licences is that the concept of what is a
‘modified version’ is unclear. The GNU website says simply: ‘Where’s the
line between two separate programs, and one program with two parts?
This is a legal question, which ultimately judges will decide.’ Its own
preferred view is to focus on the means of communication between the
two parts. If the two parts are bound together in the same executable,
then the whole is a ‘modified version’ of the original. This is so, says the
FSF, even if, in terms of quantity of lines of code, or even in terms of
relative importance of functionality, the original is a relatively minor part.
It is clear that great care is needed.
Practical tip
Cloud developers using open-source software as a component and

who are concerned to avoid the viral, copyleft effect, need to
carefully check the applicable terms. Older licences may not (at least
expressly) apply. If one of the Affero (or other SaaS-applicable)
Licenses is used, care is needed in terms of how open-source
components are built into the overall package.
115
See reference to Richard Stallman’s comments in 1.2.
116
http://www.gnu.org/philosophy/words-to-avoid.html
Cloud Computing 135

9.3.4 Open-source software in the courts

Whether or not open-source terms are actually enforceable is often
debated; after all, there is frequently no direct relationship or contact
between the copyright owner and the user of the open-source package.
There have started to be some court cases in this difficult area.
It was recognized in the 2008 US case Jacobsen v Katzer and Kamind

Associates Inc.117 that breach of an open-source licence is copyright
infringement. The court held that a licensee’s obligations were conditions
limiting the scope of the licence rather than independent contractual
covenants. Therefore, by failing to comply with the obligations, a user of
the package was acting outside the terms of the licence and was
therefore liable for copyright infringement.
The German organization gpl-violations.org was founded by Harald

Welte in 2004 with the express aim of raising awareness about violations
of the GNU GPL and enforcing its terms. In 2007, gpl-violations.org
brought legal action against Skype, which had distributed a Voice over
Internet Protocol (VoIP) handset using an embedded Linux kernel without
supplying the source code. The court found that Skype was in breach of
the GNU GPL. The organization has also brought successful action in the
German courts against Sitecom, Fortinet and D-Link.
In the UK, the Free Software Foundation Europe (FSFE) challenged BT in

2007, when it distributed the Home Hub, which used a Linux kernel
under the GNU GPL, version 2, without making available the firmware
source code. Although there was no need for court action, BT now
publishes certain parts of the firmware source code and, despite FSFE
claiming there are still parts missing, it has not taken any further action
against BT.118
9.4 Software escrow in the cloud

9.4.1 Escrow in a traditional environment
In a traditional ‘on-premises’ licence, the software house does not readily
give a customer access to its source code.119 The customer is therefore
reliant on the software house (or a contractual support partner) for
ongoing support, such as bug fixes and functionality improvements.
Software escrow is a mechanism used to enable the customer to get hold
of the source code (necessary for correcting and improving the software)
117
F.3d 1373, Fed. Cir. (2008).
118
http://www.zdnet.com/article/bt-under-fire-over-gpl-violation/
119
Source code is the human-readable element in which the software is written, a valuable
trade secret of most software houses. Source code is turned into machine-readable
executables by a process called compilation.
136 Cloud Computing

9.4 Software escrow in the cloud
in the event of a failure by the provider itself to support the software,

either because it is in breach of the support contract or because it is
insolvent. The source code is put in the hands of an ‘escrow agent’, a
third party, which enters into a tripartite agreement with both the
customer and the software house setting out the circumstances (‘trigger
events’) under which the agent is obliged to provide the customer with
the source code. The following are the normal trigger events.
• Software house insolvency – this could lead to automatic release of

the source code as there can be no argument as to whether it has
occurred or not (at least in the case of formal insolvency proceedings,
such as an appointment of an administrator or liquidator).
• Software house default – a typical software escrow agreement would
provide for release on the breach (perhaps material breach) by the
software house of particular provisions (normally the obligation to
correct an error). The release is not automatic as it is not always clear
that there has been a default. The licensee would notify the escrow
agent of an alleged breach. The licensor is informed and, if it
disagrees, a dispute resolution process is instigated, with the escrow
agent as the adjudicator, to determine whether (as the customer
says) the software house has, in fact, breached the relevant provision
in the relevant way. If so, the source code is released.
9.4.2 Escrow in a SaaS environment

Traditional escrow does not work in a SaaS environment. The customer
does not even have a copy of the executable in the first place. If there is
a supplier insolvency, it is not only an issue of loss of support, there is the
more fundamental risk of losing the application itself, as well as the loss
of data. Nonetheless, escrow agents have identified a number of
different solutions intended to guard against even this risk. New services
are coming into the market. One solution, applicable when the service is
a SaaS built upon a third-party hosting provider, allows for the escrow
agent to carry on managing that SaaS solution when the original
provider is no longer available. It might be that it takes over the
relationship with the hosting provider for the benefit of the initial
customer base (at least those that have subscribed to the escrow
arrangement), and to make sure the fees are continued to be paid. This
would typically be time-limited. Another possible solution allows the
customer to extract the data. Again, there would need to be an
underlying agreement between the escrow agent and the underlying
infrastructure provider (whether an IaaS or a traditional co-location or
hosting service). One company providing these solutions, NCC Group,
announced its first sale in early 2014.
Under other solutions that have entered the market, the SaaS provider is
obliged to deposit with the escrow agent not only the source code but
Cloud Computing 137

also the executable program and customer data. The intention is that, on
the SaaS solution being unavailable, the customer can – in theory – run
the application on an alternative infrastructure. This is perhaps more
applicable when the escrow agent cannot make a separate arrangement
with the original underlying infrastructure provider. As with traditional
escrow, it is important that the deposit is actually verified – it is too late
to find out in the event of a SaaS provider’s failure that a critical
component of software was not deposited.
Practical tip
If relying on software escrow as a protective measure, a customer

should consider utilizing the escrow agent’s ‘verification’ service to
ensure that what is in fact deposited is what should have been
deposited, that is, that the deposited materials can recreate the
actual service used.
As mentioned, the executable and the source code are not enough; data
also needs to be safeguarded – and that is within some escrow providers’
cloud solutions. Where the solution is structured on the basis of the
escrow agent taking over the existing infrastructure, then this is not so
much of an issue; the data will be available to the agent. However, if not,
as the data will constantly be changing, there should be obligations to
deposit the data with an escrow agent on a regular basis. Care is needed
here as some of the standard offerings in this space state that the
provider is to make a deposit of applications and data only every three
months. This is likely to be inadequate for almost all commercial uses. Of
course, depending on the nature of the data being held in the cloud,
even a daily deposit might not be adequate, and what is needed is a
real-time data replication service. These services, too, are being offered
by agents. Clearly, all this is an additional cost that needs to be borne in
mind when undertaking the cost of ownership analysis of whether to go
into the cloud in the first place.
Practical tip
To be useful in a SaaS environment, software escrow also needs to

deal with deposits of data (or at least the customer needs continuous
alternative access to current data). Customers should check what
precisely the escrow agent is offering: will it have a separate
arrangement with the infrastructure provider? Or will it be taking
deposits of data from the SaaS provider?
138 Cloud Computing

9.5 Key points
Any escrow arrangement for a SaaS solution would require the usual
trigger events of supplier breach of support or insolvency for release of
the deposited materials. However, it might also be useful to include a
critical failure of relevant service levels (too much service interruption
and downtime).
9.4.3 Escrow in an IaaS environment

This is even more problematic than escrow in a SaaS environment. The
main IaaS providers have their own data centres and, as such, the escrow
industry has not yet come up with a solution to mitigate a provider’s
insolvency. The SaaS solutions discussed above do not really translate to
this situation.
9.5 Key points

In this chapter we have explored software licensing issues arising in the
cloud. Key points are as follows.
◆ A customer wishing to run an existing system on a cloud

infrastructure should ensure that its software licences permit the
transportation. Existing software will have been licensed on
documentation that may not have envisaged use in a cloud
environment, and may contain any of a wide variety of restrictions
that may catch the situation.
◆ A breach of such a restriction will put the customer in breach of
contract, and both the customer and the provider in a situation of
infringing the third-party software house’s IP rights. A provider will
want to be indemnified.
◆ Open-source licences sometimes have a ‘viral’ (‘copyleft’) effect when
the software is distributed to the public; the software company that
uses the open-source component may also have to make source code
of its own software available to the wider public. Whilst older forms
of open-source licences were doubtful as to whether a SaaS
distribution triggered this obligation, the newer form of Affero
Licenses puts the matter beyond doubt if the new software is a
‘modified version’ of the original software. Great care is needed
when using open-source components in building a SaaS offering.
◆ Software escrow solutions are difficult to apply in the cloud, but the
escrow industry is beginning to develop products that could be
considered. It may need to deal with data in a dynamic fashion and
be relatively ‘open’ in allowing transfer to other infrastructures with
ease. Escrow solutions should always be ‘verified’.
Cloud Computing 139

10 Customer data: the provider’s
use of data, access to data and
lock-in
10.1 Introduction
In this chapter we deal with a number of issues concerning customer
data. A cloud provider has possession of the customer’s data and is
possibly the only entity to possess it. One fundamental issue to be dealt
with in a cloud contract, therefore, is the ability of the customer to
regain possession of the data on termination. Particularly pertinent here
are considerations around obtaining data when the provider is insolvent.
We begin, though, with another issue that can be contentious.
10.2 The provider’s use of its customers’ data

Another area of possible contention and mismatch between a customer
and provider is the issue of use by a provider of the customer’s data. A
cloud provider may want to reserve a right itself to use the customer’s
data for some purpose other than providing services to the customer. A
cloud provider (especially of a SaaS variety) will be sitting on an immense
quantity of its customers’ data, which, when aggregated, can be of
immense value. A phrase that has obtained wide currency over the past
few years is ‘big data’; it is the idea that very large collections of data
may be analysed, for example, to reveal patterns or trends, or market
behaviour. Cloud providers are in a unique position to undertake quite
sophisticated data mining. For example, although not a cloud provider as
such, the US payroll provider ADP creates its ADP Employment Report – a
report on private employment in the US derived from aggregated and
anonymous ADP payroll data from 400,000 of its customers (some 23
million employees).
Another example would be a SaaS solution that administers customer

transactions on their behalf. The cloud provider would be able to analyse
relevant data and then create a report on the typical transactions that
are happening in that field. This report could be made available either to
its customers generally, or only to those customers that are willing to pay
for this enhanced service. It could also (like the ADP payroll report) be
140 Cloud Computing

10.2 The provider’s use of its customers’ data
made available to the public generally. The idea would be that each
customer (or subscribing customer) benefits from the report and the
market knowledge gleaned from the general customer base. A report
could be issued, say, on the typical commercial terms of particular trades
(market prices, average quantities, nature of transactions, etc.). A
provider will naturally give an assurance that data in the report will not
identify a particular customer.
A customer will often be reluctant to allow any such use. It may have a
number of objections. First, it may fear the security risks. Any customer
that has been at pains to ensure security policies are properly present will
very understandably feel that any use by the provider, other than the
provision of a basic ‘vanilla’ service, will increase the risk of something
going wrong with the security (and, at worst, cause a breach, leading to
data leakage). Secondly, and related to the first reason, despite any
assurance that the provider may give in relation to anonymization of the
data, there will be a fear that somehow different pieces of data, which
might be anonymous on their own, could be put together to identify the
customer. In other words, certainly for larger customers, the reports may
be capable of being reverse-engineered to reveal underlying individual
data points. Thirdly, a customer may be disgruntled that the provider is
able to make money out of the customer’s data: surely, the customer may
think, it should be paid for its contribution to that revenue stream? The
provider will, of course, reply that the customer, too, will benefit from
the report or added value the data allows it to provide, and that that is
payment enough (assuming that the report is part of the service actually
subscribed for). This brings us to the fourth and last reason for the
customer’s reluctance. A customer will not want its data to benefit its
competitors, even if its competitors’ data benefits it. This is especially true
of large users, which may well be ‘setting the trend’ in the market and
therefore fear that any such report will not add to what they already
know about the market. Smaller customers may not have that concern.
Practical tip
Contracts should be carefully scrutinized by the customer to ensure

that it fully understands the limitations on use of the data that the
provider is volunteering. If there are no clauses expressly dealing
with the issue, then one should be suggested.
Some cloud providers, faced with strong objections from their customers,
have now dropped the permissive language that previously appeared in
their contracts. Other providers still include language allowing them to
use customers’ data, and attempt to allay customers’ fears by giving some
explanation as to what they will be doing. It is clear that any clause as
Cloud Computing 141

10 Customer data: the provider’s use of data, access to data and lock-in
stark as ‘SaaS provider can use the customer’s data for generating reports
or providing value-added services’ will find understandable objection.
Practical tip
If a provider is keen to provide any additional service that depends

on the customer’s data, then it should expect concern from its
customers. A provider should avoid ‘stark’ clauses retaining the right
to use the data for indefinite or very wide purposes. Examples of
how the data will be used, which focus on the value to the customer
of the resulting reports, are likely to be more palatable.
Cloud providers should consider expanding on this in FAQs.
If personal data is involved, then, in any case, there might be an issue if

UK or EU data protection law applies. The second data protection
principle requires that personal data is only used for the purposes for
which it has been collected (see 4.7). Processing for any purpose of the
provider could breach the second data protection principle. This may
result in the provider then becoming a ‘data controller’ in its own right,
which would present the provider with a number of issues (see 4.5.4).
The customer should, in any case, to comply with the seventh data
protection principle when appointing a data processor, ensure that it
obtains a contractual assurance that the data will only be processed in
accordance with its instructions. Moreover, if the customer knows that
this type of processing will happen and still transfers the data into the
provider’s possession for the latter’s use as a data controller, it, too, may
be in breach of the second data protection principle, unless it can
identify a basis (one of the conditions set out in Schedule 2 of the DPA
[24], under UK law; see 4.8.1) for that transfer.
10.3 Access to data on exit

10.3.1 Provider lock-in
A cloud provider (or its subcontractor) has possession of the customer’s
data and possibly is the only entity with that possession. One
fundamental issue to be dealt with in a cloud contract, therefore, is the
ability of the customer to regain possession on termination. A customer’s
142 Cloud Computing

concern as to whether or not it can actually do so (or do so economically)

is one of the main reasons for customer reluctance to move data into the
cloud.120
It is difficult to overstate the risks here. In the modern world, many

businesses’ lifeblood is their data and a fear of loss of control of that
data is a major issue that customers venturing into the cloud for the first
time will have to overcome. There are a couple of related issues. First,
how does the customer get the data back, if at all? Secondly, is the data
going to be in a format that the customer can use? A customer will not
want the data in a proprietary format as that would ‘lock in’ the
customer to a particular provider. It may well be important to also
retrieve metadata. These issues raise a number of overlapping issues:
commercial, technical and legal.
Practical tip
It is essential, in any adoption of cloud services, that the customer

knows commercially, technically and legally how it will get access to
its data (including any metadata) at all times.
There are issues not only for the ultimate cloud customer but also for a
cloud provider (say of a SaaS) that uses an underlying offering (an IaaS or
a Paas). The issue for a SaaS provider that has built its offering on a
third-party platform, is how to move its application off that platform in
the future. Any PaaS offering is, by its nature, proprietary and there may
well be quite some work to do to move the application off that service
(and all the ultimate data, that is, the SaaS provider’s customer’s data)
onto another platform. An example of this occurred in 2009 when
Coghead customers had to quickly change platform when that service
was no longer available.121
10.3.2 Commercial issues

Let’s take the commercial issues first. A customer will often want to
ensure that it has an entitlement to download the data at any time of its
choosing, or at least to be provided with a copy of the data on a regular
basis. It is not sufficient only to have an obligation upon the provider to
deliver a copy of the data, as that is something which may well be very
difficult to enforce for two main reasons. First, the relationship may not,
at the time of exit, be particularly amicable. This could be because the
120
Richard Stallman’s view (that cloud computing is ‘stupidity’, for just this reason) was noted
in 1.2.
121
See further at 10.3.6.
Cloud Computing 143

termination is through an allegation of breach (by either the customer or

the provider against the other). It may be because the customer simply
wants to move away from a particular solution, with the inevitable
disappointment for the provider of a loss of a potentially lucrative
revenue stream. Secondly, the provider could be insolvent and may
immediately cease trading. A contractual obligation will be of little use as
there might be immediate staff losses and no one to assist in an orderly
exit. Even if there is not an immediate cessation of business (say, where
an administrator is appointed to try and save a going concern), the
priority for staff and management (who might be under threat of job
losses themselves) will be to do what they can to win new business, cut
costs and look after those customers that are not terminating. A
customer that is terminating might expect little assistance, in practice,
even when there is a contractual entitlement.
For these reasons, a customer should not leave it until a termination

event to test its ability to obtain the data. It may be that a feature of the
service simply allows the customer the ability to download the data at
any time and without recourse to the provider, and, if so, there seems
little that can go wrong (other than the servers ceasing operation on
termination). It would be prudent for the customer to ensure that the
functionality does work and to do so on a regular basis (with a full
download), and to ensure that it is possible to receive the data in the
correct format. For particular services, it might be advisable for the
customer to take a backup of data on a regular basis, itself. Escrow
services that cover data might also be useful in this regard (as to which,
see 9.4.2). In short, the customer should ensure that it does not wholly
rely on the provider for the data, or at least should be fully aware of the
risks of doing so. Of course, any escrow service, or alternative data
storage/duplication solution, will have a cost and effort that might
detract from some of the cost-saving and efficiency benefits of the cloud
proposition.
Practical tip
Customers should ensure that they have ready access to data on an

ongoing basis. They need to carefully consider whether the risk of
having only one copy of their data with one cloud provider is a risk
that they are willing to take.
Customers may well wish to explore escrow solutions to assist in

mitigating the risks.
144 Cloud Computing

10.3.3 Technical issues

Data is, of course, always stored in a particular format and a customer
will not wish to simply trust the provider to return data in a format of
the customer’s choice. The data might then arrive in a proprietary format
of the provider, which will not easily enable the customer to migrate to
an alternative solution. This is a problem that also exists in traditional
outsourcing or bureau servicing arrangements. In those cases, the parties
might rely on a provision providing for the customer (at the time of exit)
to determine the format of the data, perhaps providing for data to be
supplied in a ‘reasonably appropriate’ format or something similar
specified by the customer. An outsourcing provider will insist on charging
for the conversion. Whilst this can, of course, also work in a cloud
environment, it does detract from a central aspect of the cloud model,
namely, that the offering should be standard given the multi-tenancy
architecture. The provider at the exit stage could supply a tool for
conversion into the customer-specified format, which the customer can
then itself use to migrate. Again, the provider will want to charge for
this and, again, there is a detraction from the cost-benefit. Having said
that, there is an argument that, as tools for migration from the provider’s
format to one of its competitor’s formats are something that could be
used time and again, it should not be a cost that an individual customer
should bear.
A solution that does not permit the provider to charge additional sums
would need to be specific about the type of format. At the time of
signing the contract the customer will obviously not know what
technology it will be moving to, following termination. (And of course,
even if it did, it would be back to the situation of a tailored offering
departing from the standard offering.) The contract could specify a fairly
standard, non-proprietary format, which will clearly have the attraction
for the provider of being consistent across all customers. Some providers,
for example, specify that data will be returned in the ubiquitous
‘comma-separated values’ (CSV) format (which is supported by many
database-based applications). After all, any replacement provider should
be able to import data from a standard, non-proprietary format. Some of
these providers will make the provision of data in such a standard format
part of the sales proposition.
Practical tip
Customers will want contracts to be specific in relation to the format

in which the data will be returned.
Cloud Computing 145

10.3.4 Legal issues

Once the commercial and technical issues are addressed, the legal issues
will largely fall into place. The contract needs to reflect the negotiated
position on those issues. However, in an insolvency situation the contract
may simply not work.
As noted, in practice, a company that may be desperately trying to

survive is more likely to give full attention to revenue-generating matters
(such as keeping continuing customers happy and maintaining an
ongoing sales effort), rather than assisting those customers that are
terminating (even if those customers have a binding contractual right). In
a traditional outsourcing situation, to safeguard against the possibility
that the provider will not give up the data, the customer may well want
a right to enter premises and obtain the data itself. Even if such a right is
ignored by the provider, in an extreme situation an emergency court
order might be attainable. This is a concept that is difficult to take across
to the cloud environment. As is the position with audit rights mentioned
previously (see 3.8.2), it is only likely to be relevant or cost-effective to
enforce when, first, the customer knows where the data is and, secondly,
it is in the same jurisdiction as the cloud provider.
There is an additional point. It should not be assumed that, following

termination of the contract, the provider will always delete the
customer’s data. A customer that wishes to ensure that, after
termination, the provider no longer has a copy of the data in its
possession should also ensure that there is an express obligation in the
agreement dealing with the point (but only after a copy has been
provided to the customer).
Practical tip
Ownership of data by a customer does not necessarily imply that a

provider is obliged to return that data to the customer. There must
always be an express contractual obligation upon the provider to
return (or at least make available) the data to the customer.
There could also be an express obligation for the provider to delete

all remaining copies once that has been done, perhaps after a
post-termination period to ensure that there is sufficient time to
retrieve a copy.
146 Cloud Computing

10.3.5 Contractual chains of cloud providers

The risk of a provider’s insolvency or breach as it relates to the customer
having reliable access to its own data is compounded when the data is
not actually in the hands of the provider but is instead in the hands of
one of its subcontractors.
The SaaS space is full of small(ish) companies entering into the market by
building their offerings on one of the principal PaaS offerings. Large SaaS
providers also use outsourced hosting services. Whilst the data may well
be safely secured behind state-of-the-art security deployed by the PaaS
provider (or its subcontractor) or an IaaS or hosting company, the real risk
is at the SaaS level. The issue is compounded if there are more than two
providers in the chain (see Figure 3 for an illustration).
If the SaaS provider is insolvent, whilst the data may well be very safe
indeed, it is in the hands of a PaaS (or IaaS) provider (or, worse, one of its
subcontractors). The customer will have real difficulty in retrieving the
data from anyone lower down the chain. In the first place, the customer
may simply not know where the data is (although this does, of course,
depend on the extent of its due diligence). Even when the customer does
know where the data is, the PaaS or IaaS provider may simply not be
interested in assisting the customer (who was not its customer). Certainly,
the provider would want to be paid for any help. It may already be out
of pocket given the fact that its direct customer (the provider above it in
the chain) is insolvent.
However, even with the best will in the world, the PaaS provider (the
subcontractor of the insolvent SaaS provider) may not, in practice, be
able to assist. The SaaS provider’s data ultimately belongs to many
customers, and one customer approaching the subcontractor for data will
necessitate the identification of that data amongst many. It may simply
not be possible to do so. The SaaS provider may only have been acquiring
infrastructure space and any data – in the hands of the PaaS provider –
may be encrypted or, even if not, may be simply ‘raw’ (without any
formatting). In any case, the data will be physically intermingled even if
it is logically segregated. The PaaS provider may not be able to
determine what data is what and which data is which customer’s. As
such, any approach to a provider further down the contractual chain is
likely to be fraught with difficulties. (As mentioned elsewhere in this
chapter, a customer needs to consider very carefully the risk of having all
its data in one basket, as it were.)
Cloud Computing 147

Figure 3. Data is at the bottom of the chain of contracts
148 Cloud Computing

10.4 Key points
Practical tip
When contracting with a cloud provider, customers should verify,

first, who, in fact, has the data, and, secondly, the financial stability
of the provider. New entrants to the market require especially careful
scrutiny.
10.3.6 Lock-out and Coghead

An acknowledged fear for customers entering the cloud is the possibility
of lock-in: the difficulty of a customer moving away from a particular
cloud provider, due to either the cost involved in moving data from one
provider to another or the technical difficulties of doing so. The reverse is
possible, as the Coghead situation demonstrated in 2009; it is possible to
be ‘locked out’ of a platform.
Coghead was a Californian company that offered a PaaS allowing the

building and hosting of custom, online database applications.
Applications were built around custom data collections and typically
designed to facilitate the management of, and collaboration on, business
data. The product was intended to allow users to design a range of
applications from scratch, using only a drag and drop,
what-you-see-is-what-you-get user interface, with very limited scripting or
coding (if any) required. Coghead tried to attract ‘tech-savvy business
people’ by limiting the amount of programming or design experience
required to author applications on its platform. In February 2009,
Coghead announced that it would be shutting down ‘due to the impact
of economic challenges’. It sold its IP, including the Coghead service, to
SAP for SAP to use as an internal resource. SAP imposed a lock-out from
30 April 2009, meaning that Coghead customers had only eight weeks to
completely rewrite all their applications on an entirely new platform to
prevent themselves from being in breach of contract to their own
customers.122
10.4 Key points

In this chapter we have explored customer data issues, including use by
the provider and lock-in. Key points are as follows.
◆ Some cloud providers wish to use customer data for purposes not
directly related to the service being acquired by the customer. An
example of this is aggregation to report on the market generally
(types and values of transactions, for example). This may not be
122
http://www.zdnet.com/article/cogheads-demise-highlights-paas-lock-out-risk/
Cloud Computing 149

objectionable to customers, but the leeway (if any) enjoyed by the

provider should be carefully considered by the customer and set out
expressly in the contract.
◆ It is imperative that there are no commercial, technical or legal
obstacles to retrieval of the data by the customer. Lock-in can only be
avoided where data is readily accessible in a usable format.
◆ Contracts should contain express obligations dealing with the return
of data to the customer on termination, as well as obligations for the
provider to delete all remaining copies.
◆ In practice, legal entitlements to access may not offer too much
comfort when the provider is insolvent, especially when data is, in
fact, in the possession of the provider’s subcontractor. For this reason,
customers should always consider ensuring they have access to
alternative copies of the data.
150 Cloud Computing

11 Service definition – the
provider’s ability to change the
service
11.1 Introduction
Typically, cloud solutions are not tailored to specific customers. Each
individual customer is acquiring a common solution used by all the
providers’ customers. The solution will therefore necessarily evolve as the
provider seeks to continually improve the product and match market
needs. The issue addressed in this chapter is the freedom the provider
reserves in its contracts to change that solution, which will necessarily
impact upon all customers. Once a customer has acquired the solution it
is, of course, unrealistic to suppose that the service will not change.
Indeed, a customer will want further improvements, both in functionality
and in performance. Against that, however, the customer will not want
changes that are so dramatic they require operational changes to the
business, or retraining of its personnel, nor changes that impact upon
other systems which depend on the solution or interact with it. Moreover,
the customer may well have acquired the solution on the basis of a
particular feature and will not want that feature to be one that is
‘improved’ away from what it originally found attractive. There is a
tension here that needs to be addressed.
11.2 A comparison with software licensing

Before proceeding to examine this tension in the cloud context, and to
highlight the solutions that are beginning to emerge, it is worth
considering the same issue as it arises in a more traditional, ‘on-premises’
software acquisition. When software is licensed for installation on the
customer’s own infrastructure, the software installed is not typically
different from that installed on the systems of any other customer. If a
supplier issues a new version of the software (whether it is described as
an ‘upgrade’, a new ‘version’, a ‘release’, a ‘patch’ or otherwise), the
customer is not normally automatically forced to move onto the new
version. Indeed, the superseded version can often be used indefinitely,
although support for it will naturally expire. A careful software licensee
will try to ensure that there is a contractual commitment to support older
versions of the package for a specified period of time (say, a number of
Cloud Computing 151

11 Service definition – the provider’s ability to change the service
years or months), or at least a restriction on there being ‘too many’

updates. This customer is trying to ensure that it does not have to go
through the effort (and it can be a great deal of effort) of installing the
upgrade. Apart from the fact that a software house does not want to
maintain indefinitely a superseded version for any of its customers once
any warranty has expired, it would not ordinarily care if the customer
decided never to upgrade: primarily, it is the customer that loses out on
new or corrected functionality and performance improvements.
Not all upgrade issues that are relevant to software licences are relevant
in the cloud. For example, one of the customer’s concerns is the desire to
avoid having to upgrade its infrastructure (hardware or software). A new
software release may require a newer version of an underlying database
package or operating system, or higher specification hardware, but this
issue might not arise in the cloud when those items, too, are the
responsibility of the provider.
11.3 From the provider’s perspective

Like the software licensor operating under a traditional ‘on-premises’
model, the cloud provider will constantly want to evolve its offering in
order to remain competitive. It will want to keep abreast of its
competition and their developments. It will want to deal with, and
hopefully anticipate, its typical customer’s concerns and desires. Generally,
it wants to continually improve the product and to innovate. Where the
comparison breaks down, however, is that, in on-premises licensing,
innovating the product does not (as just seen) automatically force
existing customers to move onto the improved version. In the cloud,
certainly where there is multi-tenancy, once a new version is introduced,
all customers on that version will likely have to move onto the new
version.
The cloud provider therefore wants complete flexibility. It must, in the

end, be able to force the customer to upgrade. It has no real choice; the
economics of the cloud model are predicated on the fact that all
customers run on the same version of the software and, perhaps, in the
same, multi-tenanted ‘instance’.
Practical tip
A provider should, in its terms of business, reserve the right to make

changes to the services.
152 Cloud Computing

11.5 How to deal with service change in a cloud contract
11.4 From the customer’s perspective

The customer has been sold the proposition on the basis of its current
functionality, which, to get to the stage of negotiating contracts, it must
have found attractive. Nonetheless, no matter how attractive, especially
in early adoptions, it might have had quite a lot of initial anti-cloud
reluctance to overcome. The customer will have had a number of fears,
including regarding security and the lack of direct control over an
important part of its IT offering. To then be presented with a contract
that expressly gives the provider wide discretion to change that offering
without reference to the customer may well make it pause. Yes, a
customer may say to the provider, you are selling us an exciting and
cost-effective package, but how do we know that that is what you will
be providing in a few months’ time? After all, in an ‘on-premises’
software acquisition, the customer has the ability to decline, or not
install, a new version of the software.
A customer may also fear that the removal of an element of functionality

from the service is only a precursor to that element then finding its way
into an additional option or plug-in for which there will be an additional
charge.
Practical tip
A customer should be wary of a completely unfettered ability for the

provider to change the service, at least when the customer is tied
into a long-term contract without a right to terminate early.
11.5 How to deal with service change in a cloud

contract
Cloud contracts will not always be negotiable and often a customer has
no power at all to insist upon a change to terms (certainly, when it is a
small customer acquiring a standard offering from a giant provider). The
following points assume that there is scope for some negotiation. In any
case, providers hoping to avoid unsettling their customers when the
latter are presented with a standard contract may wish to take a
reasonable and measured stance on this issue. A customer will
understandably resist a completely unfettered ability for the provider to
change the offering. Whilst a first version of a cloud contract might
include such an ability, a compromise is likely to better reflect a
customer’s concerns. Compromises will inevitably focus on different types
of service changes. Nonetheless, given the multi-tenancy model, and
Cloud Computing 153

cloud economics generally, the fetter on the provider’s ability to change

the service is likely to focus on the length of notice and not a giving up
of the ability to make such changes.
First, a contract will have to deal with trivial changes. These are likely to
be permitted by the contract (and without the requirement of any
particular notice). An example would be service changes that have no
impact on the functionality or the service levels.
Secondly, if the change is material or there is otherwise an impact upon

the customer, then the customer will want to require notice to be given.
Changes in this category would include those where a customer would
have to spend money or effort (for example, upgrading its own systems),
or even just change its processes (including the requirement for
additional training). The actual period of notice is obviously subject to
negotiation. It should be sufficiently long to allow the customer to make
an informed decision as to what needs to be done and (if unhappy about
the change or impact), ultimately, to move to another supplier.
Thirdly, the provider might be required to make a change as a result of

an IP problem. The service may be found (or thought) to infringe the IP
rights of a third party. If a problem with IP does occur, then, in order to
avoid infringing (and putting its customers also in danger), the provider
will want to be able to immediately amend its offering to avoid the
problem. This concept is capable of refinement. For example, the contract
could stipulate that the provider can only make such changes if there is,
in fact, a court order preventing the offering. A provider would never
volunteer this; it would follow from a customer request. It would
exacerbate the provider’s potential liability in the interim to the third
party. Accordingly, the contract might be more permissive and allow the
change if the provider has good faith or reasonable belief that there is a
problem and that a court order would follow. Either way, a customer
might seek to negotiate a right to terminate the agreement on any such
change.
Similarly, a change might be permitted if the provider considers the

change to be necessary to comply with a legal requirement. A provider
may not volunteer notice for this type of change, but the customer will
want no surprises and may take the view that, where it is something
which the provider should have known about, notice should be given.
Lastly, a provider might also want to make changes without notice when
it considers it necessary to do so for technical reasons, or to ensure the
continuing provision of the service without degradation or interruption.
This is a little trickier for the customer to accept as – again – it is
something which, strictly, the provider has in its control. It is reasonable
for a customer to insist that the provider takes full responsibility for
issues around its technical ability to provide the service. Nonetheless, a
provider may well want to guard against the unforeseen. A compromise
154 Cloud Computing

11.5 How to deal with service change in a cloud contract
on this point is to recognize that changes for such reasons might indeed
come about unexpectedly, and then to require that the provider gives the
customer a period of notice if reasonably practicable, recognizing that it
might not always be practical.
Practical tip
Contracts could deal with change by making distinctions between

different categories of changes: the more material the change, or the
more necessitated for reasons within the provider’s control, the
longer the notice to be given to the customer.
A couple of additional points from the customer’s perspective follow.

First, the customer can take reassurance from, and should insist upon, a
contractual provision which states that the changes will only be made in
respect of the services it is acquiring, if the same change is made in
respect of all customers generally (and not just to it). Genuine ‘technical
reasons’ or ‘service enhancements’, and so on, should be generally
applicable. Secondly, in all these scenarios, whatever other safeguards are
also present, a customer may want a right to terminate if it is dissatisfied
with what remains of the offering following the change. A right to
terminate, in a situation where the customer has paid in advance, may
also be coupled with a right to receive a refund of monies paid for
service that has not in fact been used. There is much scope for different
solutions to – and heated negotiation on – this type of issue.
Practical tip
In the event of certain types of service changes (certainly those that

impact upon the customer’s own internal processes or its retained IT),
it might be appropriate for the customer to include a right to
terminate in the contract.
If the customer’s protection is to terminate early, it should consider

whether the contract should provide for a pro rata refund of any
monies paid in advance.
Cloud Computing 155

11.6 Key points

In this chapter we have explored service definition. Key points are as
follows.
◆ Cloud economics imply that many customers will be using the same
version of the service. Change mechanics have to recognize this; a
cloud provider cannot permit any particular customer to have a say
on whether or when changes are implemented.
◆ Nonetheless, a customer may resist a completely unfettered ability
for the provider to change the service and the contract should deal
with both parties’ points of view. The customer will not want to be
forced to accept changes that materially affect its enjoyment of the
service (perhaps by the loss of functionality that it was accustomed
to, or by a need to retrain staff or to upgrade its own internal
resources).
◆ It is only in exceptional circumstances (where a customized service is
provided at a premium, for example) that a provider will agree to
address the customer’s concerns with some form of veto over its
ability to enforce change. More normal, if anything is conceded at
all, is a right for the customer to terminate early if it is unhappy with
a change.
156 Cloud Computing

12 Service levels
12.1 Introduction
There are a number of trust issues that a prospective customer will have
to overcome before venturing into the cloud. Security is foremost, of
course, but so, too, is the issue of service availability, as well as other
quality issues. A customer needs to be able to trust that the solution (no
longer in its direct control) will be available when it needs it, often, of
course, on a continuous basis. As well as being reliant on connectivity
(internet or otherwise) to be able to access data, a customer also needs
to rely on the provider maintaining its infrastructure, on which the cloud
service is supplied, in a sufficiently robust manner. No service provider
will give an absolute assurance that its service will be available 100 per
cent of the time (just as no software house would guarantee that its
software is error free). Instead, a typical cloud provider (if it offers
anything at all) will offer some form of availability expressed as a
percentage (often in the range of 95 per cent to 99.9 per cent; rarely,
higher). Cloud providers may well ask their customers, when considering
the service level being offered, to compare the proposition with the
customer’s own existing service levels. Many customers will not even have
measured availability when the service now being acquired externally
was being managed internally.
It must also be noted that some cloud providers do not offer any service
level at all and state (either expressly or by means of exclusions and
disclaimers) that the service is, in effect, ‘as is’.
The expression ‘service level’ is usually used to describe the ongoing

promise of a provider to meet a particular standard in terms of
availability, responsiveness, or other such measurable factors. In the cloud
the most important service level will be availability, but there might be
others. The service level system not only sets the target but frequently
also sets the consequence of missing the target, often a system of service
credits. This is a mechanism under which the customer is compensated by
the provider if a promised level is not achieved. Service levels and credits
sometimes appear in a separate document (or schedule) called a service
level agreement (SLA), which – despite its name – is not normally a
separate contract in its own right; rather, it is part of the overall deal.
Cloud Computing 157

12 Service levels
Practical tip
Some providers will publish their SLAs on their websites and will not
necessarily automatically provide a copy directly to a customer. These
are important documents, and part of the overall deal, and should
always be carefully reviewed.
A service level/credit regime has a few important and overlapping

purposes. Its primary function is, of course, to set out the standard to
which the service will be provided, an important part of the commercial
and technical assessment that a customer must make in considering the
offering. Then, it allows for compensation to the customer if that
standard is not met. It also motivates the provider to meet that standard
by providing for loss of revenue (through a service credit regime) if it
does not meet promised levels.
Even the biggest cloud providers suffer outages. Rackspace, the internet
hosting company, also provides cloud IaaS solutions from the same data
centres. It has had a number of service outages, including one in June
2009 sufficiently serious to merit a public statement (as it is a US-listed
company). It lost power to its data centre, but then the standby
generators also failed. Customers were left without service for 40
minutes. As a result, Rackspace estimated in its statement that it would
have to pay out service credits of as much as $3.5 million. The
best-known of the SaaS providers, Salesforce.com, is not immune from
service outages. In 2009, it suffered a service disruption for about an hour
due to a core network device failing. This is thought to have affected
900,000 users.123 Many Amazon Elastic Compute Cloud customers
experienced an outage in 2011 when one of Amazon’s data centres
suffered problems. The error started during a network upgrade and this
then set off a series of events that ultimately took down much of the
company’s service to the US East Region. The problems persisted for
about four days.124 The list of prominent examples goes on. Dropbox
suffered outages in early 2014, lasting just over two days in total.
Dropbox attributed the disruption to a scripting error.125 Google posted
two outages, also in 2014, caused when ‘an internal system that
generates configurations—essentially, information that tells other systems
how to behave—encountered a software bug and generated an incorrect
configuration’.126 In May 2014, Adobe Creative Cloud services went
123
See http://www.cnet.com/news/salesforce-com-outage-hits-thousands-of-businesses/
124
See http://aws.amazon.com/message/65648/
125
GUPTA, A. ‘Outage post-mortem’, Dropbox Tech Blog, 12 January 2014.
https://tech.dropbox.com/2014/01/outage-post-mortem/. There is an increasing amount of
candour in cloud companies’ explanations of their outages.
126
TREYNOR, B. ‘Today’s outage for several Google services’, Google Official Blog, 24 January
2014. http://googleblog.blogspot.com/2014/01/todays-outage-for-several-google.html
158 Cloud Computing

12.2 Typical service metrics
offline for 28 hours, reportedly affecting many of its 1 million+

subscribers.127 It was apparently due to an issue during database
maintenance activity.128
As we discuss issues that arise relating to service levels, it is worth

bearing in mind the point made elsewhere in this book. Only the biggest
customers making large acquisitions are likely to be in a bargaining
position to negotiate on the terms otherwise offered as standard by the
provider. For a smaller, ‘commoditized’ offering, there is not likely to be
any ability to negotiate. However, it is hoped that considerations set out
in this chapter will assist the customer in assessing the risks involved in a
particular offering.
12.2 Typical service metrics

Where service levels are offered, there are likely to be a number of
metrics that make sense in any cloud context.
12.2.1 Availability
Each cloud offering (of whatever type) will require the provider to give a
commitment that the service is actually ‘available’. This is the most
important measure and sometimes the only one that is, in fact, assured.
Availability can be complex for a number of reasons, especially when the
service might constitute a number of different elements. We explore this
further, below.
12.2.2 Service response times

Customers should consider whether to require a service response time
level. This would measure the length of time needed for the service to
perform a typical function, that is, from the request being placed until
the service responds. A cloud user might, for example, be concerned that
there are simply too many customers being serviced by the same
(multi-tenancy) instance of the software. An assurance on response times
would go some way to mitigating this concern.
127
DOVE, J. ‘Adobe says day-long Creative Cloud outage was not a security issue [Update]’,
The Next Web (TNW), 16 May 2014.
http://thenextweb.com/creativity/2014/05/16/adobe-blog-post-blames-day-long-creative-
cloud-outage-database-maintenance/
128
ADOBE CUSTOMER CARE TEAM, ‘Adobe Service Outage Update’, 15 May 2014.
http://blogs.adobe.com/adobecare/2014/05/15/recent-service-outage/
Cloud Computing 159

12 Service levels
Such a service level is not often volunteered. If it does feature in an SLA,

the cloud provider would certainly exclude the time taken for data to be
communicated (as internet or other connectivity would not normally be
in the provider’s control).
12.2.3 Problem resolution times

There can be a variety of metrics around this issue. How long before a
reported problem is logged and allocated a priority? How long before a
workaround is issued? How long before a full solution is provided? (This
is belt and braces as, of course, if a problem is not resolved, the
availability measure might also be triggered. Nonetheless, it can be useful
to have, especially as repeated failures to resolve problems in a particular
timescale can be a warning sign of greater problems to come.)
12.2.4 Elasticity
One of the benefits for a cloud computing customer is the ability to scale
quickly. It is possible to measure the speed at which an additional
resource (servers, storage and so on) is made available following a
customer request, and for the provider to commit to a particular level. It
might be worth the customer insisting upon such a service level if there is
a frequent requirement for such flexibility.
12.3 Availability
The most important metric in a cloud offering is the assurance to the
customer that the service is available, ideally 24/7, 365 days per year.
Depending on the type of service, there might be an agreed period of
‘dead time’, during which period scheduled maintenance might be
performed – in exactly the same way as would be the case if the relevant
service was being provided in-house by the customer’s IT department.
Saying that a service will be ‘available’ a particular percentage of time,

say 99.9 per cent, raises a few issues of definition. What is meant by
‘available’? Is, say, a SaaS designed for use by many hundreds of customer
employees across the globe available if just one employee in the UK (or
just the employees in the UK) can use the service?
160 Cloud Computing

12.3 Availability
Practical tip
The contract needs to be very clear on what ‘availability’ means. Is

the system available if one user (or one location) can use some (if not
all) functionality? Is it ‘unavailable’ if only one user cannot access full
functionality?
Then, over what period is availability measured? A promise of, say, 99.9
per cent availability is ambiguous unless it can be tested and, therefore,
the period over which the measurement is to be taken needs to be
clearly set out. As may be obvious, and as will be illustrated below, there
is a big difference, in terms of potential disruption to a customer,
between 99.9 per cent availability measured over a year than the same
figure of 99.9 per cent availability measured over a day. As much care is
therefore needed around the definitions in an SLA as in any other part of
the contract.
The gold standard SLA for availability are the ‘five nines’ of 99.999 per
cent, but that is fairly rare. To take a small, and possibly
non-representative, sample of what the leading cloud providers publicly
offer in terms of availability: Amazon EC2 and Google App Engine are
both at 99.95 per cent, and Microsoft Azure is at 99.9 per cent. These
numbers can appear to be encouragingly high. However, it all depends
on the period over which availability is measured. Table 2 shows how
much downtime is allowed by such figures over various measuring
periods. Whilst, from an initial look, there is not much difference
between 99.99 per cent availability and 99.0 per cent, the former only
allows just less than 1 hour downtime over a year, whilst the latter allows
over 3.5 days a year. Moreover, if something like 99.9 per cent is
acceptable in principle, an SLA providing for measurement over a year
allows a downtime of 8 hours 45 min over the year, and it needs to be
borne in mind that all 8 hours 45 min could occur on the same day. If the
service was down for 8 hours (even during the peak period), there would
be no service level failure. Contrast this with the other extreme: if 99.9
per cent is measured daily, a service level failure would occur if only 1
min or so disruption occurred on a particular day.
Practical tip
Customers should pay particular attention to the period over which a

given service level is measured.
Cloud Computing 161

12 Service levels
Sometimes availability is not measured in respect of the entire day, but

only some form of (perhaps, extended) working day. This may, of course,
be fine, but again simple arithmetic shows drafting issues that a customer
should bear in mind. If the service is one where a customer expects
realistically to use it only during the working day, a customer will want to
look closely at the time over which the availability is assured (to the
appropriate level). For example, 99 per cent availability allows 14 min
downtime over a 24-hour period (but all of those 14 min might be in the,
say, 12-hour working day). By contrast, 99 per cent availability assured
over a 12-hour working day allows 7 min downtime during that period.
Because of this, some providers do draw a distinction between availability
during core periods and availability during non-core (slow) periods.
Table 2. Permitted downtime by the 9s
Annual Monthly Daily (24

hours)
99.999% 5.259 min 0.438 min 0.0144 min
99.99% 52.59 min 4.38 min 0.144 min
99.9% 8h45.6 min 43.8 min 1.44 min
99% 3 days, 15 7 hours, 18 min 14.4 min

hours
12.4 The consequences of missing service levels

12.4.1 Target or contractual level?
The precise consequence of missing any level depends on the particular
contract. The usual remedy is a credit on missing the service level.
However, some SLAs include two figures in respect of a particular service
level: one a target and the other a lower figure to indicate failure. A
remedy is then only offered for failing to meet the lower level. From a
provider’s point of view, it sets a target that it aspires to and allows the
provider to genuinely boast about a higher level in its sales literature.
From the customer’s point of view, such a promise could be seen as
verging on the disingenuous, as, most likely, the customer has no remedy
at all unless the lower figure is missed. Customers should therefore take
care.
162 Cloud Computing

12.4 The consequences of missing service levels
Practical tip
Depending on precise drafting, a ‘target’ level (as the name suggests)

is aspirational only; there will likely be no contractual consequence if
that level is not met.
12.4.2 Credit and other remedies

The normal mechanism used in an SLA to compensate the customer for
receiving a sub-standard service is for the customer to earn service
credits. These are normally monetary discounts from either past or future
invoices. A typical service credit may state that for each minute or hour
or × per cent non-availability below the trigger level, the cloud customer
will receive a credit of a specified amount. The specified amount might
be a day’s fees or pro rata, reflecting the period of non-availability. If it is
at too low a level, it will not really be a carrot incentivizing the provider.
Practical tip
A customer needs to ensure that the level of credit is meaningful to

ensure its purposes: compensating it for loss of service and properly
incentivizing the provider.
A customer should also note carefully the contractual language. This

is not a refund of fees paid, only a credit against future invoices. (If
this is towards the end of the agreement, there may be no future
invoice.)
Whilst credits are the normal remedy, some providers (notably, Google
App Engine) instead offer additional free service (i.e. an extension of the
term) for failure. Clearly, this is less attractive to a customer: it is unhappy
with the service and all it gets as compensation for that unhappiness is
additional service.
12.4.3 Calculating credits

There are mechanics around a typical service credit regime that merit
appropriate scrutiny by the customer. These often detract from the
initially anticipated benefit of the regime in a less than obvious manner.
First, there will inevitably be caps on the amount of credit that can be
earned. The total that might be earned for service failure could be as low
as 10 per cent of the recurring fees for the service (whether the monthly,
Cloud Computing 163

12 Service levels
quarterly or annual fee). In effect, this causes pain to the provider by

severely reducing its profit, or eliminating it altogether, but not so much
pain as to actually put the particular account into a loss. Caps, however,
may be more complicated than simply one overall cap. Each of a number
of different service levels offered by the provider might have a separate
credit regime, and in relation to each such regime, there might be a cap
at a particular percentage of the fees for the relevant part of the service.
Practical tip
A service level/credit regime should be considered as a whole, and

the cap on any credit is an important part of that whole. Customers
should be wary about it being set too low.
The effect of a cap can be far-reaching. Once the service misses the
target by a particular amount or on a number of occasions during the
period, the cap will be reached. The purpose of incentivizing the provider
to fix problems quickly by having contractual consequences will be
removed; having reached the cap, there is no longer this incentive to fix
the underlying problem, as the provider cannot lose any more money by
having to pay increased credits. (That is not to say there are no other
incentives – clearly, any reputable provider will want to limit the damage
to its goodwill that any prolonged outage would entail.)
12.4.4 Exhaustive remedy

It is standard for the provider to include in its contract a clause stating
that the service credit regime is the exhaustive or exclusive remedy for
failure to provide the service. In other words, if the service is unavailable,
all the customer can do is recover credits – it cannot also seek to claim
more general ‘damages’, for example loss of revenues that would have
been made had the service been available. A customer could try to resist
such a provision, especially if there is also a cap at a fairly low level on
the credits.
12.5 Standard exceptions

Cloud providers, in common with other IT and telecoms service providers
that commit to a (more or less) continuous availability of a resource to
the customer, often include a number of fairly standard exceptions to the
service level commitment. In this section we set out those that are
common.
164 Cloud Computing

12.5 Standard exceptions
12.5.1 Force majeure

English contract law is very strict. Other than when a contract becomes
literally impossible to perform as stipulated, a party is bound to perform
no matter how difficult (or costly) it is to actually do so. So if there is a
fire or flood at a data centre, say, the provider is not normally excused
performance as it is of course possible for the provider to commission an
alternative centre; English law would disregard the costs of doing so in
forcing the provider to perform. Of course, it is open for the parties to
agree that the provider should be released from its obligation if that sort
of unexpected event were to arise. ‘Force majeure’ is an expression that
is used to encapsulate those types of events, and a clause frequently
appears in contracts excusing the provider both from primary obligations
under the contract and from commitments to provide the services to a
specified level, should such an event occur.
In an SLA context, a typical clause would state that the service level
should not apply during a period when the force majeure event is in
existence and is preventing a particular level being met. Further, the
force majeure concept is sometimes extended, to excuse a default when
the force majeure event occurs not only to the provider itself but also to
the provider’s suppliers. In the cloud context this is likely to be
particularly relevant. A SaaS provider, for example, which contracts with
an IaaS or PaaS provider for infrastructure or platform, will want to rely
on this provision if a fire was to occur at the latter’s data centre and so
on.
Care is needed in considering what events fall within the exception. A

provider will want as many as possible (within reason). The following
would usually feature (and should not be too problematic to a customer
in a sense that they are standard):
• war, riot, civil commotion;

• accidents, acts of God, natural disasters, fires, floods or storms;
• strikes and other employee disputes;
• a ‘catch-all’ concept of events beyond the control (sometimes, the
wider: beyond the ‘reasonable’ control) of the party.
The following may also sometimes appear and a customer may well find
these more objectionable:
• failure of hardware: a customer would expect the provider to ensure

proper maintenance;
• disruption of power supply: a provider might be expected to ensure
it has standby generators and take responsibility if those fail (see the
description of Rackspace’s outage mentioned at 12.1);
• communications problem: this is perhaps unacceptable when it is
wide enough to cover links between, say, different aspects of the
provider’s infrastructure, as opposed to the internet generally;
Cloud Computing 165

12 Service levels
• failures caused by other customers: this could be resisted by a

customer on the grounds that it is up to the provider to ensure that
its shared systems are sufficiently robust to withstand any use
(including misuse) by its customers;
• default of one of its suppliers. This is dealt with in detail in the next
section.
Practical tip
Force majeure clauses are sometimes treated as standard ‘boilerplate’

clauses (and, indeed, often appear under the ‘Miscellaneous’ heading
at the end of contracts). However, they contain important, and
sometimes surprising, exceptions to the supplier’s obligation to
provide the services. A customer should always carefully review them.
12.5.2 Third-party suppliers

Somewhat related to force majeure, and indeed sometimes dealt with
within that clause itself, is an exception that allows the provider to avoid
liability if a failure is due to its suppliers. Especially for a SaaS provider
offering a solution built on a PaaS or IaaS offered by a third party, this
can be a major issue. There are two separate situations here.
The first situation is when a force majeure event has occurred to the
provider’s supplier. It is not unreasonable that this type of situation
should be covered. If the principle that fire excuses performance, say, is
acceptable (as it often is), it does not really matter if the fire was at the
provider’s premises or one of its supplier’s (as long as the fire at the
supplier’s premises does, in fact, have a knock-on effect on the service the
customer is enjoying).
The second situation is when the provider’s supplier simply fails to

perform (and not only for a force majeure reason). It might, for example,
fail to perform in breach of contract to the provider. In justifying an
exception to its responsibilities to its customer, a provider would argue
that its services are dependent on these third-party suppliers but that it is
not able to control them and prevent failures. As such, it should be
excused and not be held to have breached its contract with a customer
(or held to have missed an SLA) if its supplier has let it down. A customer
might well argue that it is open to the provider to include appropriate
contractual provisions in its contract with a supplier so that it has a
remedy and can thereby pass the liability on. Whilst this is, of course,
true, the provider would reply that its ability to recover from its supplier
is likely to be limited given the inevitable existence of limitations and
exceptions to liability.
166 Cloud Computing

12.6 Drafting issues around SLAs
To illustrate how this might occur in practice, let us take the example of a
customer that acquires a SaaS from a start-up provider that has built its
offering on a PaaS solution. The PaaS provider may well be substantial
and may offer service credits for availability issues to the start-up SaaS
provider. However, if the SaaS provider is (in its contract with the
customer) excused performance due to a failure of its suppliers, then,
even if the SaaS provider earns credits as a result of that failure, it may
well have no liability to its customer.129 In this type of situation,
availability of the service is very much in the hands of the subcontractor
and if the SaaS provider is excused performance, there is little that is
meaningful left in the provider’s service level promise.
Practical tip
A customer needs to pay particular attention to how the contract

attempts to excuse the provider from performance due to a supplier
(or subcontractor) default. This is especially so in contracts with
start-up providers that have built their solutions on other cloud
services.
At the very least, a customer will want to make sure that if its provider
does recover compensation (whether in the form of service credits or
otherwise) from a supplier, that it then has a right to have those (or an
appropriate proportion of those) passed onto it.
12.5.3 Customer actions

It is normal to excuse failures to meet service levels if the failure was
caused by the customer itself.

Many cloud providers have developed a number of drafting techniques
around service credits which, even if not deliberately designed to make it
more difficult for a customer to claim credits, certainly have that effect.
We explore a few of these.
129
It should go without saying that this is all, of course, dependent on the precise contract
language.
Cloud Computing 167

12 Service levels
12.6.1 Provider reserving right to vary

First, in any service contract, some aspects can be relegated to a perhaps
arbitrary status of ‘operational detail’, in relation to which a provider
may reserve the right to change that detail, often without any specific
notice. In cloud services, this could be in relation to codes of conduct of
use, support service details, or, to bring us back to the present context,
service level details. Given the reliance a customer may have put on
acquiring a service with, say, a particular level of availability, the concern
is obvious: if the provider reserves the right to change that level, it may
be changed to the customer’s detriment going forward. A trap for the
unwary is when the provider simply refers to the service level (or indeed
any other ‘operational detail’) as being set out on a web page (or other
non-signed document external to the actual contract) ‘from time to time’.
This latter expression means that the provider can change that detail.
Practical tip
It is important that the customer is aware of whatever (if any)

discretion the provider is reserving to amend the service levels during
the term of the deal.
12.6.2 Monitoring
A service level needs to be monitored. Once a service level is monitored it
needs to be reported on and the applicable credits then need to be
applied. A cloud provider will, of course, inevitably monitor the
performance of its own service and could, if it wishes, report on it to its
customers and apply credits. This has a number of disadvantages for the
provider. If the service was, in fact, down, below the applicable level, it
may well be that a customer was not aware of it, or at least not too
concerned (the downtime could have been in a time that was not
disruptive to the client’s business). To report a problem to the customer
will highlight service issues as well as damage revenue. As such, many
cloud providers have adopted the practice of not reporting outages to
their customers (but nonetheless making the information available
through online means), and certainly not automatically applying service
credits. Instead, a customer would need to request the application of a
credit from the provider.
Whilst some cloud providers do offer the opportunity for customers to

check the availability records of their particular ‘instance’ of the offering,
often with dedicated web pages for the purpose, others do not. Some
providers require the customer itself to identify the lack of availability
(through not being able to use the service) and to give documented
evidence of it. Documented evidence required might consist of the
168 Cloud Computing

customer’s service logs. Even if the customer accepts that it has to

monitor the availability and make its own claim for credits, the
requirement for evidence needs to be carefully considered by the
customer: will it always be able to provide evidence of a service failure?
12.6.3 Processes for claiming credits

Care is always needed in relation to the actual process required to trigger
credits. Some providers, for example, require a customer, in order to
obtain a credit, to report the start of the incident when the outage is
ongoing and – according to this type of provision – the customer report
defines the beginning of the outage period for the purpose of service
credits. Accordingly, an incident that may, in reality, last a number of
hours but is reported well into the incident will only have a
correspondingly short ‘official’ outage period. Other cloud providers
require a specific request to log or record the incident as an outage for
service credit purposes. It is not, on the terms of these SLAs, sufficient
simply to report the incident for the purpose of obtaining attention to
the non-availability. These types of processes seem particularly unfair to
the customer, which, in the midst of an outage, is more likely to be
concerned about getting up and running again, than worrying about
financial compensation and the strict requirements set out in an SLA.
12.6.4 Time limits

Providers will understandably want to set time limits within which a
credit claim can be made. These are typically a number of days after the
end of the relevant accounting period. The number of days can be
relatively short (perhaps as little as 10 days). Whilst understandable from
the provider’s point of view, as it closes the incident, this is yet something
else that a customer will need to have mechanisms in place to deal with.
From a customer perspective, what is best, of course, is the automatic

reporting and application of service credits in accordance with the
appropriate formula for the calculation.
Practical tip
A customer should consider requesting provisions in its contract

requiring, first, the reporting of downtime and other service level
issues; and, secondly, the automatic application of credits to invoices.
Cloud Computing 169

12 Service levels
12.7 Termination for failure to achieve service

levels
A problem with a service credit regime as the sole remedy for service
level failures is that it does not really offer the customer much if the
provider is consistently providing a poor service, certainly, if the caps are
low. It is entitled to some money back (but only by way of credit against
invoices) or perhaps additional time for no charge. A cloud customer may
find the service so bad that it wants to exit but finds that the SLA does
not allow this; despite the poor quality, the customer may be locked in
for whatever period it signed up for as an initial term.
Contracts normally have a general termination entitlement for a

‘material’ breach of contract. However, it is possible (depending on the
precise wording) that this will not apply to service level issues if there is a
provision which states that credits are the sole remedy.
Practical tip
Customers should be aware that, if the service credit regime is

expressed to be the sole remedy for service level failure, then the
contract’s general provision allowing for termination on certain types
of breach may not apply.
Even if the general termination language did apply to a service level

failure issue, there could be an argument as to whether service level
failure is the right type of breach. For these reasons, it would normally
make sense for the customer to ensure there is an express termination
right for service level failure. Thus, if the service failure is particularly bad
over a particular period, the customer can terminate. What is particularly
bad for this purpose could be defined by a number of different criteria.
The contract could provide that the client can terminate if the maximum
service credits have been earned during any particular period.
Alternatively, a right to terminate may arise where a maximum number
of credits have been earned in a particular number of consecutive
measurement periods, or a particular number of measurement periods
(not necessarily consecutive), over a year. Where there is more than one
service level being measured, account needs to be taken of whether
there should be a requirement that all metrics should have failed, so as
to reach the maximum credits for each of those metrics. As can be seen
there are a number of possible permutations.
170 Cloud Computing

12.9 Key points
Practical tip
A customer should consider including a termination entitlement with

regards to particularly bad service level failures. How bad will always
be a matter for negotiation.
12.8 Standardized SLAs?

There are some efforts to produce standard documentation (or at least
standard terminology) for SLAs. In 2014 a European working group, the
Cloud Select Industry Group – Subgroup on Service Level Agreements, set
up by the European Commission, prepared ‘standardisation guidelines’
for SLAs.130 We discuss these further in Chapter 16.
12.9 Key points

In this chapter we have explored service levels. Key points are as follows.
◆ SLAs are an important part of the overall contract and should always
be carefully reviewed. They operate as an objective and measurable
standard to which the service will be provided.
◆ There are usually consequences for the provider missing those
standards, often the provision of credits against fees. These service
credits are normally said to be the sole remedy a customer has
(preventing an additional claim for damages), but may often,
however, be capped. The caps can sometimes be surprisingly low (as
low as 10 per cent). Once the cap is reached, there are often no
further financial consequences for the provider in failing to provide
the service to the appropriate level, although there will obviously be
increasing loss of customer goodwill.
◆ In a typical cloud solution, the ‘availability’ service level is the most
important measure. Care is needed on how ‘available’ is defined
when use by the customer might be over many different sites (and
from perhaps many different provider ‘instances’ of the service).
Another issue that needs care is the period of time over which
service availability is measured.
◆ Target levels are aspirational; contractual levels have consequences.
◆ A customer should be wary of the provider seeking to reserve the
right to amend the levels in the future.
◆ An attractive sounding level of availability needs to be considered in
the context of the exceptions contained in the contract. Force
majeure provisions can sometimes be very widely drawn. Another
130
Cloud Select Industry Group – Subgroup on Service Level Agreements. ‘Cloud Service Level
Agreement Standardisation Guidelines’ [66].
Cloud Computing 171

12 Service levels
point for particular scrutiny is how the SLA deals with inabilities to
provide services due to the fault of subcontractors. If the cloud
provider is largely reliant on another provider (say, one of the major
PaaS or IaaS providers), then there are probably few availability
issues that are not the fault of one of those providers.
◆ Obligations to monitor and report need to be clearly allocated.
Downtime of a service sometimes does not count as ‘unavailability’
for the purpose of credits until the customer has reported the fault.
The processes around measurement and crediting are often complex.
Generally, providers do not wish to make it easy for customers to
earn credits.
◆ For repeated failures, or particularly serious isolated failures, to meet
service levels, a customer might consider seeking a right to
terminate. As the service credit regime is often expressed to be the
sole remedy for service level failures, the contract’s general provision
allowing for termination on certain types of breach may well not
apply. Tailored provisions should be negotiated.
172 Cloud Computing

13 Liability issues
13.1 Introduction
Cloud contracts, like any contract, can go wrong. There are many types of
breaches that could occur in the cloud. There could be a lack of service
availability. There could be problems with the functionality (bugs in the
underlying software) so that wrong data is served up or calculations are
incorrect. There may also be breaches of security so that the privacy of
the customers’ data is compromised or valuable trade secrets are lost.
When any of these breaches occur, a customer can suffer losses and,
subject to the terms of the contract, can seek to recover compensation
for its losses from the provider. The calculation of the amount
recoverable in court is based on the innocent party being entitled to be
put in the same position it would have been in had the contract been
properly performed. The loss that a user of a cloud service might suffer
can easily become significant.
Given the multi-tenancy aspect of the typical cloud solution, if one

customer suffers a breach of contract (such as a security breach) so, too,
will many, if not all, of the other customers. As such, a breach of contract
followed by many damages claim(s) could be fatal for the provider
without the protection of wide-ranging exclusions and limitations,
perhaps more so than in other outsourcing and managed services
arrangements. Whilst a customer may well complain about needing to
have the stick of large damages claims in order to incentivize the
provider to perform diligently, a provider may remind the customer that
there are other factors that operate as incentives, in particular, the
reputational damage to the provider if it is seen to breach the
agreement or to not take its obligations seriously. Word will quickly
spread if there are significant issues regarding contractual performance
(especially given the possibility of multiple customers being affected), and
this will be a big incentive to perform.
Nonetheless, most cloud providers (like the remainder of the IT industry)

will seek to exclude or limit liability for breach of contract. There are,
broadly, two tools a provider will bring to bear to limit its exposure. First,
it will make its obligations less than absolute by, for example, not
guaranteeing all round availability (as mentioned in 12.1, some providers
state in their SLAs that availability is only ‘as is’), nor giving an absolute
assurance that the software is bug free and/or will work, and so on.
Timescales will seldom be absolute; the provider will normally volunteer
Cloud Computing 173

13 Liability issues
that it will ‘use reasonable endeavours’ to undertake particular tasks by a

particular time. Security will be ‘reasonable’ or ‘appropriate’, and, as
such, a breach of security will not necessarily be a breach of contract. In
relation to availability, the provider will have set out its obligations in an
SLA (see Chapter 12). This type of language is designed to reduce the
chances of the provider actually being in breach (even when, from the
viewpoint of the customer, the service is not fulfilling its needs).
Secondly, and normally in addition to the first tool, the provider will seek
to include contractual language excluding certain legal rights that would
normally arise for the benefit of the innocent party, that is, excluding
certain losses or limiting liability for losses. A standard liability provision
will include two parts: an absolute exclusion of certain types of losses
(sometimes called indirect or consequential) and a cap on the liability of
other (direct) losses, which then remain recoverable up to that cap. Great
care is always needed on the part of the customer as it is not uncommon
for a provider to attempt to include within a list of losses, which have
the appearance of ‘indirect’ losses, certain categories that might
ordinarily, under general legal principles, be deemed ‘direct’ losses. It is
not unknown for the ‘cap’ provision to have nothing really left to apply
to, as all conceivable losses have in fact already been excluded by what is
called the ‘consequential loss’ provision.
Practical tip
A customer should be aware that, whilst it may be considered

standard and not (necessarily) unreasonable for certain types of
losses, such as ‘indirect’ losses, to be excluded, the precise language
may be widened to include within the exclusion losses that might,
under ordinary legal principles, be considered ‘direct’ losses (such as
loss of data).131
Whatever the responsibility accepted by the provider, any contractual

protection for the customer is only as good as the financial worth of the
provider. If the provider is a start-up, has little by way of assets or
substance, and subcontracts most of its offering, then that may not be
the most suitable provider for a customer to use when outsourcing a
critical part of its IT requirement.
13.2 Exclusions of liability

Certain types of losses are normally excluded in entirety in all contracts.
131
See also the practical tip in 3.8.4.
174 Cloud Computing

13.3 Limitations of liability
The first type are economic losses such as loss of profit or revenue, or loss
of opportunity. This is intended, amongst other things, to prevent
recovery of damages related to the inability of the cloud customer to
carry on business if the service’s failure (whether through unavailability
or simply incorrect functioning) prevents it from doing so. If the cloud
offering, for example, is related to providing the ability to trade, then
trades that go wrong (profits that do not get made or losses that are not
avoided) because the service failed will not be recoverable. Secondly, and
more controversially, certainly in the cloud context, a provider may
attempt in these clauses to exclude losses around data. Issues around
liability for data are discussed in 3.8.4.
13.3 Limitations of liability

Any losses that are not excluded completely will inevitably be subject to
contractual language under which the provider attempts to limit liability.
There are many ways of structuring this but they all have one overriding
objective – to put an absolute cap on the liability that the provider may
have for breaching the contract. If the customer suffers losses above that
cap, it can only recover the amount of the cap (to the extent it can prove
under normal contract law principles the amount and the link between
the loss and the breach). A rule of thumb has emerged that providers of
IT services, hardware or software, will cap any liability that is accepted, at
the value of the contract. The rationale is that it should not accept any
risk over the benefit to it of the particular contract (i.e. the value or price
paid). What the ‘value’ is for this purpose can be drafted in a number of
ways. The total liability over the life of the contract could be limited to
the total amount paid over the full term. Alternatively, liability caps can
operate on an annual basis so that in any year it can be limited to the
amount paid in that year.
Practical tip
Customers should always bear in mind that the figure set out in
limitation of liability provisions is not an entitlement or an indication
of the amount that will be obtained as a result of breach, only the
maximum amount that could be claimed. A customer will still have to
prove that there was a breach and that it caused the loss. It will also
have to prove the amount of the loss that is suffered.
Moreover, the SLA will normally state in any case that liability for
non-availability is only for the provider to pay the appropriate service
credit (subject to all the exclusions in that SLA).
Cloud Computing 175

13 Liability issues
13.4 Chains of liability

A cloud provider that acquires components of its offering from another
provider will not want to accept liability caused by that provider. For
example, a SaaS provider that has built its offering upon the platform or
infrastructure of a large supplier, such as Google or Amazon, will not
want to accept liability for problems that are ultimately caused by its
supplier. It is unlikely to have the same negotiating power with such
giants as its customer may have with it. The provider, therefore, needs to
strike a balance between the liability it can accept with regards to
customers for failure and the rights it has in relation to its suppliers. This
issue can be dealt with by the provider in a number of ways. First, the
liability under the contract can be capped at a very low limit, perhaps
reflecting the value of the contract to it. If the provider can then
negotiate a ‘value’ cap with its suppliers, there should be approximate
correlation. Secondly, the issue might be dealt with by an express
exclusion of liability, stating that the supplier accepts no liability for
losses caused by its suppliers. Such an approach could be wrapped up in a
‘force majeure’ clause (see also 12.5.1).
Practical tip
A provider building its offering upon other cloud services will need
to take a consistent approach in its contracts with customers. It needs
to ensure that, where appropriate, it can pass liability onto its own
suppliers.
13.5 Statutory and judicial control on liability

exclusions
In the UK, contractual clauses that seek to exclude or restrict liability are
subject to statutory control. There are two principal laws: the Unfair
Contract Terms Act 1977 [5] (UCTA), which applies to both business
contracts and consumer contracts, and the Unfair Terms in Consumer
Contracts Regulations 1999 [46] (the ‘Regulations’), which apply to
consumer contracts only. A cloud provider preparing standard terms of
business will need to be aware of these statutes and take them into
account in its drafting.
13.5.1 Unfair Contract Terms Act 1977

In short, UCTA [5] restricts the ability of a party, when contracting on its
own standard terms or with consumers, from excluding or limiting
liability. In such situations, any attempt to exclude liability for breach of
176 Cloud Computing

13.5 Statutory and judicial control on liability exclusions
contract by the provider would be subject to a so-called ‘reasonableness’

test. The reasonableness test is whether the term is ‘a fair and reasonable
one…having regard to the circumstances which were, or ought
reasonably to have been, known to or in the contemplation of the
parties when the contract was made’ [UCTA, s.11(1)]. The courts have
applied a number of guidelines in judging what is reasonable, including
such considerations as whether an inducement was offered to agree the
limit, whether the parties had taken legal advice, the relative bargaining
power of the parties, and the availability of insurance.
Practical tip
A cloud provider must be prepared to justify any limitation or

exclusion of liability as ‘reasonable’. Any complete exclusion of
liability in relation to a cloud service for which the customer pays
may well fall foul of this test, and a provider has to be prepared to
accept some liability.
13.5.2 Unfair Terms in Consumer Contracts Regulations

1999
The Regulations [46] complement UCTA [5]. They only apply to terms in
contracts between a seller or supplier and a consumer (and not
business-to-business contracts). For the purpose of the Regulations, a
supplier is defined as ‘any natural or legal person who, in contracts
covered by these Regulations, is acting for purposes relating to his trade,
business or profession’ [Regulations, reg. 3(1)] and a consumer is defined
as someone who ‘is acting for purposes which are outside his trade,
business or profession’ [Regulations, reg. 3(1)]. The definition of
consumer was at issue in the case Overy v Paypal (Europe) Ltd132 In Overy,
the claimant was a photographer who devised a competition for which
contestants paid for the chance to win his house. He entered into an
agreement with the defendant for the provision of electronic payment
services. The defendant later suspended the service and the claimant
commenced breach of contract proceedings. The defendant sought to
rely on the express provisions in the contract referring to its Acceptable
Use Policy, which prohibited use for gambling activities. It was held that
the claimant could not rely on the Regulations for protection as, even
though the purpose of collecting competition payments was outside ‘his
trade, business or profession’, he had also intended to use the account to
facilitate payments for his photography business. The claimant was
therefore not a consumer for the purpose of the Regulations.
132
[2012] EWHC 2659 (QB). See: http://www.bailii.org/ew/cases/EWHC/QB/2012/2659.html
Cloud Computing 177

13 Liability issues
A term is regarded as ‘unfair’ if it has not been individually negotiated

and causes a significant imbalance in the positions of the parties to the
detriment of the consumer in a way that is contrary to the requirements
of good faith [Regulations, reg. 5(1)]. The Regulations contain an
‘indicative and non-exhaustive list’ of terms regarded as unfair, a number
of which may be particularly relevant to cloud providers [Regulations,
Schedule 2]. Any clause authorizing the supplier to terminate the
contract at will where the same ability is not granted to the consumer,
and any clause allowing the supplier of services to increase the price
without giving the consumer the corresponding right to cancel the
contract will both be unfair.
Any clause that inappropriately excludes or limits the legal rights of the
consumer in the event of inadequate performance by the supplier of any
of the contractual obligations is unfair. Any attempt at excluding liability
in entirety for lack of service availability will be within this prohibition.
Of course, the key word is that the attempt at exclusion needs to be
‘inappropriate’ and it is not always necessarily unfair to do so, certainly
when the service is made available to a consumer for free. In Overy it
was noted that, although the terms in question did seek to exclude or
limit liability under UCTA, they did fulfil the requirement of
reasonableness.
13.5.3 Attacks on suppliers’ standard terms

Given the prevalence of fairly aggressive limitation of liability provisions,
often in small print, in suppliers’ terms, it is not surprising that these
provisions feature in many reported court decisions relating to disputes
following various IT supply agreements that have somehow gone wrong.
The issue typically arises when a customer sues the provider for breach of
contract (the system did not work) and the provider (as well as denying
liability) then tries to rely on its contractual documentation to limit its
exposure. The pendulum has swung back and forth over the past 15 years
or so between judicial intervention, readily finding that supplier liability
provisions were unreasonable in order to protect the ‘small’ customer,
and a more permissive attitude recognizing that the parties themselves
are the best-placed entities to decide what is reasonable or not. At
present, the pendulum is in favour of the supplier, perhaps permanently
so.
We summarize some of the notable cases in the IT field. In the first few,
clauses were repeatedly struck down. In Salvage Association v CAP
Financial Services Ltd,133 the contract was valued at £300,000 but
contained a clause limiting CAP’s liability to £25,000. The parties were of
equal bargaining power and had taken legal advice. However, it was
found that the clause was nonetheless unreasonable and therefore
133
[1995] FSR 654.
178 Cloud Computing

13.5 Statutory and judicial control on liability exclusions
invalid. As a result, CAP’s liability was unlimited. The court was swayed by
a number of factors, including that CAP had no evidence to justify the
£25,000 limit in relation to the value of the contract or the financial risk
taken by Salvage Association. CAP also had insurance, which Salvage
Association could not easily obtain. In St Albans City and District Council
v International Computers Limited,134 the contract contained a clause
limiting International Computers Limited’s (ICL’s) liability to the lesser of
the price or charge payable or £100,000. This clause was held to be
unreasonable. Again, one of the factors taken into account, importantly,
was that ICL could not justify the cap of £100,000, as well as the
insurance position (a public sector body would find it hard to insure
against commercial risks). In Pegler Ltd v Wang (UK) Ltd,135 the court
found it was unreasonable to rely on fairly standard exclusion of loss of
profit liability when the supplier ‘had so misrepresented what they were
selling that breaches of contract were not unlikely’. In Horace Holman
Group Ltd v Sherwood International Group Ltd,136 a standard ‘price paid’
liability cap was struck down as being unreasonable.
All the cases just mentioned were very much in favour of the customer;
clause after clause was struck down on the basis of an assessment by the
courts that the terms were unreasonable. The tide turned in favour of
the providers in 2001 with Watford Electronics Ltd v Sanderson CFL Ltd.137
The contract excluded liability for consequential loss and contained a
‘price paid’ limitation for other losses. The Court of Appeal upheld the
clauses, stating that when parties of an equal bargaining power
negotiate a contract so that the risk falls on one particular party, the
courts should be ‘cautious’ about saying that a term is not reasonable.
This was such an important turning point in the application of UCTA [5]
to business cases, and a marked departure from the earlier judicial
interventionism, that it is worth quoting one of the more important
passages in the judgment:
134
135
[2000] 137. See: http://www.bailii.org/ew/cases/EWHC/TCC/2000/137.html
136
137
Cloud Computing 179

13 Liability issues
Where experienced businessmen representing substantial companies

of equal bargaining power negotiate an agreement, they may be
taken to have had regard to the matters known to them. They
should, in my view be taken to be the best judge of the commercial
fairness of the agreement which they have made; including the
fairness of each of the terms in that agreement. They should be
taken to be the best judge on the question whether the terms of the
agreement are reasonable. The court should not assume that either is
likely to commit his company to an agreement which he thinks is
unfair, or which he thinks includes unreasonable terms. Unless
satisfied that one party has, in effect, taken unfair advantage of the
other – or that a term is so unreasonable that it cannot properly
have been understood or considered – the court should not interfere.
As a result of this decision, cloud providers should be more confident

that their clauses should survive scrutiny.138
Practical tip
A cloud provider must be prepared to justify any limitation or

exclusion of liability as ‘reasonable’; and pegging the cap on liability
for direct losses to the value of the contract is one approach that
should work.
13.5.4 The danger of overselling

A 2010 case, BSkyB Ltd v HP Enterprise Services UK Ltd (formerly
Electronic Data Systems Ltd),139 has introduced another possible element
of attack. If a supplier deliberately oversells its product when it knows it
will not do what the customer wants, it will be hard for it to rely on
protective contractual language. BSkyB engaged Electronic Data Systems
Ltd (EDS) to build a customer relationship management system. The
contract had a value of £47.6 million and contained a limitation of
liability clause that capped EDS’ liability at £30 million. EDS never
delivered and BSkyB ended up building the system itself and sued EDS for
£706 million of losses. The customer (BSkyB), which suffered substantial
losses, could not attack the limitation language on the basis of UCTA [5],
as the contract was not on the standard terms of the supplier. It
successfully brought a claim for ‘fraudulent misrepresentation’ as one of
its managing directors had made statements to BSkyB that he knew were
false, or at the very least was reckless as to whether they were true or
138
Clauses can still fail, however. In Kingsway Hall Hotel Ltd v Red Sky IT (Hounslow) Ltd
[2010] EWHC 965 (TCC), the High Court struck down a fairly typical exclusion clause. See:
http://www.bailii.org/ew/cases/EWHC/TCC/2010/965.html
139
[2010] EWHC 86 (TCC). See: http://www.bailii.org/ew/cases/EWHC/TCC/2010/86.html
180 Cloud Computing

13.6 Key points
not. These statements included confirming that EDS had fully scoped the
work and that the timescales were realistic, even though it had not
carried out any supporting analysis. The £30 million cap on liability was
of no assistance to EDS as it expressly did not apply in the event of fraud.
Once liability was determined, the parties agreed a figure for damages of
£318 million.
It is a salutary reminder to suppliers not to over-promise in the tender

process, as such promises can lead to liability even if they are not then
confirmed in a written contract.
13.6 Key points

In this chapter we explored the issue of provider liability and contractual
exclusions. Key points are as follows.
◆ Any service contract produced as a standard form by a provider

(cloud or otherwise) will contain exclusions and limitations on
liability. The nature of a cloud service is that if there is a failure of
the service many customers are likely to be affected. Losses that are
suffered by users could (if they were passed on to providers) be
concentrated to levels jeopardizing the existence of the provider.
◆ Liability is limited in a number of ways. First, service credits are
sometimes said to be the sole remedy for failure. Secondly,
obligations are often not absolute but qualified by a requirement to
use ‘reasonable’ efforts, so that there is only liability if that standard
is not met. Thirdly, the type of loss that can be recovered if there is
liability under these types of reduced standards is then limited to
certain types of losses (losses such as ‘indirect’ losses or perhaps ‘loss
of data’ being excluded). Lastly, the damages that are not so
excluded are then capped at a particular financial level.
◆ Any contractual protection for the customer is only as good as the
financial worth of the provider. A customer outsourcing the custody
of valuable data needs always to be aware of the financial and
organizational substance of its chosen cloud provider.
◆ When much of the offering is subcontracted by the provider, it needs
to strike a balance between the liability it can accept with regards to
customers for failure and the rights it has in relation to its suppliers.
◆ A cloud provider preparing standard terms of business will need to
be aware of statutory controls on exclusion clauses. In the UK, UCTA
[5] requires terms to be reasonable and the Unfair Terms in
Consumer Contracts Regulations 1999 [46] requires (when dealing
with consumers) terms to be fair.
◆ The latest court decisions indicate that (certainly in
business-to-business contracts) there will be little scope for attacking
terms on the above grounds unless they are particularly
unreasonable. Nonetheless, it is likely that some liability should be
Cloud Computing 181

13 Liability issues
accepted when the service is not a free one; and as a rule of thumb
pegging the level to the value of the contract should work.
182 Cloud Computing

14 Specific sectors
14.1 Introduction
Up to this point we have considered cloud services in a general sense;
customers acquiring them could be in any sector. Many customers, of
course, operate in sectors where there exist specific regulatory
frameworks in relation to their activities, and these frameworks may
contain legal requirements relevant to a specific cloud deployment.
In this chapter we consider the legal consequences that arise from certain
specific sectors: financial services, cloud services in the public sector and
cloud services provided to consumers.
14.2 Financial services

14.2.1 Introduction to the regulatory regime
The financial sector, of course, is heavily regulated and there are a
number of international requirements that are required to be fulfilled by
those operating in that sector, both substantive legal requirements and
requirements imposed by regulators such as the Financial Conduct
Authority (FCA) and the Prudential Regulation Authority (PRA).140 The
legal framework in the UK is primarily under the Financial Services &
Markets Act 2000 (FSMA) [44]. Under section 19 of the FSMA, any person
who carries on a regulated activity in the UK must be authorized by the
FCA and/or the PRA (unless they are exempt). It is a criminal offence not
to be.
Banks authorized by the PRA and investment firms authorized by the FCA
are required to comply with rules in respect of outsourcing ’critical or
important’ operational functions, which implement requirements under
the EU’s Markets in Financial Instruments Directive [47] (MiFID). There are
140
On 1 April 2013, the majority of the functions of the FSA under the Financial Services and
Markets Act 2000 [44] were transferred to the FCA and the PRA. Banks and insurers are
now authorized by the PRA, while most other firms formerly authorized by the FSA are
now authorized by the FCA. PRA-authorized banks and insurers are also subject to certain
conduct of business regulations by the FCA and are considered ‘dual regulated’ to that
extent.
Cloud Computing 183

14 Specific sectors
no specific requirements on the topic of cloud services, but those rules

that apply to outsourcing generally are certainly wide enough to cover
the relevant cloud services.
14.2.2 Generally applicable rules – FCA ‘Principles for

Businesses’ and PRA ‘Fundamental Rules’
The FCA and PRA rules include sets of ‘High Level Standards’ that apply
generally to their respective authorized firms. These are set out in the
FCA Handbook [42] in the ‘Principles for Businesses’ and in the PRA
Rulebook [43] in the ‘Fundamental Rules’. These ‘High Level Standards’
and certain specific rules may have application to the cloud.
In particular, all FCA-regulated firms have an obligation to manage their

affairs in accordance with Principle 3 (‘Management and control’), which
requires the firm to ‘take reasonable care to organise and control its
affairs responsibly and effectively, with adequate risk management
systems’ [42]. Similarly, a PRA-regulated firm is subject to Fundamental
Rule 5, which requires it to ‘have effective risk strategies and risk
management systems’, and Fundamental Rule 6, which requires it to
‘organise and control its affairs responsibly and effectively’ [43].
There is also an extremely general and all-pervasive principle on the

relationship with regulators (FCA Principle 11 and PRA Fundamental Rule
7), which requires the regulated firm to ‘deal with its regulators in an
open and cooperative way, and…disclose to the…regulator…anything
relating to the firm of which that regulator would reasonably expect
notice’ [42]. Guidance from the FCA requires the firm to take reasonable
steps to ensure that a similar obligation on co-operation is imposed upon
any service provider to which a material aspect of the firm’s function has
been outsourced. This will include the provision of data and information.
Moreover, FCA guidance on Principle 11 and the PRA ‘Notification’

rules141 state that if an outsourcing is material (defined to be of such
importance that weakness, or failure, of the services would cast serious
doubt upon the firm’s continuing compliance with the rules), the
regulator should be informed of the outsourcing.
There are other, more specific, rules that impact upon a firm’s ability to
outsource any aspect of its function. None focuses on cloud services, but
there are requirements focused on outsourcing generally, mostly set out
in different parts of the ‘Senior Management Arrangements, Systems and
Controls’ (SYSC) sourcebook. Important general systems and controls rules
in this sourcebook include, for all firms apart from insurers, the Society of
Lloyd’s, Lloyd’s managing agents, and full-scope UK alternative
141
FCA Handbook [42], SUP 15.3.8G(1)(e); PRA Rulebook [43], Notification 2.3(1)(e).
184 Cloud Computing

investment fund managers (AIFMs) of unauthorized alternative

investment funds (AIFs), SYSC 4.1.1R(1):
A firm must have robust governance arrangements, which include a

clear organisational structure with well defined, transparent and
consistent lines of responsibility, effective processes to identify,
manage, monitor and report the risks it is or might be exposed to,
and internal control mechanisms, including sound administrative and
accounting procedures and effective control and safeguard
arrangements for information processing systems.
and, for insurers, the Society of Lloyd’s and Lloyd’s managing agents,
SYSC 3.1.1R:
A firm must take reasonable care to establish and maintain such

systems and controls as are appropriate to its business.
14.2.3 Banks, building societies and investment firms

Certain FCA- and PRA-regulated financial institutions [referred to in the
SYSC as ‘common platform firm[s]’ (SYSC 8.1.1R),142 which include banks,
building societies and investment firms] are obliged to comply with the
rules set out in the outsourcing provision of the SYSC, Section 8.1. Certain
other regulated firms (not ‘common platform firm[s]’) should have regard
to these provisions as if they were guidance rather than rules.
SYSC 8.1 focuses on the outsourcing of operational functions that are

‘critical or important’ (these terms are probably alternatives; although
both are used, there is not thought to be any difference in their
meaning).143 These are functions where a defect or failure in
performance would materially impair:
• the continuing compliance with the conditions and obligations of the

firm’s FCA or PRA authorization; or
• its other obligations under the regulatory system; or
• its financial performance; or
• the soundness or the continuity of its relevant services and activities.
Where a function that is to be outsourced to a cloud provider is ’critical

or important’, it should be noted that there is no prohibition on
engaging that cloud provider, only a requirement to take additional care.
SYSC 8.1.1R stipulates that the firm, when engaging a provider (cloud or
otherwise) to provide a service that is critical or important, should take
‘reasonable steps to avoid undue additional operational risk’ [SYSC
142
These include firms subject to the Capital Requirements Directive [48] (CRD) or MiFID [47],
or both.
143
Indeed, there is probably no difference between these terms and the term ‘material
outsourcing’ used elsewhere in the rules.
Cloud Computing 185

14 Specific sectors
8.1.1R(1)]. It should also not engage that provider in such a way as to

impair materially the quality of the firm’s internal controls and the ability
of the FCA or PRA ‘to monitor the firm’s compliance with all obligations
under the regulatory system’ [SYSC 8.1.1(R)(2)].
Some typical cloud services may well be automatically deemed not to be

critical or important as a result of SYSC 8.1.5R, paragraph (2), which reads
‘the purchase of standardised services, including market information
services and the provision of price feeds’. The full width of the term
‘standardised’ may lead to surprising consequences. Most cloud services
are indeed standardized (in that they are not tailored for a particular
customer) and that is true for both SaaS and IaaS solutions. We come
back to this in 14.2.4.
If the cloud provision is a ’critical or important’ function then other parts

of SYSC 8.1 need to be considered. SYSC 8.1.7R requires a common
platform firm to ‘exercise due skill and care and diligence when entering
into, managing or terminating any arrangement for the outsourcing to a
service provider’ of such a function. SYSC 8.1.8R elaborates and sets out a
number of more specific tasks, some of which, in reality, are no more
than sensible commercial provisions that any customer would want to put
in place, as follows.
• The firm must ensure that the service provider has the ‘ability’ and
‘capacity’ to perform the services ‘reliably and professionally’.
• It must put in place ‘methods for assessing the standard of
performance of the service provider’ and ‘properly supervise’ the
performance.
• It is required to take ‘appropriate action…if it appears that the
service provider may not be’ performing.
• It should contain in the contract an obligation to ensure that ‘the
service provider…disclose[s] to the firm any development that may
have a material impact on its ability to carry out’ the services
properly.
• The firm should have regard to exit arrangements (to ensure that the
provision can be terminated ‘without detriment to the continuity and
quality’ of its servicing of its own clients).
• The service provider should be obliged to protect confidential data.
• The firm (with the service provider) needs to maintain disaster
recovery plans and backup facilities.
Lastly, SYSC 8.1.9R requires a written contract to be entered into.
14.2.4 FCA-regulated investment firms using cloud services

Many of the SYSC 8.1 requirements that have just been summarized are
what a well-advised and prudent cloud customer would be doing in any
case: undertaking due diligence in relation to the provider’s ability,
186 Cloud Computing

monitoring and reporting, exit planning and so on. This should be done
by any (even non-regulated) customer.
Some provisions might present more difficulty. In particular, the firm is

required to ensure that the service provider co-operates with the FCA
and it is hard to see how the average cloud provider (certainly a non-UK
provider) would agree to co-operate with the FCA. Likewise, the firm is
also required to ensure that it, its auditors, the FCA and other EEA
regulators have effective access to data and audit rights. As such, any
FCA-regulated firm outsourcing ‘critical or important’ functions to the
cloud would need to get assurances from the cloud provider that the
data and the provider’s premises can be appropriately accessed.
It is therefore important (if the cloud provider cannot or will not grant
such access rights) for a customer to determine whether a cloud service is
not ‘critical or important’. This topic is addressed in industry guidelines
from 2007. MiFID Connect is a grouping of UK trade associations set up
to advise its members on compliance with MiFID [47] generally. In 2007, it
produced guidelines on outsourcing [49], which were sanctioned by the
then FSA [the FSA (and presumably, now, the FCA) said that it would take
these guidelines into account when exercising its regulatory functions].
This document states that the following are likely to constitute
outsourcing within the rules, and potentially (although not definitely)
outsourcing of critical or important functions:
d) Provision of data storage (physical and electronic);

e) Provision of ongoing, day-to-day systems maintenance/support;
and
f) Provision of ongoing, day-to-day software/systems management
(e.g. where third party carries out day-to-day functionality and/or
runs software or processes on its own systems) [49].
All of these functions could be acquired through the cloud. Whilst they
are potentially critical or important, the same guidelines also state that
‘where the outsourced function is only one of many ways in which the
service…can be provided…[it would] not be considered critical where a
failure in relation to one…[way] would not affect the firm’s ability to’
operate [49]. Thus, if data storage is acquired as a cloud service, it would
be critical or important if the firm were using that service provider only,
but not (or at least not necessarily so) when it is merely one of a number
of storage solutions (say, for backup).
Cloud Computing 187

14 Specific sectors
Practical tip
Financial services firms need to consider whether a particular cloud

service is, or may be, ’critical or important’. If so, or if there is doubt
as to whether it might be, the additional controls set out in SYSC 8
should be applied, including by means of appropriate contractual
language.
In particular, they will need to ensure that they obtain assurances

from the cloud provider to co-operate with the FCA and to give
access to data.
Lastly, any acquisition of a cloud service (of a critical or important

type) leads to an obligation to inform the FCA.
14.2.5 Insurance companies

Insurance companies are authorized by the PRA and dual regulated by
the FCA and the PRA for conduct of business purposes; however, they are
not subject to the SYSC rules for common platform firms, which include
the outsourcing rules in SYSC 8.1. Instead, they are subject to separate
systems and controls rules and guidance in the SYSC, including the
guidance in SYSC 13 (‘Operational risk: systems and controls for insurers’),
and, in particular, SYSC 13.9, on outsourcing. SYSC 14 (‘Risk management
and associated systems and controls for insurers’) is also relevant.
SYSC 13 provides guidance to insurers in relation to their systems and

controls for managing risks concerning any of their operations, including
their IT systems. Whilst much of the guidance is relevant to outsourcing,
there is specific guidance on outsourcing in SYSC 13.9. The guidance
re-emphasizes that an insurer ‘should take reasonable care to supervise
the discharge of outsourced functions’ [SYSC 13.9.1G]. It also restates the
guidance mentioned above that a firm ‘should notify the appropriate
regulator when it intends to enter into a material outsourcing
arrangement’ [SYSC 13.9.2G].
There are recommendations targeted at the pre-contract stage. The

insurer should undertake due diligence in relation to the service provider,
and should consider how the arrangement will fit into its risk profile and
business strategy, paying particular attention to what will happen on
termination of the contract.
As with investment firms outsourcing critical functions, the guidance in

SYSC 13.9 indicates that the insurer should put certain contractual
protection in place. Regard should be had to appropriate monitoring and
to appropriate contractual protection. Again, there should be sufficient
access available to the insurer’s auditors and to the FCA. A SLA is advised,
188 Cloud Computing

14.3 Cloud services in the public sector
and that should contain appropriate performance targets to assess the

adequacy of service provisions. Service delivery should be evaluated
through service delivery reports and periodic self-certification or
independent review by auditors. An insurer should ensure that it has
appropriate business continuity arrangements for the possibility of a loss
of services.
The guidance expressly recognizes that an insurer may find it beneficial

to use externally validated reports commissioned by the service provider,
to seek comfort as to the adequacy and effectiveness of its systems and
controls (see 3.5 and 3.6). Nonetheless, the use of such reports will not
absolve the insurer of responsibility nor remove the need to have its own
right to access premises.
SYSC 14 requires an insurer to take reasonable steps to have an adequate

risk management system, to document its policy for operational risk and
how it monitors and controls that risk, and to have in place adequate
internal controls.
14.2.6 Insurers using cloud services

Insurers have greater leeway to enter into a cloud service than banks,
building societies and investment firms. Whilst the latter have to comply
with mandatory rules in relation to critical or important functions,
insurers, when outsourcing, are required only to have regard to the
relevant guidance – it is less prescriptive. Nonetheless, the same
difficulties that were mentioned for investment firms, in relation to
preserving access rights for both the customer and the regulator, would
exist here.

Coupled with intense cost-saving to deal with budget deficit reductions,
the UK government has been at the forefront of seeking to save IT
expenditure. The Digital Britain Final Report [50] of 2009 contained a call
that ‘all those Government bodies likely to procure ICT services should
look to do so on a scalable, cloud basis…’, and gave the cloud
momentum additional credibility. Government should share in the
well-known benefits of cloud computing: adopting cloud computing, the
report said, ‘substantially cuts hardware and application costs and allows
much more rapid product and service innovation’. Indeed, given the size
of the public sector IT spend, a major adoption of cloud technologies
(perhaps more of the ‘private cloud’ type) can be expected in the near
future.
Cloud Computing 189

14 Specific sectors
In 2013, the UK government went further and adopted a ‘Cloud First’

policy. Public sector buyers of IT products and services should first
consider cloud offerings. This is mandatory for central government and
‘strongly recommended’ for other public authorities.144 Purchasers need
not take up cloud services, but if they do not they will be expected to
demonstrate that the alternative offers better value for money. It is still
early days, but the government hoped that formal introduction of this
policy would drive a bigger take-up of cloud services by public
authorities. The government also hoped that this would boost business
by leading to savings.
The UK government created a marketplace for the adoption of cloud

services called ‘CloudStore’. Various suppliers were invited to participate
in a tendering exercise as part of a government cloud initiative (called
G-Cloud). Those meeting the relevant criteria were then listed on the
store, allowing the public sector to then contract with the suppliers. A
negotiation, though, might also be appropriate, but the hope is that
savings would arise.
There have been a number of different tendering exercises, resulting in

different G-Cloud frameworks (Gi, Gii, Giii, G4 and G5 up to the time of
writing).
In late 2014, the CloudStore was replaced by the ‘Digital Marketplace’.
The UK public sector is not alone here in looking for cloud-inspired

savings in IT.
The US public authorities have adopted cloud services with perhaps more
fervour than the UK. In July 2014, Unisys announced that the state of
Pennsylvania had signed a $681 million hybrid cloud services contract,
one of the biggest public sector cloud contracts seen.145 The contract
would unify the state’s data centres and allow greater flexibility. There
have been other similarly sized US public sector deals.
Most legal issues around cloud adoption apply equally in the public
sector as they do in the private sector. Public entities need to worry
about service levels, service descriptions/changes, information security and
so on just as much as entities in the private sector. One legal issue that
does not arise in the private sector is that of public procurement rules.
A full discussion of the public procurement rules is outside the scope of

this book (reference could be made to the standard texts). Suffice to say
144
See
https://www.gov.uk/government/news/government-adopts-cloud-first-policy-for-public-
sector-it.
145
See
http://www.unisys.com/offerings/cloud-solutions/News%20Release/Commonwealth-of-
Pennsylvania-Selects-Unisys.
190 Cloud Computing

that when a public authority acquires any goods, works or services above
a certain threshold an open (and published) process needs to be
followed. The intention of the rules is to open up the market to
competition throughout Europe. There are separate rules and thresholds
depending on whether the contract is for goods, works or services. Whilst
the acquisition of hardware would be within the ‘goods’ rules, cloud
services (including the acquisition of server capacity as an IaaS) would, if
caught at all, be within the ‘services’ rules, in England and Wales, in the
Public Contracts Regulations 2006 [51] (which implement a directive from
2004).146
The public sector for this purpose includes central government

departments, local government, NHS trusts, police and fire authorities,
national museums, various quangos and so on. The threshold for services
depends on the type of services, divided into different parts of a schedule
to these regulations. Cloud services are likely to be ‘Part A’ services,147
which includes computer and related services, for which the current
threshold is €162,000 (for central government) and €249,000 (for other
public sector bodies).
If a public authority is acquiring IT services with a value above these

thresholds, the process set out in the Public Contracts Regulations 2006
needs to be followed. This process includes: an obligation to advertise
the contract, prescribed rules on the minimum number of tenderers
being invited fully into one of the three alternative processes, and a
requirement for the decision-making process to be transparent. The
public body must award the contract to the tender that has the lower
price or, alternatively, that is the ‘most economically advantageous tender
(MEAT)’ (which can take into account other factors such as quality and
technical aspects). The relative weighting of the MEAT factors needs to
be part of the tender documentation.
One final legal aspect that cloud providers should be aware of: contracts
entered into with public authorities may be subject to the Freedom of
Information Act 2000 [52] (FOIA) and so come into the public domain.
Any person, such as the media or competitors, can submit a request
under the FOIA to a public sector body to disclose the widest class of
information (including contracts that have been awarded and service
reports that have been provided). There are exemptions where the
information is a trade secret or held in confidence, but these are high
thresholds. There are some practical steps that a cloud provider can take
to maximize the chance that one of these exemptions will apply (for
example, to include pricing or proprietary information that is a trade
146
Directive 2004/18/EC of the European Parliament and Council of 31st March 2004 on the
co-ordination of procedures for the award of public works contracts, public supply
contracts and public services contracts.
147
Part B services are those that are likely to be of interest only to suppliers in the same
country as the public authority.
Cloud Computing 191

14 Specific sectors
secret in a separate schedule, clearly labelled as such, and to contractually

require the public authority to consult with the provider). Reference
should be made to the standard texts on the topic. (Some of the US
public sector contracts have already been made public, with full
commercial terms, under the US equivalent of the UK’s FOIA.)
14.4 Consumer cloud

14.4.1 Introduction
Many consumer applications on the internet are cloud services (at least, if
you take the widest meaning of that term). Consumers using such
services as email (e.g. Gmail and Hotmail), social networking sites (e.g.
Facebook) and media-sharing sites (e.g. YouTube and Flickr) are all
entrusting their data to software applications acquired remotely and in a
scalable fashion, and they have no idea at all where the data is. These
are all examples of SaaS. There are also more ‘infrastructure’-like services
available for consumers, such as data backup and storage sites (e.g.
Dropbox), but, to the extent it makes any difference, these, too, are
really best characterized as SaaS, since the consumer is not ‘building’
anything onto the infrastructure.
The consumer, of course, makes a decision about using a cloud service in

a somewhat different way to an enterprise. Concerns such as security
standards, due diligence, service level commitments and the terms of the
contract (which are never negotiable) are not normally in the forefront
of a consumer’s mind. And this is so, even when services are paid for. A
consumer is unlikely to compare, for example, different providers’ stances
on liability or availability issues. A decision will be made on the basis of
functionality, usability of the service and, to a certain extent, fashion and
peer pressure.
In this section we examine a few other legal issues that arise in the
consumer cloud environment. Many of the consumer cloud services allow
a consumer to upload content (perhaps for wider dissemination) and so
one legal issue that arises is whether, and to what extent, a provider
might be held liable for that type of hosting. Next, we look at this
potential liability. In Chapter 13 we looked at liability issues generally
(which arise with a different flavour here), including statutory control
over the extent to which a provider can exclude liability for its own
breach. Lastly, we look at how the data protection rules (covered
extensively in Chapter 4) apply when the provider is selling to consumers.
192 Cloud Computing

14.4 Consumer cloud
14.4.2 Liability of a cloud provider for hosting user

content
Many cloud services (especially those – but not exclusively – targeted at
consumers) involve the provider hosting on the internet content created
or uploaded by the user. In doing so, a cloud provider risks liability for
the actions of its users. In an attempt to shield themselves from liability,
cloud providers will generally have terms (sometimes in a separate
document called an Acceptable Use Policy or AUP) that set out what
customers can do with the service, including an appropriate indemnity (so
that the provider’s liability to a third party is passed back). Nevertheless,
such providers remain a more attractive target for a potential claimant
than the user, who may not have the same level of financial resources
and may be difficult (and possibly impossible) to trace. This section
examines the extent of this potential liability and how it can, in practice,
be avoided.
There are a number of potential liability risks that a cloud provider leaves
itself open to as a result of content put up by its users. In many cases,
European cloud providers will have a general defence under the
Ecommerce Directive [4], which is where we begin.
Many businesses (and, indeed, individuals) are using the threat of liability
arising, on the likes of Facebook, Twitter, eBay and so on, as a means to
have user-generated content that is unacceptable to the complainant
taken down. Websites are often very cautious, not wanting to be forced
to adjudicate on complaints, and so – to the extent they need to make
use of available defences under the Ecommerce Directive148 (which we
come to next) – will take down the content quickly. Many such websites,
in particular, larger US sites, will have automated processes and dedicated
teams.
Defence under the Ecommerce Directive
The Electronic Commerce (EC Directive) Regulations 2002 [54] (the

‘Ecommerce Regulations’) implement the Ecommerce Directive [4] in the
UK. Regulation 19 of the Ecommerce Regulations provides a ‘hosting’
defence available to providers of ‘information society service[s]’, which
will include the type of cloud service being considered here. This
provision states that where a service consists of the storage of
information provided by a user (that is, uploaded content), the service
provider will not be liable where it ‘does not have actual knowledge of
unlawful activity or information’, and ‘is not aware of facts or
circumstances from which it would have been apparent to the service
provider that the activity or information was unlawful’ [Ecommerce
Regulations, reg.19(a)(i)]. Where the provider discovers the unlawful
148
And equivalents elsewhere, such as the US Digital Millennium Copyright Act 1998 [53]
(DMCA).
Cloud Computing 193

14 Specific sectors
activity or information (perhaps as a result of a rights holder informing

it), the provider avoids liability if it ‘acts expeditiously to remove or to
disable access to the information’ [Ecommerce Regulations, reg.19(a)(ii)]
(a so-called, ‘notice and takedown’ process).
There are now quite a few examples of this defence being used in
practice. In Tamiz v Google,149 the court held that Google Inc. was ‘not
liable at common law as a publisher’ in respect of the claimant’s libel
action. Even if this was wrong, the court said that Google Inc. was still
protected against liability by Regulation 19 because it did not have a
sufficient state of knowledge of unlawfulness.
The defence was also examined in another libel case, Kaschke v Gray.150
When considering whether a defendant would be entitled to the
immunity conferred by Regulation 19, the court stated that the question
to be asked was whether the service provided in respect of the
information containing the defamatory words, which would otherwise
give rise to liability, consisted only of, and was limited to, storage of that
information. In this case, it was clear that the defendant exercised some
editorial control over parts of the website where the words appeared,
and so his involvement went beyond mere storage of information. This
was a summary judgment, not a full trial, but the comments are still
useful. The court found there was a realistic prospect that the Regulation
19 defence might fail at trial.
A notification to a service provider does not automatically preclude the

exemption from liability in Regulation 19, given that notifications of
allegedly illegal activities or information may turn out to be insufficiently
precise or inadequately substantiated. The issue is often whether or not
the service provider seeking protection had sufficient ‘knowledge’ of the
unlawful opinion, and this turns often on how much information has
been given to the service provider. In Davison v Habeeb,151 the claimant
had notified Google of a complaint. The court had to consider, amongst
other things, whether Google (one of the defendants) had actual
knowledge of unlawful activity or information, or was aware of the facts
or circumstances from which it would have been apparent to it that the
activity or information was unlawful. The court held that there was no
realistic prospect of the claimant establishing that her notification of her
complaint was sufficient for these purposes. That was not, of course, to
say that a different conclusion could not be reached on different facts,
such as where a complaint was sufficiently precise and well substantiated,
and where there was no attempt by the author of the defamatory
material to defend what had been written.
149
[2012] EWHC 449 (QB). See:
http://www.bailii.org/cgi-bin/markup.cgi?doc=/ew/cases/EWHC/QB/2012/449.html
150
151
194 Cloud Computing

14.4 Consumer cloud
Regulation 19 derives from Article 14 of the Ecommerce Directive and the

wording of this article has been considered by the CJEU (Grand Chamber)
in L’Oréal SA v eBay International AG.152 The Grand Chamber held that it
was:
sufficient, in order for the provider of an information society service

to be denied entitlement to the exemption from liability provided
for in Article 14…, for it to have been aware of facts or
circumstances on the basis of which a diligent economic operator
should have identified the illegality in question and acted in
accordance with Article 14(1)….153
There is some guidance as to ‘actual knowledge’ in Regulation 22 of the

Ecommerce Regulations, which includes whether the service provider has
received a notice with, amongst other things, ‘details of the unlawful
nature of the activity’ [Ecommerce Regulations, reg. 22(b)(iii)]. In Bunt v
Tilley,154 the judge said that ‘in order to be able to
characterise…[information] as “unlawful” a person would need to know
something of the strength or weakness of available defences’. This view
was endorsed in Kaschke v Gray, referred to above.
Practical tip
A cloud provider allowing users to upload content should reserve the

right, under its contract, to remove that content in certain
circumstances (such as when a complaint arrives).
It should also ensure that, in the contract, the user indemnifies the
provider in relation to any liability.
As mentioned, this process is a general provision applicable to many

different types of potentially unlawful activity. We now consider some
specific types of potential liability for consumer content.
Copyright infringement
If content is uploaded into a cloud service, the copyright of which is not

owned by the user, the provider will also potentially be infringing
copyright.155
152
Case C-324/09, 12 July 2011.
153
Paragraph 120 of the judgment.
154
[2006] EWHC 407 (QB). See http://www.bailii.org/ew/cases/EWHC/QB/2006/407.html
155
This would be as a result of either ‘reproducing’ the work (whether or not it is further
disseminated or made available) when it is stored on servers for example, or
communicating the work to the public when other users can access it, both of which are
‘restricted acts’ under the Copyright, Designs and Patents Act 1988 [55].
Cloud Computing 195

14 Specific sectors
To date, the most well-known examples of this type of liability have

arisen in the US. Viacom International unsuccessfully sued YouTube and
its owner Google in the US courts.156 In March 2007 it claimed
compensation of $1 billion for infringement of copyright in videos posted
on the YouTube site. Viacom argued that Google did not qualify for
immunity under the Digital Millennium Copyright Act 1998 [53], which
provides a hosting defence similar in intention to that in the Ecommerce
Directive [4], because internal records showed that Google was well
aware that its video-hosting site was riddled with infringing material
posted by its users. In essence, Viacom argued that general awareness of
infringing acts was enough. Google contended that it needed specific
notice of each infringement and that it had, indeed, complied with
thousands of takedown notices from Viacom. Google initially prevailed in
a summary judgment given in June 2010.
Viacom appealed that decision and, after a few more skirmishes in the
courts, Google and Viacom settled the week before the parties were due
to appear in court for a full trial. The terms of the settlement were not
disclosed although apparently no money changed hands.157
A very recent example, also in the US, is the Aereo Inc case (American
Broadcasting Cos Inc et al v Aereo Inc).158 Here, the US Supreme Court
held that online video start-up, Aereo, Inc., infringed broadcasters’
copyrights in on-air programming when it transmitted the programmes
to its internet subscribers, on the basis that the transmissions were a
public performance, and therefore infringed the exclusive right to
publicly perform a work protected by copyright. Aereo argued that it was
only an equipment provider and that it was its subscribers that actually
‘performed’ each transmission, but this was rejected. The case was very
specific to its facts, but it is not impossible to see that cases will be
brought against cloud services on a similar basis (that making copyright
work available through the service is a ‘public performance’ under US
copyright law).
In the UK, likewise, a service provider may well be able to rely on the
hosting defence of the Ecommerce Regulations, Regulation 19 [54].
Trademark infringement
There are two main ways in which online service providers can be liable
for trademark infringement: when a user puts a third-party trademark
into the service as an advertising ‘keyword’ and when a user attempts to
156
Viacom International Inc. and others v YouTube, Inc. and others, 07 Civ. 2103 (LLS) United
States District Court for the Southern District of New York, 23 June 2010.
157
STEMPEL, J. ‘Google, Viacom settle landmark YouTube lawsuit’, Reuters, 18 March 2014.
http://www.reuters.com/article/2014/03/18/us-google-viacom-lawsuit-
idUSBREA2H11220140318
158
US (2014), Supreme Court, 25 June 2014.
196 Cloud Computing

14.4 Consumer cloud
sell infringing goods. Two recent cases (albeit not involving services that
can properly be called cloud) show alternative approaches.
In Google France v Louis Vuitton,159 a number of trademark owners,

including Louis Vuitton, sued Google France for trademark infringement
on the basis of the use of their trademarks as sponsored keywords. The
CJEU held that Google could not be liable for trademark infringement
because the provision of its Google AdWords tool did not amount to use
of a third-party mark in the course of trade for various technical reasons,
which are outside the scope of this book. However, it also found that the
hosting defence of the Ecommerce Directive [4] only applies where the
service provider’s role is ‘neutral, in the sense that its conduct is merely
technical, automatic and passive, pointing to a lack of knowledge or
control’ of the keyword data that it has stored from the advertiser.160
Once the provider becomes aware of the infringing nature of the stored
data or the advertiser’s activities, it must act expeditiously to remove, or
disable access to, the data in order to avoid liability.
However, the CJEU seems to have taken a harder line with service
providers in L’Oréal SA v eBay International AG (see above).
Defamation
Anyone who participates in the publication of defamatory material is

treated as having caused its publication. A cloud provider hosting user
content is potentially liable for anything defamatory that the user posts.
The main defence available to service providers is that of innocent
dissemination under the Defamation Act 1996 [56]. To rely on this, the
service provider must show that:
• it is not the author, editor or publisher of the relevant statement;

• it took reasonable care in relation to its publication; and
• it did not know, and had no reason to believe, that what it did
caused or contributed to the publication of a defamatory statement.
Similar defences arise under the laws internationally. A recent Hong Kong
case ruled on whether, and under what circumstances, the provider of an
internet-based discussion forum may be held liable for defamatory
material posted on the forum. In Oriental Press Group v Fevaworks
Solutions,161 the Hong Kong Court of Final Appeal held that the provider
was a subordinate publisher (and not the first or main publisher of the
defamatory postings) because it was not aware of the content of the
159
Google France SARL and Google Inc. v Louis Vuitton Malletier SA, Google France and
Google Inc. v Viaticum SA, and Google France and Google Inc. v CNRRH, Joined Cases
C-236/08, C-237/08 and C-238/08, 23 March 2010. See
http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:62008CJ0236&from=EN
160
Paragraph 114 of the judgment.
161
[2013] HKEC 1025. See
http://legalref.judiciary.gov.hk/lrs/common/ju/ju_frame.jsp?DIS=87880&currpage=T
Cloud Computing 197

14 Specific sectors
postings and realistically did not have the ability or opportunity to

prevent their dissemination, only learning of them after they had already
been published by their originators. As to knowledge, the Court ruled
that, given the large volume of traffic on the forum and the speed with
which it was generated, the provider had no realistic means of acquiring
such knowledge or of exercising editorial control before the content was
posted.
The Supreme Court of Canada discussed the Canadian version of the

’innocent dissemination’ defence in Crookes v Newton162 and suggested
that an innocent disseminator in the internet context is an entity that
acts in a content-neutral manner, having no actual knowledge of
defamation, and not being aware of circumstances to put it on notice to
suspect defamatory content, nor being negligent in failing to find out
about it, and whose role in the dissemination of the information is
merely passive, instrumental and automated. The Court also endorsed the
principle that providers have to take active measures to remove or
disable access to defamatory content from their systems in order to
prevent further dissemination, to avoid being liable for defamation.
A cloud provider will not be considered to be an author, editor or

publisher if it is only involved as a provider of services without exerting
any editorial control. However, if the provider exerts that control, it may
lose the benefit of the defence. Also, if it decides neither to monitor
content on its site nor to respond to complaints, it may breach the
requirement to take reasonable care in relation to its publication of the
offending statement. Thus, as with the Ecommerce Regulations [54]
(which would also, in any case, apply), if material is taken down, the
provider should avoid liability.
Other illegal content
There are a whole range of other unlawful acts that a cloud provider
might unwittingly be implicated in as a result of content posted by a
user. For example, it is a criminal offence to publish, disseminate or
display written material where it is intended or likely to stir up racial or
religious hatred. A provider can avoid conviction if (as would be likely
when it is merely hosting) it can show that it was not aware of the
content of the material and did not suspect, and had no reason to
suspect, that it was unlawful. Providers can also rely on the ‘hosting’
defence under the Ecommerce Regulations [54] to avoid liability.
Providers also face a risk that users will upload inappropriate or illegal
content that includes obscene or classified content and child
pornography. Such content is governed by a number of key criminal law
statutes (for example, the Obscene Publications Act 1959 [57], the
162
[2011] 3 SCR 269, 2011 SCC 47. See
http://scc-csc.lexum.com/scc-csc/scc-csc/en/item/7963/index.do
198 Cloud Computing

14.4 Consumer cloud
Protection of Children Act 1978 [58] and the Criminal Justice Act 1988
[59]). Content may also be inappropriate for minors. The use of age
verification software to separate adult content from other content could
reduce the risk that material is considered obscene, as the target
audience is restricted. Primary defences of innocent publication are
available in some circumstances. However, where these might not be
available, providers may, again, be able to rely on the ‘hosting’ defence.
Some statutes have special provisions dealing with internet activities (and
defences). Regulation 7 of the Electronic Commerce Directive (Terrorism
Act 2006) Regulations 2007 [60], for example, mirrors the ‘hosting’
defence of the Ecommerce Regulations. It provides a defence for service
providers against certain terrorism offences, in respect of a service that
consists of the storage of information provided by a user, if (broadly):
(a) the service provider did not know when the information was
provided that it was…terrorism-related; or
(b) upon obtaining actual knowledge that…[it] was…, the service
provider expeditiously removed the information or disabled
access to it.
[Electronic Commerce Directive (Terrorism Act 2006) Regulations 2007, reg. 7(1)]
Conclusion on user content hosting
Any cloud provider hosting user content will always run the risk of
unwittingly committing some unlawful act as a result of users’ actions.
Clearly, AUPs, warranties and indemnities can – in theory – provide
protection to a provider. However, in practice, such protection is often
worthless. It will not normally be possible to identify the real person
behind the user account (certainly for free services where credit card
details are not obtained), and, in any case, private individuals will often
not be worth pursuing through courts.
Practical tip
The risk can be minimized by having in place proper procedures to

quickly take down any material that the provider becomes aware of
as being suspect. It is also advisable (even recognizing the limitations)
to include proper warranties and indemnities from the user in the
terms of use.
14.4.3 Liability under contracts with consumers

Any contractual limitation or exclusion of liability can only be relied on if
it can be successfully assessed against the ‘reasonableness’ test of the
UCTA [5] and the ‘fairness’ test under the Unfair Terms in Consumer
Cloud Computing 199

14 Specific sectors
Contracts Regulations 1999 [46] (see 13.5.2). The fact that a service may
be free of charge will assist in ensuring that any such assessment is in the
provider’s favour, but it will not be determinative. Indeed, an exclusion of
all liability for failure to provide services may well survive scrutiny when
the service is free.
Practical tip
A complete exclusion of liability in a consumer contract is unlikely to

be judged fair or reasonable if the service is one for which the
consumer pays.
Liability for data in consumer contracts is a little bit more complex. A

distinction needs to be made between liability for breach of security of
data (that is, when the data gets into the wrong hands) and liability for
loss of data (that is, when data is simply deleted). In respect of the
former, a provider is unlikely to be able to hide behind exclusions in
relation to questions of data breach as there are statutory obligations
under the Data Protection Act 1998 [24] that cannot be overridden by
contractual language. However, that is not the case in relation to loss of
data, and an attempt to exclude liability for failing to keep the data
(certainly in a free service) may well be reasonable and fair. Consumers
will therefore need to ensure that they have an alternative repository of
any valuable data they have stored in a cloud service.
In short, liability for availability can probably be avoided, as can liability

for loss of data, with carefully drafted contractual terms. However, a
provider will always be potentially liable for breach of security as a result
of data protection law.
14.4.4 Data protection when dealing with consumers

Any business (cloud or not) dealing with consumers will have complex
data protection issues to deal with. The business will have to comply with
the data protection principles and other rules summarized in Chapter 4.
A SaaS provider targeting consumers has to take appropriate security
steps, use data only for purposes for which it was collected (unless
exempt), register with the ICO, and so on.
However, some of the issues that arise because the business is operating
in the consumer cloud can, in fact, be simpler to deal with than in the
business cloud. We discussed in earlier chapters such issues as: which of
the cloud customer or the cloud provider is the ‘data controller’,163 with
163
See Chapter 4.
200 Cloud Computing

14.5 Key points
the associated data protection responsibilities; how the customer can, in

compliance with its data protection obligations, ensure that proper
security is in place;164 and how the customer can lawfully transfer data to
a non-EU cloud provider.165 These issues do not really arise, or at least not
in the same way, in a consumer cloud situation; the provider is clearly a
data controller. If the provider is ‘established’ within the UK, it has to
comply with the Data Protection Act [24] (see 4.6.2).
If a UK-based SaaS provider uses, in turn, an IaaS or PaaS provider, which

might be located outside the UK, it is no different from any enterprise
putting its customers’ data into the cloud; all the issues summarized in
Chapter 5 and Chapter 6 apply equally here. It makes no difference that
the data is ‘consumer data’ collected as part of a cloud service; the cloud
provider is also, in turn, a cloud customer using those IaaS/PaaS solutions.
Lastly, it is true that regulators have taken a particular interest in relation

to some of the issues that arise for the provider when selling services to
consumers. There is an opinion from the Article 29 Working Party, for
example, on data protection in the social networking arena [61]. The
privacy practices of Facebook and Google have been under particular
scrutiny, including in relation to the default ‘privacy settings’ they have
on their sites.
Practical tip
Cloud service providers handling consumer personal data have a

particular need to be careful in complying with data protection rules.
14.5 Key points

In this chapter we have explored issues that arise in specific sectors
(financial services, the public sector and consumers). Key points are as
follows.
◆ Entities in the financial services sector are subject to regulation that

might impact upon their freedom to use cloud services. The FCA is
entitled to be informed of any material outsourcing that regulated
entities undertake.
◆ The FCA sets out requirements that apply when ‘common platform
firm[s]’ (which include banks, building societies and investment firms)
outsource ‘critical or important’ functions. Some of the functions that
might be outsourced to the cloud (such as data storage) could fall
into this category, in which case the FCA requirements must be
164
See Chapter 5.
165
See Chapter 6.
Cloud Computing 201

14 Specific sectors
adhered to. However, many of these rules are what any prudent
cloud customer would be doing in any case.
◆ Some of the requirements will be difficult to comply with, except
(perhaps) where the cloud provider is specializing in providing
services to UK financial services clients. The firm is required (for
‘critical or important’ functions) to ensure that the cloud service
provider co-operates with the FCA and that the FCA has effective
access to data and audit rights.
◆ Insurance companies are not ‘common platform firm[s]’ and have
greater leeway to enter into a cloud service. There are no mandatory
rules, even in relation to critical or important functions, only
guidance. Nonetheless, they face the same difficulties in relation to
preserving access rights for both the customer and the regulator.
◆ Legal issues around cloud adoption in the public sector are largely
the same as in the private sector. One novel issue is that of public
procurement rules, which public authorities will always need to
adhere to when the value of a cloud contract is over a particular
value.
◆ Many consumer applications on the internet are examples of SaaS.
Consumer services that allow a consumer to upload content give rise
to the possibility of a provider being held liable for anything
unlawful in that content. Many of the wrongs for which a provider
might inadvertently be held liable are subject to a defence under the
Ecommerce Directive [4] if a ‘notice and takedown’ process is applied.
◆ Contracts with consumers should always reserve the right for the
provider to remove/take down content. Indemnities are standard, but
when there is a difficulty even in identifying the real person behind
the account, let alone being certain as to whether that person has
substance to put behind an indemnity, their usefulness is doubtful.
◆ Contracts with consumers should also contain protection in relation
to claims a consumer might bring against the cloud provider. Any
limitation language needs to be ‘reasonable’ and also ‘fair’, to be
enforceable under UK law. Breach of data protection rules cannot be
excluded.
◆ Cloud service providers handling consumer personal data (in
particular, social networking sites) are being carefully scrutinized by
regulators in Europe, and so have a particular need to be careful in
complying with data protection rules.
202 Cloud Computing

15 Tax considerations
by Daniel Hawthorne
15.1 Introduction
The fast-paced development of the cloud computing industry presents
increasing commercial opportunities to providers of such services and
their consumers. As it does this, it results in increasing complexity for the
tax managers of such businesses and challenges for the tax authorities
themselves. Put simply, the existing tax regimes in most jurisdictions
predate the digital age (or even the electronic age) and generally do not
cater well for cloud computing transactions. In addition, many cloud
services will be multi-jurisdictional and, although we are entering an era
of increasing international co-operation on tax matters, there are
currently no single, consistent, international tax principles applicable to
cloud transactions.
The initial challenge for the tax managers of businesses engaged in the
cloud will be identifying the various elements comprising a cloud
transaction and understanding how those elements fit within the existing
tax rules in each of the relevant jurisdictions. In many cases this will be a
very complex task. Once the transaction is understood from a tax
perspective, the focus will shift to ensuring that the transaction is
structured in the most efficient manner and that the transaction does not
pose unacceptable tax risks in any jurisdiction.
For the tax authorities, the challenge will be to keep pace as technology
continues to evolve, and to ensure that cloud transactions are
appropriately taxed, with no tax leakage, profit shifting or other
avoidance.
This chapter does not profess to be a detailed guide to the tax treatment
of cloud transactions, which in all cases will be heavily fact specific.
Instead, it is intended to provide a basic overview of some of the tax
issues to consider in the context of such transactions. In practice, local
specialist advice is likely to be needed in relation to complex,
multi-jurisdictional cloud activity.
Cloud Computing 203

15.2 Possible tax benefits of using the cloud

For many businesses, the alternative to using the cloud will be to develop
and maintain their own IT capacities. This is a capital-intensive exercise, in
terms of both the initial acquisition of the required hardware and
software, and the subsequent maintenance and replacement of such
assets in due course.
In most jurisdictions, certain items of capital expenditure will be

deductible against taxable profits over time (for example, by way of
capital allowances in the UK), although some capital expenditure may
not be deductible at all. Thus, although relief will generally be available
for some of the costs involved in establishing and maintaining IT
functionality, that relief will often be spread over a significant period,
and other costs will be non-deductible.
In contrast, businesses using cloud IT services will not generally incur such
significant capital expenditure. Instead, they will incur additional revenue
expenditure (such as the fees paid to cloud providers), which, in most
jurisdictions, will qualify as a deductible expense in the year it is incurred.
As a consequence, use of the cloud may provide accelerated tax relief for
IT expenditure.
Practical tip
Businesses should consider the tax deductibility of expenses when

considering the cost of cloud services. Tax relief may be accelerated
by using external cloud services rather than incurring capital
expenditure to provide the service in-house.
15.3 Determining the nature and source of the

supply
From a tax point of view, a fundamental question when considering the
taxation treatment of a cloud transaction will be whether the transaction
amounts to a supply of services or whether it is a supply of goods (for
example, a sale, lease or licence of an asset). The classification of the
transaction will be crucial as in many jurisdictions the tax treatment of
different transactions (and the income arising from them) will vary
considerably. For providers of cloud products, this classification is likely to
influence whether any sales tax or VAT should be levied and, if so, at
what rate (as to which see further below). It may also determine the
basis on which the resulting income is taxed. For customers and
consumers, it may determine whether any VAT or sales tax is payable in
204 Cloud Computing

15.3 Determining the nature and source of the supply
addition to the consideration and, perhaps, whether any withholding tax

needs to be applied to payments (for example, if the fee is in respect of
royalties).
In most cloud transactions there will be no transfer of property. As such,

most cloud transactions are likely to be viewed as supplies of services,
and most income derived from cloud transactions will therefore be in the
nature of fee income. However, there may be circumstances in which
interests in property or rights in respect of property do transfer, either on
a permanent or a temporary basis. In such scenarios, the resulting
receipts could be in the nature of rental income or capital gains, which
may be treated differently in some jurisdictions.
There may also be transactions that, as well as cloud services, involve

additional (and more traditional) forms of supply – for example, the
leasing of particular servers or infrastructure, or the licensing of software.
In those cases, and, in particular, for VAT purposes (as to which see
further below), it may be necessary to consider whether the supply is to
be treated as a single, composite supply for tax purposes, or whether it
involves multiple, differing supplies (in which case, an apportionment of
fees between the constituent elements may be required). From a
provider’s perspective, a complete understanding of the composition of a
supply will be essential in order to correctly determine the tax position.
Identifying the underlying nature of cloud supplies may also help to

determine another critical factor in relation to the tax treatment – the
source of the income. Source will often be crucial in determining the
place of taxation and, thus, the applicable rate and method of taxation.
In traditional transactions involving a supply of services, the place where
services are provided will generally be the source of the income. Where
there is rental income, the source of that income will usually be the
jurisdiction in which the rented asset (such as a server) is located, and
sales income will generally arise where the sale is concluded. Royalty
income arising from licensing arrangements should be expected to arise
in the jurisdiction in which the licensed property is used by the consumer.
A difficulty cloud providers will have will be applying these principles to
cloud services, where there is not (or may not be) a clear place for the
provision of the services. If a SaaS provider uses a third-party IaaS, then it
will not even (necessarily) know where the servers are located.
Depending on the nature of the income, source will be important to a

cloud service provider, as it will affect whether or not withholding tax
will be applied by a customer on payments for the cloud services
received. If income has a foreign source, and accordingly suffers foreign
taxation, it will be necessary to determine whether domestic credit can
be given for the foreign taxes, and whether the global tax position is
governed by a double tax treaty between the relevant jurisdictions. It
should also be borne in mind that a supply which includes multiple
constituent elements (see above) may also have multiple sources.
Cloud Computing 205

Double tax treaties are designed to allocate taxing rights amongst

jurisdictions and to prevent double taxation, which might otherwise arise.
Although tax treaties may be helpful in the context of cloud transactions,
it should be taken into account that existing treaties were not drafted
with the cloud in mind and the application of a treaty to a cloud scenario
may be problematic. In this respect, the ongoing work of the
Organisation for Economic Co-operation and Development (OECD) in
developing the international tax treatment of the digital economy (as to
which see further below) should hopefully bring increased clarity over
time.
Practical tip
In order to understand the tax treatment of a cloud service, providers

(and, to a lesser extent, recipients) must fully understand the
different elements that make up the service, how those elements are
provided and their relative value to the value of the overall supply.
15.4 VAT and sales taxes

At a European level, it will be necessary to consider the VAT treatment of
cloud transactions. In particular, is VAT payable in addition to the
consideration for the supply and, if it is, where is it payable and at what
rate, and is it recoverable? The possible impact of sales tax and other
consumption-based taxes should also be considered in non-EU
jurisdictions.
To determine the VAT treatment of a cloud transaction, the provider will

need to consider the following key questions: Is the transaction a supply
of goods or services (or both – see 15.3)? Where is the supply made from
(i.e. the head office or another jurisdiction)? Where is the supply
received? Is the supply a one-off supply or a continuous supply?
Supplies of goods and services are treated differently for VAT purposes.
Although the intricacies of the VAT system may vary from country to
country, under current EU law business-to-business supplies of services
generally take place where the customer is established. The recipient of
the supply will generally be expected to self-assess or ‘reverse charge’
VAT, which will be recoverable to the extent the recipient has full input
tax recovery. Business-to-consumer supplies, on the other hand, generally
take place where the provider is established [although, with effect from 1
January 2015, special rules apply to treat the supply of broadcasting,
telecommunication and electronic (BTE) services, which will likely
encompass most cloud services, as made in the consumer’s jurisdiction].
206 Cloud Computing

15.4 VAT and sales taxes
As a general rule, the place of supply of goods will generally be the place
where goods are physically supplied. The different VAT treatment for
goods and services illustrates the need to fully understand the nature of
the supply. For example, if a provider in country A makes a supply of
cloud services (involving a server in country B) to a customer in country C,
the supply will generally take place in country C if the customer is a
business customer but would, prior to January 2015, have taken place in
country A, if the customer is not a business. On the other hand, if the
supply involves a supply of goods, the supply will generally take place in
country B where the goods (the server) are located. In practice, supplies
of goods are unlikely to occur in a cloud scenario. At an EU level, the
place of supply also remains potentially subject to the ‘use and
enjoyment’ override,166 which can apply to shift the default place of
supply to the place where supplies are effectively used and enjoyed.
Providers of cloud services should bear in mind that, if they do make

supplies outside their home jurisdictions, they may be liable to register
for VAT (or equivalent taxes) and have to file tax returns in those
jurisdictions. In practice, where the provider has no physical presence in a
territory, it will often be simpler to appoint a local tax representative to
handle the tax administration.
The commercial consequences of VAT should also be factored into the

structuring of cloud transactions. At a business-to-business level, VAT will
often be recoverable (depending on the nature of the supplies made by
the recipient of the supply) and so will not impose an additional absolute
cost. However, any VAT arising on supplies to non-business consumers will
not be recoverable and will thus impact on the ultimate price paid by
consumers and the competitiveness of the product. Since VAT rates vary
from country to country, historically there was an incentive for providers
to non-business consumers to locate themselves in low VAT jurisdictions.
However, any such benefit likely no longer exists following the BTE
changes in 2015.
Practical tip
Providers of cloud services should consider whether VAT or sales tax

is chargeable in addition to their fees. This will require an
understanding of the location of the customer and whether they are
in business. Contractual documentation should make clear whether
any VAT or sales tax is payable in addition to the agreed fee for the
cloud services.
166
Article 59a and Article 59b of Council Directive 2006/112/EC and Article 5(3) of Council
Directive 2008/8/EC.
Cloud Computing 207

15.5 Withholding tax

Certain jurisdictions (including the UK) apply withholding tax to certain
royalty payments in respect of the use of IP rights. For these purposes,
‘royalties’ will generally include payments for the use of, or right to use,
certain IP rights (such as patents). It would be unusual for payments in
respect of cloud services to be royalties (as the cloud provider will usually
provide a service, rather than a simple right to use the IP on which the
service is based). However, where a provider is carrying on a business of
exploiting IP rights and its customers pay a fee to use such rights, some
jurisdictions may view the fee as a royalty. Where relevant, providers will
need to consider whether payments they receive from overseas customers
may be subject to withholding tax and, if so, whether a double tax treaty
allows any relief from such tax. Customers of overseas providers of
services will need to consider whether the payments they make are in the
nature of royalties and whether they may be under any obligation to
withhold tax. It will be important to ensure that any contractual
documentation fully reflects the possibility of any relevant withholding
tax. In particular, it should cover the commercial agreement between the
parties as to which party should bear the cost of any withheld amount,
and any procedural requirements for recovering any withheld amounts
from the relevant tax authority.
15.6 Permanent establishments

From a technical tax perspective, it will be important for both providers
and recipients of cloud services to consider whether the provision of such
services through the cloud could lead to a taxable permanent
establishment in another jurisdiction. In the case of a provider, the
presence of IT infrastructure (such as servers) in an overseas jurisdiction
could potentially amount to a fixed place of business. For a recipient, the
question is whether the use of such infrastructure (perhaps for the
storage and processing of data) through an overseas server could amount
to such a permanent establishment.
The OECD Model Tax Convention on Income and on Capital 2010 [62]
defines ‘permanent establishment’ widely to mean a fixed place of
business through which the business of an enterprise is wholly or partly
carried on.167 Although the definition goes on to explain situations that
are included within, and excluded from, the meaning of permanent
establishment, no express reference is made in the treaty itself to
electronically supplied services. Instead, it is necessary to seek guidance
from the OECD commentary, which does include a specific section on
electronic commerce.
167
See Article 5: ‘Permanent Establishment’.
208 Cloud Computing

15.7 Transfer pricing
The electronic commerce commentary notes that, whilst it is possible for

automated equipment operated by an enterprise to constitute a
permanent establishment in the country in which it is situated, a
distinction has to be drawn between the equipment and the data and
software that is used by, or stored on, that equipment.168 It is expressly
noted that a server, on which a website is stored and through which it is
accessed, may amount to a permanent establishment, although the
website itself may not. However, the generally accepted conclusion seems
to be that the mere presence of a server in and of itself will not amount
to a permanent establishment. The key question will be whether the
business of the enterprise that owns or leases such server can be said to
be wholly or partly carried on at the location of the server. This needs to
be considered on a case-by-case basis. A permanent establishment may
exist even though no personnel are required at the site to operate the
server.
No permanent establishment will arise where the activities carried out

through equipment (such as a server) are merely auxiliary or preparatory
to the business of the enterprise. This will be a question of fact based on
the functions performed through the equipment. However, where such
functions form an essential and significant part of the business of the
enterprise as a whole, or where the core functions of the enterprise are
carried out through the equipment (which may often be the case in the
context of an IaaS provider or of a SaaS provider with its own servers),
the auxiliary or preparatory exemption may not apply and there may be
a permanent establishment. If a permanent establishment does arise, it
will generally be necessary to determine the profits attributable to the
activities carried out through the establishment, such determination
being carried out on an arm’s length basis, as though the permanent
establishment is a separate, unconnected entity.
Practical tip
If planning on locating servers or other equipment outside the home

jurisdiction, cloud service providers should consider the law and tax
rules in such territory, and seek confirmation that the mere presence
of such assets will not result in a taxable presence (or the extent to
which it will).
15.7 Transfer pricing

Cloud transactions will often involve input from a number of related
entities. For example, the head office of a business may enter into an
168
Article 42 of OECD Commentary on Article 5: ‘Concerning the definition of Permanent
Establishment’.
Cloud Computing 209

agreement with a customer for the provision of cloud services, which

services may be provided through IT infrastructure hosted in a second
jurisdiction and using staff or IP of another group company in a third
jurisdiction. In such circumstances, transfer pricing legislation is likely to
be relevant [potentially both domestic transfer pricing rules, in the case
of group entities in the same jurisdiction, and international transfer
pricing rules (including the OECD transfer pricing guidelines), in the case
of group entities in multiple jurisdictions].169
To ensure transfer pricing rules are satisfied, it will generally be necessary

to evaluate each participating related entity’s contribution to the end
supply, and to apportion the profits from such supply between those
entities on an arm’s length basis. The appropriate arm’s length amount is
likely to take into account the functions performed, the assets, staff and
finance contributed, and the risks undertaken by each group entity. This
will be a very fact specific evaluation and, again, will be heavily
dependent on a full understanding of the elements of the supply being
made and their relative values. This may be a complicated exercise
requiring specialist transfer pricing advice. The relative infancy of certain
types of cloud solutions may mean that there are limited benchmarks on
which to base any analysis, which may complicate the exercise further.
On a related topic, many jurisdictions have implemented controlled

foreign company anti-avoidance legislation. The general purpose of such
legislation is to avoid the movement of income to low-tax jurisdictions in
order to avoid tax. Where servers or other IT capacity are established
offshore, care should be taken to ensure that the arrangements are not
brought within the scope of such anti-avoidance provisions.
Practical tip
As systems to encourage the international exchange of tax

information continue to develop, additional emphasis will be placed
on cloud service providers operating across multiple jurisdictions to
document and maintain a clear and justifiable transfer pricing policy.
15.8 International tax developments

Europe’s economy is becoming ever more digitalized. Intangible digital
products have become as important as physical commodities, companies
are increasingly outsourcing their corporate functions to low-cost
locations and firms are benefiting from reduced workforce overheads
through the automation of business processes. Whilst the digital
economy has stimulated innovation, investment, mobility and
169
See OECD Transfer Pricing Guidelines for Multinational Enterprises and Tax Administrations.
210 Cloud Computing

15.8 International tax developments
employment, it presents a clear challenge for our tax systems. It equally

offers great potential for simplifying tax administration and collection
across the EU.
The inability of national and international tax laws and standards to keep
up with the way today’s digitalized global businesses operate means that
the locations to which taxable profits are allocated often differ to those
where the business activities in question actually take place. This
discrepancy leads to the perception that multinational companies are
able to circumvent taxation and is therefore one of the key areas
European policymakers are hurriedly trying to address; in 2013 the OECD
published an Action Plan on Base Erosion and Profit Shifting [63] (the
‘OECD Action Plan’) and in May 2014 an expert group appointed by the
European Commission issued an extensive report on the taxation of the
digital economy [64] (the ‘EC Report’).
The EC Report identified ‘economic efficiency, distributional equity as

well as efficiency and effectiveness in tax administration and
enforcement’ as the fundamental principles that should guide
international taxation of the digital economy going forward. With
regards to policy options for corporation tax, the report concluded that
there should not be a special tax regime for digital companies, but that,
rather, the existing rules should be applied or adapted so that digital
companies will be treated in the same way as others. The EC Report
echoed a number of key action items from the OECD Action Plan, in
particular, highlighting the importance of improved co-operation
between Member States, a fundamental review of transfer pricing and
profit allocation rules, and a thorough analysis of a potential
destination-based corporation tax based on cash flow. The report also
concluded that there is ‘currently no valid justification’ for why the
collection of data via electronic means in a country should in itself create
a taxable presence in that country.
In terms of the VAT landscape going forward, as mentioned above, from

1 January 2015 BTE services have become subject to VAT in the Member
State of the consumer (the ‘destination principle’). Providers of electronic
services are therefore no longer able to benefit from a VAT advantage by
establishing in a territory with low VAT rates. As part of the ongoing VAT
reforms, a ‘mini One Stop Shop’ (MOSS) has also been introduced to
enable providers to register, declare and pay VAT due on supplies to
consumers in other Member States via a web portal in their home
Member State. The EC Report recommends that a broader one-stop shop
should be ‘pursued as a priority’ for all EU business-to-consumer supplies
of goods and services. The expert group also suggested that, in the long
run, a standard VAT rate should apply to all goods and services in Europe,
and that the destination principle could eventually apply to all
cross-border, business-to-consumer transactions globally.
Cloud Computing 211

Practical tip
The international tax landscape is developing at a rapid pace. It is

essential that cloud service providers operating internationally
maintain a close eye on developments and, particularly, on the OECD
Action Plan.
15.9 Key points

As hopefully highlighted by this short chapter, there may be a myriad of
tax issues to consider in the context of a cloud computing offering.
◆ Those providing cloud services, or entering into cloud transactions,

should do so with a full understanding of the possible tax
implications, and should be careful to structure their arrangements in
such a way as to minimize any unwelcome complexity and cost.
◆ Existing tax systems are not designed for cloud transactions. In order
to apply the existing tax rules to increasingly complex and
international cloud services, providers may need to seek specialist tax
advice in multiple jurisdictions.
◆ Providers should be aware that there is increasing international focus
on the taxation of multi-jurisdictional supplies. The failure to operate
tax in a clear, open and transparent manner risks tax authority
scrutiny and, increasingly, unwanted public attention. Changes to the
tax treatment of cloud transactions are likely to occur in the near
future and providers should monitor potential upcoming changes to
their tax obligations.
212 Cloud Computing

16 The future of cloud law
16.1 Introduction
As will have been seen throughout this book, the predominant feature of
the legal landscape in the cloud is the application of familiar legal
principles to an unfamiliar terrain. Cloud computing as a model has
evolved out of earlier structures for the sale of computing functionality
and infrastructure, and the legal principles that sufficed for those earlier
structures are being made to apply to the new model. There is as yet no
such independent body of ‘cloud law’.
We conclude this book by briefly speculating on how that landscape may

change in the medium to long term, as well as dealing with a number of
initiatives that seek to make it easier for customers to contract for the
cloud.
16.2 Open cloud

As noted elsewhere in this book,170 one of the critical issues with
contracting for the cloud is the ability of the customer to retrieve data
from a particular provider, either for it to then handle it itself or to move
it to another provider. Customer reluctance to move data into the cloud
is partly explained by the fear of being locked into a particular vendor.
The cloud industry recognizes this (primarily technical) challenge to make
the cloud interoperable, so that it is easy for customers to exit one
provider and migrate their data to another. There are a number of
industry initiatives that fall under the broad umbrella term of ‘open
cloud’, designed to facilitate such portability.
One such initiative was the Open Cloud Manifesto of March 2009. This
initiative asked stakeholders that are involved in developing cloud
services to bear in mind the following principles.
• Cloud providers must be open and address, in their offerings and

through the implementation of standards, the perceived challenges
to cloud adoption (including security, portability and
interoperability).
170
See, for example, Chapter 10.
Cloud Computing 213

• Providers should avoid using their market position to lock customers

into their proprietary platforms.
• Providers should use and adopt existing standards wherever
appropriate.
• Providers should be pragmatic in relation to new standards, and
should avoid creating too many. Standards should promote
innovation.
• Open cloud efforts should be driven by customer needs, not
proprietary technical interests.
• Stakeholders should work together.
There have been other, similar efforts, some developed in reaction to this
manifesto.
We referred to some of these in the first edition of this book, but any
consensus as to how an ‘open cloud’ is to look is yet to appear. It is
worth noting, however, that the Open Cloud Manifesto website is no
longer functioning and the initiative appears to have been suspended.
If at some future point there emerge industry standards that become

widely accepted, then cloud customers will, of course, wish to consider
exploring adherence to these standards as part of due diligence, and to
seek to extract contractual assurances in relation to standards in this
field, as they do in relation to security.
16.3 Development of industry standards and

codes of practice
Out of the cloud industry are emerging a number of industry bodies
(including, in Europe, EuroCloud and the Cloud Industry Forum) generally
promoting the industry and – as part of that promotion – trying to allay
customer concerns. (The ‘open cloud’ initiatives just mentioned are one
facet of this.)
For example, the Cloud Industry Forum (CIF) (which includes Microsoft
and Rackspace amongst its members) recognizes a number of issues that
need to be addressed to reassure the public, including:
• lack of transparency: the fact that professional-looking cloud services

can be set up by small organizations without meaningful experience;
• data protection, information security and service continuity;
• the anticipated dramatic speed of cloud takeover, over the coming
few years.
To that end, the CIF has prepared a ‘code of practice’ designed to allay
those fears. Its aim is for such a code to become a recognized standard
(supplemental to the more traditional information security standards,
such as the BS ISO/IEC 27000 series) and so assist in bringing greater
214 Cloud Computing

16.4 Developments in data protection law
transparency and trust to the cloud. Suppliers could self-certify or obtain

third-party certification accredited by the CIF.
A number of, in particular, UK cloud providers are obtaining certification

to this standard and it will offer a degree of assurance to cloud
customers. However, at the time of writing (six years after the CIF was
launched), the take-up remains modest.
A weakness of these types of schemes, given that there is no legal

backing for them, is that the sanction for non-compliance (assuming it is
discovered at all) with the relevant code of practice is relatively benign:
removal of the provider’s ability to claim certification. However, when a
user has contracted with a provider claiming compliance, it is, of course,
possible to obtain a contractual assurance that the provider does, in fact,
comply.
16.4 Developments in data protection law

Chapter 8 deals with the proposed European data protection reform that
is likely to happen in the medium term. However, those who see the
stringent European rules as a hindrance to cloud services are likely to see
these proposals as being a missed opportunity. Those (such as the German
and other regulators noted above) who are sceptical about cloud services
may well also see the same or similar difficulties in a revised regime, for
example the seeming lack of activity on the part of US authorities in
enforcing Safe Harbor (see 6.4.5).
It is difficult to see how the Proposed Regulation will assist the take-up
of cloud services within Europe. The regulatory difficulty that exists under
the present Data Protection Directive [1] remains (cross-border data flow
issues, restrictions on the appointment of sub-processors and so on), as
do certain conceptual difficulties (whether a provider is a processor or a
controller). Moreover, in some respects, the position in the Proposed
Regulation is arguably more of a hindrance. For example, there is an
increased regulatory burden upon cloud providers (which are at present,
when they are processors, not subject to substantive provisions directly):
under the Proposed Regulation they begin to have direct responsibility
for security, and regulators would be able to enforce the Proposed
Regulation directly against them. There is the potential for substantial
fines.
The Proposed Regulation was launched with a professed desire to

‘enhance opportunities for companies that want to do business in the
EU’s internal market, while ensuring a high level of data protection for
Cloud Computing 215

individuals’.171 It formed part of the EU’s overall strategy for the so-called
‘digital economy’, which it unveiled in its 2010 paper, ‘A Digital Agenda
for Europe’.172 The broad aim, as described by Commissioner Reding, was
to make ‘the Digital Single Market more accessible for both businesses
and consumers’,173 allowing Europe to become more competitive, as well
as setting the standard for data protection regulation worldwide. To
further this aim, the Proposed Regulation had three objectives: to create
legal certainty; to simplify the regulatory environment; and to provide
clear rules for international data transfers.
Many in the cloud world will consider that these objectives have not
been met. The Proposed Regulation does not seem to solve the problems
currently experienced by European customers (such as issues around
cross-border data flows) and the service providers seeking to sell to them
(such as the rules around appointing sub-processors). In the long term, it
may encourage European customers to use European service providers,
but given the predominance of the US in this sector, it will do little in the
short term to ‘liberate the cloud’. In this respect, it could be seen as a
missed opportunity. At the time of writing, there was still some way to
go before the Proposed Regulation was finalized, but the indications are
that there will not be any substantial relevant changes.
16.5 The European Commission cloud initiatives

As part of its cloud strategy, as set out in ‘Unleashing the Potential of
Cloud Computing in Europe’, published in 2012,174 the European
Commission launched an initiative to move towards standardization and
codes of practice for cloud computing, in particular, to look at what it
called ‘service level agreements’ between cloud providers and enterprise
users.
A working group, the Cloud Select Industry Group – Subgroup on Service

Level Agreements, was set up to develop ‘standardisation guidelines’.
This group had the participation of some of the biggest names in cloud
computing (such as Amazon, Microsoft and Google), as well as
representatives of various cloud bodies (such as Cloud Security Alliance
171
Vice-President of the European Commission, EU Justice Commissioner Viviane Reding, ‘The
EU Data Protection Reform 2012: Making Europe the Standard Setter for Modern Data
Protection Rules in the Digital Age’, SPEECH/12/26, Munich, 22 January 2012.
172
‘A Digital Agenda for Europe’, COM(2010)245 final, Brussels, 19 May 2010.
173
Vice-President of the European Commission, EU Justice Commissioner Viviane Reding, ‘The
EU Data Protection Reform 2012: Making Europe the Standard Setter for Modern Data
Protection Rules in the Digital Age’, SPEECH/12/26, Munich, 22 January 2012.
174
‘Unleashing the Potential of Cloud Computing in Europe’, COM(2012) 529 final, Brussels, 27
September 2012 (to be found at:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0529:FIN:EN:PDF).
216 Cloud Computing

16.5 The European Commission cloud initiatives
and EuroCloud). It finished its work in June 2014 and published a paper
entitled ‘Cloud Service Level Agreement Standardisation Guidelines’.175
The aim is to attempt standardization of certain aspects of SLAs so as to

improve clarity and understanding within the cloud market in which
different providers use different terminologies, which makes it difficult
for customers to compare different solutions. The guidelines are designed
to help fix this problem by providing information on concepts usually
covered by SLAs and related documents.
The report is intended also to feed into international work being done
under the ISO/IEC banner.
The guidelines are designed to be technological and business model

neutral, and to have an international applicability. They do not cover all
issues that might need to be dealt with within a contract. For example,
they make a distinction between the SLA and other documents that
might form part of the overall agreement, such as the ‘Master Service
Agreement’, the latter containing some of the more general contractual
provisions (duration, liability and so on). For the purpose of that
document, the SLA defines the document by setting out the description
of the service and the ‘cloud service level objectives’ (‘SLOs’).
In the guidelines, SLOs fall into four categories: Performance, Security,

Data Management and Personal Data Protection. Clearly, and the
guidelines recognize this, there is overlap between the different
categories: specifically, security and data management and data
protection. Each of the objectives within these categories is defined and
explained. Within each category there is recognition that not all of them
will, in fact, be applicable.
Performance SLOs cover functionality and performance issues (such as

those dealt with in Chapter 12). They include availability, response time
and capacity.
The Security SLOs cover such things as terminology around the provision
of assurance and transparency. It approaches the issue from the
perspective of both the provider and the customer and draws upon the
BS ISO/IEC 27000 series (see Chapter 3). The guidelines accept that not all
aspects of security lend themselves to an SLO (for example, business
continuity and disaster recovery). The different objectives within this
category include service reliability, authentication and authorization, and
cryptography.
The Data Management SLOs seek to address challenges to traditional

methods of securing and managing data thrown up by cloud’s
175
Cloud Service Level Agreement Standardisation Guidelines, 24 June 2014. Available at:
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-standardisation-
guidelines
Cloud Computing 217

characteristics (such as multi-tenancy, layered architectures and so on).

They cover all aspects of the data life cycle and include such things as
data mirroring and backup, and data portability.
Lastly, the Personal Data Protection SLOs focus on some of the data
protection issues that arise when the provider is only a processor (see
4.5). Not all data protection issues lend themselves to an SLO, though,
and that again is recognized. Issues dealt with here include data
minimization, use, retention and disclosure limitation, and geographical
location of customer data.
Another working party set up by the European Commission was

established to work on a data protection code of conduct for cloud
service providers. At the time of writing, this work was ongoing. The
final draft report will then be submitted to the Article 29 Working Party.
218 Cloud Computing

Glossary
Article 29 Data Protection The body set up by Article 29 of the

Working Party (the ’Article Data Protection Directive [1] to provide
29 Working Party’) guidance on the operation of the
Directive. There are 28 members of the
Article 29 Working Party, one from each
of the EU member states.
BCR (binding corporate An internal policy adopted by a group

rules) of companies, and approved by
European data protection regulators,
permitting that group to share personal
data (of which a group member is a
data controller) amongst its members.
BCR-P (binding corporate A form of BCR where the group is

rules for processors) sharing, internationally, personal data of
which a group member is a data
processor.
BS ISO/IEC 27000 series A series of ISMS standards published

jointly by the International Organization
for Standardization (ISO) and the
International Electrotechnical
Commission (IEC)
Data controller The company, body or other person that

determines the purposes and means of
the processing of personal data;
responsible for data protection
compliance
Data processor The company, body or other person that

processes personal data on behalf of the
data controller; it does not have its own
data protection compliance
responsibilities under data protection
law
Cloud Computing 219

Glossary
Data protection principles Eight principles set out in the DPA [24],
with which a data controller must
comply. Each reflects a concept in the
Data Protection Directive [1], although
the latter does not use the terminology
of ’principles’
EEA (European Economic The European Union together with

Area) Iceland, Liechtenstein and Norway
Eighth data protection The data protection principle that

principle requires the data controller not to
transfer personal data outside the EEA
unless adequate safeguards are in place
IaaS (infrastructure as a The provision of computing

service) infrastructure (such as server or storage
capacity) through a remotely provided
service
ICO Information Commissioner’s Office; the

UK data protection regulator
Instance In the context of SaaS, an occurrence of

the software running on a server. A
provider may have many instances
running on different servers (or on the
same server)
ISMS Information security management

system
Multi-tenancy One particular instance of software is

simultaneously handling the data of a
number of cloud customers (the
‘tenants’) on the provider’s server
PaaS (platform as a The provision of a platform allowing the

service) development and then deployment of
new software applications.
Personal data Data about identifiable individuals; the

subject of data protection legislation
Proposed Regulation A proposed new law on data protection

published in January 2012 [65] by the
220 Cloud Computing

Glossary
European Commission to replace the

Data Protection Directive [1].
SaaS (software as a The delivery of a software application

service) remotely by the provider over the
internet, perhaps through a web
interface
Safe Harbor scheme A scheme under which US entities can

self-certify to an overarching set of data
protection principles and so facilitate the
transfer to them of personal data from
Europe
Seventh data protection The data protection principle that

principle requires the data controller to ensure
personal data is kept secure
Standard clauses Three different sets of model contracts

approved by the European Commission
to ensure compliance with the eighth
data protection principle.
Virtualization Technology that enables an enterprise to

operate software on a ‘virtual’ server
(which could be spread across a number
of different physical servers), rather than
on a specific physical server
Cloud Computing 221

References
[1] EUROPEAN COMMUNITIES. Directive 95/46/EC of the European

Parliament and of the Council of 24 October 1995 on the protection of
individuals with regard to the processing of personal data and on the
free movement of such data. (Data Protection Directive.) Luxembourg:
Office for Official Publications of the European Communities, 1995.
[2] Council Regulation (EC) No. 593/2008 of the European Parliament

and of the Council of 17 June 2008 on the law applicable to contractual
obligations. (Rome I.) OJ 2008 No. L177/6, 04 July 2008.
[3] Council Regulation (EC) No 864/2007 of the European Parliament and

of the Council of 11 July 2007 on the law applicable to non-contractual
obligations. (Rome II.) OJ 2007 No. L199/40, 31 July 2007.

Parliament and of the Council of 8 June 2000 on certain legal aspects of
information society services, in particular electronic commerce, in the
Internal Market (‘Directive on electronic commerce’). Luxembourg: Office
for Official Publications of the European Communities, 2000.
[5] GREAT BRITAIN. Unfair Contract Terms Act 1977. London: HMSO.
[6] UNITED STATES OF AMERICA. USA Patriot Act 2001. Washington:

Government Printing Office.
[7] GREAT BRITAIN. Regulation of Investigatory Powers Act 2000.

London: HMSO.
[8] GREAT BRITAIN. Intelligence Services Act 1994. London: HMSO.
[9] GREAT BRITAIN. Police Act 1997. London: HMSO.
[10] UNITED STATES OF AMERICA. Stored Communications Act of 1986.

Washington: Government Printing Office.
[11] UNITED STATES OF AMERICA. Foreign Intelligence Surveillance Act

of 1978. Washington: Government Printing Office.
[12] CANADA. Freedom of Information and Protection of Privacy Act,

1993. Province of Nova Scotia.
222 Cloud Computing

References
[13] INFORMATION COMMISSIONER’S OFFICE (ICO). Guidance on the use

of cloud computing. Version 1.1. Wilmslow, Cheshire: ICO, 2012.
[14] BS ISO/IEC 27001:2013, Information technology – Security

techniques – Information security management systems – Requirements
[15] BS ISO/IEC 27002:2013, Information technology – Security

techniques – Code of practice for information security controls
[16] AMERICAN INSTITUTE OF CERTIFIED PUBLIC ACCOUNTANTS (AICPA).

Statement on Standards for Attestation Engagements (SSAE) No. 16:
Reporting on Controls at a Service Organization. (SSAE 16.) New York:
AICPA, April 2010.

Statement on Auditing Standards No. 70: Service Organizations (SAS 70).
New York: AICPA, April 1992.
[18] INFORMATION COMMISSIONER’S OFFICE (ICO). Information

Commissioner’s guidance about the issue of monetary penalties prepared
and issued under section 55C (1) of the Data Protection Act 1998.
Wilmslow, Cheshire: ICO.
[19] BS 7799 series, Information security management
[20] BS ISO/IEC 17799 series, Information technology
[21] BS ISO/IEC 27011, Information technology – Security techniques –

Information security management guidelines for telecommunications
organizations based on BS ISO/IEC 27002
[22] ISO/IEC TR 27015, Information technology – Security techniques –

Information security management guidelines for financial services

International Standards for Assurance Engagements (ISAE) No. 3402:
Assurance Reports on Controls at a Service Organization. (ISAE 3402.)
New York: AICPA, December 2009.
[24] GREAT BRITAIN. Data Protection Act 1998. London: HMSO.
[25] EUROPEAN COMMUNITIES. Opinion 05/2012 on Cloud Computing.

(WP 196.) 1 July 2012.
[26] EUROPEAN COMMUNITIES. Opinion 4/2007 on the concept of

personal data. (WP 136.) 20 June 2007.
[27] INFORMATION COMMISSIONER’S OFFICE (ICO). Determining what is

personal data. Wilmslow, Cheshire: ICO, 2007.
Cloud Computing 223

References
[28] EUROPEAN COMMUNITIES. Opinion 10/2006 on the processing of

personal data by the Society for Worldwide Interbank Financial
Telecommunication (SWIFT). (WP 128.) 22 November 2006.
[29] EUROPEAN COMMISSION. ‘Factsheet on the “Right to be

Forgotten” ruling (C-131/12)’.
http://ec.europa.eu/justice/data-protection/files/factsheets/factsheet_data_
protection_en.pdf
[30] EUROPEAN COMMUNITIES. Opinion 8/2010 on applicable law. (WP

179.) 16 December 2010.
[31] EUROPEAN COMMUNITIES. Opinion 1/2010 on the concepts of

“controller” and “processor”. (WP 169.) 16 February 2010.
[32] INFORMATION COMMISSIONER’S OFFICE (ICO). Outsourcing – A

guide for small and medium-sized businesses. Wilmslow, Cheshire: ICO,
2012.
[33] UNITED STATES OF AMERICA. Health Insurance Portability and

Accountability Act of 1996. (HIPAA.) Washington: Government Printing
Office.
[34] UNITED STATES OF AMERICA. Gramm–Leach–Bliley Act 1999. (GBL;

also known as the Financial Services Modernization Act of 1999.)
Washington: Government Printing Office.
[35] UNITED STATES OF AMERICA. Children’s Online Privacy Protection

Act of 1998. (COPPA.) Washington: Government Printing Office.
[36] INFORMATION COMMISSIONER’S OFFICE (ICO). Assessing Adequacy,

International data transfers. Wilmslow, Cheshire: ICO, 2012.
[37] EUROPEAN COMMUNITIES. Working Document 02/2012 setting up a

table with the elements and principles to be found in Processor Binding
Corporate Rules. (WP 195.) 6 June 2012.
[38] EUROPEAN COMMUNITIES. Explanatory Document on the Processor

Binding Corporate Rules. (WP 204.) 19 April 2013.

Parliament and of the Council of 12 July 2002 concerning the processing
of personal data and the protection of privacy in the electronic
communications sector. Luxembourg: Office for Official Publications of
the European Communities, 2002.
[40] GREAT BRITAIN. The Privacy and Electronic Communications (EC

Directive) Regulations 2003 (SI 2003 No. 2426). London: HMSO.
224 Cloud Computing

References
[41] INFORMATION COMMISSIONER’S OFFICE (ICO). Guidance on data

security breach management. Version 2.1. Wilmslow, Cheshire: ICO, 2012.
[42] GREAT BRITAIN. Financial Conduct Authority. Financial Conduct

Authority Handbook. (FCA Handbook). London: FSA, 2005.
[43] PRUDENTIAL REGULATION AUTHORITY. Prudential Regulation

Authority Rulebook. (PRA Rulebook). Available at:
http://www.fshandbook.info/FS/prarulebook.jsp
[44] GREAT BRITAIN. Financial Services and Markets Act 2000. (FSMA.)
London: TSO (The Stationery Office).
[45] GREAT BRITAIN. Financial Services Authority. Data Security in

Financial Services. London: FSA, 2008.
[46] GREAT BRITAIN. The Unfair Terms in Consumer Contracts

Regulations 1999 (SI 1999 No. 2083). London: TSO (The Stationery Office).

Parliament and of the Council of 21 April 2004 on markets in financial
instruments amending Council Directives 85/611/EEC and 93/6/EEC and
Directive 2000/12/EC of the European Parliament and of the Council and
repealing Council Directive 93/22/EEC. (Markets in Financial Instruments
Directive – MiFID.) Luxembourg: Office for Official Publications of the
European Communities, 2004.
[48] EUROPEAN COMMUNITIES. Directive 2013/36/EU of the European

Parliament and of the Council of 26 June 2013 on access to the activity of
credit institutions and the prudential supervision of credit institutions and
investment firms. (CRD.) Luxembourg: Office for Official Publications of
the European Communities, 2013.
[49] MIFID CONNECT. Guideline on the Application of the Outsourcing

Requirements under the FSA Rules Implementing MiFID and the CRD in
the UK. 16 May 2007.
http://www.mifidconnect.com/news/mifid-connect-guideline1
[50] GREAT BRITAIN. Department for Culture, Media and Sport and
Department for Business, Innovation and Skills. Digital Britain Final
Report. (CM 7650.) London: TSO (The Stationery Office), 2009.
[51] GREAT BRITAIN. The Public Contracts Regulations 2006. London:

TSO (The Stationery Office).
[52] GREAT BRITAIN. Freedom of Information Act 2000. (FOIA.) London:

TSO (The Stationery Office).
[53] UNITED STATES OF AMERICA. Digital Millennium Copyright Act

1998. (DMCA.) Washington: Government Printing Office.
Cloud Computing 225

References
[54] GREAT BRITAIN. The Electronic Commerce (EC Directive) Regulations

2002 (SI 2002 No. 2013). (Ecommerce Regulations.) London: TSO (The
Stationery Office).
[55] GREAT BRITAIN. Copyright, Designs and Patents Act 1988. London:
HMSO.
[56] GREAT BRITAIN. Defamation Act 1996. London: HMSO.
[57] GREAT BRITAIN. Obscene Publications Act 1959. London: HMSO.
[58] GREAT BRITAIN. Protection of Children Act 1978. London: HMSO.
[59] GREAT BRITAIN. Criminal Justice Act 1988. London: HMSO.
[60] GREAT BRITAIN. The Electronic Commerce Directive (Terrorism Act

2006) Regulations 2007 (SI 2007 No.1550). London: HMSO.
[61] EUROPEAN COMMUNITIES. Opinion 5/2009 on online social

networking. (WP 163.) 12 June 2009.
[62] OECD (2012). Model Tax Convention on Income and on Capital 2010
(updated 2010). OECD Publishing.
http://dx.doi.org/10.1787/978926417517-en
[63] OECD (2013). Action Plan on Base Erosion and Profit Shifting. OECD
Publishing. http://dx.doi.org/10.1787/9789264202719-en
[64] EUROPEAN COMMUNITIES. Report of the Commission Expert Group

on Taxation of the Digital Economy. Luxembourg: Office for Official
Publications of the European Communities, 28 May 2014.
[65] EUROPEAN COMMUNITIES. Proposal for a Regulation of the

European Parliament and of the council on the protection of individuals
with regard to the processing of personal data and on the free
movement of such data (General Data Protection Regulations), 25
January 2012, 2012/0011 (COD).
[66] EUROPEAN COMMISSION. Cloud Select Industry Group – Subgroup

on Service Level Agreements. ‘Cloud Service Level Agreement
Standardisation Guidelines’. Brussels, 24 June 2014 (see
http://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-
standardisation-guidelines).
226 Cloud Computing

Index
Acceptable Use Policy (AUP), 193, 219 on service credits, 163–164, 168, 171
adequate countries, 88–89, 110, 113, certification to standards, 35, 37, 38, 40,
127 41, 44–46, 53, 83, 214–215
Adobe, 32 client/server, 11
Affero, 134–135, 139 cloud computing, 1–2, 3, 4, 10, 11–12,
Amazon, 6, 12, 132, 176 13
Amazon EC2, 6, 12, 32, 132, 158, history, 1, 2–3
161, 219 Cloud Industry Forum (CIF), 214–215
Amazon S3, 6, 219 cloud law, 15, 16–18, 19, 213, 215–216
application service provision (ASP), 11, cloud providers, 9, 13–14, 16, 19, 20–21,
133 22–23, 25–26, 27, 151–152, 155
Article 29 Working Party, 55–56, 61, 62, as a data controller, 62–63, 64, 75,
67–68, 95, 109, 111, 201–202, 219 81, 85
binding corporate rules for as a data processor, 61, 62, 72, 78,
processors, 105, 106, 109, 122 79–80, 81, 85, 99
opinion on controller/processor, 61, information security, 28, 36–38, 39,
78, 110 40, 45–46, 54, 72–73, 85
opinion on SWIFT, 61, 78 onward transfers, 87, 89, 96, 99–101,
role, 55–56 105
SWIFT, 61, 78 cloud service level objectives (SLOs), 217
auditing customers, 47, 49–50, 54 cloud service types, 3, 4, 5–7
’balance of interest’ test, 70, 81 cloud transactions, 203, 204–205,
batch computing/service bureau, 11 206–207, 209–210, 212
binding corporate rules (BCRs), Coghead, 149
105–106, 108–109, 219 community cloud, 8
binding corporate rules for processors consent, 111, 122
(BCR-Ps), 105, 106–107, 109–110, consumer cloud, 1, 8, 192
111–112, 113, 219 data protection, 200–201
British Columbia Government and liability for consumer contracts,
Service Employees’ Union (BCGEU), 199–200, 202
25 liability for hosting user content,
BS 17799 series, 38 193–199
BS 7799 series, 38 contract law, 15, 19–20, 165
business as a service (BaaS), 7 Rome I, 15, 18, 19
calculating credits, 163–164, 167, 169, Rome II, 15, 20
171 contracts, 13–14, 19, 48–49, 97–98, 125,
caps 141, 145, 150, 153–154, 178–179
enforceability (under UCTA etc), contractual chains, 147, 148
176–178, 180 contractual security schedule, 48–49
on liability, 53, 113, 174, 175, 176, copyleft problem, 133–134, 135, 139
180, 181 copyright infringement, 136, 195–196
Cloud Computing 227

Index
customer data, 11, 13, 26, 140, 149–150 Data Protection Directive, 2, 16, 19, 55,
access by customer on termination, 56, 57, 59, 66, 69, 122, 219
142–144, 146, 150 data breach notification, 72, 115
backups of, 51, 144, 192 data transfer, 86, 88, 97, 127
in hands of cloud subcontractor, 35, data protection officers (DPO), 126–127
87, 147, 150 data protection principles, 55, 69, 73,
lock-in, 3, 142–143, 149, 150 76, 106–107, 111, 142, 219
lock-out, 149 first (legitimate basis), 64, 69–70, 76,
providers use of, 140–142 81, 101
damages, 64, 72, 77, 91–92, 164, 172, first (sensitive personal data), 69,
175, 181 70–71
data - See customer data seventh (security), 69, 74, 75, 76,
data breach notification, 51–52, 72, 79–80, 82, 84, 101, 103, 221
114, 116–117, 120–121, 126 eighth (data transfer), 69, 76, 86, 87,
application to cloud, 119–120, 128 88, 89, 99, 101, 104, 220
in Europe, 115–116 Data Protection Proposed Regulation,
in UK, 115, 116, 117–118, 120–121 EU, 122–128, 215–216, 220
in US, 89, 114–115, 120 data transfer, 88–89
data controllers, 26, 38, 59, 60, 71–72, adequate countries, 88–89, 110, 113,
76, 81–82, 219 127
cloud provider as, 62–63, 64, 75, 81, binding corporate rules, 105–108,
85 111–112, 113
data breach notification, 114, 119, eighth data protection principles,
120 69, 76, 86, 87, 88, 89, 99, 101,
data protection principles, 65, 67, 104, 220
69, 73, 76, 86, 101, 104 onward transfers, 87, 89, 96, 99–101,
enforcement, 72–73 105, 112
multiple controllers, 64 personal data, 76, 78, 86, 88, 89,
SWIFT, 60–61, 78 91–92, 97, 102–103, 111, 113
Working Party opinion on meaning, Safe Harbor, 68, 79, 89–96, 101, 104,
61, 78 111, 113, 221
data flows - See data transfer; eighth self-assessment, 101–104, 113, 127
(data protection) principle standard clauses, 97–98, 99–101, 113,
Data Handling Review, 117 127
data portability, 124 standard clauses (controller to
processor), 98, 99–101
data processors, 59–60, 64–65, 75, 76,
83, 125, 219 standard clauses (Set I), 97
binding corporate rules for, 105, standard clauses (Set II), 97
106–107, 109–110, 111–112, 113 defamation, 197–198
cloud provider as, 61, 62, 71, 78, Defamation Act 1996, 197
79–80, 81, 85, 99 deployment models, 7–9, 84
SWIFT, 60–61 Digital Millennium Copyright Act 1998,
data protection, 2, 13, 124, 200–201 195
Data Protection Act 1998 (DPA), 55, 56, DPA enforcement
65, 67–68, 73, 80, 85, 122, 219 damages claims, 72, 77
data breach, 72, 119 enforcement notices, 72–73
data protection principles, 64, 69, monetary penalties, 73–75, 76
70–71, 80, 82, 84, 86 Dropbox, 31
personal data, 57, 59, 60, 64, 103 due diligence, 25, 33–36, 45, 53, 85
self-assessment, 101–102 examining certifications, 34, 36
228 Cloud Computing

Index
pre-contract, 82–83, 84 Foreign Intelligence Surveillance Act

questionnaires, 34–35, 53 1978 (FISA), 24
regulatory requirements (under Freedom of Information Act 2000
DPA) for, 34, 82, 85 (FOIA), 191
site visits, 34 General Public License (GPL), 132, 133,
Durant v FSA, 58 135, 136
eBay, 33 Gmail, 5, 8, 30, 31, 192
Ecommerce Directive (2000), 16 GNU, 132n107, 135
’country of origin’ rule, 20–21 GNU Affero GPL, 133, 135
liability for hosted user content, 193, GNU GPL, 132, 133, 136
193–194, 196 GNU project, 3
’notice and takedown’, 193, 198, 202 Google, 2, 5, 30, 66, 79, 158, 193, 194,
eighth (data protection) principle, 69, 201
76, 86, 87, 88 in Brazil, 16, 17
data controllers, 86, 101, 104 Google App Engine, 6, 143, 161, 163
self-assessment, 101, 104 Google Docs, 30
standard clauses, 99, 104, 220 in Spain, 16, 18, 66–67, 124
Electronic Commerce (EC Directive) Viacom, 196
Regulations 2002, 193, 194–195, 196 Google France v. Loius Vuitton, 197
Ellison, Larry, 3 government cloud, 190
enforcement, 55, 72–75, 91, 93 public procurement rules, 190, 202
enforcement notices, 72–73 green computing, 2, 12
ePrivacy Directive, 115 grid computing or distributed
escrow, 136–138, 139, 144 computing, 6–7
of SaaS, 137, 138–139 HM Revenue and Customs (HMRC), 22,
traditional escrow, 136–138 116
Eurocloud, 214 Hotmail, 1, 8, 31, 192
European Economic Area (EEA), 65, 69, hybrid cloud, 8, 190
79, 86, 88, 96, 109, 187, 220 iCloud, 33
Facebook, 1, 5, 8, 16, 32, 193, 201 illegal content, 17, 198–199
in Germany, 17–18 industry codes of practice, 214–215,
FBI, 24–25 216–218
FCA ’Principles for Businesses’, 118, Information Commissioner’s Office
184–185 (ICO), 25, 26, 220
Federal Trade Commission (FTC), 91, 92, data breach notification, 38, 51, 73,
93, 113 74–75, 116–117, 119, 120
Financial Conduct Authority (FCA), 118, data protection, 38, 56, 62, 68, 69,
183, 187, 188, 201, 202 73, 79, 85
financial institutions, 24, 61, 185–189, data transfers, 35–36, 82, 101, 102,
201 103
financial services, 5, 28–29, 34, 39, monetary penalties, 73–75, 76
118–119, 183–189, 201 outsourcing, 26, 83, 101, 103
Financial Services & Markets Act 2000 information security, 28–29, 51–53, 54
(FSMA), 183 contracts, 48–51, 53, 54
Financial Services Authority (FSA), 118, due diligence, 33–36, 53
183n140, 187 ISO/IEC 27000 series, 38–46, 53, 54,
fines, 128 83, 214, 217
Flickr, 1, 192 SAS 70, 46, 54
force majeure, 165–166, 171, 176 security breaches, 29–33, 53
third-party suppliers, 166–167 security standards, 34, 37–38, 54
Cloud Computing 229

Index
information security management exclusions, 53, 99, 174–175, 176, 181

system (ISMS), 38, 39–41, 53, 220 exclusions for loss of data, 53
infrastructure as a service (IaaS), 3, 5–6, for hosted user content, 193–199
7, 68, 129, 131, 132, 147, 201, 220 indirect losses, 174, 181
escrow, 139 limitations, 175
onward transfers, 87 provider, 51–53, 77, 98, 104, 113,
outsourcing, 10 131, 176, 180, 181
third-party suppliers, 50, 129 third-party suppliers, 51, 154,
virtualization, 9 166–167, 176
insolvency UCTA, 176–177
access to data, 138, 144, 146, 147, Unfair Terms in Consumer Contract
150 Regulations 1999, 177–178
of cloud provider, 103, 108, 144, lock-in, 3, 142–143, 149, 150
146, 147, 150 lock-out, 149
and escrow, 136, 137, 138, 139 main establishment, 123
instance (of software), 4, 9, 10, 152, managed services, 10–11, 49, 173
159, 220 Microsoft, 2, 5, 23, 29–30, 31, 111, 213
insurance companies, 188–189, 202 Microsoft Azure, 6, 161
insurers using cloud services, 189 MiFID, 183
Intelligence Services Act 1994, 22 outsourcing of critical or important
international disputes, applicable functions, 187
(cloud) law, 16–18, 27 MobileMe, 31
investment firms, 183, 185–188, 189, monetary penalties, 73–75, 76, 128
201 multi-tenancy, 4, 9–10, 49, 54, 145, 152,
ISO/IEC 27000 series, 38–46, 53, 54, 83, 153–154, 173, 220
214, 217 multiple controllers, 64
ISO/IEC 27001, 36, 38, 39–41, 44, 45, 46, non-disclosure agreement (NDA), 36
53 non-EU cloud providers, 68, 83, 88, 95,
ISO/IEC 27002, 36, 38–39, 40, 41–44 98, 99, 100, 111, 113
ISO/IEC 27011, 39 in US, 88, 89–96, 111
IT services, comparisons with, 10–12 notification to the Office of the
application service provision, 11 Information Commissioner, 71–72,
batch computing/service bureau, 11 116–117, 119, 120
client/server, 11 exemptions, 71–72
grid computing or distributed Office of Fair Trading, 22
computing, 6–7 Open Cloud Manifesto, 213–214
managed services, 10–11 outsourcing, 2, 10, 11, 24–25, 34, 68, 83,
outsourcing, 10 84, 102–103, 145
software licensing, 108–111 guidance, 184, 185, 186, 187,
jurisdictional issues, 65–69, 86, 92, 203, 188–189, 201
204 Patriot Act - See USA Patriot Act
law enforcement agencies, 21–26, 27 permanent establishment, 208–209
legitimization of processing, 51, 62n32, personal data, 8, 28–29, 35–36, 55,
64, 70–71, 81, 83, 105 57–59, 60, 64–65, 69–70, 76, 81–82,
Lesser General Public License (LGPL), 220
133–134 sensitive, 59, 64, 69, 70–71, 111
liability issues, 12, 20, 28–29, 36, 54, SWIFT, 61
173–174, 181–182 transfers, 76, 78, 86, 88, 89, 91–92,
consumer contracts, 199–200 97, 102–103, 111, 113
direct losses, 174, 180
230 Cloud Computing

Index
platform as a service (PaaS), 6, 21, 50, Snapchat, 32–33

87, 143, 147, 149, 167, 201, 220 Twitter, 31
PlayStation, 32, 74–75 security policies, 34, 36, 41, 48–49, 141
Police Act 1997, 22 security standards, 28, 34, 37–38, 54, 61
PRA ’Fundamental Rules’, 118, 184–185 certification, 44–46
pre-contract due diligence, 82–83, 84 contractual effect, 48–53
Privacy and Electronic Communications ISO/IEC 27000 series, 38–46, 54
Regulations 2003 (PECR), 115–116 self-assessment, 39, 99, 101–104, 113,
private cloud (sometimes called an 127
’internal cloud’), 7, 11, 129, 131 Senior Management Arrangements,
Proposed Regulation, EU, 122–128, Systems and Controls (SYSC), 184,
215–216, 220 185–186, 187, 188, 189, 201
Prudential Regulation Authority (PRA), service credits, 157, 163, 167, 168, 169,
118, 183, 188 170, 171, 181
public cloud, 7, 131 calculation of, 163–164, 169, 170
public sector, 74, 117–118, 189–192, 202 exhaustive remedy, 164
’reasonableness’ test, 177, 178, 199–200 service level agreement (SLAs), 106–107,
Regulation of Investigatory Powers Act 110, 157, 158, 167–169, 172,
2000, 22 188–189, 217
right to be forgotten and erasure, availability, 161, 174, 175
123–124 force majeure, 165–166
rights to audit, 49–50, 54 service credits, 157, 163, 169
Rome I, 15, 18, 19 service response times, 160
Rome II, 15, 20 target or contractual level, 162
SaaS (software as a service), 1–2, 5, 6, 7, termination, 170
10, 11, 50, 129, 140, 143, 147, 220 third-party suppliers, 166–167
Affero, 134–135, 139 service levels or service metrics, 2,
copyleft problem, 133–134 157–159, 162–164, 172
escrow, 137–138 availability, 159, 160–162
liability issues, 176, 201, 202 elasticity, 160
onward transfers, 87, 100 problem resolution times, 160
third-party suppliers, 166, 167 service response times, 159–160
Safe Harbor, 68, 79, 89–96, 101, 104, standard exceptions, 164–167
111, 113, 221 target or contractual level, 162
Salesforce.com, 5, 158 termination for failure to achieve,
sanctions, 128 170
SAP, 149 seventh (data protection) principle, 69,
SAS 70, 46, 54 74, 75, 76, 79–80, 82, 84, 101, 103,
Search for Extraterrestrial Intelligence 221
(SETI), 6–7 Sidekick, 29–30
security breaches, 29–33, 53, 114–116 Snapchat, 32–33
Adobe, 32 software, 132–133, 136
Dropbox, 31 Affero, 134–135, 139
eBay, 33 copyleft problem, 133–134, 135, 139
Gmail, 30 GNU, 132, 133, 136
Google Docs, 30 GPL, 132, 133
Hotmail, 31 LGPL, 133
iCloud, 33 software escrow, 136–138, 139
PlayStation, 32, 74–75 software licensing, 129, 131–138, 139,
Sidekick, 29–30 151–152, 153
Cloud Computing 231

Index
restrictions on cloud deployment, Unfair Contract Terms Act 1977 (UCTA),

130–131 19, 176–177, 178, 179, 180, 181,
SSAE 16, 38, 46–48, 54 199–200
Type 1 Report, 47, 54 Unfair Terms in Consumer Contracts
Type 2 Report, 47–48, 54 Regulations 1999, 176, 177–178, 181,
stack of services, 7 199–200
Stallman, Richard, 3, 143n120 US Safe Harbor - See Safe Harbor
standard clauses, 97–100, 104, 113, 127, USA Patriot Act, 21–22, 23, 24, 25, 27,
221 79
SET I, 97 utility computing, 6
SET II, 97 VAT, 206–207, 211
statement of applicability (SoA), 36, viral effect in the cloud, 133, 134–135,
40–41, 45, 53 139
Stored Communications Act, 23–24 virtualization, 2, 9, 11, 49, 221
SWIFT, 60–61, 78 Working Party, 55–56, 61, 62, 67–68, 95,
tax considerations, 203, 204–208, 109, 111, 201–202, 219
210–211, 212 binding corporate rules for
technological terminology, 1, 9–10 processors, 105, 106, 109, 122
third-party suppliers, 35, 96, 105, 129, opinion on controller/processor, 61,
131, 137, 166–167, 205 78, 110
trademark infringement, 196–197 opinion on meaning, 61, 78
transfer pricing, 209–210 role, 55–56
Twitter, 31 SWIFT, 61, 78
Type 1 Report, 47, 54 Yahoo! in Belgium, 16–17
Type 2 Report, 47–48, 54
232 Cloud Computing

Bip 0117-2015

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bip 0117-2015

Uploaded by

Copyright:

Available Formats

Cloud Computing

A Practical Introduction to the Legal Issues

A Practical Introduction to the Legal Issues

BSI Standards Limited

© The British Standards Institution 2015

Typeset in Great Britain by Letterpart Limited, www.letterpart.com

Printed in Great Britain by Berforts Group, www.berforts.co.uk

British Library Cataloguing in Publication Data

ISBN 978 0 580 82246 9

2 Which law of the cloud? 15

4 Data protection: basics 55

5 Data protection: appointing a cloud provider 78

6 Transfers of data to non-EU cloud providers 86

7 Data security breach notification in the cloud 114

8 Data protection: the proposed reforms and the cloud 122

9 Software licensing and the cloud 129

10 Customer data: the provider’s use of data, access to

11 Service definition – the provider’s ability to change the

12 Service levels 157

13 Liability issues 173

Cloud Computing vii

14 Specific sectors 183

15 Tax considerations 203

16 The future of cloud law 213

viii Cloud Computing

I am grateful to my colleagues Daniel Hawthorne, a tax specialist at

1.1 Preliminary comments

A fuller definition of the terminology necessary to serve the aim of this

This book attempts to identify, discuss and elucidate many of the

(depending on the current price in each). Whilst this book is based on

Whilst this book is intended as a practical guide to these issues, it goes

1.2 History and development

• 1940s to 1950s: early beginnings in isolated research centres;

As this very approximate timeline is examined, it is possible to detect a

Others, implicitly recognizing that there was something new happening,

It seems likely that, new or not, the cloud is here to stay.

1.3 What is cloud computing?

• there will be no actual requirement for software installation at the

A basic categorization is between, on the one hand, a cloud service that

1.4 Cloud service types

1.4.1 SaaS – software as a service

It can be provided to enterprises (the main focus of this book) or to

There are a myriad of examples. An extremely common enterprise

There are, of course, also SaaS solutions tailored to very specific

Many of the most successful consumer-facing applications (Facebook,

1.4.2 IaaS – infrastructure as a service

S3) provides a cloud storage service, whilst Amazon Elastic Compute

1.4.3 PaaS – platform as a service

1.4.4 Utility computing

1.4.5 Grid computing or distributed computing

1.4.6 Other cloud service types

1.4.7 A stack of services

1.5 Deployment models

1.5.1 Public cloud

1.5.2 Private cloud (sometimes called an ‘internal cloud’)

Figure 1. Different types of offerings built on top of each other

1.5.3 Community cloud

1.5.4 Hybrid cloud

1.5.5 Consumer cloud

1.6 Technological terminology

Given the importance of the concept, a further word of explanation

same version number) but it will be a different instance (not least

Now assume that the software is provided remotely by a SaaS provider.