#3.1 Privacy by Design
Pursuant to Article 25(1) GDPR:
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 [1 – corresponds to Art. 32(1) – processing security], the controller shall, both [2] at the time of the determination of the means for processing and [3] at the time of the processing itself, implement [4] appropriate technical and organisational measures, such as [5] pseudonymisation, which are designed to implement data-protection principles, such as [6] data minimisation [privacy by default], in an effective manner and [7] to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
Privacy by design requires you to think about personal data protection from the stage of designing procedures and IT systems, processes, and products. Accordingly, you must implement measures that guarantee the security of data processing from the design stage and not ‘add’ them later after a given solution has already been invented and designed. This makes it possible to avoid loopholes and inconsistent processes. Yet, it should be emphasised that the effects of privacy by design should be visible throughout the entire data processing procedure.
Important
New design activities also include modifying existing solutions.
The main advantages of the privacy by design approach are:
- 1)identifying potential problems at the very beginning of the process;
- 2)having a greater likelihood of meeting the GDPR requirements, and in particular embedding data subjects rights related functionalities into software systems;
- 3)mitigating ‘error in design’ issues related to data processing and privacy;
- 4)increasing awareness in the organisation of the personal data processing requirements.
Privacy by design is a consequence of one of the main assumptions of the GDPR – that of a preventive approach. But please note that the privacy by design concept is not entirely new – it was presented in the 1990s by Ann Cavoukian, the Ombudsman for Ontario. Cavoukian’s conception was based on seven pillars that included a pro-active and preventive approach, privacy as the default setting, and data protection throughout the entire processing cycle.
Privacy by design refers to minimisation, the latter in general corresponding to privacy by default. So you should probably start reading Article 25(1) GDPR from Article 25(2) GDPR.
#3.1.1 What Privacy by Design Consists In
From the wording of the GDPR provision on privacy by design, three things can be distinguished: you must guarantee (1) security and (2) minimisation of access, and these must be taken account of (3) in advance, meaning that you must design whenever possible, that is for all new plans.
The provision itself is worth reading more or less from the end:
[7] in order to secure the processing and ensure its lawfulness, and [6] in order to apply the principle of the minimisation of data, [4] you must use technical and organisational measures appropriate
- [1] to the risk of a breach of the rights and freedoms of persons as a result of the processing, and you must do this
- [2] at the stage of selecting technologies, suppliers and processing procedure, as well as
- [3] during the processing itself, [5] including by using pseudonymisation, or at least by verifying its usefulness.
#3.1.1.1 Security
The first part of the provisions is in effect a repetition of Article 32 GDPR on data processing security.
The factors that affect the scope of the privacy by design obligation are: the state of the art; the costs of implementation; the nature, scope, context, and goals of the processing; and the risk of a breach of the rights and freedoms of natural persons.
This means that in every case a controller should weigh those factors from the perspective of its own individual situation. Mind, however, that ‘no considerations of an organisational or financial nature should be treated as a basis for the unlawful processing of personal data’. A controller is not obliged to ensure that all security measures are used when processing data; it may limit itself just to those that are adequate and appropriate (whatever that means in light of the GDPR requirements. Actually, it means whatever comes out from a risk analysis and cannot be easily questioned).
#3.1.1.2 Pseudonymisation
In respect of privacy by design, the GDPR directly specifies only one of the security measures available – the pseudonymisation of data. This does not mean, though, that you can neglect the other measures included in Article 32 GDPR or you are obliged to implement pseudonymisation. You should interpret things in this way – that you must not neglect pseudonymisation when analysing the adequacy of security measures or designing changes in data processing. In every case, you should verify whether pseudonymisation has a place in the solutions designed.
As shown above, when discussing pseudonymisation and encryption, pseudonymisation fits in with the principle of minimisation, because it can be used to limit the amount of information on natural persons processed by an organisation for business and other purposes and is therefore also suitable for limiting authorised access (graded access).
#3.1.1.3 Minimisation
The concept of minimisation is discussed below in section 3.1.2 on privacy by default. Here we will just mention that it concerns minimising knowledge about a person in order to maximise that person’s privacy and primarily involves minimising access to information (personal data) in the possession of an organisation.
#3.1.2 How to Implement Privacy by Design in an Organisation
#3.1.2.1 Privacy by Design in a Specific Project
Meeting the requirement of privacy by design in a specific instance involves conducting risk analyses and frequent DPIAs and then acting on the organisation and technical conclusions resulting from these. This can be by choosing a system that provides more diverse access procedures, purchasing access management tools having high organisational logic and intuitive screens that graphically organise supervision over authorised users in various systems, choosing suppliers that accept the most responsibility for personal data breaches or that offer certified solutions and tools that make it possible to force customers to go along with security policy in an integrated manner (cloud services often have a problem with this), etc.
#3.1.2.2 Rules of Privacy by Design
As mentioned above, privacy by design involves taking care of personal data security in advance, minimising processing, and above all minimising data access. For this to take place, you must check when starting up a new project whether any other change in the organisation has taken privacy into consideration.
To this end, you should include the requirements for protecting privacy in your procedures for initiating new projects, new investments, seeking new suppliers, and making changes in the organisation. If your organisation has not yet worked out such procedures, it is high time to draw up a short checklist for those who make decisions on new outlays. That list should include questions on whether the impact of activity related to the outlay/investment on privacy has been verified, whether a risk analysis has been conducted concerning a potential breach of the rights and freedoms of people whose data the new project will affect, and whether privacy by design has been guaranteed – including through organisational or technical data protection measures and the principle of minimising data access as well as ensuring tools for executing data subject rights and allowing for accountability are in place. You should also make sure that new projects are reflected in the register of processing activities – by using appropriate connections between procedures or involving those persons responsible for the data processing activity record in the process of starting up new projects.
In practical terms, it may make more sense to perform a DPIA (DPIA – described in Chapter 5 below) for each new project initiated than to design an additional less detailed PIA procedure for a starter and then to check if a DPIA is needed and move to perform such DPIA.
#3.1.2.3 When to Design Privacy
Privacy should be designed and implemented at once, that is, whenever there is to be an organisational, technological, process, or business change that could have an impact on data processing and that is completed after 25 May 2018. You must conduct a documented privacy analysis, make a decision on the requirements and activities needed to secure privacy, and implement those requirements and activities. Privacy by design programme might be a righteous response to legacy issues of existing personal data processing systems and processes in a particular organisation. Due to various practical reasons, you were probably not able to be truly GDPR compliant on 25 May 2018 or even by the end of 2019. And that may be even fine. However, you should achieve appropriate technical level of GDPR maturity in a definite time. And that is what a privacy by design programme may serve for.
#3.2 Certification of Privacy by Design and Privacy by Default
Pursuant to Article 25(3) GDPR, you can demonstrate that you have met the obligations referred to in paragraphs 1 and 2 of the article by introducing an approved certification mechanism as described in Article 42 GDPR.
However, at the time we write this book, there are no existing certification mechanisms in place. So far only European Data Protection Board (EDPB) issued guidelines on certifications mechanisms, not adding much to general rules already described in ISO standards.