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).
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 :
In summary, here are the rules to take into account when designing an information system :
However the GDPR took a completly different direction for implementation of these ideas.
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 :
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 :
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.
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:
Controllers should then do the work of translating each requirement into operational tools, or use our pre-built templates inside Legiscope