Implementing Privacy By Design (GDPR)

The GDPR introduced an interesting new concept to ensure the protection of personal data : the notion of “privacy by design”. In fact, to be completely exact, the GDPR distinguishes two ideas : the idea of ​privacy by design and the idea of ​privacy by default. These concepts originally came from the Commissioner of the Canadian Agency for the protection of personal data (Dr. Anne Cavoukian) who developed a series of principles in 2010 to take privacy into account straight from the design of processing systems.

The GDPR welcomed this idea but from a rather specific angle. Therefore it’s necessary to understand these concepts(1) before clearly looking at their impmentation in the GDPR that really differs (2). Finally we will look implementation in practice (3).

I. - What is privacy by default and privacy by design ?

The principle is quite simple : privacy by design is the idea that the protection of privacy must be taken into account at the very moment of designing an IT system. For Apple for example, it’s the idea that the company need to propose an option to encrypt hard drives to it’s users. So, in the event of loss or theft, encryption will keep personal data confidential.

This concept differs from privacy by default, which is the idea that - when protection measures are set, they must be activated by default. In the case of Apple, it means that in the settings, the checkbox “encrypt the data on my hard drive” should be checked by default - as soon as the laptop is delivered to the user, in order to avoid any additional effort which might not systematically be carried out.

The details of the Canadian proposal and the 7 principles

Let’s take a look at the Canadian proposal of 2010 and the principles of data protection by design and default originally set :

1. “Proactive not reactive—preventative not remedial. Anticipate, identify, and prevent invasive events before they happen; this means taking action before the fact, not afterward.”
2. “Lead with privacy as the default setting - Ensure personal data is automatically protected in all IT systems or business practices, with no added action required by any individual.”
3. “Embed privacy into design - Privacy measures should not be add-ons, but fully integrated components of the system.”
4. “Retain full functionality (positive-sum, not zero-sum) - Privacy by Design employs a “win-win” approach to all legitimate system design goals; that is, both privacy and security are important, and no unnecessary trade- offs need to be made to achieve both.”
5. “Ensure end-to-end security - Data lifecycle security means all data should be securely retained as needed and destroyed when no longer needed.”
6. “Maintain visibility and transparency—keep it open - Ensure stakeholders that business practices and technologies are operating according to objectives and subject to independent verification.”
7. “Respect user privacy—keep it user-centric - Keep things user-centric; individual privacy interests must be supported by strong privacy defaults, appropriate notice, and user-friendly options.”

In summary, here are the rules to take into account when designing an information system :

1. Anticipate privacy risks
2. Enable all privacy-protecting options by default
3. Plan for privacy as a central function
4. Do not limit system functionality in return for privacy protection
5. Ensure end-to-end IT security
6. Maintain the transparency of the processing carried out by the IS
7. Respect the privacy of users and provide this as an additional benefit offered to users

However the GDPR took a completly different direction for implementation of these ideas.

II. - What are the obligations imposed by Privacy By Design in the GDPR?

Unfortunately, as good as these ideas were, the GDPR took a completly different direction for their implementation - despite the title of art. 25 was kept the same: Data protection by design and by default.

Let’s look at the detail of article 25 :

1.Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
2.The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.

Upon reading article 25.1, we can legitimately wonder what it really brings in terms of legal obligations :

• if we summarize main obligation laid down by art. 25.1 we can establish that “the controller implements (…) measures (…) in order to meet the requirements of this regulation”. To sum up: the law requires the data controller to comply with the law. It doesn’t add very much.
• Article 25.2 does not really do any better, as it indicates that the data controller ensures to collect the minimum amount of personal data. This might seem like a new rule of law, but it’s not. It’s a reminder of the principles set by article 5.1, which already imposes the controller to collect the minimum amount of data.

It is common, when faced with such a problem, to analyze the recitals of the text in order to determine what the intention of the legislator was. Recital 78 of the GDPR adds a bit more details to the article 25 :

The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.

These provisions in mind, it is now difficult to find real new obligations that don’t already exist within the GDPR :

• principle of minimization (already set by art. 5)
• principle of minimization over time (again set by art. 5)
• principle of data security (set by art. 5 and mostly art. 32)
• respect for the rights of individuals (art. 12 et seq.) etc.

The conclusion we could reach here is that we are confronted with a legislative bug, as article 25 just imposes obligations that were already set by other provisions. We could argue that these obligations make a specific distinction about the moment of implementation (when the IT systems are desgined). But the scope of the general obligations already apply to that : Ubi lex non distinguit, nec nos distinguere debemus

In realty, there’s a specific category of persons that should have been targetted by the principles Privacy By Design: software editors. This is an real missing actor in the GDPR as if they do not process personal data, they have no obligation whatsoever in regard to the design of their systems. In reality, that’s what the GDPR tried to aim at. GDPR targets Controllers, Processors, joint controllers, but never specifically software editors, or producers of IT equipements and it’s a missing category, to which the principles set out in Article 25 should really be applied to. GDPR choose not to target these intermediaries who provide the tools to operate the data processing. As a result, the obligations set by article 25 are a bit of a miss. It is likely that the next revision of the regulations - probably around 2035-2040 - will address that issue.

In the meantime, we must do our best to try to give meaning to the intention of the legislator.

III. - Operational actions that can be taken to implement privacy by default and privacy by design

Fortunately, even if the article 25 lacks structure, it’s possible to build a clear step by step processes to implement the principles of privacy by design :

For example let’s take the one requirement : transparency. This can be translated into a operational process:

• Clarity – Information delivered to the user shall be in clear and plain language, concise and intelligible
• Semantics – Communication should have a clear meaning to the audience in question (ex : children)
• Accessibility - Information shall be easily accessible for the data subject (materially, user should not have to do efforts to access the inforamtion about the processing activity)
• Contextual – Information should be provided at the relevant time and in the appropriate form
• Relevance – Information should be relevant and applicable to the specific data subject
• Universal design – Information shall be accessible to all data subjects, include use of machine readable languages to facilitate and automate readability and clarity
• Comprehensible – Data subjects should have a fair understanding of what they can expect with regards to the processing of their personal data, particularly when the data subjects are children or other vulnerable groups
• Multi-channel – Information should be provided in different channels and media, not only the textual, to increase the probability for the information to effectively reach the data subject
• Layered – The information should be layered in a manner that resolves the tension between completeness and understanding, while accounting for data subjects’ reasonable expectations.

Controllers should then do the work of translating each requirement into operational tools, or use our pre-built templates inside Legiscope