The legal aspects of multi-cloud: DECIDEdly not unimportant! Part 2 - GDPR Application

In this second blog post, arguably the main legal instruments relevant to DECIDE is addressed: the general data protection regulation (GDPR). The new European law on data protection is introduced and its application to the DECIDE project is clarified. The post continues to explain how the concepts of processor and controller can be mapped on the situation in DECIDE.

General Data Protection Regulation – Application

First up: the application of the EU’s new data protection law to the cloud and multi-cloud environment. 

The GDPR is a European regulation laying down rules on the processing of personal data (by automated means), in order to protect the fundamental rights and freedoms of the persons concerned (the data subject), while aiming to enable the free movement of personal data throughout the European Union. The GDPR replaces the Data Protection Directive and will fully apply from 25 May 2018 onwards. Nonetheless it is already relevant to consider the new rules and all references will be to the GDPR and not to the current law, based on the Directive, unless explicitly stated.

These rules are relevant to the multi-cloud scenario of DECIDE, foremost, because the definitions of “personal data” and “processing” are very broad. Personal data is any information relating to an identified or identifiable person, whereas processing means any operation performed on such personal data, including operations with minimal or no impact such as consultation or storage of the data. Taken together, this gives the GDPR a very broad application. Additionally, given that even information relating to an identifiable person is personal data, even information that does not directly let you identify somebody is personal data and warrants the application of the GDPR. IP addresses for example have been considered personal data; despite the fact that information held by a third party (the Internet Service Provider, ISP ) is necessary to concretely identify the person in question. Even data that is by all means non-personal at present can become personal data when different data sets are combined, allowing the identification of a natural person. Moreover, when dealing with mixed data sets or when in doubt, the legally sound option is to either label and/or separate the data or to threat the whole data set as personal data, which is often the more practical approach. 

It follows that a lot of information held in applications that are to be developed by using the DECIDE tools will contain personal data. Moreover, given the broad definition of processing, all and any activity related to this data will be considered processing of said personal data. The sock shop application (used in DECIDE as the first sample application) for example will contain a lot of personal data such as name, address, telephone number, credit card information etc. It will also involve many instances of processing of that personal data, both by the application developer and by the cloud service providers involved. Therefore, the GDPR will largely apply to the situation in DECIDE. It is however important to specify that the GDPR applies to controllers and processors. So in order to determine what the impact of the GDPR is, we need to map the concepts of processor and controller on the situation in DECIDE, which will reveal in exactly which constellation DECIDE will be faced with the challenges posed by the GDPR in terms of different obligations being imposed on the respective actors in the chain of processing of personal data. 

Before doing so however, some territorial aspects of the application of the GDPR have to be pointed out. First of all, although the GDPR substantially applies to the DECIDE situation, the GDPR only territorially (jurisdictionally) applies to entities (Cloud Service Providers CSPs , application developers) established in the EEA, European Economic Area, or those (hypothetically) offering services to natural persons in the EEA (article 3 GDPR). Most large CSPs and most potential application developers will however be established in the EEA. Another, maybe more pertinent aspect is that many large CSPs and their potential sub-contractors are based outside the EU, which means that for transfer of personal data to these datacentres, adequate mechanisms under the GDPR have to be in place. This will be further discussed in the next blog post.

GDPR – Controllers and processors in DECIDE

Under the GDPR the controller is the “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data”. In other words, the controller is the one taking the decisions and often the initiative for the processing

The processor on the other hand is the “natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”. 

In the DECIDE scenario, the application developer is to be considered the controller, since he or she determines both the purpose of the application (i.e. the sock shop application developer decided to build an e-commerce website for the sale of socks) and the means (i.e. the sock shop developer decided to use the DECIDE tools and a multi-cloud solution) and thus the purpose and means of the processing done by the application. 

The cloud service providers involved in the deployment on the other hand are processors under the GDPR, since they are processing personal data on behalf of the controller, i.e. the application developer. This might sound somewhat counterintuitive since many cloud service providers simply provide resources very flexibly, without being much aware or needing to be much aware about what the customer exactly does with the resources that were provided. Given the low involvement and restricted impact some would argue that cloud service providers are not processors of personal data but play a purely intermediary role. However, the GDPR knows no such intermediary or neutral concept. Even if the legal text could technically hold such an interpretation, it would go against the spirit of the regulation and thus could not be interpreted as such, touching upon the ‘effet utile’ of the rules in question. Given the extremely broad definition of the term processing in the GDPR, any cloud service provider that provides resources that come into contact with personal data will be considered to be processing personal data and therefore is a processor under the GDPR, which leads to certain obligations, as will be discussed below. 

Before one can move on to obligations, two additional points should be highlighted

First, the role of the DECIDE framework and project itself has to be defined. After all, the DECIDE tools have an impact on the data contained in the application. Even if the data does not pass through the DECIDE tools, it might be argued that the DECIDE tools at the very least structure the (personal) data for use in different containerized micro-services. Such structuring might be considered a processing activity and thus DECIDE could act as a processor. Given the broad definition of processing other actions might equally come within reach of this concept. Whether or not this holds true is something that will have to be studied more in depth, taking into account the role of the tools and the way in which DECIDE is provided to the application developer, as a service in the cloud or rather as a local application. At the current stage of the project is seems the answer will be different for some of the DECIDE tools. At this point, it is important to note that DECIDE is not a legal person. Therefore, in the hypothesis that DECIDE acts as a processor, the consortium might want to create a separate company to exploit the DECIDE tools and take up the responsibilities as processor, rather than having an unclear situation where some of the consortium partners might be considered a processor. 

The second point that has to be made is that the initial assumption that the application developer is the controller is far too simplistic. This is true where the application developer is both the one making the application and using it to process personal data. In case of the Sock Shop, this hypothesis is reasonable. The entrepreneur/owner of the business behind the website would be the one making (potentially with help) the application and using it afterwards. However, as the use cases and the analysis in the recent deliverable D6.2 clearly illustrate, in many cases the application developer will not be the final user of the application and controller of the processing of personal data contained within the application. This would be the case if the developer sells the application as a product or service or makes a bespoke application. Although dependent on the particular situation it is likely that the original application developer will remain involved in the lifecycle of the application, making adaptions, re-deploying etc. In this case again it could be considered that an additional processor role is created. It is also possible that application developer and the user are both considered joint controllers of the processing of personal data ensuing out of the use of the application. Moreover, situations may appear where an application developer is considered a processor in relation to the main processing done in the application but then starts to use some of the information or meta-data for its own purposes such as product and services development or analytics. Then in relation to that processing the application developer might again be considered a controller.

As one can gather from the foregoing, the concepts of controller and processor large depend on the factual situation at hand and therefore depend on an ad hoc assessment. This assessment has to be done by the parties involved in any particular application creation. DECIDE has not role to play in this nor should it. It could be considered to create some guidance material that could help potential parties to a creation using the DECIDE tools better assess their position but this information would have to be offered “as is” and with an extensive disclaimer to avoid any issues.

It is important to already point out at this point that the concepts of controller and processor are based on factual assessments. In the end, when they will be considered by a data protection authority looking to fine the parties involved, the assessment will depend on the actual role of the parties. Contractual arrangements will logically be a part of this assessment but contracts cannot change a controller-processor relationship by themselves, without the actual behaviour and role of parties changing as well. 

The more important question, which is also less obvious to answer, is what role DECIDE should play in facilitating the different obligations incumbent on processors and controllers. This is covered in the next blog post.

DECIDE project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 731533.