With cloud computing, many fear losing control. True, supply chains may be complex: services may be layered; separation of ownership, control and use is common not only for services, but also software and hardware. However, users can retain control in cloud computing—depending. But given the increasing virtualisation and, more significantly, abstraction of computing resources that cloud computing enables, logical control trumps physical control—whether in terms of computing, storage or networking. In particular, it is logical control over access to data that matters most.
The Data Export Restriction
Consider the data export restriction under Articles 25-26 of the Data Protection Directive (DPD). This bans any “transfer to a third country” (outside the EEA) of personal data, unless certain qualifications are met, e.g., use of model clauses or the EU-U.S. Safe Harbor framework. The original legislative purpose of this restriction was anti-circumvention: to stop controllers from avoiding being subject to substantive DPD principles simply by moving personal data to a third country. Against the background of the 1990 proposal’s requirement that EC member states apply its data protection laws to “all files located in its territory,” the restriction made sense.
Recognizing the difficulty or impossibility of determining physical location of electronic data, the 1992 amended proposal changed this jurisdictional basis to use of 'equipment' in the EEA. Furthermore, it subjected EU-established controllers to DPD principles regardless of where the data were “located.” However—crucially—the restriction was neither deleted nor consequentially amended even though, arguably, following deletion of the 'EU-located data' jurisdictional basis, there ceased to be good reason on anti-avoidance grounds to restrict data locations.
Take websites. If EEA controllers publish personal data on websites, they must do so in compliance with the principles. If it is not fair and lawful to make certain personal data available publicly on a website, then it shouldn’t be published, regardless of provider or server location or the restriction.
Problems with Transfers and “Third Country”
The fact that that “transfer to a third country” is undefined poses another problem. What does “transfer” mean in the age of the Internet?
In Lindqvist, the European Court of Justice decided there was no “transfer” when a volunteer uploaded personal data to an EEA-established web hosting provider's server, noting that if the restriction were interpreted such that a “transfer” occurred with every webpage upload of personal data, the restriction's 'special regime' would apply generally and prevent any uploading of personal data on the Internet if even one third country was found inadequate.
The European Data Protection Supervisor considers Lindqvist to mean the restriction doesn’t apply to public websites, but applies only to sites where transfers are intended to specific third countries, such as an intranet with known users/locations.
To the UK Information Commissioner, a “transfer” occurs upon access by third country visitors if the uploader intends, or is presumed to intend, to give such visitors access, similar to The Netherlands’ submission to the Lindqvist court.
Accordingly, I suggest intention to enable those subject to a third country’s jurisdiction to access personal data seems a better test than “transfer.”
Lindqvist might suggest that no “transfer” should occur if EEA controllers use EEA-established cloud providers to process personal data, irrespective of server locations. However, data protection authorities consistently interpret “transfer” as “movement of personal data’s physical location to a third country”, e.g., in the well-known Swift incident.
In Odense, a Danish municipality wished to use Google Apps *SaaS. The Danish DPA considered that there might be impermissible “transfers” because personal data could be processed in data centres in “Europe” outside the EEA, unless a recognized mechanism such as model clauses was used. But a data centre is not a legal entity that can sign a contract. Contracts may only be made with whoever owns/operates the data centre—here, Google Inc. Transfers to Google’s U.S.-located data centres were permissible because it participates in Safe Harbor, yet transfers to Google’s data centres located in any third country were not, absent model clauses or the like—despite Google's binding Safe Harbor commitments.
This approach was perpetuated in the Article 29 Working Party’s subsequent cloud computing opinion (WP196). It also stated that the current legal framework “may have limitations” because controllers lack real-time knowledge of cloud locations. However, arguably, the limitations relate not to such lack of knowledge, but to DPAs’ requirement that controllers must always have such knowledge.
The restriction has become what I call a Frankenrule: it has taken on a life of its own. Separately from, and regardless of, compliance with the DPD's substantive principles, many DPAs insist on physical location of data within the EEA, or use of permitted mechanisms like model clauses or derogations.
Data Location and Data Realities
Consequently, cloud providers are increasingly allowing users to choose data location. The associated costs, e.g., building EEA data centres) are likely to be passed on to users, reducing one of the benefits of cloud.
But today, storage and processing of a dataset, including metadata and temporary caches, may be distributed across different equipment in one or more data centres. Data and processing operations are often replicated to multiple locations within and across data centres. Thus, data movements are often frequent, multi-point and/or multi-stage. Data are accessible remotely via Internet or private network without physical access to storage equipment; conversely, data may be physically moved to a third country without anyone in that country having access to intelligible data, if, for example, it’s been encrypted beforehand.
Nowadays, physically confining data to the EEA does not equate to or guarantee data protection. Yet vast amounts of time and resources are poured into compliance with the restriction, which could be better spent on improving information security.
Although current reform proposals, notably the draft General Data Protection Regulation, aim to modernize laws, they could hold back cloud computing. Instead, let’s go back to basics. The restriction’s legislative purpose was to ensure compliance with DPD principles. The “what” is compliance. The “how” is control over logical access to personal data, particularly intelligible personal data. Here, information security plays a major role to protect confidentiality, integrity and availability.
Physical location is just one factor. It is relevant to security, but shouldn’t be considered an end in itself. Indeed, multiple physical locations may enhance security; e.g. backups in different countries to mitigate natural disasters’ impact on availability and integrity or governmental attempts to take down services or trace users.
So we return to the role of technology and effective jurisdiction. A country may claim jurisdiction on any basis it likes, but its claims may be ineffective unless it can enforce them. In practice, this requires some real connection with that country: incorporation, an office, staff and/or assets there. Separation of ownership/use of resources, combined with remote access, encryption and backups elsewhere, may positively protect cloud users against the country of data centre location having effective jurisdiction over them, as exemplified by file-sharing facilitator The Pirate Bay’s move to the cloud.
Controlling logical access to personal data, particularly intelligible data, is far more important than physically restricting data location to the EEA. The focus should not be on where personal data are located, but on who can access personal data, how (and how to control such access) and, crucially, what they can do with the data and why. Let’s not lose sight of the DPD’s principles.
To achieve a better balance between data protection and international commercial/social data flows, we don’t need to restrict physical data location: we need better, more technologically-neutral rules regarding security, transparency and accountability that properly recognize the role that code, not just law, can play in protecting personal data.
It is therefore heartening that the Trusted Cloud Europe policy vision document, recently issued by the European Cloud Partnership’s Steering Board for feedback by 2 May 2014, contemplates the possible reduction of data location restrictions in similar vein: “it is often possible and advisable to replace formal legal requirements (such as geographic location of the data) by the corresponding functional requirements (such as ensuring the accessibility and security of the data).”