This article considers some international aspects of the EU Data Protection Directive as it affects cloud computing. This Directive, which extends to the European Economic Area (the EU plus Iceland, Liechtenstein and Norway), regulates the automated processing of personal data. It is currently being reviewed, with a draft reform measure expected over the next few months.
There are 2 key issues here:
- Impact on EEA cloud users - as is well-known, the Directive requires Member States to prohibit the transfer of personal data except to countries affording an 'adequate' level of protection. This restriction obviously inhibits EEA users from using non-EEA data centres for cloud computing, even if that offers costs savings or greater flexibility. While there are exceptions to the restriction, they are not straightforward, and it may be queried whether the data export restriction is still appropriate today, given the ease of data transmission and remote access to data via the internet.
This article deals with issue 1; a future article will deal with issue 2.
A preliminary note: EU data protection law obligations apply mainly to the 'controller', who determines the' purposes and means of processing' personal data. 'Processing' includes electronic storage as well as data transmission or access. Controllers may engage 'processors' to process personal data for them.
Generally, cloud users who process personal data in the cloud will be controllers unless an exemption applies, e.g. private use only, as with purely personal webmail. Cloud service providers are generally treated as processors. In some situations, providers may be controllers, e.g. because they determine 'means' of processing, although the position here is unclear and, as discussed elsewhere, there are grounds for arguing that IaaS/PaaS providers and certain SaaS providers ought not to be treated even as processors, but as neutral intermediaries. Under the current law, cloud storage providers will usually be 'processors'.
When are non-European cloud users or providers subject to EU data protection laws?
Article 4 of the Directive requires Member States to apply data protection rules to controllers who process personal data in the 'context of the activities' of their EEA 'establishment', or who are not 'established' in the EEA but, for purposes of processing personal data, 'makes use of' equipment (or 'means', in some languages) situated in the EEA.
The application of article 4 to cloud computing is complicated by the fact that many cloud computing service providers don't own the data centres or equipment they use, and indeed may well use the resources of other cloud providers (typically IaaS or PaaS providers), who in turn may ultimately use data centres, servers and storage equipment rented from or managed by third parties. For instance, it was only in 2010 that consumer SaaS service Twitter started using its own dedicated data centres, while many of enterprise SaaS service Salesforce's data centres are are co-located. An example of a SaaS provider building its service on IaaS, i.e. a double 'layer', is Dropbox on Amazon S3. A SaaS or PaaS service could be built on IaaS (e.g. dotCloud's PaaS on Amazon EC2), and SaaS could be built on PaaS (eg Google App Engine applications or Windows Azure applications). Even a triple layer of SaaS on PaaS on IaaS is possible, eg Facebook apps on Heroku on Amazon .
This means that cloud users don't necessarily know in which data centres or even countries their data are stored or where their processing operations are run, or which sub-providers are used by the provider with whom they have the direct relationship. Indeed, even cloud service providers who use other providers' resources (e.g. a SaaS service layered on IaaS or PaaS) may not necessarily know which data centres or countries are involved.
Establishment and context
Does use of a data centre located in the EEA to store or otherwise process personal data, constitute processing in the context of activities of an EEA establishment under article 4(1)(a)? This question is relevant not just to cloud computing, but also to traditional outsourcing using EEA data centres.
Legal uncertainties arise because it's unclear what 'establishment' and 'context' mean. Those who like to criticise lawyers for hairsplitting over words may wish to reach for a cold towel now, as it's impossible to try to apply article 4 otherwise.
An 'establishment' is generally taken to involve the ‘effective and real exercise of activity through stable arrangements’.
It's generally considered that one server does not an 'establishment' make - but what about a data centre or server farm, a building full of equipment with staff to guard and maintain it? Does that provide enough stability to constitute an establishment, e.g. when used for a self-hosted private cloud?
Arguably, a data centre is not an 'establishment' of those processing data using its servers, or, even if it is, the processing is not in the context of the data centre's activities, but in the 'context' of economic activities of the user elsewhere. E.g. if a US corporation processes personal data for its US business using an EEA data centre, surely the processing is in the 'context' of the US business's activities, not in the 'context' of the data centre's activities as a mere processing centre. In other words, it's activities as controller, not processor, that should be relevant for article 4(1)(a). Indeed, article 4(1)(a) itself refers to an establishment 'of the controller'.
Similarly, if the US corporation has a separate office in the EEA, say for marketing or licensing activities, but the processing within its EEA data centre is by and for its US business, logically the processing is in the context of the US business's activities (even if the data centre is an 'establishment' of the US corporation), not the EEA marketing office's activities.
However, EU data protection regulators interpret 'context' more widely. In 2010, an Italian court convicted a number of Google executives for breach of Italy's data protection law in relation to a video uploaded to Google Video, even though the video data were not processed in servers in Italy, and decisions about content were not made in Italy. Google had an advertising/marketing establishment in Italy, Google Italy, and the judge considered that Italian law applied because the processing was in the 'context' of Google Italy's activities. Similarly, EU data protection regulators collectively, in the form of the Article 29 Working Party (A29WP), think that when a non-EEA search engine provider has an EEA establishment, its processing (outside the EEA) of personal data is in the 'context' of the EEA establishment's activities - even if the establishment doesn't perform or direct any processing operations, but only deals with local search engine users, sells ad there or complies with local law enforcement requests for user data. It seems the notion of ‘context’ is not being linked to the processing activities of the establishment as a controller who determines the purposes and means of that processing. Arguably, it should be.
It is also possible to have an 'establishment' in the EEA through a third party, e.g. an agent. Legal ownership is not determinative. An EEA data centre owned/operated by a third party, such as a managed data centre dedicated to a single non-EEA customer for a private cloud, may still be considered an 'establishment' of the user if there is enough stability and control over the third party. However, when a non-EEA cloud user uses an EEA data centre through layers of providers, e.g. SaaS on IaaS, the EEA connection seems further removed, particularly if the direct provider is not EEA-based.
There's a stronger argument that the data centre is not the user's EEA 'establishment' if the user doesn't even know that an EEA data centre is to be used and has little control over that data centre's activities. Also, public cloud services usually have multiple customers, so any one user may have less control over the provider, which again may make it less likely that the data centre could be considered an 'establishment' of a public cloud user. However, the position is unclear.
To complicate matters, what if data centres in more than one Member State are used, e.g. for distributed processing of the same dataset? Member States have implemented the Directive into their national laws inconsistently (notably as regards security requirements), so in this situation the same processing could be subject to the laws of more than one Member State, which might conflict with each other.
The 'equipment' ground under article 4(1)(c) of the Directive is very wide. EU data protection regulators consider, not without controversy, that if a website sets or reads cookies on the computer of an EU user to process personal data, that is 'making use' of equipment in the EU, so as to entitle the EU State concerned to assert data protection jurisdiction over the site owner/controller. This would be relevant to many SaaS services that save cookies or the like on EEA users' computers. This approach applies EU data protection law to many online services worldwide, and it might be questioned to what extent an EU State can in practice enforce its laws against someone not in that State, e.g. a US corporation with no presence in the State.
Servers and storage devices are 'equipment'. Whatever the position regarding EEA data centres under the 'establishment' ground, if EEA data centres are used for cloud computing, then it seems the users are 'making use' of equipment in the EEA to process data, even for users based outside the EEA. If the data processed include personal data, then theoretically the user could be required to comply with EU data protection laws in relation to the processing inside the EEA data centre. In this situation, it is irrelevant who legally owns the equipment.
The A29WP said in The A29WP said in its opinion on article 4) that (WP179) that ‘making use’ involves two elements: (i) some kind of activity of the controller, and (ii) the clear intention of the controller to process personal data. This isn't helpful regarding the use of EEA data centres for processing personal data, because there the controller clearly intends to process personal data, and carries out processing activity. Unfortunately, there's no discussion of any intention of the controller to use EEA equipment to process personal data, although that seems implicit. Thus, the position is unclear.
Because of the possible layering of providers/infrastructure, even with a single provider the user may not know where its provider will process its data. Suppose that a US corporation, to process personal data, uses a service from a US cloud provider which, behind the scenes, uses an EEA data centre. (This may be unlikely for market and latency reasons, but let's run with it.) In that case, the US corporation is using equipment in the EEA, so EU data protection law may apply to that processing - even if the data relate to US residents and were collected in the USA. Indeed, on importing the data to the EEA data centre from the USA, the Directive's data export restriction could apply, limiting whether and how it may be re-exported back to the USA! Yet the US corporation would not necessarily know that its data were being processed using EEA equipment.
Particularly where more layers are involved and a user doesn't know EEA equipment is to be used, it may not intend to process personal data using EEA equipment. But it certainly intends to process personal data actively using equipment somewhere. Because the position on intention to use EEA equipment is uncertain, the controller still risks being subject to EU data protection law. It would be desirable if any update of EU data protection laws dealt explicitly with the significance, if any, of the end user's knowledge and/or intention that ultimately EEA equipment is to be used for their processing.
For example, should a user be forced to ask its direct provider which other providers are involved in lower layers of the cloud 'stack', and in which country the equipment used is located? For security and other reasons, many providers are reticent about the location of their data centres, or those used for particular users or services, so, even if the user asks, the provider may not be willing to disclose the relevant location(s).
These uncertainties may put off non-EEA users from using EEA cloud providers or EEA data centres. Interestingly, in March 2011 the French data protection regulator CNIL CNIL passed a new law designed to encourage non-EEA users to use providers located in France. CNIL allowed certain exemptions from French data protection law for processing of certain types of personal data for limited purposes, when performed by French service providers on behalf of controllers established outside the EU, and will allow transborder data flows 'back' to these non-European companies. It's not clear whether the Directive permits Member States to allow these kinds of exemptions, but it seems telling that the CNIL felt it necessary to pass this law.
There's one final complication, due possibly to a drafting oversight. Under article 4(1)(c), the equipment ground only applies if the controller is 'not established' in the EEA, but with no reference to 'context'. This leaves a possible loophole. If a non-EEA controller has an EEA establishment, but the establishment doesn't process personal data in the context of its activities, the establishment ground can't be used to apply EU data protection law to the processing (as the establishment ground refers to 'context').
However, because the controller has an establishment in the EEA, the equipment ground can't apply either! To get round this possible lacuna and enable use of the equipment ground to take jurisdiction over non-EEA controllers, EU data protection regulators consider that any EEA establishment (like a marketing office) is 'irrelevant' and doesn't count for the purposes of disapplying the equipment ground unless, effectively, it processes personal data in the context of its activities. If its activities are unrelated to the processing of personal data, it is ignored for the purposes of article 4(1)(c).
To illustrate the practical complexities, the tables below summarise the position of a non-EEA entity Customer, which for cloud computing services directly or indirectly uses data centres in the EEA (in Member State DataCentreState, or in some scenarios both Member States DataCentreState and another Member State).
Customer customer or user of cloud computing services, being an entity incorporated in a non-EEA country; Customer will usually be a controller of personal data. We assume Customer is incorporated and based in a non-EEA country, and collects personal data in that country for its business there, where the data relate only to residents of that country. We also assume Customer has no other presence in the EEA, unless otherwise stated.
Provider provider of cloud computing or related services.
DataCentreState data centre country, being here an EEA Member State in which a data centre used in cloud computing is located.
Multiple means several data centres in different EEA Member States are used, between which personal data may flow automatically.
The tables summarise in each alternative scenario whether EU data protection law could be applied to Customer, based on either the:
- establishment/context ground (‘effective and real exercise of activity through stable arrangements’), or
- the equipment ground (‘if the controller, by determining the way how [sic] the equipment works, is making the relevant decisions concerning the substance of the data and the procedure of their processing’, and (i) some kind of activity of the controller, and (ii) the clear intention of the controller to process personal data).
If Provider is considered to determine ‘purposes and means’ of the processing so as to be considered a controller (for example through its choice of data centre(s) or any sub-provider used), then the analyses regarding Customer would apply to Provider.
||Type||Variations||Establishment and context?||Equipment?|
|1||Private cloud - self-hosted||A. If Customer owns the data centre/servers||Uncertain. There may be enough stability for an ‘establishment’, especially if Customer’s employees maintain the servers. However, arguably the personal data processing within the data centre is not ‘in the context’ of the data centre’s activities. The position is unclear.||Yes|
|B. If Customer rents space/servers||As in 1A. Possibly, stability increases if Customer uses more space/servers, particularly if its employees maintain the servers. Conversely, arguably the number of servers/employees dedicated to Customer should not matter - nothing turns on the ‘size’ of an establishment, only whether there is an establishment. As above, the ‘context’ question is unclear.||Yes|
|C. If Customer has an establishment O in the EEA, eg marketing office for hardware sales or software licensing||Arguably, same as above.
However, the wide view of ‘context’
taken by the A29WP raises the risk that the processing in DataCentreState
could be deemed to be in the context of O’s activities.
|This is the apparent lacuna in art 4(1)(c). WP179 would consider O to be an ‘irrelevant’ establishment, so that Customer is still considered to be making use of equipment in DataCentreState.|
|D. Multiple||Uncertain. Either there is
insufficient ‘stability’ in both DataCentreState and the other
State, as data are not definitively in one centre or the other, or Customer
has establishments in both states, subjecting the same
processing to the laws of both DataCentreState and the other State.
Whether the second data centre is used for full replication/backup or
just for ‘overflow’ may be relevant.
The context issue again arises here.
|Yes, Customer would be subject to the (possibly conflicting) laws of both DataCentreState and the other State for the same processing, if the distributed processing employs equipment in both those states.|
|E. Lights out data centre||Uncertain. Customer may still control processing operations in the centre, albeit remotely.||Yes|
|2||Private cloud - data centre dedicated to Customer, owned and managed by Provider||A. If Provider is incorporated/ established in DataCentreState||It is uncertain to what extent Customer may be considered ‘established’ in DataCentreState through a third party, eg Provider or Provider’s data centre. Relevant factors may include the extent to which the data centre is dedicated to Customer, and the extent of Customer’s control over activities in the data centre through its contract with Provider (possibly Customer may be afforded greater control if it is Provider’s only customer using that data centre). Again, the context question remains relevant.||Probably, although in a sense Provider also determines ‘how the equipment works’. It seems that a case by case assessment should be undertaken to avoid ‘undesirable consequences’.|
|B. If Provider is incorporated/ established in the other State||Uncertain. Customer risks being considered to have an establishment in DataCentreState, through the dedicated data centre in DataCentreState; and possibly also in the other State, through using Provider’s services, as Provider is incorporated in the other State. This depends on the national laws of DataCentreState and the other State. Again, the context question is relevant.||Very probably, in DataCentreState - see 2A. the other State’s law determine whether Customer is using ‘means’ in the other State through its use of Provider, although the data centre is in DataCentreState.|
|C. If Provider (non-EEA) has no other EEA presence||Uncertain. See 2A: could the
data centre be attributed to Customer nevertheless, because it is dedicated
to Customer? Again, the context question arises.
||Very probably, in DataCentreState - see 2A. The processing is still conducted on EEA territory, ie DataCentreState.|
|D. If Provider rents the data centre/ servers||Ownership should not matter, but it is unclear to what extent the number or proportion of servers/employees dedicated to Customer affects whether it has an establishment, see 1B.||See 2A. Ownership/full control is unnecessary. ‘Intention’ is, but activity in the EEA plus intention to process personal data suffices.|
|E. Multiple||If Customer is considered to have an ‘establishment’ through Provider or the data centre, see 1D.||Yes, in both DataCentreState and the other State - hence, both their laws would apply to the same processing.|
|F. If Provider is a subsidiary of Customer||Customer may be more likely to be considered to have an establishment through Provider if Provider is its subsidiary, in some States.||Customer would be using equipment in DataCentreState; but, if Provider is incorporated in a Member State that considers a subsidiary to be ‘means’, Customer risks being considered to use ‘means’ in that Member State also.|
||Type||Establishment and context?||Equipment?|
|3||Public cloud - Provider provides IaaS, PaaS or SaaS to Customer; Provider has server space in a data centre (or whole data centre)||Depends on type of service and exact nature of service, but generally use of IaaS may be more likely to constitute an ‘establishment’ of Customer than PaaS or SaaS, and Customer’s knowledge as to use of EEA data centres and the extent of its control may be relevant. As above, it is irrelevant whether Provider owns or rents the data centre, space or servers. Similar questions as above arise on ‘context’, and, if Provider uses multiple EEA centres, on sufficient stability, and multiple laws possibly applying.||Depends on the service. Whether Provider owns or rents infrastructure is irrelevant. If Provider uses data centres in multiple EEA states and equipment use is attributed to Customer, multiple laws may apply to Customer.|
|4||Public cloud - Provider provides cloud services to Customer using Provider2’s IaaS or PaaS service; Provider2 has server space or whole data centres||The EEA data centre is even more removed from Customer than in 3. Similar questions arise as in 3 as to the extent of Customer’s control or knowledge of the use of Provider2’s EEA data centres, but Customer would have to delve deeper into the cloud stack to find out. Should it be required to? Other issues are also similar eg context.||The extra layer may affect whether Customer has the necessary intention, but the position is unclear (see 2D). Knowledge that Provider2’s data centres are in the EEA may be relevant, but the position is further removed.|
|5||Public cloud - Provider provides cloud services to Customer using Provider2’s IaaS/PaaS service, which uses Provider3’s IaaS service; Provider3 provides the servers in data centres||This illustrates that even more layers are possible, including a further layer still if Provider3 does not own the data centres but rents space/servers. As with 4, a key question is whether the further removed the data centre is from Customer, the less likely it is to be considered Customer’s establishment. Again, context is an issue.||As 4, but the position is even further removed.|
|6||Lights out data centre||Depends more on type and nature of service, and layers between, than on whether the data centre is remotely controlled.||Depends on service and layers.
The way forward?
For understandable consumer protection reasons, EU lawmakers consider that, in some circumstances, EU data protection jurisdiction should extend extra-territorially to non-EU service providers who process the personal data of EU consumers. However, the current legal uncertainties are unsatisfactory, and may disincentivise the use of EEA cloud providers or EEA data centres. It may also be asked whether a more focused approach would meet with greater success in achieving the desired policy objectives than an approach that may be overly, sometimes unrealistically, broad.
Policymakers need to consider, decide and set out clearly:
- in exactly what circumstances should a non-EEA entity be regulated because it uses an EEA data centre (or space/servers in a data centre) or an EEA provider, including the relevance of:
- layers of providers,
- the entity’s actual or deemed knowledge (or not) about EEA infrastructure (or infrastructure in a specific Member State) being ultimately used, and
- the entity’s ability to choose (or not) whether EEA infrastructure should be used, and
- what regulations should be applied to such a non-EEA entity (if at all), such as when the personal data processed do not relate to EEA residents and do not originate from the EEA.
There are significant precedents within the EU for an approach based on location of economic activities rather than location of technological equipment, such as in relation to the EU E Commerce Directive, insurance services and online gambling. It is hoped that, for EEA controllers, the data protection law reforms will provide for applicable law to be that of a single country of origin, with clear rules as to how that country is determined. Substantive harmonisation of data protection laws would be a pre-requisite.
For non-EEA controllers, rather than over-stretching the meaning of ‘equipment'/'means’, data protection law jurisdiction should be based instead on the targeting by the controller of EU residents, as with the test for jurisdiction in consumer contracts under the Brussels I Regulation, elaborated in a 2010 European Court of Justice decisision.
Finally, the status of providers of the physical and software infrastructure, as well as intermediate providers, would also benefit from clarification. To reduce uncertainties for cloud service providers, consideration should be given to enacting specific provisions regarding processors, with clear rules for determining which State’s security requirements apply to processors, ie determining EEA ‘establishment’ or its equivalent for processors.
A future article will cover the impact on cloud computing of the data export restriction under the Directive
Research Assistant, Cloud
Legal Project, Centre for Commercial Law Studies, Queen Mary,University of London.
Other articles in this series:
- Cloud computing contracts and services: What's really happening?
- Data protection, the law and you - The cloud of unknowing, and the "personal data" problem
- Who's responsible for personal data in cloud computing? You and your Saas, Paas and IaaS providers
- Law enforcement agencies' access rights to your cloud data