DP Impact Assessments: EDPB Differs Slightly from ICO Position

In its Opinion, the EDPB appears to be moving away from the idea that processing of genetic or loca­tion data, on its own, might be enough to trigger the mandatory DPIA requirements of the GDPR. This news will perhaps come as a relief to organi­sations currently struggling to come to grips with the “new” DPIA process and the resources and time that it demands. But, should we be surprised by the EDPB’s Opinion and will it have a significant impact in practice on the way organisations consider and conduct DPIAs?

Back to Basics

A data protection impact assessment, or DPIA, is a process for identifying and addressing any privacy risks asso­ciated with a particular processing activity. It is, in essence, the meeting point of two fundamental features of the GDPR: “Privacy by Design” and “accountability”. Mandatory DPIAs for high risk processing activities is one of the changes to the data protection regime introduced by the GDPR.

Though mandatory impact assess­ments were not written into the old Data Protection Act 1998, the concept is not new. Undertaking privacy impact assessments (a DPIA by another name) had been encouraged as “best practice” by the ICO for some years. The GDPR merely enshrined the process into law and attempted to introduce some con­formity to the varying approaches that had been adopted across the EU Member States.

To many, this will not be news. Organisations grappling with GDPR preparation and remediation over the past months will already be well aware of the concept of DPIAs.

Implementing DPIAs

For some organisations, the transition from the old to the new data protection regimes (as far as impact assessments are concerned, at least) has been rela­tively smooth. Those that had adopted the concept of privacy impact assess­ments as best practice under the old Data Protection Act already had the baseline organisational infrastructure in place. So, aside from some tweaks, the DPIA requirements of the GDPR have, in effect, been business as usual for those organisations. This is espe­cially true in the public sector, where (on the whole) privacy impact assessments have been undertaken as a matter of course for some time.

Whilst this might be the position for some organisations, it is certainly not the case for all.

We have now been living in the new GDPR world for six months. A number of organisations (in particular, large global groups) are still struggling to implement effective processes for undertaking DPIAs. In particular, some organisations have been over­whelmed by the influx of DPIA, or potential DPIA, requests that have been generated from within since May. The message that all areas of an organisation’s business should be aware (or, even, afraid) of data protection has clearly been well communicated.

This echoes what we have seen with breach reporting. The fear of GDPR (or, more specifically, its financial penal­ties) is such that since May the ICO has been inundated with reports of personal data breaches. As was revealed by a recent freedom of information request, the ICO has received 6,281 complaints since 25 May 2018, compared to 2,417 over the same period last year. That’s a whopping increase of 160%.

Whether it’s internal DPIAs or controllers reporting breaches to the regulator, over-reporting seems to be the norm.

Bringing Order to Chaos

Keen to tackle the unexpectedly high levels (and inevitable backlog) of DPIA requests that need to be considered, organisations are increasingly seeking more streamlined approaches to the DPIA process as a whole. Inevitably, a number of GDPR compliance software tools have entered the market to address this. Presenting the DPIA process as a set of binary questions which automatically identify (a) whether a DPIA is required and (b) the mitigation controls required to make the processing activity in question “GDPR compliant”, has become the holy grail.

There is no doubt that these solu­tions can streamline the process and offer some much needed relief to pri­vacy teams still overburdened by GDPR remediation work. But, reducing the DPIA process to a set of pre-deter­mined risks, assumptions and controls is somewhat missing the point. Given much of data protection compliance is fact and context-specific (e.g. the same information may be personal data in one context and not in another), this may not always be a good approach. The ICO and the EDPB are equally keen to point out that DPIAs are a useful tool for demonstrating and ensuring compli­ance. In other words, it is meant to be more than just a tick box exercise.

There is only so much standardisa­tion that can be imposed on a process that by its nature is supposed to be fact specific. The ICO’s own sample DPIA template, for instance, predominately consists of open questions and free text boxes, allowing for full descriptions and variations according to the particu­lar processing activity. It is light on binary questions.

Thinking like the regulator, it seems unlikely that the ICO would have much time for a process that, by design, avoids engaging with the detail. It is, therefore, questionable to what extent the DPIA process can be streamlined and still stand up to the scrutiny of the regulator: in our recent experience, the ICO has been quite cautious. A balance needs to be struck between efficiency and compliance.

Where Does Efficiency Meet Compliance?

For those organisations struggling with a sudden influx of DPIAs or those who are looking to hone the efficiency of their internal processes in a compliant way, there are a number of options:

1. Check whether the DPIA requests being received actually relate to GDPR remediation work or to business as usual data protec­tion activities. In other words, does the DPIA request relate to an ongoing high-risk processing activ­ity which started before the GDPR became enforceable or to a new project or procurement? Although this won’t necessarily lessen the number of DPIA requests that need to be processed in the short term, it will help organisations understand whether the influx is temporary. This, in turn, will help determine whether the DPIA process actually does need to be streamlined or not.

2. Enhance DPIA training and guidance. This is particularly important where, as is often the case, staff at the business end of an organisation (i.e. those who may not be privacy specialists) are being asked to complete the DPIA triaging questions. Often the level of detail provided is inadequate, or they do not understand what is being asked of them. This means that it is difficult for privacy teams (a) to conduct a meaningful assessment of whether a DPIA is required and (b) to complete the DPIA where necessary. If staff are provided with the tools to understand the types and level of information that is required, it will reduce the level of investigation and validation required by the privacy team. Strategically appointing “Data Protection Champions” with additional training, particularly in areas where high numbers of DPIA requests are generated, will help with this issue.

3. Ensure that the triage phase of the DPIA process is robust. A DPIA is only mandatory for high risk processing activities. If, after triaging DPIA requests, processing activities that are not high risk are being identified as requiring a DPIA, then the triaging questions may need to be refined. For those organisations that implemented their DPIA processes in May (or before), it will now be apparent how effective the triaging questions are. If hundreds of DPIAs are required (to the extent that they do not relate to GDPR remediation work (see point 1)), consider hon­ing the triaging questions to more accurately reflect what might be a high risk in the context of your organisation.

4. Replicate or share DPIAs for sim­ilar processing activities or similar data protection risks. Once you have a number of DPIAs under your belt, common themes and trends will start to emerge. Where a full DPIA is required and where relevant, sections of DPIAs can be replicated or whole DPIAs can be repurposed, there is no need to reinvent the wheel each time. The key is to ensure that all of the privacy risks have been identified, mitigated and documented.

5. Light touch DPIAs for borderline cases. If there is any doubt about whether a processing activity does trigger the requirement to under­take a DPIA, best practice is to undertake a DPIA. The EDPB and ICO are both clear on this recom­mendation. Nonetheless, where volumes of DPIAs are high and resources are stretched, there is an argument for saying that organisa­tions should take a purposive approach; focus on undertaking full DPIAs for the processing activities which are clearly high risk and undertake light touch DPIAs for more borderline cases. A “light touch” DPIA could include a pri­vacy review (which could be docu­mented, for example, by way of an email exchange), highlighting any risks and required mitigations, but without completing the full DPIA form or process. Do still retain these with your data processing records, however.

Back to the EDPB

A robust DPIA triaging phase (see point 3 above) is crucial to an efficient DPIA process. In effect, it is the sluice gate of the DPIA process.

This is where the EDPB’s recent Opinion comes into play. Most organi­sations have based the questions in their triaging phase on a combination of the criteria set out in the Article 29 Working Party’s guidance on DPIAs and the ICO’s list of processing types that automatically require a DPIA. And, rightly so.

The aim of the EDPB in publishing its Opinions on each of the supervisory authorities’ lists is to create a har­monised approach across the EU. Whilst the EDPB claims that it is not looking for each supervisory authority’s list to be identical or to create a single EU list (although there may be some logic in them doing this), it is keen to avoid any “significant inconsistencies”.

In its Opinion, the EDPB criticises the ICO’s approach, in particular, sug­gesting that processing of location and genetic data would not, on its own, rep­resent a high risk. Those types of pro­cessing, in the EDPB’s view, would need to be in conjunction with at least one other criterion (such as, high volumes of data) in order to trigger the requirement to undertake a DPIA. Some commenta­tors have suggested that this move away from regarding location and genetic data as inherently high risk is significant. Although it may be that in practice, most projects that involve them will still meet other criteria requiring a DPIA. It is equally interesting to see whether the EDPB, in its mission for consistency, will be successful.

Some organisations may be relieved that the EDPB is, in effect, reducing the number of processing activities that are likely to trigger a mandatory DPIA. Others will no doubt regard this move of the EDPB with some dismay. More uncertainty has been cast onto a process which, for many, is still in its infancy and target­ing the specific aspect of the process which many organisations are strug­gling with the most – the assessment of whether a DPIA is required or not.

The ICO must now decide whether it intends to amend its list in light of the EDPB’s comments or retain it in its current form. Given the UK’s quest for an adequacy decision after it has left the EU (no commen­tary on data protection would be complete without the spectre of Brexit), it is likely the ICO will feel compelled to do the former.

Always Look on the Bright Side of DPIAs

While we wait, organisations should carry on as before: assessing whether a DPIA is high risk on the basis of the current ICO guidance and docu­menting this decision. And, remem­ber, the DPIA process is not, as some GDPR-sceptics may regard, just time-consuming. It really is a useful data protection tool. Though poten­tially painful in the short term,embracing DPIAs, rather than resist­ing, will lead to more efficient and effective data protection compliance in the long run. And, the more you do, the easier and more streamlined they will become.

Originally published in the November 2018 issue of Privacy Laws & Business’ United Kingdom Report.

Authored by Nicola Fulford and Louisa Williams