The legal aspects of multi-cloud: DECIDEdly not unimportant! – Part 3 Controller and Processor Obligations and DECIDE’s role in this regard

This third blog post in the series of legal blog posts continues with the main assessment on GDPR for DECIDE: how does DECIDE interact with the legal obligations imposed by the GDPR. Without going into too much detail, this post tries to touch upon the most pressing matters of relevance.

Controller and processor obligations and DECIDE’s role in this regard.

It is absolutely out of scope of this blog post to consider all obligations incumbent on controllers and processors under the GDPR. Such obligations will have to be addressed by each entity for itself when conducting their internal GDPR exercise. DECIDE has no role to play here. However, the GDPR does bear certain implications for the DECIDE framework in relation to the controller and processor relationship. The focus will therefore be on those aspects, which clearly are highly relevant to DECIDE.

Under the GDPR the controller bears the bulk of the obligations, although in comparison with the current law (based on the Data Protection Directive 95/46/EC), the division has somewhat shifted, leaving the processor with much more obligations than before. While a processor does not bear the responsibility towards data protection authorities to prove compliance with data protection law (article 5, paragraph 2 GDPR, article 24 GDPR), nor is it the first line of contact for data subject rights (see articles 12-22 GDPR), the GDPR has nonetheless imposed some important obligations on processors as well, which are of direct relevance for DECIDE. 

After all, DECIDE will in any case contain processors and likely sub-processors as well, since the application developer will use different CSPs acting as a processor for the deployment of the application and these CSPs might themselves use sub-contractors for the final provision of their services. 

Therefore, the following will focus on the essence of DECIDE in GDPR terms, namely the relationship between the application developer and the CSP processors and their sub-contractors. 

However, it should already here be mentioned that if the application developer itself is already considered a processor, this adds another layer to the whole situation, making the CSPs whose cloud resources are used in deployment of the application already a sub-processor rather than a processor to start with. The importance of this will be explained further on.

Now, in general it should be noted that, other than under the Data Protection Directive, where CSP processors, particularly those providing IaaS or PaaS were often not very interested in the data they were processing, the GDPR contains some direct obligations for the processor necessitating certain measures to be taken. Examples of this include the register obligation for the processor contained in article 30(2) of the GDPR, obliging a CSP processor to keep minimal records of the processing activities it carries out for controllers, the technical and organizational measures in place and any transfers to third countries.

Most relevant for DECIDE however are the obligations contained in article 28 GDPR. This article first charges the controller with the task to only engage processors providing sufficient data protection guarantees, which means that sufficient organizational and technical measures are in place to ensure compliance with the GDPR. This includes e.g. respect for compliance with the data protection principles. This is a broad obligation to scrutinize processors and select trustworthy business partners, and includes the obligation to have a written data processing agreement with the processor.

With regards to such a data processing agreement, article 28(3) GDPR stipulates that:

Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor: 

(a)  processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest; 

(b)  ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; 

(c)  takes all measures required pursuant to Article 32 [security measures]; 

(d)  respects the conditions referred to in paragraphs 2 and 4 for engaging another processor [a processor can only engage sub-processors that have been generally or specifically confirmed by the controller and that accept the same data processing agreement as the one between the controller and the first processor]; 

(e)  taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights laid down in Chapter III; 

(f)  assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 [security, data breach and data protection impact assessment obligations] taking into account the nature of processing and the information available to the processor; 

(g)  at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data; 

(h)  makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.

This means that in the context of DECIDE, a written data processing agreement between controller and processor will need to be in place, containing all the items required by article 28(3) GDPR. DECIDE needs to accommodate this. Such contracts will be standard contracts imposed by the strongest party. For many CSPs this well therefore be the CSP itself. However, this is only the case where CSPs are a first line processor and not a processor itself. In cases where the application developer would be considered processor, the data processing agreement would have to be concluded between the controller/client and the application developer.

It is important to note two things here. First of all, as noted before, the definition of controller and processor is a factual assessment and cannot be altered by contractual arrangements alone. Second, although the GDPR does determine quite specifically what has to be contained in a data processing agreement, it does not take away contractual freedom. Based on the requirements of the controller, more or less stringent obligations can be formulated for the processor. After all the GDPR often uses broad concepts to be further defined in the situation at hand. Article 28(3), c) GDPR for example does obligate the processor to take the necessary measures to ensure the security of the processing but this leaves room for contractual specification of these obligations. One of such contractual specifications concerns the engaging of sub-processors. This can be allowed specifically or generally or can be forbidden (article 28(3), d) GDPR and 28(2) and (4) GDPR). In regards to the use of (sub-)processors outside the EU/EEA, this can be forbidden or conditions can be imposed in terms of data location (article 28(3), a) GDPR).

Second, there are two potential situations in DECIDE, which have a different impact on the obligation contained in article 28 GDPR. In the first situation the application developer is also the controller of the processing. In the second situation the application developer is not, but rather the client of the application developer is the controller of the processing of personal data involved in the application.

In relation to any process in which the application developer would itself be the controller, this would need to be inserted in the relationship with the CSPs used by the application developer for deploying the application with the use of the DECIDE tools. The data processing agreement here will likely be determined by the (larger) CSPs involved and may leave less room for negotiation and adaption to the situation at hand. In relation to application developers-controllers it might be relevant for ACSmI, exploited by a special purpose vehicle (i.e. a separate company), to directly contract services from CSPs in bulk and to put in place the necessary contractual provisions. Bundling the whole business of DECIDE in this way could help the contractual leverage in order to assure a favorable position and to prevent CSP processors to offer the absolute minimum they (consider they) are obliged to under the GDPR, although even this approach might prove unfruitful. A race to the bottom to a low standard imposed by large CSPs is not an unlikely scenario. Moreover, such an approach of bulk-buying and re-selling CSPs services could provide a good business model and steady revenue for the project afterwards.

These conditions would have to be further pushed down to any sub-processors the CSPs engage following article 28(4) of the GDPR, which requires that the same terms (or arguably at least the same level of terms) apply throughout the processing chain, which means that the all sub-processors are bound by the same data processing agreement as the first processor. Moreover, following article 28(2) GDPR, the application developer should at least in general terms allow the CSP processor the employ sub-processors in the first place. This would, if necessary, have to be accommodated in the contracting through DECIDE. A very important remark here is that article 28(2) GDPR requires that when permission to engage sub-processors is general (“you can use sub-processors (of this kind)”) rather than specific (“you can use sub-processor X”), the processor has to inform the controller of any change in sub-processors used. DECIDE could play a role in helping accommodating these obligations, although the obligation of course lies with the CSP-processor.

In the second situation, where the application developer is a processor for the customer of the application, the data processing agreement on the first level will be between the customer-controller and the application developer-processor. Following the above reasoning, this means that the same terms of that agreement (either exactly the same or at least on the same level) will have to be pushed down to the sub-processors, which in this scenario are the CSPs themselves. If the CSPs providing the cloud resources themselves use sub-contractors, they would be sub-sub-processors. This means that given the huge leverage some of the large CSPs have, the initial contract between the application developer-processor and its client will more likely have to reflect what the larger CSPs offer, than the other way around. Large CSPs will not allow different terms to be imposed upon them, which additionally are potentially different for each client the application developer engages with. Rather, a standard data processing agreement for DECIDE could be aimed at which CSPs endorsed in ACSmI would have to accept. This agreement would have to strike a fair balance so as to be acceptable to all parties.

Another important consequence of the foregoing is that the client-controller has to allow the application developer to change sub-processors, i.e. CSPs. A general permission can be given, if the processor informs the controller of changes in sub-processors. More precisely article 28(2) GDPR reads: “In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.”

With DECIDE deployments changing regularly, potentially involving many different CSPs the interpretation of this clause is important. It seems that the clause requires for the application developer-processor to inform the client when new CSPs would be added which haven’t been used before, or the known CSPs used are replaced by others. Such information notably has to be provided prior to actually implementing these changes. DECIDE should accommodate this. However, it seems that one could circumvent this by having the controller specifically authorize some of the likely CSP candidates for the deployment or giving general authorization and informing the controller before the first deployment of all likely candidates for the future. If for example CSPs 1,2,3,4 and 5 are accepted by the controller, different configurations can be deployed dynamically with a subset of these CSPs without having to always inform the controller. Notably, the same obligation applies to a sub-processor engaging another processor, i.e. the CSP using sub-contractors in this situation. Here as well an elegant solution can be found. DECIDE should however help accommodate this process.

Lastly, article 28(5) GPDR should be discussed as well. This paragraph hints at the fact that codes of conduct and certification can help establish which CSPs provide sufficient data processing guarantees. Codes of conduct and certification can also play a large role in specifying the general requirements mandated for processors by article 28(3) GDPR and further imposed down the line (push-down of terms) to sub-processors by article 28(4) GDPR. This kind of standardization can help solve the issue of a lack of contractual leverage to impose terms on large CSPs, acting as (sub-)processors.

Standardization can also help alleviate the issue that, although article 28(3) GDPR confers audit right on the controller towards the processor, and by virtue of article 28(4) GDPR also on the processor in relation to the sub-processor, it is not always straightforward to implement audit measures in the cloud certainly not in relation to large CSPs.

Therefore, DECIDE should accommodate the use of established codes of conduct and certifications for the application developer to be able to select only CSPs that according to these instruments have deemed to be suited for the processing at hand.

Related to this is the issue of data location and the transfer of data outside the EU/EEA, i.e. to third countries, which will soon include the UK following Brexit. The consortium is very aware of this issue and is working on addressing it. While there is no ground under the GDPR or otherwise that in principle discourages data from being kept and processed outside the EU/EEA, some comments should be made. First, in terms of GDPR, a transfer mechanism has to be in place containing adequate safeguards for the processing of such data outside the EU/EEA. This could be an adequacy decision of the European Commission on the legislation of the country to which the data is exported, standard contractual clauses, privacy shield certification, etc. DECIDE should find a way in which to flag this situation through ACSmI, especially in regards to sub-processors. Second, there can be commercial or other reasons for wanting data location to be inside the EU/EEA or even a specific Member State. DECIDE has to accommodate this, either through the NFRs of the application or by a similar flagging of this for CSPs and any sub-processors they may use through the information provided in ACSmI.

In the foregoing it has been stated several times that DECIDE should develop a mechanism to flag certain legally relevant information. This comes down to the method that will be used in ACSmI. ACSmI should be able to match quite specific non-functional legal or legally relevant requirements. Given this and the foregoing, it could be considered to make the endorsement into ACSmI of CSPs dependent of their adherence to the C-SIG code of conduct for cloud service providers. Another, non-exclusive path is to make use of certain certifications as a means to determine which CSPs are suited for sensitive applications and data, linking these certifications to certain non-functional requirements so that only CSPs with the necessary certifications are possibly suggested in a potential deployment configuration. This could help create trust in using public cloud resources, rather than hosting all sensitive data in the private cloud, which foregoes some of the potential added value of the multi-cloud approach. In order for this to work, certification needs to be transparent and a common approach or framework is needed to be able to allocate solutions optimally and to compare certifications and CSPs. The work done by Tecnalia in project SMART 2016/0029 might in the course of DECIDE prove fruitful to that purpose. During the implementation of the project the role and manner in which codes of conduct and certification will be used in DECIDE will be made concrete.

Nonetheless the challenge is broader than certification alone or selecting trustworthy CSPs. In order to properly flag all legally relevant information ACSmI will have to have a multitude of data fields which will have to be linked to the NFRs of the application in some way so as to ensure that specific requirements are met in reality and data protection related concerns are addressed on all levels throughout the DECIDE workflow. Even with a technically sound way to communicate all this data throughout DECIDE, it will be a challenge in itself to make sure that all relevant information is available in or through ACSmI in the first place. The partners concerned with ACSmI and the DECIDE framework are aware of these challenges and are working on solving them.

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