Data protection impact assessments (DPIA) have been getting a lot of attention lately thanks to the upcoming EU General Data Protection Regulation (GDPR). For the first time, the GDPR introduces mandatory DPIAs “where a type of processing . . . is likely to result in a high risk to the rights and freedoms of natural persons.”1 While this seems straightforward, there are specific requirements for what must be included in a DPIA and in how to conduct the process of carrying one out — a common pitfall being that organizations will take their pre-existing approach to the DPIA and assume that it already meets GDPR requirements, without first digging into what those requirements actually are.
What is a DPIA?
Generally speaking, a DPIA is an assessment used by an organization to identify and reduce risks to privacy and data protection. While the GDPR provides data controllers with flexibility in determining the precise structure and form of the DPIA, the end result must be a genuine assessment of risk that also supports controllers in taking measures to address and treat those risks. A DPIA should describe the processing activity, assess its necessity and proportionality, and help to manage any risks to the rights and freedoms of individuals.
There are a variety of tools out there designed to assist with this work. OneTrust, for example, has DPIA templates that can be used to support compliance with the GDPR and other laws. Using tools like OneTrust can help to streamline workflows, enable greater collaboration between the privacy office and business teams, and operationalize Privacy by Design.
The Article 29 Working Party
In April 2017, the Article 29 Working Party (WP29) released a draft of its guidelines on DPIAs and determining whether processing is “likely to result in a high risk” for the purposes of the GDPR. After examining comments received during the public consultation period for the draft, the WP29 has adopted a revised version of the guidelines. The stated purpose of the guidelines is to anticipate future guidelines, recommendations and best practices expected to be issued by the European Data Protection Board (EDPB) according to Article 70(1)(e), “and therefore to clarify the relevant provisions of the GDPR in order to help controllers comply with the law and to provide legal certainty for controllers who are required to carry out a DPIA.”2
While the WP29 did not make any major revisions to its guidelines, there were some tweaks worth noting, such as:
- Reinforcing the importance of taking a risk-based approach;
- Removing cross-border transfer from the criteria to consider when evaluating for high-risk;
- Adding additional practical examples of activities that might constitute high-risk;
- Announcing that DPIAs may also be required in some circumstances for processing activities existing prior to May 25, 2018;3
- Removing the minimum three year re-assessment requirement;4 and
- Further defining the role of Chief Information Security Officers (CISO) and Data Protection Officers (DPO) in the DPIA process.5
What is “high risk”?
As mentioned above, a DPIA is mandatory in cases where a processing activity is “likely to result in a high risk” to individuals. Of course, this begs the question, what is considered high risk? The GDPR provides some guidance here by providing examples of when a DPIA might be required, but in many ways it tends to raise more questions than answers.6 For example, in practice, what would be considered “systematic and extensive evaluation of personal aspects,” “processing on a large scale of special categories,” or “systematic monitoring of a publicly accessible area on a large scale.”
In an effort to provide some clarity around questions like these, the WP29 includes a non-exhaustive list of nine criteria in its DPIA guidelines for evaluating whether a processing activity is likely to result in high-risk, as well as specific real-world examples of each criterion.7 8 The nine criteria laid out by the WP29 are as follows:
- Evaluation or scoring;
- Automated-decision making with legal or similar significant effect;
- Systematic monitoring;
- Sensitive data or data of a highly personal nature;
- Data processed on a large scale;
- Matching or combining datasets;
- Data concerning vulnerable data subjects;
- Innovative use or applying new technological or organisational solutions; and
- Preventing data subjects from exercising a right or using a service or a contract.
The revised guidelines also include new examples of each criterion. For example, evaluation or scoring “could include a financial institution that screens its customers against a credit reference database or against an anti-money laundering and counter-terrorist financing (AML/CTF) or fraud database . . . .” The guidelines also state that “[i]n most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out” and that “[i]n 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.”
At OneTrust, we use these criteria as part of our threshold assessment for determining whether an activity is likely to result in high risk and therefore necessitating a DPIA. It is worth noting, however, that while these nine criteria can serve as the basis for threshold questions in determining whether a DPIA is mandatory, it is important that they not be relied on too heavily as hard and fast rules. Risk analysis is not a one-size-fits-all exercise, and therefore requires more than a checklist approach.9 Instead, it requires analysis of numerous variables including contextual and cultural considerations, the type of harm and recipient of that harm, as well as its severity (or “impact”) and likelihood of occurring.
Risk should also be analyzed through the lens of the data subject, rather than the business. This will be a new challenge for some US-based companies and privacy offices who up until now have only viewed privacy through an American-lens. Under GDPR, these companies will need to put themselves in the shoes of a European data subject, and because privacy is a fundamental human right written into the EU Constitution, a European data subject’s expectations of privacy are likely going to be different than a US data subject’s. For instance, behavioral advertising may be viewed as more of an invasion of privacy by European data subjects than by American data subjects. To assist with this paradigm shift, US-based privacy counsel can work with their European colleagues or their European customers and data subjects themselves, to better understand these cultural differences.
In its revised guidelines, the WP29 also emphasized that “[a]s a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed.”10 This is significant given that the text of Article 35 itself takes a more laxed approach in this area, stating that reviews should take place “where necessary” and “at least where there is a change [emphasis added] of the risk represented by processing operations.” Operationally, organizations may want to set timeframes for when reviews will occur, based on risk-level. For example, calendar reminders could be set for the review of high risk activities every six months.
More than just a DPIA
This risk-based approach was underlined by the WP29, stating in their guidelines that the “obligation for controllers to conduct a DPIA in certain circumstances should be understood against the background of their general obligation to appropriately manage risks presented by the processing of personal data.” This is an important point. Regardless of whether a DPIA is required for a particular processing activity, aspects of it can be useful in carrying out the general obligation to implement measures to manage risks to data subjects.
GDPR compliance is intended to be an ongoing exercise, rather than as a means to an end. It is also full of overlap between its various requirements, which allows the DPIA to serve as more than just an item on a compliance checklist. For example, a DPIA can be used to help with:
- Keeping Article 30 records of processing up-to-date by feeding DPIA questionnaire responses into the records in an ongoing manner;
- Documenting technical and organisational measures to assist with demonstrating compliance with Article 32;
- Documenting how data subject rights under Articles 12-22 are facilitated;
- Documenting measures that demonstrate data protection by design and by default under Article 25;
- Documenting vendor management in accordance with Article 28;
- Determining whether a personal data breach is likely to result in a high risk and therefore necessitating the notification of affected data subjects under Article 34; and
- Working through the harms versus benefits analysis that is required where relying on legitimate interests as a legal basis.
Additionally, DPIAs can assist with the compliance with other privacy and data protection laws, as many of the principles found in the GDPR also exist in other frameworks, and additional requirements can be incorporated as needed.
The DPIA can increase trust, confidence and efficiency
As emphasized by the WP29, “DPIAs are a useful way for data controllers to implement data processing systems that comply with the GDPR” and are “a key part of complying with the Regulation where high risk data processing is planned or is taking place.”11 However, with the right mindset and approach, the DPIA can be even more than that. It can be a tool for addressing requirements beyond the GDPR; assisting with overall risk management efforts; growing the trust and confidence in your organization among data subjects, customers, regulators and others; and increasing overall efficiency in your privacy and data protection efforts.
1 GDPR Article 35.
2 Article 29 Working Party (WP29), 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, 17/EN WP248 rev.01 (4 October 2017), 5.
3 See Article 29 Working Party Guidelines at 13 (“The requirement to carry out a DPIA applies to existing processing operations likely to result in a high risk to the rights and freedoms of natural persons and for which there has been a change of the risks, taking into account the nature, scope, context and purposes of the processing.”)
4 See Article 29 Working Party Guidelines at 14 (“As a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed.”)
5 See Article 29 Working Party Guidelines at 15 (“the [CISO], if appointed, as well as the DPO, could suggest that the controller carries out a DPIA on a specific processing operation, and should help the stakeholders on the methodology, help to evaluate the quality of the risk assessment and whether the residual risk is acceptable, and to develop knowledge specific to the data controller context; the [CISO], if appointed, and/or the IT department, should provide assistance to the controller, and could propose to carry out a DPIA on a specific processing operation, depending on security or operational needs.”)
6 See GDPR Article 35(3) for examples.
7 Article 29 Working Party Guidelines at 9-11.
8 The draft guidelines had 10 criteria. However, “data transfer across borders outside the European Union” was removed in the revised version. This is a notable revision as this criteria would have likely applied to most processing activities conducted by multi-national organizations.
9 However, in some cases, it may be clear cut, as EU supervisory authorities are expected to publish lists of the kinds of processing operations for which they deem DPIAs are and are not required. So far, the Belgian DPA has issued a draft of such list. See GDPR Article 35(4)-(5).
10 Article 29 Working Party Guidelines at 14
11 Article 29 Working Party Guidelines at 19.
Latest posts by Brian Philbrook
Latest posts by Andrew Clearwater
- GDPR Derogations and How to Prepare for Member State Variation - September 29, 2017
- Video: PIAs and Data Mapping – Operationalizing GDPR and Privacy by Design - December 25, 2016
- Operationalising GDPR and Privacy by Design - November 25, 2016