The data protection impact assessment (DPIA) I (Preparation of DPIA)
The GDPR contains rules on when controllers are required to prepare a data protection impact assessment (DPIA), when they have to seek the views of data subjects or their representatives on the intended processing and, furthermore, when they are obliged to consult the supervisory authority prior to processing.
The Article 29 Data Protection Working Party (WP29) issued guidelines on the DPIA on 4 April 2017 (WP248), that were then revised on 4 October 2017, and that interpret the respective provisions of the GDPR (Articles 35-36 and Recitals 75-76, 84 and 90-95).
Below you fill wind a Q&A concerning the obligation to prepare a DPIA.
1. Who is required to prepare a DPIA?
Under the GDPR, the obligation to prepare a DPIA lies with the controller.
It is worth mentioning that if the controller has a data protection officer (DPO), the controller is required to seek the advice of the data protection officer when carrying out a DPIA. Thus, the DPO may also have an essential role in preparing a DPIA. With respect to this, it is advisable to include a provision in the agreement with the DPO pursuant to which the DPO is required to assist the controller in every way in connection with the DPIA, including also the preparation of the same.
2. Does the processor have any obligation in connection with a DPIA?
Under the GDPR, the agreement that the controller concludes with the processor must stipulate that the processor is required to assist the controller in ensuring compliance with the obligations, including but not limited to the obligations connected to the DPIA taking into account the nature of processing and the information available to the processor.
3. When is it required to prepare a DPIA?
A DPIA is required when the processing is “likely to result in a high risk to the rights and freedoms of natural persons” unless the respective data processing is white-listed (Article 35(5) GDPR) or union or member state law meeting certain conditions allows for an exception (Article 35 (10) GDPR).
DPIAs are about managing risks and managing them in an appropriate way. The purpose of a DPIA is a minimization of privacy risks. As the WP29 puts it, “a “risk” is a scenario describing an event and its consequences, estimated in terms of severity and likelihood.” Furthermore, risk management “can be defined as the coordinated activities to direct and control an organization with regard to risk.”
It is important to note that just because the conditions for having to prepare a DPIA have not been met, controllers are still obliged to take appropriate measures with a view to ensuring an acceptable level of risk. In addition, the WP29 also stresses that in line with the principle of accountability, controllers are under the obligation to continuously monitor and assess the risks caused by their processing activities in order to identify when a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons”.
For further details, please see the response to question 5 below.
4. At what point in time must a DPIA prepared?
The GDPR makes it clear that a DPIA must be prepared prior to commencing processing operations provided that the conditions as referred to in questions 3 and 5 apply. Thus, in accordance with the principles of privacy by design and by default, controllers are highly advised to plan well ahead and take into account that the launch of a new data processing activity may require the preparation of a DPIA, which may take some time.
5. When is processing “likely to result in a high risk?”
The GDPR is not quite explicit on this but contains some guidance and also three examples when a DPIA must be prepared, which are as follows:
“(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person;
(b) processing on a large scale of special categories of data (such as, for example, health data or personal data relating to criminal convictions and offences); or
(c) a systematic monitoring of a publicly accessible area on a large scale.”
This list is non-exhaustive, meaning that there may be other data processing activities that are not covered by this list. The WP29 has developed a list of nine criteria to be taken into consideration when assessing if a DPIA is required. Such criteria are as follows:
(i) evaluation or scoring, including profiling, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (Recitals 71 and 91 of the GDPR). Examples: a financial institution screening its customers against a credit reference database or an anti-money laundering database; company building marketing profiles based on the navigation on its website.
(ii) automated-decision making with legal or similar significant effect: processing the purpose of which is to take decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person”.
(iii) systematic monitoring: e.g. data collected through networks. The data may be collected in a way that the data subjects may not be aware of who is collecting their data and how they will be used.
(iv) sensitive data or data of highly sensitive nature: e.g. health / medical data, data concerning political opinions, religion, data concerning criminal convictions, financial data and personal documents, diaries may also be included.
(v) data processed on a large scale: the GDPR does not define the term “large scale”. However, the WP29 gives some guidance on its meaning in its guidelines on the data protection officer (DPO). For details on the DPO, please click here.
The following factors have to be assessed to decide if processing takes place on a large scale:
- the number of data subjects concerned, either as a specific number or as a proportion of the relevant population;
- the volume of data and/or the range of different data items being processed;
- the duration, or permanence, of the data processing activity;
- the geographical extent of the processing activity.
(vi) combining datasets: e.g. combining two databases containing personal data collected for different purposes.
(vii) data concerning vulnerable data subjects: e.g. the personal data of children, the elderly, employees, patients or of people where there is an imbalance in the relationship between the controller and the data subjects.
(viii) innovative use or applying new technological solutions: e.g. combining the use of finger print and facial recognition for physical access control. The use of a new technology may mean an increased level of risk to the rights and freedoms of data subject as the possible consequence of the use of such a new technology may be unknown. The WP29 emphasizes that certain Internet of Things applications may also require a DPIA.
(ix) processing in itself “prevents data subjects from exercising a right or using a service or a contract”: e.g. a bank screens its customers against a credit reference database in order to decide whether to offer them a loan.
The WP29 says in the guidelines that:
“In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out. In general, the WP29 considers that the more criteria are met by the processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and therefore to require a DPIA, regardless of the measures which the controller envisages to adopt.
However, in some cases, a data controller can consider that a processing meeting only one of these criteria requires a DPIA.”
The guidelines also contain a non-exhaustive list of data processing activities where a DPIA is required and where a DPIA is not required.
Examples where a DPIA is required:
- a hospital processing its patients’ health data;
- a company systematically monitoring its employees’ activities, including the monitoring of the employees’ work station, internet activity;
- a company gathering social media data for generating profiles;
- a company storing (for archiving purpose) pseudonymised personal sensitive data concerning vulnerable data subjects of research projects or clinical trials.
The WP29 adds that even if a data processing activity falls under any of the above criteria, it may still be that no DPIA is required provided that the data processing is not likely to result in a high risk. In such a case, however, the controller must document the reasons for not having to prepare a DPIA.
Examples where a DPIA is not required:
- processing of “personal data from patients or clients by an individual physician, other health care professional or lawyer”;
- an online magazine using a mailing list to send a daily digest to its subscribers.
The WP29 recommends that when it is not clear if a DPIA must be prepared, the controller is advised to prepare one.
6. What about processing operations that exist prior to 25 May 2018?
The GDPR provides that if a DPIA must be carried out, it must be carried out prior to the processing. Thus, one may come to the conclusion that no DPIA is required in regard of a data processing operation that is already underway prior to 25 May 2018 since it is not possible to prepare a DPIA prior to a processing which is already ongoing. However, such a conclusion should be treated with caution. The WP29 stresses that:
“As a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed. Therefore, even if a DPIA is not required on 25 May 2018, it will be necessary, at the appropriate time, for the controller to conduct such a DPIA as part of its general accountability obligations.”
Having the above in mind, in line with the principle of accountability, it is advisable to prepare an analysis in regard of the data processing operations as to whether or not a DPIA is required and if the analysis concludes that a DPIA is required, it is certainly recommended preparing one prior to 25 May 2018. Furthermore, even if the conclusion is that no DPIA is required, a regular monitoring and re-assessment of the analysis is required since risks may change over time and a DPIA may become required.
7. What does a DPIA have to contain?
The GDPR enlists the minimum elements a DPIA must contain, which are as follows:
(a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
(c) an assessment of the risks to the rights and freedoms of data subjects; and
(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR taking into account the rights and legitimate interests of data subjects and other persons concerned.
The GDPR contains no rules as to the methodology of preparing a DPIA. However, the guidelines contain a non-exhaustive list of methodologies developed by certain DPAs (the UK, German, French and Spanish DPAs) and names also two-sector specific methodologies, namely, the DPIA framework for Radio Frequency Identification (RFID) applications and smart metering systems.
The DPIA framework for RFID Applications specifies the issues as named under question 8 below, which must be addressed when it comes to preparing a DPIA. For details, please see the response to question 8.
8. How should a DPIA be prepared?
The GDPR only contains the minimum elements a DPIA must include but contains no rules as to the methodology.
Furthermore, it is worth noting that Recital 90 of the GDPR contains some additional useful guidance as to what a DPIA must contain and assess. Namely, when preparing a DPIA,
(a) the “nature, scope, context and purposes of the processing and the sources of the risk” must be identified and taken into account;
(b) it is important to “assess the particular likelihood and severity of the high risk” and
(c) it is essential to properly treat the risks.
Although, the DPIA framework for RFID applications was tailor-made for RFID applications, it contains useful and practical information that controllers may find very helpful. Under the DPIA framework for RFID applications, the following issues must be addressed in a DPIA:
(a) description of the data processing operations (overview of processing, who processes the data, what is the purpose of and legal basis for processing, where are the data stored, where are the data transferred to, who has access to the data, what is the duration of processing);
(b) identification and evaluation of the privacy risks (what are the risks, what is the likelihood of the risks, what is the severity level of the risks);
Below is a non-exhaustive list of possible privacy risks:
- the purpose of data collection has not been specified, more data is used than necessary;
- the information given to data subjects is incomplete;
- the combination of data with other data to an extent that is not necessary to achieve the purpose of processing;
- the data is retained longer than necessary;
- some data are secretly recorded, i.e. without the knowledge of the data subject;
- the data subject cannot object to processing or exercise other rights;
- access rights are not revoked when they are no longer necessary;
- data subjects are not informed about the logics of automated individual decision-making;
- a suspicious number of attempts to authenticate are not prevented;
- there is no valid legal basis for processing;
- the implemented logging mechanism is insufficient.
(c) measures to mitigate risks (what are the measures the controller takes to mitigate risks);
Below is a non-exhaustive list of possible mitigating measures:
- appropriate privacy policy is in place;
- access rights are properly set and implemented;
- appropriate data retention policy is in place;
- appropriate IT security measures are in place.
(d) if there are any residual risks (if any risk remain despite the taking of mitigating measures);
(e) implementation of measures and the drawing of consequences.
The DPA in the UK, i.e. the Information Commissioner’s Office (ICO) issued a document named “Conducting privacy impact assessments, Code of Practice” in February 2014 and it basically follows the same logic as the DPIA framework described above.
9. Are controllers required to keep the DPIA up to date?
Yes. Pursuant to the GDPR, “where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.”
As the WP29 puts it, “carrying out a DPIA is a continual process, not a one-time exercise.” The DPIA is regarded as an important tool for compliance, “a process for building and demonstrating compliance” and it should be continuously reviewed and regularly re-assessed.
10. Does a data protection officer (DPO) have any task concerning a DPIA?
If the controller has a data protection officer (DPO), the controller is required to seek the advice of the data protection officer when carrying out a DPIA. Thus, the DPO may also have an essential role in preparing a DPIA. If the controller does not take the advice of the DPO, this fact and the reasons for not taking the advice have to be documented.
Also, it is advisable to include a provision in the agreement the controller has with the DPO pursuant to which the DPO is required to assist the controller in every way in connection with the DPIA, including also the preparation of the same.
11. Is the controller required to publish the DPIA?
No. However, the controller may decide to publish the DPIA or the most important findings of it (of course, without revealing any business secrets of sensitive information) on its website to demonstrate compliance.
In my next post, I will address issues concerning seeking the views of data subjects and prior consultation with the supervisory authority.
Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)
The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.
