Here’s a funny thing – recital 84 of the EU’s GDPR legislation states “…where processing operations are likely to result in a high risk to the rights and freedoms of natural persons, the controller should be responsible for the carrying-out of a data protection impact assessment…”. Paragraph 1 of Article 35 says pretty much the same thing.
So why is it funny or rather odd? Well, quite often it is the very act of undertaking a data protection impact assessment (DPIA) that reveals the nature of the risks to the data subjects due to the processing.
How do you know when to carry out a DPIA?
These high risks to the rights and freedoms of data subjects might not be immediately obvious so how do you know when to carry out a DPIA? There are 3 triggers for conducting a DPIA and they should become automatic. These are discussed in the following sections but can be summarised here:
- A new processing activity
- A change to an existing processing activity
- A change in the legislation, regulations or ICO guidance
In addition to the above triggers, there’s also some best practice around DPIAs which I will discuss.
Trigger 1 – A new processing activity
This is fairly obvious as any new processing activity will need to be assessed to see if it is processing personally identifiable information (PII). If it is processing PII, you’ll need to ask yourself if any special categories of personal data (‘sensitive data’) is being processed? The absence of sensitive data does not preclude the requirement to undertake a DPIA but it is likely to reduce the inherent risks to the data subjects.
When PII includes sensitive data, then the potential risks to the data subjects are increased and the measures to protect the data must compensate for this.
Trigger 2 – A change to an existing processing activity
Any (and I do mean any) changes to an existing processing activity should always trigger a DPIA. This is true even for processing activities that did not previously include any PII. The change might be to include PII or an identifier to tie it to a data subject. It is not safe to exclude systems that previously did not contain PII.
I have been vague here on what a change is, and for good reason. The change could be anything from moving an application to the cloud, transferring the processing to a sub-processor, the inclusion of additional data, changing the data retention policy, the list is endless. Whatever the change the DPIA needs to evaluate the risks to see if there has been any significant change in them.
While the focus is rightly on identifying increases in the risks to the data subjects and mitigating these risks you should not discount the changes that reduce or eliminate the risks. In this case, there may be an opportunity to simplify the processing and possibly save the company money.
Trigger 3 – A change in the legislation, regulations or ICO guidance
The actual requirement in the legislation to undertake DPIA’s is not as all-encompassing as you might think. The legislation mentions processing that is likely to result in a high risk or is systematic and largescale or extensive evaluations for automated profiling.
These all need DPIA’s but what if your processing doesn’t quite fit within the description? Well, the ICO lends a hand here with guidance that “It is also good practice to do a DPIA for any other major project which requires the processing of personal data.” Of course, there isn’t a definition of what a major project might be but nevertheless, it gives each organisation a yardstick to evaluate proposed processing activities.
The ICO does on occasion update its guidance so it is best to keep an eye on their web site to see what is happening.
Changes in legislation can also lead to a requirement for a DPIA. The number one example of this is of course Brexit. It is still not clear what (in terms of GDPR) the UK’s relationship with the EU will be. The UK is currently being assessed for an adequacy decision which ultimately can be either a ‘yes’ or a ‘no’. If it is a ‘no’ then the UK is demoted to 3rd country status and PII transfers to/from the EU need to be re-evaluated. The best tool for doing this is the DPIA.
DPIAs as good practice
One of the benefits of a DPIA request which often goes unnoticed is that it brings to the DPO’s attention proposed or existing PII processing that previously would have occurred with no oversight or governance. This is why I’m a strong advocate of requiring a DPIA for all new projects and where time and resources allow DPIAs for all existing processing operations.
I can justify my position on DPIAs for all projects regardless of size after an experience with a client during a data audit. A spreadsheet was uncovered which contained children’s names, age, address and food allergies amongst other things. The data had been collected for a Christmas party the firm had held the employees’ children’s data a few years prior to the audit. Not only did the spreadsheet contain sensitive data, but it had also been retained for far longer than necessary. Clearly, a DPIA before the event would have been in everyone’s interests.
Pulling the trigger on the DPIA
Now that you understand the three triggers that prompt the need to conduct a DPIA, you can put it into practical action. If you have any further questions on how to conduct a DPIA or require assistance with your data protection and privacy compliance, please contact one of our Crew. We like to help. It’s what we do at Risk Crew.
