For those not buried in the details of the European General Data Protection Regulation (GDPR), there is often confusion about be the differences between Data Protection Impact Assessments (Article 35) and Data Protection by Design and Default (Article 25). Many people assume that DPIAs, as the impact assessments are called, are synonymous with with Data Protection by Design and Default. This article we highlight some of the key differences.
Article 35 Data Protection Impact Assessments
- Applies to: processing of personal data that likely poses a high risk to individuals, especially where there is automated processing, processing large scale special categories of information or systematic monitoring of public spaces
- Requires: documentation of the measures to address the risk and demonstrate compliance with the regulation
- When: prior to processing
Article 25 Data Protection by Design and Default
- Applies to: all processing of personal data
- Requires: implementing appropriate technical and organizational measures designed to implement data protection principles and only process the personal data necessary for the specific purposes
- When: at the time of determination of the means of processing AND at the time of processing
I’ve obviously summarized the language of the articles but only to highlight the differences. So let me dive a little further. First off, you’ll notice the first key distinction on the applicability. DPIAs are only necessary for high risk processing, whereas Data Protection by Design (and default) applies to ALL processing of personal data. Of course, to get to a DPIA, most organizations rely on some threshold analysis which would suggest whether or not the processing is high risk. This is not necessary for Data Protection by Design because it applies to all processing.
The second key distinction is that DPIAs are about documenting your measures and compliance whereas Data Protection by Design is about implementing measures. Article 35 DPIA is about proving you’re complying whereas Article 25 Data Protection by Design and Default is about trying to comply (i.e. the measures are “designed” to implement data protection principles). Presumably, if you’ve designed data protection into your processing, the DPIA is about ensuring that you’ve formally documented it (with all your i’s dotted and t’s crossed). An example might help. If you’re planning on collecting contact information of potential customers at a concert, you might implement an organizational measure (a policy) that tells your employees to ensure they tell potential customers what their data will be used for. That is a measure designed to comply with the data protection principle of transparency. Will some of your people forget to tell them? Perhaps. Perfection is not the goal. Change this up to you’re planning on video recording individuals at the concert and doing demographic analysis on ethnicities in attendance. Now you fall under the systematic monitoring clause of Article 35 (and special categories clause as well). You have to document how you’re complying with the regulation, including all the technical and organizational measures. Maybe only three employees have access to the data. Maybe you’re doing this under the lawful basis of being carried out in the public interest. Maybe you had notice printed on the back of the ticket before everyone entered. Document. Document. Document is what DPIAs are all about.
The final key distinction is about timing. For DPIAs, you need to do that anytime prior to processing. The idea here is if you don’t have the documentation or can’t prove your complying with the regulation, that would stop you from processing the personal data at high risk to the individuals (or at least give you pause). Because, Data Protection by Design is about implementing measures rather than documenting those measures, it must be done (1) when you determine what processing you’re going to do and (2) at the time of processing. The reason for this is because the measure may have different effects at different times. For instance, one measure (in accordance with the data minimization principle) might be to exclude collection of certain information, say ethnicity, when asking for contact information. This might be implemented on the form being used to collect data by not having an ethnicity field. Since we create the form at the “time of determination of the means of processing” we’re implementing that measure at that time. Another measure might be to audit the forms to make sure employees aren’t secreting marking codes next to minority names and contact information. That measure would obviously be at the “time of the processing itself.”