Chapter 8: Conducting DPIAs – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide

CHAPTER 8: CONDUCTING DPIAS

It’s important to recognise the very real benefits of conducting a DPIA, and they’re not just limited to complying with the law. A DPIA builds trust. You can publish the results of a DPIA in order to show both that your organisation is keeping personal data secure and that you have taken a rigorous approach to ensuring this. In doing so, you will also demonstrate your commitment to transparent processing.

Consistently using DPIAs raises awareness of your compliance with the Regulation. Internally, this translates to a greater awareness of the individual’s duties; externally, it translates to an improved reputation and increased trust. Furthermore, taking advantage of this awareness can contribute to the effectiveness of your overall privacy compliance framework.

A DPIA also helps you to identify problems early on – often before you’ve spent a considerable amount of time and money implementing a project – and to find other efficiencies. This may extend to revising the actual data you collect in accordance with the principle of data minimisation.

The overall procedure for data protection impact assessments can be long and complex, especially for large organisations or those that handle large volumes of complex data. The DPIA is an integral part of the organisation’s risk management framework, so there are some core principles that can be applied to any such project.

Reasons for conducting a DPIA

First and foremost, you should conduct your DPIAs when it is still possible to have an impact on the project in question. If you conduct DPIAs at the start of your compliance project, of course, you could well be examining existing processes, but this is an instance of “better late than never”, and stakeholders will be pleased to see that you’re taking compliance seriously.

You can use a set of questions about your project to determine whether a DPIA may be necessary:

 

Will the project involve the collection of new information about individuals?

 

Will the project compel individuals to provide information about themselves?

 

Will information about individuals be disclosed to organisations or people who have not previously had routing access to the information?

 

Are you using information about individuals for a purpose it is not currently used for, or in a way it is not currently used?

 

Does the project involve using new technology that might be perceived as privacy-intrusive?

 

Will the project result in decisions being made or taking action against individuals in ways that could have a significant impact on them?

 

Is the information about individuals of a kind likely to raise privacy concerns or expectations?

 

Will the project require you to contact individuals in ways they may find intrusive?

Answering “yes” to any of these questions is a good indication that a DPIA may be a useful exercise, if only as part of due diligence. If you fail to perform a DPIA when one is required under the Regulation, there could be severe repercussions, so you should always consider conducting a DPIA.

As established in Chapter 5, there are a range of scenarios that require you to conduct a DPIA. The Regulation itself sets these out in Article 35 and in several of the recitals. The data maps you construct will highlight processing activities that require you to conduct a DPIA under the Regulation. The UK’s ICO also offers guidance on when it may be advisable to conduct a PIA.

You will need to keep track of any additional conditions under which DPIAs are deemed necessary by the supervisory authority.

You may wish to conduct a DPIA for your organisation’s benefit rather than out of necessity or an abundance of caution. As noted earlier in this chapter, there are distinct benefits to DPIAs that can be motivations in themselves.

Even if you elect not to perform a DPIA, you should retain any records you create indicating why you chose not to. This in itself demonstrates that you have performed due diligence, and may minimise the impact of any actions taken against you in the event of a personal data breach.

Objectives and outcomes

Like any other project, the DPIA should have a set of objectives and defined parameters for the outcomes. As described earlier, the Regulation specifies a minimum set of outcomes:

 

(a)  a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;

(b)  an assessment of the necessity and proportionality of the processing operations in relation to the purposes;

(c)  an assessment of the risks to the rights and freedoms of data subjects [affected by the processing operation]; and

(d)  the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.124

In simpler terms, the desired outcomes of a DPIA can be reduced to:

  • a description of the processing and its purposes,
  • the legitimate interests you are pursuing with this processing,
  • an assessment of the necessity and proportionality of the processing,
  • an assessment of the risks to the rights and freedoms of data subjects,
  • the measures envisaged to address the risks,
  • all of the safeguards and security measures to demonstrate compliance with the Regulation,
  • indications of timeframes if the processing will include erasure of personal data,
  • an indication of any data protection by design and by default measures,
  • a list of the recipients of personal data,
  • compliance with approved codes of conduct,
  • details of whether the data subjects have been consulted and have consented.

These should be established as the minimum outputs of any DPIA. In addition to this, there may be specific outcomes that you determine necessary on the basis of your organisation’s needs or the nature of the processing itself.

For instance, you might require the DPIA to determine how little personal data is needed to achieve the intended outcome of the processing, thereby improving efficiency and (as noted earlier) living up to the principle of data minimisation. Alternatively, you might require a given DPIA to pay special attention to a specific element of the processing because the organisation has had an issue with it in the past.

As the DPIA is part of the larger risk management process, you should also seek to frame the “measures envisaged to address the risks” in terms consistent with your broader risk management framework. Because these measures are necessary in order to meet legal requirements, they become part of the baseline security criteria – the set of controls and business processes that the business puts in place as an ordinary part of doing business.

Consultation

Throughout the DPIA process, you’ll need to consult a number of people or entities. Some will provide input or insight, others will be experts in the processing or scope of the project, and others will have vested interests in the processing. Equally, you may need to consult both internally and externally.

Internal stakeholders are likely to be involved in the processing or the project in some way, and may be consulted in order to get a better idea of the risks involved, the impact of treating the risks, or for their opinion on risk responses and treatment options. Such stakeholders might include the project management team, the DPO themselves, engineers, the IT team, procurement, customer support, legal counsel, and so on.

The Regulation stipulates that “where appropriate, [data controllers] shall seek the views of data subjects or their representatives on the intended processing”125. The Regulation doesn’t specify precisely what makes this “appropriate”, but it’s safe to assume that if you’re seriously considering whether it’s appropriate that it probably is. It’s best to assume the supervisory authority will side with the data subjects in most instances.

Consulting external stakeholders like the data subjects improves transparency by making people aware of how the information about them is being used. Of course, it’s also very easy for external stakeholders to lose sight of the project; they’re not invested in it, they may not have a complete understanding of it, and they may not be interested at all. As such, it’s important to frame this consultation to get results that you can use in the DPIA.

When consulting external stakeholders, you should follow a set of principles:

  • Make it timely. Consult at the right stage and give stakeholders enough time to respond. If you’re expecting answers from an online survey, you need to account for traffic and conversion rates to get enough responses.
  • Make it clear and proportionate. Present the information necessary – no more and no less. Providing too much information or context will confuse people, and withholding information will only result in vague or useless responses.
  • Consult appropriate representatives. You should ensure that those you approach fairly represent those who could be impacted, or those who should have input (such as local authorities or regulatory bodies).
  • Be objective and realistic. Offer external stakeholders realistic options and present the information without bias. If you find you’re having to dodge around the issues, it could be a sign of larger problems with the project.
  • Feedback goes both ways. You are getting feedback, so ensure that you also offer feedback in turn. In many cases, the stakeholders will end up consulting on a number of projects for a variety of organisations and bodies, so feedback will prove valuable in the long term, especially if you need to consult them again.

The most important external stakeholder to consult will be the supervisory authority. Article 36 of the Regulation states that the controller must consult the supervisory authority if the DPIA “indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk”126. This means that the supervisory authority would be permitted to extend or even suspend the length of its consultation following the DPIA, potentially holding up the organisation indefinitely127.

To avoid such a situation arising, the supervisory authority should be consulted when determining how to treat privacy risks during the DPIA. This may involve terminating whole parts of the process and redesigning them in order to avoid such significant risks.

Five key stages of the DPIA

The key stages of the DPIA are:

  1. Identify the need for the DPIA.
  2. Describe the information flow.
  3. Identify privacy and related risks.
  4. Identify and evaluate privacy solutions.
  5. Sign-off and record the outcome.

The need for the DPIA has already been covered, so we can leap straight into describe the information flow. Your data mapping exercise is crucial here.

While data mapping will provide you with a large-scale overview of all of your processing activities, it could also produce more granular maps of individual processes. A thorough assessment of privacy risks is only possible if your organisation fully understands how information is actually being used. You need to be able to describe how this information is collected, stored, used and deleted, and this should be available in an abstract form from your data mapping.

For some DPIAs – notably when the processing is complex or multi-stage – you may need to go into greater detail than the mapping exercise. You may also need to translate it into another format, such as a spreadsheet or written report.

The information flow is where you begin to identify privacy and related risks. Risk identification can be a bit of an art in itself, and there are a number of training opportunities that offer qualifications and certifications available to help you get a background in risk identification (and risk management more generally).

You should aim to identify risks to the rights and freedoms of the data subjects in accordance with the data protection principles. This means looking for sites where data may be or may become inaccurate, insufficient or out of date; where data may be excessive or irrelevant; where data is kept for too long; where data is disclosed to the wrong people or entities; where the data is used in ways that are unacceptable or unexpected to the data subject; and where it is stored or transmitted insecurely. These are broad categories, of course, and not particularly useful if you want to mitigate those threats. The actual risks to personal data might include:

  • hacking,
  • viruses and other malware,
  • intruders stealing or damaging data,
  • phishing scams,
  • inadequately trained staff,
  • unencrypted laptops outside the premises,
  • poor access control,
  • weak passwords.

Some of these risks will continue to exist regardless of what you do (malware, hackers, natural disasters, etc.), while others can essentially be eliminated (weak passwords, unlocked doors, etc.). The former can be treated to reduce the likelihood or potential impact of the risk. Many of the latter, as noted, can be completely eliminated. For example, weak passwords may be eliminated by improving the password policy to force users to create strong passwords that are changed every three months.

When identifying a risk to privacy, you need to assess the potential impact. In a DPIA, you are specifically looking for harm to the data subject rather than harm to the organisation, which would be covered in a broader information security risk assessment.

One of the first considerations for harm is whether the data involved can identify a data subject. This will depend on the data in question, and some sets of personal data cannot be used to identify a specific individual. For instance, data comprising dates of birth, postcodes or gender usually won’t provide enough information for direct identification, but context and sample size could increase the possibility. Meanwhile, data comprising names, fingerprints or national identity numbers can directly identify individual data subjects.

A second consideration for harm is the quantity of data involved. If, for instance, the specific risk results in the loss of 25 records, there is limited harm to society and to the organisation. In conjunction with the identifiability of the data, it may even be harmless. Hashed data, for instance, is usually quite secure, but if the hashing method is flawed, it may be possible to crack the hash with a large enough sample to identify patterns.

A third consideration for harm is the sensitivity and variety of the data. Some information is naturally sensitive, such as medical information and political allegiances. The “special categories of personal data”128 that the Regulation refers to are always sensitive. Data regarding a data subject’s criminal convictions and offences, as referred to in Article 10, should also be treated similarly here129. Less sensitive information could have secondary uses or be significantly more sensitive in context. For instance, possession of both the data subject’s national identification number and their mother’s maiden name could be used to gain access to more sensitive information and commit fraud or identity theft.

Harm is often tangible and quantifiable, and may be predictably obvious when you’re conducting a DPIA. Harm may take the form of financial or job loss, or damage to personal relationships and social standing from disclosure of sensitive information. This information can be quite easily translated into harm to the data subject and to the organisation (in terms of compensation payments, etc.).

Harm may not always be tangible and quantifiable, however. The fear of identity theft after personal data has been breached is harmful. This sort of harm can be more difficult to identify because it often does not derive directly from the actual data. Accounting for this, case law in many jurisdictions has developed to allow the courts to make awards for “distress”.

It is also important to recognise that harm can be done by damage to or loss of data – it’s not always about theft or what criminals might do. For instance, a healthcare organisation might mix up patient data, resulting in an incorrect diagnosis, a failure to treat a serious illness, accidental disclosure of sensitive information to the wrong patient, and so on.

With risks identified and the harm established, you can now begin to identify and evaluate privacy solutions. These are the measures you put in place in order to prevent the risks from doing harm. In Chapter 6, we identified four possible responses to risk:

  1. Treat
  2. Tolerate
  3. Terminate
  4. Transfer

These apply equally here, and just as in ‘ordinary’ risk management, your decisions will be informed by a variety of considerations. The cost of treating a risk may exceed the cost of the risk coming to pass. The cost isn’t simply the cash value of implementing the control, but also includes the impact on the project’s outcomes. If the risk slows the process by 20%, or reduces the value of the output at the end, then this should be factored into your decision. In instances where cost of treatment is excessive, other options, such as terminating the risk, may be preferable.

It is possible to apply multiple treatments or even mix responses. For example, consider a process that entails five risks, two of which are minor, and three more serious risks, the last of which relates to a critical part of the process. The risk assessor might decide to tolerate the two minor risks, terminate the two non-essential serious risks and apply a combination of treatments to reduce the impact and likelihood of the final, business-critical risk, potentially also transferring part of that risk via insurance.

It is not necessary to eliminate all privacy risks. The key is to reduce risk to an acceptable level (based on your risk acceptance criteria) while still allowing a useful project to go ahead.

A variety of sources catalogue different risk responses, but the following are typical examples of actions an organisation might take to treat, transfer or terminate risks to personal data130:

  • Reduce the amount of data collected.
  • Develop a retention policy governing how long and in what format personal data is stored.
  • Securely destroy information when it is no longer needed.
  • Access control policies and procedures to minimise access to personal data.
  • Introduce a training and awareness programme to reduce accidental exposure of or damage to personal data.
  • Anonymise the personal data.
  • Draw up contracts or data sharing agreements.
  • Develop a subject access request process to protect data subjects’ rights.
  • Demand that suppliers conduct risk assessments and supply you with the results.

The results of this process should be recorded in a data protection risk register. Like other risk registers, this should record not just the risk, but also explain what action has been taken or will be taken in response to the risk, and identify who is responsible for approving and implementing any solutions that have been chosen. This is comparable to a risk treatment plan, and might look something like the example in Figure 12.

Figure 12: A sample risk treatment plan

Your risk register should be tailored to your business needs. It might automatically calculate the risk score and colour-code risks that exceed the risk acceptance criteria for ease of reference, or it might include additional columns to record other data relevant to your organisation, the processing or your responses to risks.

You should ensure that any risk that you choose to tolerate is explained. This applies not just to risks that you simply tolerate outright, but also to residual risks that remain after treatment.

The final step is to sign-off and record the outcome of the DPIA. Many of the documents you produce as part of the DPIA will be of limited use to stakeholders outside the organisation, such as the supervisory authority, partners, clients or the wider public. These are precisely the entities you need to impress, however, so you need to ensure that you have a final DPIA report suitable for external distribution.

Whatever the nature of the project and the information you are providing, your DPIA report should include a project overview, which should indicate what personal data is involved, what you’re doing with it and why, and how long the data will be held. This project might be a set of processing functions, a single process or a business project that will only run for a defined period.

The DPIA report should also provide information to demonstrate that you have adequately assessed the impact of the project on data protection, including a description of the data flows and identified privacy risks, and details of how the privacy risks will be handled. Your supervisory authority may have applied further conditions to the DPIA report.

The report should be sanitised to protect the data subjects and the organisation itself, and to meet the requirements of its audience. If you’re simply submitting the report to your organisation’s board for their approval, you might exclude information that’s excessively technical. The board relies on the expertise of the company’s employees and only need a good, reliable overview in order to make strategic decisions.

Before being sent out, the report should be signed off by the appropriate authority. Internally, this should typically be the DPO. Other external approval could be supplied by the supervisory authority, and may in fact be required under law in some instances.

Once you have received external sign off, the report is ready to publish or be made available in summary form to stakeholders. If you wish to release the full details, a second round of sanitisation may be necessary. Publishing the DPIA report is what earns you real trust and builds a reputation for transparency. In the UK, the ICO encourages organisations to consider publishing material relating to PIAs. It’s good advice: the more organisations within an economy that publish such reports, the more transparent the economy becomes and the easier it is to secure international business and investment.

Integrating the DPIA into the project plan

The outcomes of the DPIA need to be integrated into the project plan. You will need to continually refer back to the DPIA in order to ensure that it is being followed and that its responses to the risks have been effectively implemented.

You should define metrics for effectiveness against which risk responses may be measured. In some cases, the metric will be as simple as “the information is still intact”, while for others it might be more complex, perhaps “number of times the log has been accessed by non-admin staff”.

In any case, you will need to ensure that your privacy compliance framework takes effectiveness into account. ISO 27001, for instance, applies a set of checks against the information security management system to ensure that all necessary processes are both functioning and effective. Even if you don’t choose to implement ISO 27001, it would be valuable to look at clauses 9 and 10 of the Standard to see how it approaches monitoring, measurement, analysis and evaluation of information security, as well as the review and response to the results of monitoring.

The DPIA is a written record of your determination to protect personal data throughout the project, and external stakeholders – including the supervisory authority – will hold you to this. Furthermore, if you’ve chosen to publish your DPIA reports, those same external stakeholders will be able to ask specific questions about the effectiveness of your security measures.

________________________

124 GDPR, Article 35, Clause 7.

125 GDPR, Article 35, Clause 9.

126 GDPR, Article 36, Clause 1.

127 GDPR, Article 36, Clause 2.

128 GDPR, Article 9, Clause 1: “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation”.

129 GDPR, Article 35, Clause 3(b) states that a DPIA would be required for “processing on large scale of special categories of data … or of personal data relating to criminal convictions and offences”.

130 Tolerating the risk would be done after treatments, transfers and terminations are applied – for instance if your various responses cannot reduce the risk enough but the process is essential.