Cloud Computing vs Traditional Outsourcing – Key Differences
Kuan Hon and Christopher Millard particularise the many faces of cloud computing and warn of the dangers of pretending that each matches old outsourcing profiles when determining how to regulate.
Cloud computing represents a new way to outsource IT resources. With SaaS, the outsourced resource is application software; with IaaS, computing hardware (servers, storage devices etc); with PaaS, hardware plus a development and hosting software platform.
However, there are important differences between cloud computing and traditional outsourcing. Current laws do not accommodate properly these differences, nor indeed do proposed laws. Nevertheless, these differences should be taken into account if cloud computing is to be regulated appropriately so as to protect users adequately while enabling them to take advantage of costs savings and flexibility benefits, and without stifling innovation in the sector.
1. Traditional Outsourcing
Many current laws are based on models and assumptions of traditional outsourcing, as follows:
1. A data controller, who has been processing data inhouse, decides to outsource some of its data processing - for example, payroll processing.
2. It narrows the field down to several possible data processors and, after discussions with and evaluation of the contenders, chooses and hires a processor, with whom it enters into a data processing contract. The contract contains instructions tailored to that specific processing and other contractual provisions on how the processor must process the data.
3. The processor may choose to engage or commission sub-contractors, ie sub-processors, to help it perform the processing tasks entrusted to it by the controller. For that purpose, it enters into contracts with its sub-processors.
4. The processor (and/or any sub-processor) has full access to the relevant data, and actively processes the data for the controller, in accordance with the controller's instructions and contract(s).
To use a food analogy, current laws assume that you either cook food yourself (process data inhouse), or hire caterers, who may then engage sub-caterers (hire processors who may use sub-processors).
2. Cloud Computing
Contrast the following cloud computing examples.
2.1 'Unlayered' IaaS/PaaS/SaaS
A provider X decides to offer a IaaS or PaaS service on its own standard contract terms. A customer C may choose to use X's IaaS/PaaS services to perform certain data processing, on X's terms, to avoid buying and maintaining its own hardware or software. C itself still manages and maintains, in a self-service fashion, virtual machines running on X's infrastructure, and/or programs the application(s) it wishes to run on X's infrastructure, which C uses to process data. As with inhouse servers, C is free to install firewalls, anti-malware and anti-spam software etc.
X can keep costs down, passing some of the savings to users, because it can procure infrastructure to service multiple users, benefiting from economies of scale; the infrastructure's use is shared amongst multiple customers; and the base infrastructure and environment are standardised (rather than being customised for different users).
Note that X does not process any data actively for C. In fact, it does nothing for C except provide and maintain the shared hardware and software infrastructure and environments in which C, and X's other users, manage their virtual machines or code and run their own applications. C is conducting 'self-service processing' using X's resources. X does however passively store, on X's infrastructure, the data C has uploaded to X's service, ready for active processing by C when C requires. This passive storage is still considered 'processing' under data protection laws.
Analogy: rent a computer, which you use yourself to process data. The rental company may have supplied the computer complete with a third party's operating system, but neither rental company nor third party are performing any 'processing' for you when you use the computer to process data; they merely supply resources you use to process data by yourself. This is self-service processing, using rented resources.
As another example, a provider P could offer a standardised SaaS service. C may use P's SaaS application over the Internet, running on P's infrastructure, instead of licensing and installing application software locally. Again, C is performing self-service processing using the application supplied by P. C may also store data on P's infrastructure.
Analogy: rent a computer, which you use yourself to process data; the rental company may have supplied the computer complete with a third party's application software, but the third party could not be said to be 'processing' data for you, when you use the computer to process data.
(We should mention another possible scenario. A provider may well be a processor if it processes, for its own purposes, any data stored on its service by its customers – for example, if it analyses the data using automated software to display advertisements to customers based on the data content; or if it discloses customer data to a third party. In comparing cloud computing and classic outsourcing, we consider only what happens in relation to the 'outsourced' processing tasks and who performs them, rather than what happens when a processor, whether under classic outsourcing or cloud, processes personal data for illegitimate purposes. Hence, we use 'infrastructure services' and 'infrastructure providers' to refer to situations where the cloud provider merely provides hardware/software resources for self-service use by customers.)
2.2 Layered cloud services
Now suppose another provider Y offers its own cloud service, 'layered' on X's existing services/infrastructure, obtaining X's service on X's standard contract terms. Y offers Y's service to its own multiple customers on Y's own standard terms.
Then another provider Z offers its own cloud service, layered on Y's service, obtaining Y's service on Y's standard terms. In turn, Z itself offers services to Z's multiple customers on Z's own standard terms. A user D signs up for Z's service, entering into a contract with Z for that purpose. D then uses Z's service itself, in a self-service, self-managed fashion, to process data. Again, Z does not actively do anything for D; neither do Y or X.
The analogies are as before, except for the added layers of services, ultimately built on hardware infrastructure supplied by X. Again (unless it processes the data for its own purposes etc), as infrastructure providers neither Y nor Z (or indeed X) could be said to be 'processing' data for D, when D uses Z's service to process data.
3. Key Differences between Traditional Outsourcing and Cloud Computing
As these examples illustrate, there are several key differences between traditional outsourcing and cloud computing.
Current laws envisage traditional outsourcing and the stand-alone databases in use when they were drafted. They do not cater adequately for differences arising from service type, particularly with public shared-infrastructure IaaS and PaaS (ie infrastructure services), or differences arising from individual services' designs.
3.1 Active agents vs passive self-service usage of resources
Traditional outsourcing of data processing, eg payroll processing, involves commissioning agents, who are provided with data and tasked with processing the data actively for the user according to the user's mandate. The agent may itself engage sub-processors to assist with this processing.
However, with public cloud services, users 'rent' pre-packaged IT resources from providers and then process data themselves in self-service fashion, using infrastructure/resources supplied by the provider. Infrastructure providers do not actively act as agent processing data for users but, at most, passively store data which users choose to store on the provider's infrastructure ready for retrieval by the user when needed. Such providers may be active in maintaining and supporting the infrastructure and environment within which users process their data (discussed below), but the data processing is generally performed by users operating the provider's resources on a self-service basis, not by the provider.
Given the self-service nature of cloud, it is difficult to make sense of regulatory interpretations regarding 'intervenability' and data subjects' rights such as: 'A cloud provider may not provide the necessary measures and tools to assist the controller to manage the data in terms of, e.g., access, deletion or correction of data.' And 'The cloud client must verify that the cloud provider does not impose technical and organisational obstacles to these requirements, including in cases when data is further processed by subcontractors. The contract between the client and the provider should stipulate that the cloud provider is obliged to support the client in facilitating exercise of data subjects' rights and to ensure that the same holds true for his relation to any subcontractor'.
If a controller chooses to store personal data on a cloud service, it would upload, edit and delete the data in self-service fashion. Should a data subject request the controller to provide or correct their personal data, the controller may retrieve or edit the data, again in self-service fashion, and should not need any assistance or 'support' from the provider or sub-provider to do so. It is therefore unclear what issue these regulatory statements are aimed at. Similarly, 'The provider may even be instructed to answer requests on behalf of the client' may apply to a traditional outsourcing but are not relevant in self-service cloud. Indeed, controllers would probably wish the opposite – they would not want to pass on data subject requests to the provider to ask the provider to trawl through the controller's data looking for one person's personal data (which might be inimical to the rights of other data subjects whose personal data are also stored using that service), and providers are unlikely to accept any such request from controllers!
3.2 'Direction of travel' and sequence of events
With traditional outsourcing, a user hires a processor to meet its specific processing needs. The processor may then engage sub-processors to help it fulfil its contract with the user. Successive contracts 'down the chain' of processors may therefore be easily tailored, from both timing and control perspectives.
With cloud computing, however, the sequence of events and 'direction of travel' are the opposite. Many cloud services are pre-packaged standardised commoditised services, which may be built on existing 'sub-provider' services on the sub-provider's standard terms. The 'sub-service' in turn may be based on other existing services. The user chooses the provider and pre-built package that the user thinks best meets its specific processing and other needs.
It may therefore be difficult if not impossible to change, particularly in different ways for different customers, any sub-contracts the provider already has in place with its sub-providers - because it has already pre-built its service using standardised sub-service(s), rather than being commissioned to provide a service to order.
3.3 Standardised, shared infrastructure/environment
Public cloud computing providers use standardised, shared infrastructure/environments, often using relatively cheap commodity hardware, rather than tailoring to each customer. Customisation of the service is sometimes possible, but costs extra time/money. Private cloud allows the greatest degree of customisation and control, especially if on the user's own infrastructure and managed by it, and if on third party infrastructure and/or managed by a third party is closest to traditional outsourcing.
True, some traditional outsourced processing may use standardised infrastructure, sometimes at large scale, but it is unlikely to be shared to such a degree as in cloud computing. Shared infrastructure undoubtedly involves more risks for users if the separation between users, which relies on software and logical separation rather than physical separation, is not implemented properly and securely.
3.4 Differences in type, and degree of user control
As can be seen from the examples above, cloud services differ. With traditional outsourcing, the user has control over its processor, through the contract and its instructions to the processor. With cloud computing, while it is commonly thought cloud users lose control, much depends on type of service and exact nature and design of individual services. A 'one size fits all' approach to cloud is common, but would not be wise, because there are significant differences between services.
The table below, created by the Cloud Security Alliance (copyright Cloud Security Alliance, reproduced with permission) illustrates that users ('tenant' below) have varying control, and therefore responsibility, over different aspects of public cloud computing, depending on service type. For some aspects the tenant has sole control, for others the provider, while in other cases both have a degree of control. An individual system's design may affect what's controllable and by whom.
As can be seen, in reality users do not necessarily lose all control in the cloud, particularly in relation to security measures. They may encrypt or obfuscate data, whatever the service type; IaaS users may install their own firewalls and anti-malware, etc.
Treating all cloud services alike, as if they were the same as traditional outsourcing and as if all cloud services posed equal risks to privacy or security, could lead to inappropriate regulation which may stifle innovation and impede cloud development and use without necessarily protecting users' privacy or security.
Kuan Hon is consultant to the Cloud Legal Project, Centre for Commercial Law Studies, Queen Mary, University of London, and Christopher Millard is leader of the Cloud Legal Project and Professor of Privacy and Information Law at Queen Mary.
 Other than self-hosted, self-managed private cloud, which would not constitute outsourcing.
 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  OJ L 281/31, and 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 Regulation), COM(2012) 11 final 2012/0011 (COD)..
 Eg, Amazon Web Services or Google Compute Engine IaaS, or Microsoft Windows Azure PaaS.
 X's physical and software infrastructure could be owned by X, or leased or licensed from third parties, but we refer to it as 'X's infrastructure' for convenience.
 'The problem of 'personal data' in cloud computing: what information is regulated?—the cloud of unknowing', W Kuan Hon, Christopher Millard and Ian Walden, International Data Privacy Law (2011) 1(4):211-228. doi:10.1093/idpl/ipr018.
 Eg, using Google Docs (now Google Drive) or Office 365 instead of installing word processing or office applications locally.
 Or even a controller, in data protection law terms.
 Eg, Engine Yard's PaaS service, which is built on Amazon Web Services IaaS.
 Eg, Skydox's document collaboration SaaS service, which is built on Engine Yard which is built on Amazon IaaS.
 Notably, EU data protection laws, and indeed proposals to update them.
 We distinguish infrastructure providers from providers who process user data for their own purposes, eg to run advertising or sell aggregated data.
 Article 29 Working Party, Opinion 05/2012 on Cloud Computing, WP196 (2012), 196 5-6, and 184.108.40.206. Regulators consider that the 'complexity and dynamics' of the outsourcing chain in cloud result in 'lack of intervenability' – it is not clear what 'intervenability' means in this context. If it refers to data subject rights, how does the outsourcing chain prejudice their exercise?
 With some uses of private cloud, users might well control the physical infrastructure themselves.
To post a comment, log on (you must be a current member of SCL to post a comment ). Comments are limited to 4096 characters (roughly 500 words). Comments are subject to the SCL standard terms and conditions. Please go to My SCL and log on now.