GDPR: Read from a CPC perspective
Christian Laux (CH), Partner of EuroCloud CPC Network
Introduction
The CPC has been implemented before the GDPR has been released. The CPC network, however, is now about to release the GDPR version of the CPC, a version of the CPC that reflects the changes the GDPR brings to European data protection law. The work of the CPC network proves that the CPC structure can be upheld, even under the GDPR. Therefore, it is worth discussing the GDPR a bit more closely, from a CPC perspective.
A fascinating document
Why is it worth writing about the GDPR in the context of the CPC website? Because it is a fascinating document.
The GDPR applies directly, and for all members of the EU, without the need for them to release own rules implementing the provisions of the GDPR. Local rules would be possible where the GDPR leaves room for such rules, but the framework would work without such local rules.
The legislation process has started in January 2012 with a first draft submitted by the EU Commission. The European Parliament could go through the text in early 2014. The Council of Committee Ministers (Justice and Home Affairs) chewed on it in summer 2015, until there was a political breakthrough per the end of 2015. Then, the bunch landed on the desk of the translators who made the draft document available in all local languages by April 2016. Following this process, the GDPR document was published, enacted and then became law on 25 May 2016 (with a postponed effective date on 25 May 2018).
In short, this is four years plus two. Some more stats, please: During the legislative process, 3999 change requests have been submitted. That is 1’000 a year, three a day. The GDPR now is 88 pages thick. You get to the 57 pages of legalese when having completed 31 pages of recitals.
CPC structure applied to GDPR metrics
On this basis, let me summarize the GDPR from the CPC four-step perspective:
First step: The “Personal Data” test
Nothing dramatic to report under this first test. The CPC of course requires an understanding about personal data. This is to determine whether certain rules apply or not. Whether the GDPR has new rules or not is not relevant, from a CPC perspective. When there is personal data the CPC will deploy its usefulness.
Second step: Moving data to a Cloud Service Provider
Technically, nothing changed. Storage and access remain the main criteria. Two noteworthy things, here:
- No Consent required: The Cloud Service Customer (CSC) does not need to ask for the data subject’s consent.
- Information required: The Cloud Service Customer (CSC) should be prepared to notify the data subject and provide at least some information about the fact that it uses a Cloud Service Provider (CSP).
So why are these two statements fascinating? Let me add some comments to explain:
a) No consent from the data subject needed to migrate data into a cloud setup
This is fascinating because the response (a) (“no consent required”) is not made explicit in the GDPR. Lawyers must draw the argument from the fact that a whole specific provision in the GDPR (Article 28) does not mention consent at all. Given there is so much text, such a clarification could have helped. Because: Believe me, in projects, questions like these will eat up a significant amount of time when discussing the project with the project’s stakeholders.
Article 28 states that the requirements for a cloud migration are (only):
- existence of a Data Processing Agreement;
- existence of technical and organizational safeguards;
- processing only if instructed by CSC and only as instructed by CSC, in particular, no processing for own purposes;
- no sub-processors without (at least general) authorization of the CSC.
Accordingly, it is clear that the data subject does not need to be asked before a CSC implements a cloud migration (at least not from a data protection analysis under the GDPR).
This rule, by the way, applies even if special categories of data are concerned; member states could not add more restrictive requirements to special categories of data. Member States could not even do this under article 9 para. 4 GDPR which provision relates to the question for what purposes special categories of data will be used (“processing”):
“Member States may maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health.“
(Article 9 para. 4 GDPR) A member state could not limit the migration of data into the cloud, on that basis. Article 28 GDPR prevails.
b) Some Comments Relating to the Expected Information Requirement
The expected information obligation should also be dealt with in more detail. The relevant wording, under articles 13 and 14 of the GDPR, is that the data subject should be informed of the “recipients” or “categories of recipients”:
„the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: (a) – (d); (e) “the recipients or categories of recipients of the personal data, if any” (Article 13 para. 1 lit. e GDPR).
and
„Where personal data have not been obtained from the data subject, the controller shall provide the data subject with the following information: (a) – (d); (e) “the recipients or categories of recipients of the personal data, if any” (Article 14 para. lit. e GDPR).
“Recipient” is defined in the GDPR. The GDPR reads as follows:
“ ‘recipient’ means a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not.” (Article 4 para. 9 GDPR)
The relevant factor thus is „disclosure“. Most likely, the drafters wanted a CSP to be a recipient, one should assume. Therefore, the CPC network came to the conclusion that the CSC must provide transparency to the data subject about the fact that the CSC uses a CSP. The CPC network found that one will need to assume that the GDPR requires a notification. But the information can be generic (reason: the GDPR does not clarify the level of detail).
As a reminder, “Cloud Computing”, as understood here, anticipates a use case in which the CSP does not reuse the data for own purposes. And typical cloud computing setups, at least those of professional providers, are set up in a manner, i.e. with technical and organizational measures, that make sure that data are protected against disclosure to the personnel of the CSP.
For a number of reasons, I believe the notification requirement should not apply to cloud computing setups (however, there can be a notification if data will be exposed to a foreign country, see later, note 27). Let me list these reasons here:
First, notification of the fact that the CSC uses a CSP does not add anything to the protection of personal data. It is normal that people use others to process data. We are living in a modern economy, and modern economies rely on division of work (“Arbeitsteilung”, “répartition du travail”). Thus: How could it be a surprise that a CSC uses a CSP?
Second, if the use of a CSP is not a surprise: Why should there be a specific mention to the data subject? The underlying response, of course, is that the data subject should not be left in the dark about important aspects. While this is wise in principle, other approaches would be available to meet this interest of the data subject. The data subject could always ask (and, in the response, the Cloud Service Customer would always need to be candid about details, too). Or, supervisory authorities could perform reviews and test the Cloud Service Customer about whether the Cloud Service Customer complied with all requirements under Article 28 GDPR.
Third, I believe notification requirements should apply only if there is an increased risk. The fact that a cloud computing setup is being used does not per se increase the risk if one agrees that the division of work is normal. And if one believes that Article 28 of the GDPR is what it takes to make the use of processors lawful.
Fourth, the GDPR requires notification only if there is “disclosure”. I believe the term “disclosure” is not clear enough and, above all, does not provide for appropriate distinctions in a modern, data driven world. It is accepted legal doctrine that “information” usually has more than one layer. Without going into detail, these layers are the physical layer, the code layer and the content layer. Only the disclosure on the content layer should be dealt with as a “disclosure” in the terms of Article 4 para. 9 GDPR. If there are cloud computing setups that do not result in a disclosure on the content layer then there should not be a notification requirement for such cloud computing setups.
There is not much room to explain the underlying concepts in too much detail, here. But let us, in the interest of being practical, distinguish machine-readable notations (data code layer) from the human-readable content (information content layer) they are able to convey. Data then are “a container” to the information, and the container can be made accessible to the human if there is a machine that helps the human to read what it is in the container. In this example: If applications with data are moved onto a IaaS setup – why should this be treated to be “disclosure” of information as defined in Article 9 para. 4 GDPR? To ask the questions implies the response I would give: This should not be treated to be a disclosure in the meaning of Article 9 para. 4 GDPR.
Fifth, the information to be provided can be very generic. Of course this makes sense: The data subject is not in a position to assess whether the steps the CSC required from the CSP under Article 28 GDPR are useful. But: What does generic information help the data subject? Nothing, frankly. The data subject will receive an email, perhaps. But the email will be not more than “noise” in the data subject’s email inbox. So what is this good for?
In light of this: Would it not be sufficient, or even more useful to have the CSC inform the data subject upon request, only? I believe the answer should be “yes”. Articles 13 para. (1) lit. e and 14 para. (1) lit. e GDPR should not be applied with respect to cloud computing setups.
Does that qualify to be ”fascinating”, as promised? Given cloud computing is core for the digitalization, then it is fascinating that the GDPR seems not to be prepared well enough to provide clarity to cloud setups.
Third step, foreign country nexus
The fascinating part, here, is that there is not much to report. The GDPR requires that a notification must be given if data ”leaves” the European Union (or the EEA), or comparable situations, which is provided for in Articles 13 and 14 of the GDPR:
„the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: (a) – (e); (f) “where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.” (Article 13 para. 1 lit. f GDPR).
and
„Where personal data have not been obtained from the data subject, the controller shall provide the data subject with the following information: (a) – (e); (f) “where applicable, that the controller intends to transfer personal data to a recipient in a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means to obtain a copy of them or where they have been made available” (Article 14 para. lit. f GDPR).
Such notification, within the framework of the GDPR, makes sense, and also is simple to understand, from a data subject perspective.
Fourth step, sub-processors
The agreement between the CSP and sub-processor must be made in writing (including in electronic form, Article 28 para. 9 GDPR). The fact to see the formalities clarified is a positive thing and helpful for cloud computing as an instrument.
Summary
The GDPR has been released with the claim to be an overall solution, and useful per se. “Useful per se”, of course, is a high standard. And, of course, I acknowledge that what has been discussed in the above shows that the GDPR does follow respectable lawmaking policies – even where I disagree with the interpretation to be given to certain clauses of the GDPR (see above, notes 15 – 26). The most relevant thing to be noted is the following: the GDPR reflects the CPC methodology and does not change it. This is what will permit the CPC to be useful, under the GDPR, too.
Format of this Contribution
This contribution is being published in the format of a dissenting opinion to a common and adopted position of the CPC network. Generally, it is in the interest of the CPC network to act unanimously. But a dissenting opinion as the one published here is one of the instruments contributors to the CPC network can take if they feel a decision of the CPC network does not reflect very elementary interests the contributor is strongly convinced should be highlighted to the public so that a later analysis can eventually pick up the argument, and potentially add more to it.
Article published by Dr. Christian Laux, LL.M., Attorney in Switzerland, Laux Lawyers AG
Discover more about the Cloud Privacy Check(CPC) / Data Privacy Compliance(DPC) project
CPC project office: Dr. Tobias Höllwarth, tobias.hoellwarth@eurocloud.at