This part summarises how EEA cloud users are affected by the Directive's requirement that EEA countries must prohibit transfers of 'personal data' outside the EEA, except to countries affording an 'adequate' level of protection - meaning, a standard in keeping with the Directive's main principles.
This international transfers restriction (Restriction) applies even if the EEA user transfers personal data internally, to its own (non-EEA) branch or group company.
The general view is that the Restriction would apply if, in order to process or store personal data, an EEA controller uses a cloud provider who employs data centres outside the EEA, so that data may flow to non-EEA data centres. This is one driver behind cloud providers increasingly offering European customers the option to confine data to EEA servers only.
Indeed, non-EEA users who process personal data, but use EEA cloud providers or any providers who employ EEA data centres, could theoretically become subject to EU data protection laws. The Restriction could apply when trying to 're-export' the data - even data originally collected outside the EEA, relating only to non-EEA individuals. This must raise issues about enforcement against non-EEA users.
To maximise efficient resource utilisation, in cloud computing automated software may replicate or move data between different data centres, possibly even in different countries. Some cloud providers may know or be able to pinpoint the exact geographical location of certain data at any one time, but are reluctant to share that information with their users, for security or other reasons. However, other providers can't verify data location.
Even where all relevant data centres are confined to the EEA, if non-EEA staff access personal data, eg for support queries, that could involve a 'transfer' to them.
It's not just deliberately uploading personal data to a cloud service that may trigger the Restriction. E.g., a German data protection regulator required local website owners to deactivate the Facebook 'Like' plugin etc on their sites, on the basis that it would transfer visitors' personal data to Facebook in the US, which was not allowed without visitors' prior informed consent.
So, how can cloud users who are 'controllers' of personal data comply with the Restriction?
The European Commission has decided that certain countries have 'adequate protection': Andorra, Argentina, Canada (where the Canadian Personal Information Protection and Electronic Documents Act 2000 applies), Switzerland, Faeroe Islands, Guernsey, Israel, Isle of Man and Jersey.
Personal data may therefore be transferred to data centres in those countries for processing there. But that whitelist is short. How else can 'adequate protection' be achieved?
Data subjects (individuals to whom data relate) could be asked to consent to transfers of their personal data outside the EEA. However, that's generally considered inadequate for repeated or regular transfers, as opposed to one-off transfers, because strict conditions apply and, if consent is withdrawn, the position could be difficult to unwind.
Also, the person transferring data may not be the person whose consent is needed, as in the German example above. It may depend on the circumstances.
Therefore, in practice, other methods are usually considered safer for compliance.
US organisations (including cloud providers) that import personal data from the EU can show an adequate standard of protection by participating in a 'Safe Harbor' programme, a self-regulatory regime established by an agreement between the EU and US. However, certain organisations aren't eligible, notably telecommunication common carriers and financial institutions.
Currently most large cloud providers are US-based, so it might seem that Safe Harbor would be the obvious way to facilitate EEA controllers' use of US cloud services.
However, doubts have been raised about the efficacy of Safe Harbor, particularly by German regulators. For instance, Safe Harbor has been in place since 2000, but the US Federal Trade Commission took its first action for breach of Safe Harbor principles only in 2011 - against Google, regarding its Buzz service, for not giving notice or choice to users when it used information collected for Gmail for different purposes.
The Danish regulator has ruled, in relation to Google Apps, that Safe Harbor can only be used if the personal data transferred are processed in data centres located in the EEA or US - and only there. Stating 'Europe' for data centre locations wasn't considered good enough, as some European countries aren't in the EEA.
Furthermore, the position on 'onward transfers' to third parties of personal data initially transferred under Safe Harbor is unclear.
The cloud provider receiving the initial transfer under Safe Harbor could be using a sub-provider's services - typically, SaaS layered on IaaS or PaaS. For example, Dropbox's SaaS storage service is built on Amazon's IaaS infrastructure service, so here Dropbox is the provider, Amazon the sub-provider. As the status of the IaaS or PaaS sub-provider under Safe Harbor is uncertain in such a situation, it's unclear what requirements must be met for 'onward transfer' of data to the sub-provider whose infrastructure is being used. Similarly, there may be issues if a controller wants to allow third parties access to personal data originally transferred under Safe Harbor.
'Adequate protection' may be provided by making transfers under contractual clauses in form approved by the Commission.
There are two main sets of these model clauses: for transfers from controller to controller, and from controller to processor.
Providers are generally considered 'processors', although in some cases they may be controllers (the dividing line isn't clear enough), and in others, perhaps neither.
However, model clauses have their limitations. They must be used without any changes, although they can form part of a larger contract. So, they can only be used if the provider is willing to agree to commitments under them, 'as is'. Also, model clauses won't help where the provider is not even a processor, or the processor set of clauses was used but the provider turns out to be a controller!
Furthermore, there are issues with a layered situation (again, think SaaS on IaaS/PaaS) where the provider offers services based on the IaaS/PaaS services of a non-EEA sub-provider. In this scenario, an EEA controller can use model clauses only where the provider is itself non-EEA - but not where the provider is EEA-established.
Covered by model clauses?
In the latter case, signing model clauses with the provider won't work; the non-EEA sub-provider needs to sign up to model clauses direct with the controller, or with the EEA provider acting for the controller - or sign an ad hoc contract with the controller, which regulators may or may not approve.
This means that, in a layered situation involving non-EEA sub-providers, it may actually be easier for EEA controllers to use non-EEA providers. This may drive business away from EEA providers. The unequal position of EEA and non-EEA providers of cloud services that are based on, eg, Amazon, Google App Engine or Windows Azure, seems unintentional - but it is what it is.
Furthermore, if non-EEA controllers use EEA data centres or EEA providers to process personal data, model clauses can't be used to 're-export' the data. That may put non-EEA cloud users off from using EEA providers or data centres.
So in many ways, current laws actually discourage customers who are controllers of personal data from using EEA providers or EEA data centres!
Hopefully, in future lawmakers will remove these disincentives. A draft Data Protection Regulation to reform current laws was proposed by the Commission in January 2012, and is going through the EU legislative process currently. It would allow transfers under model clauses adopted or authorised by a supervisory authority, as well as by the Commission, which is helpful. Suitable model clauses rectifying this problem, and covering processor to processor transfers, would be welcome.
'Binding corporate rules' are codes of conduct governing international transfers of personal data within the controller's multinational corporate group, meant to be enforceable by data subjects.
Personal data may be transferred under BCRs approved by relevant authorities. However, the process for obtaining regulatory approval of BCRs is long and expensive, with different countries having their own procedures, and some data protection authorities still require individual approval of individual transfers made under approved BCRs. BCRs might assist data transfers within a corporate group’s private cloud, though.
There have been only a handful of BCRs to date, for large global groups that can afford the time and money.
The draft Regulation would require EEA-wide recognition of BCRs, and also envisages allowing BCRs within processors' corporate groups. That would help, but transfers are still restricted to within the group. Extending BCRs to allow transfers within a community cloud, eg of unrelated financial services organisations with shared high security requirements, might be even more helpful.
Own adequacy assessment
Even without any of the above, controllers may still be able to provide 'adequate safeguards' for international transfers. The UK regulator doesn't pre-approve transfers, but lets controllers make their own adequacy assessments. However, most other EEA countries won't allow this, and it may be time-consuming and costly to seek approval for every ad hoc data transfer contract.
The draft Regulation would allow transfers only under Commission adequacy decisions, or if 'appropriate safeguards' for data protection are adduced 'in a legally binding instrument' (such as BCRs or model clauses). That may stop authorities from allowing controllers to make their own adequacy decisions, and seems retrograde. It could increase bureaucracy and requests for regulatory pre-approvals. Wouldn't regulators' resources be better directed towards investigating and enforcing data protection law breaches, rather than approving routine transfers?
Given the issues outlined above, it's not surprising that currently the easiest practical way to deal with the Restriction is simply to keep personal data within the EEA.
Some providers allow customers to choose the geographical region for their data/applications. However, as flagged above, for controllers to comply with the Restriction it may not be enough to offer "Europe" or even "Western Europe" as a region; providers need to offer "EEA", or list named EEA countries.
Even providers who allow users to specify "EEA" or particular EEA countries may not commit contractually to keeping data in the chosen region, although eg Amazon does now agree not to move data from the selected region without notification (unless required by law/authorities).
A final problem is that EEA countries have implemented the Directive differently, so their data protection laws are not identical. For example, UK security requirements are relatively general and high level, whereas Italy requires many detailed measures.
This means that personal data moving between data centres in different EEA countries could be subject to different legal requirements at different times, even within the EEA! That's obviously not very satisfactory, and one aim of the draft Regulation is to harmonise data protection laws across the EU. Being a Regulation rather than Directive, its provisions would apply directly throughout the EU when it takes effect, without countries having to pass any implementing legislation.
However, direct effect isn't enough. To achieve true harmonisation, the Regulation needs to be sufficiently clear and certain. But, in many respects, it isn't. Different countries, authorities and courts might interpret it differently. More work is needed on the draft Regulation.
The Restriction obviously inhibits EEA users from using non-EEA data centres (or providers who use non-EEA data centres) for cloud computing, despite cloud's potential costs savings and greater flexibility. Furthermore, data protection laws are not sufficiently clear or harmonised across the EEA. While there are exceptions to the Restriction or ways to achieve adequacy, they are not straightforward.
As technology improves, costs reduce and customers increasingly demand greater transparency for regulatory compliance and other reasons, perhaps more providers will, to maintain or increase market competitiveness, offer users capabilities to monitor data location etc, at least to country level - whether as a standard or additionally-priced feature.
It's also not inconceivable that in future servers could be housed in ships or aircraft in or over international waters, flying the flag of an EEA country. Google has patented floating data centres, while the Pirate Bay is considering using servers on drones in low orbit, although for other reasons and probably not sporting any EEA flags!
However, let's step back and ask a more basic question. Is the Restriction really still appropriate today? It was written in the days of floppy disks and stand-alone databases, based on the assumption that data physically located in a particular country would risk being accessed by unauthorised third parties in that country.
But surely this assumption has been undermined by technological developments and globalisation, particularly the ease of data transmission and remote access to data via the internet. Personal data may be emailed, instant messaged, tweeted or copied to recipients in multiple countries across the globe instantly, as well as being available internationally on websites - and even accessed remotely by hackers.
Wouldn't a better, if more radical, solution be to abolish the Restriction altogether? Restricting data location isn't the only or even best way to prevent unauthorised access to personal data. Shouldn't the availability of encryption be recognised? What's more at risk: strongly-encrypted data stored outside the EEA on servers with no network connection, or unencrypted data on insecure internet-connected servers in the EEA? Isn't it relevant that cloud data may be stored in fragmented form using proprietary file systems, so that seizing equipment or even a data centre may not necessarily result in unauthorised access to data (unless the provider cooperates)?
Rather than specifically restricting data location, why not simply focus on requiring appropriate security, transparency and accountability requirements that are technologically neutral and take into account cloud computing's characteristics, with data location being just one factor that may affect data security?
The draft Regulation would not do that. While in some ways it tries to address certain of the problems mentioned above, in other ways it may make international data transfers more difficult, as discussed previously.
It seems unfortunate that the opportunity wasn't taken to allow appropriate safeguards to be provided using technological means, eg by the controller using encryption and taking its own backups.
The draft Regulation would allow transfers necessary for ‘the purposes of the legitimate interests pursued by the controller or the processor’, where it's secured appropriate safeguards. However, that won't be allowed where transfers are ‘frequent or massive’. But how much or often is 'frequent or massive'? It's not clear enough. More importantly, shouldn't the focus simply be on having appropriate safeguards, whatever the size or frequency of transfers?
In summary, restricting data export per se, rather than emphasising security, accountability and transparency (wherever in the world data are processed), may hold back the efficient use of cloud computing, and the draft Regulation would exacerbate this.
The full paper by Kuan Hon and Prof Christopher Millard detailing the above (including tables showing how the Restriction applies to various permutations of locations of cloud user, provider and data centre), is available for free download: Data Export in Cloud Computing - How Can Personal Data Be Transferred Outside the EEA? The Cloud of Unknowing, Part 4
Kuan Hon, a non-practising English solicitor and New York attorney, is part-time consultant to the Cloud Legal Project, and a joint law and computer science PhD candidate at Queen Mary, University of London.