We all know the benefits of the cloud for outsourcing business processes. Dumping all that internal infrastructure in favour of remotely hosted applications which are more reliable, scalable, up to date and cheaper.

Still, the move to the cloud has been more a trickle than a flood because of various concerns. Some are valid, such as less-than-balanced "take 'em or leave 'em" terms and conditions. Some are less so, such as a feeling of lack of control masquerading as security or resilience concerns. In the 19th century, businesses with onsite electricity generation were nervous of switching to third-party supply for the same reason, until a tipping point was reached when the decision became cost-driven. Those who didn't outsource couldn't compete.

In anticipation of a similar surge to the cloud, the Information Commissioner's Office (ICO) has released Guidance on an area which may get overlooked in the enthusiasm. If all that data being transferred includes personal data, the company has obligations in respect of it. The Guidance's stated intention is to "explain what you should consider prior to a move to cloud computing for the processing of personal data".

The Guidance is primarily aimed at customers, but it also says that "cloud providers should use this guidance so that they are aware of the data protection issues that their current and prospective cloud customers may need to deal with".

Is it relevant to me?

The Data Protection Act (DPA) protects personal data. Most people instinctively know what "personal data" means. The DPA gives a rather cumbersome definition - which can be shortened to "data which relates to an identifiable living individual" - but your instincts were probably right.

The DPA applies where personal data is being "processed" which includes simple storage, so pretty much any transfer to the cloud will fall under it.

"Data controllers" and "data processors"

Where personal data is processed the DPA defines who controls it, as they are responsible for DPA compliance even if they delegate tasks to data processors.

The Guidance says cloud service customers will generally be controllers, but that doesn't stop cloud service providers from also being controllers, depending on what they do. Usually:

  1. In "private clouds", the customer will be the controller and the provider will be the processor.
  2. In "community clouds", customers will each be the controllers of their own data and the provider, even if a customer, will only be a processor to the extent it is performing that function. If data is shared - the legality of which is subject to separate guidance in the ICO's Data Sharing Code of Practice - the customers should clarify amongst themselves who is controlling the shared data.
  3. However, when most people think of the cloud, they think of web-based "public cloud" services. Despite the lack of control over them, customers are controllers because they choose to use them.

The provider will just be a processor unless it uses the data for its own purposes, to which extent it will be a controller. For example, if a customer develops an application to run on a social network like Facebook, it would be the controller of personal data harvested from people using the application, but the network would be the controller if it used the data for its own purposes, like advertising.

Responsibilities of the data controller


The ICO's cloud computing Guidance supplements its Online Code of Practice relating to all use of personal data online including, for example, in e-commerce. The Code says that, if the controller uses a processor, there must be a written contract ensuring that the processor's security is at least as good.

We have written before about how cloud providers' standard T&Cs are often weighted in their own favour. However, in this regard at least, they may not have the whip hand. If their T&Cs do not promise adequate security measures, a customer who wants to be DPA-compliant can't buy their service.

Security is not always a matter of contract. It can be a matter of fact. The Guidance suggests a common-sense risk assessment as to whether the service's security is appropriate for the data in question. For example, a service for which the login is email address and password may be acceptable for low-level personal data, but people know each other's addresses, and - if they know each other's pet's or other half's names - they can have a pretty good stab at passwords too. Hackers have software that can make thousands of guesses per second. The more damage the data could cause in the wrong hands, the stronger the authentication should be.

Of course, the user interface is not the only place where security can be breached. In traditional outsourcing, customers usually ensure DPA compliance by visiting the service provider's premises to assess security vis-à-vis the data's availability (to the customer), confidentiality (from others) and general integrity. The ICO realises this may be impractical in the public cloud, and suggests providers commission an independent security report. This is one area where the Guidance is a bit of a fudge as, if the provider is the client of the security assessor, it seems optimistic to expect independence or that a damning report would be published; and no guidance is given for the circumstances where no report exists.

Shop around for the right contract

The DPA requires the controller to have a written contract with any processor. The Guidance says somewhat optimistically that "a written contract should mean that the cloud provider will not be able to change the terms … without the cloud customer's knowledge and agreement".

As noted in our previous article, a survey of the T&Cs of 31 providers found 13 of them reserved the right to change their T&Cs unilaterally by posting new ones on their website with no duty to notify.

The Guidance cautions against "take 'em or leave 'em" T&Cs, as they may not give the customer sufficient control. However, the reality is that most public cloud T&Cs are "take 'em or leave 'em" and, with the best will in the world, public cloud providers may be seriously restricted in how they can tweak their service for individual customers, and they cannot tweak their T&Cs to promise a customised service they cannot deliver.

A better solution may therefore be to select the right service, which is something else the Guidance recommends. For example, if one provider's security systems are not robust enough for the type of data to be processed, the customer should find another.

Necessity of processing

Unless the individual (the "data subject") consents, his personal data cannot be processed unless it is necessary, for example:

  • to perform a contract with him;
  • to protect his vital interests; or
  • to comply with the controller's legal obligations.

Schedule 2 of the DPA has the full list; and there are further requirements for data defined as "Sensitive".

This does not mean the switch to cloud processing must be necessary. The test is whether the processing is necessary wherever it is done.

It does however mean that personal data cannot be transferred to the cloud willy-nilly. The data may be held legitimately for a necessary function, but it should not be transferred to the cloud unless it is necessary for the function being performed there.

There should be no further processing by the cloud provider for its own purposes (like advertising) unless authorised by the customer and the customer has explained this processing to data subject.

Necessity of retention

Personal data must not be kept for longer than necessary. The cloud customer, as data controller, is responsible for ensuring the data will be deleted by the service provider in line with the customer's own data deletion schedule, and deleted if the service is terminated. This responsibility probably goes no further than ensuring the contract says the data will be deleted, but the survey of the T&Cs of 31 providers found only one who guaranteed deletion on termination of the service, showing the present conflict between the nascent cloud industry and the legal regime customers must comply with.

Transfer of data outside the European Economic Area

The DPA prohibits transfer of personal data outside the EEA. There are exceptions to this rule which can be found here, but customers will save themselves a headache by sticking to cloud providers who can confirm that data will not leave the territory.

If that is not practical, the best thing is to ask the cloud provider how it can ensure compliance with the 8th Principle of the DPA, and to assess the reply against the guidance at the link in the previous paragraph. Compliance with the 8th Principle is a big deal, and customers should be wary of any provider who does not understand the question.

The above article does not repeat every aspect of the Guidance, so those contemplating a significant use of cloud services for personal data to should read it in its entirety.