Data Protection Impact Assessment (Chapter 3, Section 5) — Guide to the GDPR

A DPIA is a new obligation of data controllers not foreseen in the Personal Data Protection Directive.

Pursuant to Article 35(1) GDPR:

Where a [1] type of processing – [2] in particular using new technologies, and taking into account the [3] nature, [4] scope, [5] context and [6] purposes of the processing, [7] is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, [8] prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address [9] a set of similar processing operations that present similar high risks.

What is hidden within the mysterious name ‘DPIA’? The GDPR does not introduce any legal definition of a DPIA, nor does it contain clear indications of when and how a company must conduct such an assessment.

Nevertheless, a DPIA is one of the key elements for ensuring GDPR compliance, and in practice is nothing other than a ‘qualified’ form of risk analysis and prior evaluation of the adequacy of the data protection measures for the processes planned accompanied by additional verification of legality of processing and verification of the way data subject rights are being serviced within a specific data processing set of operations.

In its guidelines on DPIAs, the Article 29 Working Party stated that a DPIA is a process to describe processing, assess the necessity and proportionality of processing, and help in managing the risk of a breach of the rights or freedoms of natural persons resulting from the processing of personal data by assessing existing risk and determining means of managing it. A DPIA is thus a further element of the GDPR that deals with protection and security using a risk-based approach and requires organisations to introduce risk management rules that are as clear and specific as possible, taking account of personal data processing procedures.

The Article 29 Working Party emphasises that the DPIA is an important tool for accountability because it facilitates for a controller not only to comply with the requirements of the GDPR but also to show that it has taken appropriate measures to comply. A DPIA, then, makes it possible to build and demonstrate GDPR compliance. It is a process that should be implemented according to the method accepted within an organisation and appropriately documented.

Apart from a ‘data protection impact assessment’ another term exists: ‘privacy impact assessment’. DPIA differs from PIA though in reality nobody precisely defines that difference – experts differ as to differences between both terms. Probably the simplest explanation would be that PIA is a general term – not having a legal definition, while DPIA is formally defined in the GDPR. Though the difference between the two is to that level unclear that the CNIL named their software tool designed to support manifesting GDPR compliance ‘PIA Tool’.

Dissecting Article 35(1) GDPR on the general obligation of the DPIA, we find the following elements:

A data processing impact assessment may concern a single data processing operation or may cover a number of similar operations. Recital 92 GDPR adds that:

There are circumstances under which it may be reasonable and economical for the subject of a data protection impact assessment to be broader than a single project, for example where public authorities or bodies intend to establish a common application or processing platform or where several controllers plan to introduce a common application or processing environment across an industry sector or segment or for a widely used horizontal activity.

This means that data processing operations can be grouped together, and that, where necessary, a DPIA can be conducted in respect of a specific group of processes in order not to replicate activities within this scope.

How can a controller know whether the operations it is planning may entail a risk of a breach of the rights or freedoms of natural persons?

In practice, for every data processing operation, a controller must evaluate whether and to what extent it poses a risk to the rights and freedoms of data subjects. There is no simple checklist in the GDPR of security measures that allow you to say with certainty that you are processing data safely and in compliance with the law. This is why a risk approach entails conducting a ‘first-degree’ risk analysis for every data processing procedure (activity). We mention this as part of our discussion on how to approach data security. The GDPR imposes a change in how we approach the issue of data protection, and how we think about processing security.

If such a ‘first-degree risk analysis’ shows that a given type of process may cause a high risk of a breach of the rights or freedoms of data subjects, then you should conduct a further, more formalised ‘second-degree risk analysis’ – a DPIA – that is systematic and documented.

‘Both an overall risk analysis and a data protection impact assessment involve the multiple (periodic) repetitions of four basic stages (context, control mechanisms, risk estimate, risk management)’.

Without an initial evaluation of every data processing operation in terms of the possibility of the occurrence of a risk of a breach of rights or freedoms, even given the large number of guidelines from supervisory and consultancy authorities such as the EDPB or your local friendly data protection supervisory authority, you cannot know for sure when a DPIA should be conducted in your organisation.

The basic tool of accountability is helpful here – the RDPA (records of data processing activities). It covers the purposes of processing, a description of data categories and data recipients, and ‘where possible, a general description of the technical and organisational security measures as referred to in Art. 32(1) GDPR’. In an RDPA you can make an initial assessment of whether there exists a likelihood of a high risk occurring and identify operations (activities) that may require a DPIA.

Theoretically, an organisation need not conduct a DPIA for every processing operation that may cause a risk of a breach of the rights or freedoms of natural persons. A DPIA is compulsory only when the processing ‘may cause a high risk of a breach of the rights or freedoms of natural persons’, especially when introducing new data processing technologies.

How should the logic of the GDPR be understood as to the need to conduct a DPIA? There must be a situation where, first, a) we may know too much or b) a data leak may occur, and second, there is a serious risk that, as a result of these circumstances, serious harm may be caused to data subjects.

The GDPR does not specify all the possible situations in which a high risk of a breach of rights and freedoms may arise and in which a DPIA must be conducted. It only gives certain indications of what direction to proceed in, providing a catalogue of operations that may require a DPIA, that is, of ‘high-risk’ processes.

Article 35(3) GDPR states:

A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of:

Thus, the GDPR only gives very general examples of operations that can cause a high risk of a breach of the rights and freedoms of data subjects.

Large-scale processing is probably the most debated GDPR term. There is a strong dissent among supervisory authorities what and if there should be generally applicable quantitative thresholds for large-scale processing. The problem is not easy, because the Union legislator did not provide quantitative (countable) criteria, even though the figure of 5,000 records came up in the legislative work on the GDPR.

The Article 29 Working Party also avoided giving figures. It counts the following (unhelpful) examples of ‘processing on a large scale’:

The Article 29 Working Party Guidelines do not, however, consider the processing of patients’ data by individual doctors, or of data on rulings by an attorney, as ‘large scale’.

When discussing the obligation to appoint a data protection officer (DPO), we mentioned that the legislator had considered introducing an obligation to have a DPO when more than 5,000 records were processed annually. Ultimately, though, no quantitative threshold was agreed.

Initial debates within EDPB have not resulted in agreeing what is large-scale processing. In the meantime Viljar Peep head of the Estonian supervisory authority in his LinkedIn post suggested: 5,000 records for special category as well as ‘criminal’ data, 10,000 for other high-risk data (e.g., financial data, e-signatures, real-time geolocation) 50,000 for other data (Viljar has not managed to indicate conditions for large-scale monitoring at the time). The Dutch supervisory authority indicated 10,000 records for health data. Those numbers have not been so far accepted by the EDPB. EDPB specifically requests supervisory bodies to remove numbers from their compulsory DPIA lists. We find EDPB’s approach counterproductive.

The figure of 5,000 remains, though, as a kind of mental anchor for monitoring. Yet, the non-invasive monitoring of unknown persons is one thing, but monitoring a fixed group of people or tracking and profiling unknown persons is another. This is why we propose using a number of quantitative parameters:

For video and other monitoring of employees, we propose a threshold of 500 employees, based on the following logic: with less than 250 employees, an employer is ‘small’ from the GDPR perspective; with 250–500 employees, an employer is considered medium-sized; with above 500, it is a large employer, and so the video monitoring of employees is monitoring on a ‘large scale’. Mind, however, that EDPB seems to consider each case of monitoring of employees as requiring DPIA (which does not seem workable at all).
For monitoring special category data, we suggest a threshold of 6,000 persons calculated as four doctors examining 1,500 patients per year.
For monitoring persons other than employees (e.g., energy consumers) known from their first and last name, and for tracking people based on electronic tags (e.g., cookies) or other tracking that makes it possible to build personality profiles, we propose a threshold of 10,000 persons.
For monitoring other data we recommend threshold of 50,000 persons/records in line with the optics of Viljar Peep.

You do not have to stick with these figures and can question them for a particular industry, but the logic behind them at least provide a starting point for considering your own calculations.

Apart from these situations, there are others in which processing may involve a high risk of a breach of the rights and freedoms of data subjects. Some of these have been taken into consideration in the Article 29 Working Party Guidelines; they recommend considering nine criteria when deciding whether a DPIA is necessary. Based on the Article 29 Working Party Guidelines, the following are examples of processing that requires a DPIA to be conducted:

evaluating or scoring. A business creating behavioural or marketing profiles based on the scope of use of a website and on that basis addressing advertisements (ratings or scores, including profiling and forecasting);
systematic monitoring. Monitoring a shopping centre, street, market, railway station, or public library (systematic monitoring of public spaces);
innovative technological or organisational solutions. Processing data using innovative technological solutions (cloud computing, blockchain, data analytics, machine learning, etc.) (use of new technologies);
processing sensitive or highly personal data. A hospital processing data contained in medical records), a private detective processing data of a highly personal nature, processing data from personal identity documents, email messages, online diaries (including using applications of the nutrition log or pregnancy calendar type), notes from e-books equipped with a notes function, or highly personal data contained in applications that automatically record daily activity – step measurements, heart rate, GPS location, collecting public data from social media in order to generate a profile (sensitive or highly personal data, large scale, ratings, or scores).

But a leak from a dating application such as Tinder may prove catastrophic in terms of the scope of harm suffered by users if data is published on who they arranged to meet, how often, the content of their conversations, or their sexual preferences. The same goes for when users (or their computers) are tracked using cookies, and data on their sexual preferences are obtained and then published (anonymously – this is possible) for the marketing purposes of a sex shop. A tracked user or tracked computer may then be targeted with sex-related ads beyond their control, which can lead to awkward situations for such people, e.g. when ads pop up on a tracked computer at work.

Another example of an operation that will probably require a DPIA is what is known as anti-fraud processing. Of course, you have to verify potential frauds, but at the same time, you have to be very careful about the circle of people who have access to the results of such analyses, because these are often not accurate and reliable, and cross into an area reserved for the judicial authorities. In the event of a leak of such data, the risk of harm being caused to the data subjects is very high. That risk relates to both the type of data processed and the nature and scope of the processing.

Out of interest, it is worth considering that another serious risk is the possibility of someone (usually an IT administrator) destroying large amounts of data in revenge against a company. Such incidents occur now and then around the world. This type of problem can be abated using a mechanism we call a ‘double nuclear key’ – that is, a requirement of two-person authorisation for any operation having a large impact on data (the problem being that current IT systems do not generally support ‘countersignatures’).

The conclusion: in ‘sensitive’ cases, you need to conduct a DPIA because the risk of harm being caused by a data leak is very high. When evaluating whether to run a DPIA, you should consider absolutely all of the factors that could affect the risk of harm being caused, including not only the nature of the processing but also the activities you are engaged in and the level of awareness of your employees. Even at this stage, one can say with a high degree of certainty that e-commerce, banks, insurers, telecommunications companies, and producers of ‘tracking’ applications have no escape from the obligation to conduct DPIAs.

Taking account of (a) the provisions of the GDPR, (b) the Article 29 Working Party Guidelines setting out criteria for evaluating the justifiability of conducting a DPIA, (c) having a properly maintained RDPA, and (d) those factors that are completely individual for your company, we recommend you develop your own, tailor-made criteria for determining whether or not to conduct a DPIA. Or instead, perhaps you can rely on the DPIA screening list prepared by the Information Commissioner’s Office – UK supervising authority (ICO), according to which:

you should consider carrying out a DPIA if you plan

any major project involving the use of personal data;
evaluation or scoring;
automated decision-making with significant effects (legal or similar);
systematic monitoring;
processing of sensitive data or data of a highly personal nature;
processing on a large scale;
processing of data concerning vulnerable data subjects;
innovative technological or organisational solutions;
processing that involves preventing data subjects from exercising a right or using a service or contract;

you should carry out a DPIA if you plan to:

use systematic and extensive profiling or automated decision-making to make significant decisions about people;
process special-category data or criminal-offence data on a large scale;
systematically monitor a publicly accessible place on a large scale;
use innovative technology in combination with any of the criteria in the European guidelines;
use profiling, automated decision-making or special category data to help make decisions on someone’s access to a service, opportunity or benefit;
carry out profiling on a large scale;
process biometric or genetic data in combination with any of the criteria in the European guidelines;
combine, compare or match data from multiple sources;
process personal data without providing a privacy notice directly to the individual in combination with any of the criteria in the European guidelines;
process personal data in a way that involves tracking individuals’ online or offline location or behaviour, in combination with any of the criteria in the European guidelines;
process children’s personal data for profiling or automated decision-making or for marketing purposes, or offer online services directly to them;
process personal data that could result in a risk of physical harm in the event of a security breach.

Pursuant to Article 32(4) GDPR:

The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment … The supervisory authority shall communicate those lists to the [European Data Protection] Board referred to in Article 68.

In practice, this means that an authority must create a catalogue of processing operations subject to a compulsory DPIA as a supplement to the situations set out directly in the GDPR.

EU supervisory authorities created DPIA lists and delivered them to the EDPB. EDPB opined on those lists in the fourth quarter of 2018. At the time we write this book there is no general pan-EU list of compulsory DPIA processing operations, as EDPB seems to be at an early stage of working out consensus.

If you are a controller operating in one Member State, you should check a DPIA list issued by your local supervisory authority as well as a respective opinion of EDPB. And if you operate in more.

A DPIA is not required:

It will probably come as no surprise to learn that the generally-worded and unclear GDPR does not say how to conduct a DPIA. Organisations will have to work out their own methodology for this, taking account of the specific nature of their activities, their data processing procedures, the security measures they are able to apply, their available resources, organisational structure, and so on. You can draw, though, on certain theoretical studies that have arisen, including:

When? Before commencing processing. This is in line with the principles of taking data protection into account during the design phase and of privacy by default. When planning any business process, you should always take account of the possible need to perform a DPIA and to document it appropriately. If there is a data processing process already in place, DPIAs should be conducted before any change to the process impacting personal data processing.

Who? The data controller is responsible for conducting a DPIA. If you have a DPO appointed in your company, you must consult the DPIA process with the DPO (Article 35(2) GDPR). The company must document the results of the consultation and the decisions taken. A DPO’s obligations also include monitoring the performance of the DPIA, though for any non-compliance with the GDPR it is the controller that is responsible. Despite it is the data controller who is ultimately responsible for conducting a DPIA, in many cases the controller will be unable to perform their DPIA without an input from a data processor. Therefore in practical terms, a data processor will be responsible as well for performing their DPIA.

How? Drawing on the above publications, a company should develop its own method of conducting a DPIA, adjusted to its own needs. Based on the logic applied by the French supervisory authority, the CNIL, the methodology for running a DPIA should take account of the following elements:

In short, DPIA consists of (regulatory elements underlined):

A DPIA must be consulted with the DPO. In practice often this is a DPO who conducts a DPIA. This is not in line with the GDPR of course.

Resorting to outside experts is recommended. The EU legislator is aware of the size of the challenge it has imposed, and of how difficult it can be for organisations to meet that challenge on their own. That is why Article 29 Working Party Guidelines recommend turning to specialists, which we as experts wholeheartedly endorse.

In model DPIA methodologies, a data controller is encouraged to consult with representatives of data subjects. It is hard to say what would need to be a minimum cost threshold to conduct a meaningful representative group test. Even more questionable how meaningful such tests are. Therefore, unless you are a multinational corporation, you may start with testing your privacy ideas on an unprepared colleague or any other layperson. That is what we refer to as the ‘John or Jane Doe test’ (not to mix with the ‘Jerry of the Day test’).

When should you consult the supervisory authority?

Article 36(1) GDPR is worded somewhat mysteriously:

The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.

Given that Article 35(1) GDPR says that a DPIA must be conducted:

Where a type of processing … is likely to result in a high risk …’, When put together, the whole forms a tautology: ‘if the risk could be high, it could turn out that the risk is indeed high …’.

The more foolish the law, the more power we put in the hands of bureaucrats. As you can see, the GDPR is a perfect example of this. But fortunately, this time the bureaucrats have come to our aid and are trying to give some kind of sensible explanation of Article 36 GDPR.

In accordance with those explanations, a DPIA must be consulted with the supervisory authority if the residual risk is high; in other words, when a controller cannot eliminate the risk identified to a sufficient degree (the residual risk remains high), it must consult the supervisory authority.

The GDPR leaves certain procedural loopholes concerning such consultations. There is no need to go into the details here; it is enough to take a look at the last sentence of Article 36(2):

Those periods may be suspended until the supervisory authority has obtained information it has requested for the purposes of the consultation.

It results from this provision that the supervisory authority has an unlimited amount of time to evaluate the problematic processing in a consultation procedure and that this provision was introduced for that very purpose. We are not questioning the sense of that solution (at least officially), although it does leave a lot to be desired in terms of the principles of reliability and clarity. It would be more honest to write: ‘The authority can think about it until it comes up with something.’

Being realistic, knowing that the supervisory authority may tell you not to initiate processing, to stop processing and may initiate investigation against you and fine you, how inclined you are to address the supervisory authority with your concerns about the security of processing?

#5.1 Preliminary Remarks

#5.2 ‘Qualified’ Risk Analysis and Accountability

#5.3 Similar Processes, One DPIA

#5.3.1 Risk Analysis

#5.3.2 In Practice, How Can I Conduct a First-Degree Risk Analysis and Have an Initial Overview of What Operations Require a DPIA?

#5.4 When Is a DPIA Necessary?

#5.4.1 Large Scale

#5.4.2 Article 29 Working Party

#5.5 How Can I Determine Whether I Need to Run a DPIA in My Company and for What Processes?

#5.5.1 Regulatory Catalogue of DPIA Operations

#5.6 When Do I Not Need to Conduct a DPIA?

#5.7 DPIA Step by Step

#5.7.1 General Remarks

#5.7.2 Data Protection Officer

#5.7.3 Experts

#5.7.4 Representatives of Target Groups

#5.7.5 Prior Consultations with the Supervisory Authority