Missing Links in the Proposed EU Data Protection Regulation and Cloud Computing Scenarios: A Brief Overview

Although the concept of “cloud” is metaphorical, cloud computing currently represents another big innovation in the IT industry that tends to maximize the use of the Internet. This is not only seen in its concentration of large computing power in a single space, but also in its functionality as an always available, unlimited tool to store and access data no matter the location. ¹ However, like some other technical innovations before it, it has not been easy to determine how to append a precise legal definition to the concept as well as to bring its uses within a legal framework. This conundrum is easily appreciated when analyzing data protection laws within the context of cloud computing, for instance, because data represents the main raw material upon which cloud technology thrives. The fact that more data is constantly linking to individual persons, of course, plausibly triggers debates concerning data protection requirements in cloud transactions (requirements relating to privacy, security, transparency, accessibility, and rights and freedoms of data subjects). Such requirements could, for example, restrict personal data from being transferred from one country to another for jurisdictional purposes. ² Cloud computing, on the other hand, depends on automated data movement around several data centers located in different parts of the world, and relies on the Internet for access to such data. This location-agnostic feature of cloud computing potentially has several data protection implications because of the multiple jurisdictions that may be involved.

European data protection law, for instance, is location-focused, assuming physical movement of data from one place to another. ³ This fact is reflected in the current Data Protection Directive 95/46/EC (“DPD”) which predates the Internet boom, making it difficult to reconcile some of its provisions with the operations of Internet-enabled technologies such as cloud computing. ⁴ However, in a bid to reflect the traditional reasoning in a cloud framework, the Article 29 Working Party (WP29) has opined that mirroring personal data from a server in the EU to a US-located server constitutes a data transfer. ⁵ While this may appear convenient for the WP29, it fails to solve the complexities in applying the data export rules in cloud transactions.

Having recognized this state of affairs, the European Commission has published a draft proposal for a Data Protection Regulation (“draft regulation”) that will replace the DPD. ⁶ Though the draft regulation is still undergoing parliamentary amendments, this paper seeks to examine some of its salient provisions as applicable to cloud computing models. In particular, it will focus on the controller-processor roles and data export provisions in the draft regulation that may potentially impact cloud transactions. At the end, it will show some of the missing links in the proposal that need to be addressed before the final version is passed.

Like most technical concepts, defining cloud computing is fraught with difficulties and controversies, especially due to the evolving nature of the technology. It is, however, not the intention of this paper to go into those controversies. For the purpose of this paper, cloud computing describes a set of technologies and service models that focus on the Internet-based use and delivery of IT applications, processing capability, storage and memory space. ⁷ A more technical and widely cited definition has been offered by the United States National Institute of Standardization and Technology (NIST). ⁸

Cloud computing services can be offered in various forms, three of which are most prominent: SaaS, PaaS and IaaS. Software as a Service (SaaS) refers to providing the cloud consumer with the capability to use the cloud service provider’s applications (software) running on a cloud infrastructure. ⁹ These applications are configured to suit the consumer’s preferences and are accessible from various client devices through the Internet (e.g. web-based email or electronic health records). Platform as a Service (PaaS) is another service offering where the service consumer is provided with the capability to deploy onto the cloud infrastructure, applications created using programming and support tools from the cloud service provider (e.g. centralized analysis of MRI scans or X-rays built on Microsoft Azure, for example). Infrastructure as a Service (IaaS) refers to the capability provided to the service consumer to provision processing, storage, networks, and other fundamental computing resources on an infrastructure of the cloud service provider. One fundamental consequence of these service models is that the service consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems or storage, ¹⁰ but may have control over the deployed applications and possibly configuration settings for the application-hosting environment. ¹¹

The above-mentioned services can be deployed in four possible ways:

The cloud supply chain could be a combination of many components or services from different suppliers or providers. Multiple services are involved in the layers of the stack of the cloud ecosystem, each of which could be managed by a different party. These could range from third parties who are involved in the provisioning of physical space for the data centers to those who maintain the data centers and even cloud brokers. A good illustration has been provided by Hon and Millard (2013), ¹⁵ and diagrammatically represented in Kate’s blog. ¹⁶ It is significant to note, however, that cloud end users see the services they are using as an integrated service, and do not bother with the underlying components. Regrettably, this has the tendency of depriving the legally defined data controller the actual control of the data in factual understanding. ¹⁷ As we will see below, this state of affairs is yet to be addressed in the draft regulation.

The draft regulation retains the core concepts and basic principles enshrined in the DPD, such as technology neutrality, controller-processor dichotomy and legal bases for data transfer to third countries, among others. This means that there are no specific provisions for cloud computing per se, and the data controller remains responsible for data processed on its behalf, no matter the means. At the same time, however, there are significant improvements in the draft regulation. Importantly, it will have direct application in the Member States, which will eliminate the fragmentation seen in national implementation of the DPD to a large extent. ¹⁸ Another significant change is the amendment of the extra-territorial application of Article 4(1)(c) of the DPD. In effect, this amendment will exempt the application of data export rules during a re-transfer of data that had originally been collected from a third country (involving non-EU residents) but transferred to an EU-based processor (e.g. cloud provider) for processing. ¹⁹ The French Commission nationale de l’informatique et des libertés (CNIL) has already initiated this exemption, thereby removing cumbersome procedures during such data re-transfer. ²⁰ Non-EU data controllers will be regulated only where their processing activities relate to the offering of goods or services to EU subjects or monitoring their behavior. ²¹

The draft regulation further provides additional rights to data subjects; increases the obligations of data controllers; and imposes some direct obligations on data processors (a category that most cloud service providers will possibly belong to). This will inevitably affect the relationship between cloud providers and their customers. For instance, data subjects’ rights to data portability may force cloud customers to use only service providers that have portable facilities in order to comply with the law. Similarly, cloud customers will favor providers who are more proactive in their internal controls, which reflect increased accountability as envisaged in the regulation. ²²

A data protection certification seal has also been introduced in the draft regulation. ²³ In effect, a cloud provider could voluntarily apply to the Data Protection Authorities (DPAs) to be audited and given a European Data Protection Seal as a certification mark indicating its compliant status with EU data protection law. ²⁴ Furthermore, data controllers wishing to use cloud services for certain types of data processing such as sensitive health data will have to conduct a data protection impact assessment before sending data to the cloud. This will be the necessary implication of Article 33 of the draft regulation. ²⁵ Mandatory notification of data breaches (by data controllers with the help of processors where necessary) will equally be given due consideration in cloud relationships when the regulation becomes effective. ²⁶

While retaining the current approach for third-country data transfer, the regulation still introduces remarkable changes:

Another remarkable provision in the draft regulation is the adoption of ‘one-stop-shop’ or general recognition of a lead authority in cases where the controller or processor is established in more than one Member State. This will be a time- and cost-saving mechanism for obtaining authorization where necessary. It is hoped that the delegated acts in the draft regulation will not create more red tape in this regard. ³³ Additionally, fines of up to 500,000 EUR, or 1% of its annual worldwide turnover in the case of an enterprise, could be imposed as an administrative sanction for a violation of the regulation. ³⁴

It is believed that these provisions will make international transfer restrictions easier to navigate. ³⁵ However, it is not certain how these reforms will look in the final version of the regulation, since recent parliamentary amendments have modified a lot of the initial provisions. The Committee on Civil Liberties and Home Affairs (“LIBE”), for instance, has rejected the adequacy finding for a processing sector, insisting that such an approval would increase legal uncertainty in international data transfers. ³⁶ For example, this could have the effect that it would not be possible for the Commission to decide that cloud providers who are Health Insurance Portability and Accountability Act (HIPAA)-compliant in the US would provide adequate protection to host health data from the EU. The LIBE Committee also rejected the use of non-legally binding instruments for international data transfers, and additionally proposes a two-year transition period for all authorizations by DPAs on the basis of Article 26(2) or Article 26(4) of the current DPD to elapse. ³⁷ A new provision meant to address the issue of access request by public authorities or courts from a third country has also been included in both the LIBE Committee’s report and the compromise text from Parliament. This provision requires that such a transfer shall only be on the basis of a mutual assistance treaty or international agreement in force between the requesting third country and the Union or the Member State involved. A prior authorization from the supervisory authority should also be obtained before effecting the transfer, and a notification given to the data subject. A new default position has also been created by the Parliament’s compromise text to the extent that where there is more than one controller or processor involved in the processing, each controller or processor will be jointly and severally liable for the damage (unless they have an appropriate written agreement establishing liability in the determination of their responsibilities), and in the case of a group of undertakings, the entire group shall be liable as a single economic entity. ³⁸

What the effect of these parliamentary amendments will be for cloud services is yet to be fully understood, except to say that obtaining new approvals after the transition period will have cost implications to data controllers and processors. Second, where no mutual assistance treaty or international agreement exists between the countries involved, there is a potential risk that this may put the cloud provider in an awkward position as to which rule to follow. In essence, because of the lack of clarity about jurisdictional boundaries, this provision would prohibit organizations from complying with governmental orders, and this makes them vulnerable to criminal penalties.

While the draft regulation and various amendments to it are being debated, it is important to point out some other issues that have not yet been addressed in the proposal, especially in relation to cloud computing. First, as pointed out earlier, cloud computing involves various layers and intermediaries of actors for which a strict application of the data controller-processor dichotomy may be ambiguous and misleading. ³⁹ This can be seen in the use of intermediaries such as cloud brokers and integrators who act as a conduit between the cloud customer and the provider but in fact have no infrastructure to process data. Some other actors in the cloud stack, such as those who provide the physical infrastructure, may be so remote from the actual data processing that regarding them as either a joint controller or a processor may make no sense. So far, the draft regulation has not taken proper cognizance of these sets of actors. The closest attempt at recognizing this gap is in a new provision in the LIBE Committee’s report that introduced a new party defined as “producers”. ⁴⁰ Though by a stretch of argument the definition of “data producer” may include some cloud intermediaries, this may be an ambiguous way of describing all of them, since some of the intermediaries do not have any infrastructure for producing or processing data but only provide monitoring services. Of course, making every party in the chain of transaction joint controllers will not solve the problem as purported in Article 24 of the draft regulation. Hert and Papakonstantinou (2012) have opined as follows:

… the distinction between data controllers and data processors, that was perhaps clear at the time the Directive was introduced, is increasingly disputed in the contemporary complex business environment. […] The distinction between the two data processing actors is becoming increasingly blurred in an interconnected world of ubiquitous computing. In view of the above, perhaps the preferable way forward would be for the Commission to boldly abolish the notion of “data processors” from its Regulation altogether, and vest the data controller title, rights and obligations upon anyone processing personal information, regardless of its means, conditions or purposes. ⁴¹

While this stand may appear extreme, it goes to show the frustration at reconciling the inadequate nature of the binary division of actors in the data processing chain, where collaborating but autonomous entities are involved, and whose mutual relationships can no longer be characterized as a simple ‘relationship of command’ or ‘principal-delegate’ relationship. ⁴² Not clarifying these relationships in the draft regulation may have unintended consequences, such as creating legal uncertainty as to the status of actors and the allocation of responsibility in the data processing chain. ⁴³ A number of opinions have called for a rethinking in the classification of actors in view of modern data processing possibilities, of which cloud computing is a ready example. ⁴⁴ The draft regulation, as well as the various parliamentary amendments, has not devoted significant attention to this issue.

Second, the regulation has retained the use of the model contractual clauses. However, in their present form these clauses do not adequately cover all the constellations of cloud transactions. For instance, there are no model contractual clauses for an EU processor to transfer data to a controller in a third country, or for an EU processor to transfer data to a sub-processor in a third country. ⁴⁵ These cases are possible as more data processors in the EU are transacting with many data controllers and sub-processors who are outside the EU. ⁴⁶ Furthermore, certain clauses in the model do not reflect and may not fit into the technical and organizational frameworks of cloud services. For instance, the assumption that the data controller is the strong, controlling party that has the actual ability to instruct and control the processor (cloud providers, for example) may be illusory. ⁴⁷ Provisions requiring the processor to submit its facilities for audit by the controller and supervisory authorities are less feasible in the cloud, in view of the millions of customers a cloud provider may have. ⁴⁸ It is also less likely that a cloud service provider will first obtain prior written consent from all of its customers before engaging in every support service, where those are regarded as sub-processing. ⁴⁹ As Svantesson (2012) rightly observes, “the power-balance in cloud computing agreements is typically different to the power-balance between data controllers and data processors anticipated in the data protection regulation.” ⁵⁰ This calls for an amendment of these clauses in view of emerging structures in modern data processing realities.

Third, some of the provisions of the draft regulation on international data transfer raise fresh questions. ⁵¹ In spite of the controversies surrounding the use of “onward transfer” in the EU-US Safe Harbor framework, it has been recognized in the regulation without any definition or mechanism for its application. ⁵² The concept entails that after EU personal data is transferred to a Safe Harbor-certified US entity, further transfers from the importer to a third party (onward transfers) are possible, subject to restrictions under the Safe Harbor. ⁵³ It is not clear how this concept will apply to other entities that are not subject to the Safe Harbor framework, since the original concept has been limited to the US. There is a need for more clarity in the application of the concept if it is intended to have a general application, so that it does not serve as a tool to circumvent data protection requirements. ⁵⁴

Fourth, although the draft regulation has recognized the use of BCRs, its application only within the same group of companies or organization will still limit its potential impact. The inability to transfer data between two different processors or controllers, who both have duly approved BCRs but not belonging to the same group, is not logical. This appears to be contrary to the case where two third countries that have adequacy status are allowed to transfer EU data between them on that basis. A similar facility should be accorded to BCR-approved entities since it represents a binding obligation.

It is encouraging that the draft regulation will bring a level of harmonization in the data protection regime within the EU. However, cloud realities show that much still needs to be done in order to reap the full potential of cloud computing in Europe. There is a need for legislators to understand cloud architecture, features and business models. Hon, et al (2012) argue that some of the current difficulties in the legal aspects of the cloud arise not necessarily because contract terms are poor, but because data protection laws assume certain things which are not true in the cloud. ⁵⁵ If the present reform is not holistic, it may lead to unintended consequences. Reflecting privacy in a pragmatic way without disproportionately interfering with technological advancements is essential in this e-age. ⁵⁶ It is hoped that the outlined missing links in the draft regulation will be addressed while the proposal is still debated.