In the scope of the General Data Protection Regulation (GDPR) and other data laws a data protection impact assessment or DPIA helps organizations to assess what will/might be the impact of (new) personal data processing activities from the perspective of data protection, privacy and most of all the risks regarding the personal data of the data subject.
The usage of a DPIA is not new, nor is that of privacy impact assessments or PIAs. However, under the GDPR a Data Protection Impact Assessment or DPIA is mandatory in specific circumstances. These circumstances are broader than one might expect when just looking at the key stipulations regarding the need for a DPIA in the text of the GDPR itself.
While the GDPR text provides guidance, the guidelines on DPIA, as published by the WP29 (adopted in April 2017 but last revised in October 2017), are more useful as we’re in the actual implementation and enforcement guidelines of the GDPR here – and it’s in these guidelines, among others in several of the criteria to determine whether a high risk, and a DPIA as a consequence, is likely, that the actual application areas become clear (the WP29 publishes many guidelines which are key to understand the application of the GDPR, for instance also on GDPR fines).
In other words, DPIAs are less exotic and less exceptional than they might seem in times when organizations introduce and leverage new ways, processes, technologies and systems in an age where it’s all about data monetization, data exchanges, big data analysis, monitoring, profiling and a real deluge of unstructured data and data gathered by using sensors and tags as we do in the IoT (Internet of Things).
The Data Protection Impact Assessment: demonstrating GDPR compliance
As a DPIA is an assessment of the impact of specific (planned) data processing activities on data protection we’re of course in the field of personal data here and personal data protection is obviously the scope of privacy laws (hence also the existence of privacy impact assessments or PIAs), and in this case the GDPR.
Needless to say that in a data-driven economy personal data often are more valuable than other types of data, depending on the scope of the data processing purpose (scientific research, profiling and targeting, you name it) and thus deserve more protection. Simply put, a DPIA is mainly used when an organization is anything but sure about the impact on data protection of something it is planning to do and needs more thorough analysis and guidance, among others by inviting regulators, professionals and/or supervisory authorities. In the latest WP29 guidelines the role of the Chief Security Officer (CISO), for example is also strengthened.
Do note that the fact that a DPIA is only mandatory in specific circumstances under the GDPR doesn’t mean that they can be extremely useful if they are not really mandatory too. What better way to demonstrate GDPR compliance than a DPIA?
That’s also what the WP29 clearly emphasizes in its DPIA guidelines where it states “A DPIA is a process designed to describe the processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data by assessing them and determining the measures to address them. DPIAs are important tools for accountability, as they help controllers not only to comply with requirements of the GDPR, but also to demonstrate that appropriate measures have been taken to ensure compliance with the Regulation. In other words, a DPIA is a process for building and demonstrating compliance”.
This makes the DPIA one of several ways to demonstrate GDPR compliance as they are listed in the GDPR text. Another example of a way to demonstrate GDPR compliance is the adherence to a code of conduct.
The GDPR and DPIAs: the General Data Protection Regulation rules: DPIA Articles and Recitals
Let’s look at the essence of what the GDPR says about DPIAs and those guidelines we mentioned. First the Regulation itself.
In Article 35 the GDPR introduces the circumstances in which there is a requirement for a data protection impact assessment.
Article 35 says that a DPIA needs to be carried out when:
- a specific type of personal data processing is planned and in particular when that type of processing uses ‘new technologies’, and
- taking into account nature, scope, context and purposes of the data processing,
- is likely to impact the data subject’s rights and freedoms in a high degree (‘high risk’).
If such is the case the data controller must conduct a DPIA to assess the impact of the data processing on personal data protection BEFORE starting the actual processing operation.
When thinking new technologies you can think, for example the combination of finger prints and face recognition for physical access control but also, as said, IoT applications, as mentioned in the WP29 guidelines.
Additionally, Article 35 on the DPIA states that:
- One DPIA may be used to assess the impact of several data processing operations that are similar and are likely to lead to similar risks,
- the advice of the data protection officer needs to be sought (when there is one of course, the designation of a data protection officer is only mandatory in specific cases),
- when it is appropriate the views of data subjects themselves (or their representatives) will be asked regarding the planned data processing activities for which the DPIA is needed (keeping in mind other aspects than the data subject’s rights such as commercial, public and security aspects),
- the supervisory authority will establish a list of the processing operations for which the DPIA is conducted and make it public.
The GDPR also sums up 3 cases in which a DPIA is required, emphasizing the importance of the concerned data processing operations and their scope and impact which by the way again gives more insights into what is really important from a personal data risk perspective for the GDPR.
The 3 cases in which a DPIA is particularly required are:
- When there is a systematic and extensive evaluation of personal aspects relating to the data subject which is based on automated processing such as profiling that leads to decisions whereby legal effects or other important effects are produced regarding that data subject,
- When there is a large-scale processing of the special categories of personal data which the GDPR mentions in the first paragraph of its Article 9 (personal data revealing racial/ethnic origin, political opinions, religious/philosophical beliefs, membership of a trade union and several types of sensitive data such as genetic data, biometric data when the aim is to uniquely identify the data subject, as well as health-related data and data regarding the sex life or sexual orientation of the data subject), or of personal data regarding criminal convictions/offences (mentioned in Article 10 of the GDPR),
- When there is a systematic monitoring, again on a large scale, of a publicly accessible area.
The GDPR’s Article 35 also sums up the elements that should be AT LEAST in the DPIA.
We summarized those elements that need to be present at least below.
Check out the full Article 35 as there is more on what the controller can do.
The controller can, among others, check if the processing is de facto done in accordance with the DPIA and more.
Relevant Recitals concerning the DPIA in the GDPR text are:
- GDPR Recital 89, which abolishes the general obligation to notify processing of personal data to supervisory authorities as was the case in Directive 95/46/EC but instead calls for more effective procedures and mechanisms, in particular for processing operations using new technologies,
- GDPR Recital 90 which refers to Recital 89 and says that in such cases a DPIA should be carried out and stipulates what a DPIA should contain,
- GDPR Recital 91 that dives deeper in the necessity of a DPIA,
- GDPR Recital 92 where the reasons for a data protection impact assessment to be broader than a single project are mentioned and
- GDPR Recital 93 that tackles DPIAs for public authorities.
DPIA guidelines: from risk management to 9 criteria helping to gauge whether a concrete personal data processing operation might result in a high risk
OK, so those are the main things about DPIA’s in the scope of Article 35 and the Recitals of the GDPR. Now those guidelines by the WP29 (Article 29 Working Party).
As a reminder: we base ourselves on the version of the “Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is likely to result in a high risk for the purposes of Regulation 2016/679″ as last revised and adopted on October 4, 2017.
First, the requirement to conduct a DPIA, when it needs to be conducted, must be understood against the background of the general obligation of the controller to appropriately manage risks as a result of personal data protection.
That risk, which the guideline defines as “a scenario describing an event and its consequences, estimated in terms of severity and likelihood” and the obligation of risk management, which appropriately managing risks of course is (the guideline defines risk management as “the coordinated activities to direct and control an organization with regard to risk”), is essential and controllers cannot cover it under insurance policies. It’s the responsibility of the controller and that responsibility, as well as the ability to manage it, comes with duties to identify, analyze, estimate, evaluate, treat (e.g. mitigate) and review risks regularly.
It again shows the importance to look at the GDPR overall from the data subject’s risk perspective, whereby the WP29 guideline on the DPIA also again mentions the role of a risk-based approach in data protection legal frameworks, including the GDPR of course.
Elaborating on the ‘rights and freedoms’ of data subjects which we mentioned above in the scope of Article 35, WP29 says that they primarily concern the rights to data protection and privacy “but may also involve other fundamental rights such as freedom of speech, freedom of thought, freedom of movement, prohibition of discrimination, right to liberty, conscience and religion”.
The guideline regarding the DPIA also offers a far more concrete list of processing operations for which a DPIA is required with ample of concrete examples. On top of that, it provides 9 criteria to ‘consider’ to gauge whether a concrete processing operation is likely to result in a high risk as you can see below.
Do check out those DPIA guidelines as you’ll notice, among many others, that there are practical cases and examples whereby these 9 criteria are used to respond to the question whether in each case a DPIA will be needed, it also shows the relationship between various key principles in the GDPR in the scope of the DPIA and, very important, adds a lot to each criterion, in comparison with the GDPR text.
Criterion 4 (sensitive data or data of a highly personal nature), for instance, includes the earlier cited special data categories. However, here the DPIA guidelines go far deeper into detail in additional types of data which de facto also means that you best approach the data categories that are concerned in determining the ‘likeliness to result in a high risk’ and the DPIA as a result broader than what is strictly mentioned in the Articles regarding these data categories (Article 9 and 10) and thoroughly check them out in the DPIA guidelines of the Article 29 Working Party, which you can download in PDF here (PDF opens immediately).
Next in regulations and compliance: EU DORA Digital Operational Resilience Act
All quotes are from the mentioned October 2017 WP29 guidelines. Top image: Shutterstock – Copyright: adike – Icons: Shutterstock – Copyright: Nevada31 – Although the content of this article is thoroughly checked we are not liable for potential mistakes and advice you to seek assistance in preparing for GDPR.