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.