Chapter 5: Requirements for Data Protection Impact Assessments – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide

CHAPTER 5: REQUIREMENTS FOR DATA PROTECTION IMPACT ASSESSMENTS

The data protection impact assessment (DPIA) is one of the specific processes mandated by the GDPR. Many organisations will be required to conduct DPIAs and, in many instances, an organisation may find it a valuable process even when a DPIA is not required by the Regulation.

DPIAs are used to identify specific risks to personal data as a result of processing activities and the significance of their role in a PIMS could be compared to that of the information security risk assessments required by ISO/IEC 27001 and described in ISO/IEC 27005 (see Chapter 6). DPIAs naturally have a greater focus on data protection and privacy, of course, so a more focused model is valuable. The Regulation describes the purpose of DPIAs:

 

In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. […] In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.94

The GDPR also sets out what must, as a minimum, be contained in a DPIA:

  • a description of the processing and purposes,
  • legitimate interests pursued by the controller,
  • 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 safeguards and security measures to demonstrate compliance,
  • an indication of timeframes if processing relates to erasure,
  • an indication of any data protection by design and default measures,
  • a list of recipients of personal data,
  • confirmation of compliance with approved codes of conduct,
  • details of whether data subjects have been consulted.

Prior to the GDPR, privacy impact assessments (PIAs) were widely considered best practice by regulators, including the UK’s Information Commissioner (ICO). Given the wide acceptance of PIAs and the availability of resources supporting them, the PIA model can be taken as a good foundation for GDPR-compliant DPIAs. For any practical purpose, PIAs and DPIAs are the same thing.

Data protection impact assessments

A DPIA is a process that helps organisations identify and minimise privacy risks, and is usually conducted ahead of implementing new processes, projects or policies. DPIAs aim to seek out potential problems so that they can be mitigated ahead of time, thereby reducing the likelihood of occurrence and the associated costs. Furthermore, DPIAs should directly benefit the organisation by improving policies, processes and systems, and securing relationships with customers and stakeholders.

The UK’s ICO produced a comprehensive code of practice for PIAs95, and several other European agencies have also produced documents relating to PIAs96. Approaches are generally identical, with some varying commentary based on local laws and implementations of the Data Protection Directive (DPD). Under the GDPR, the differing guidance for each country will likely be reviewed, updated and brought in line with each other and with the requirements of the GDPR out of necessity.

For ease of reference – and to avoid issues with translation – we’ll refer to the ICO’s PIA guidance document. If you are implementing GDPR compliance elsewhere in Europe, you should consult your local supervisory authority in case there is alternative regionally appropriate guidance.

The ICO recommends that PIAs be conducted by a DPO, but also notes that “not all organisations have their own DPO, or it may be difficult for a DPO to conduct all the PIAs – the general approach to PIAs is also intended for use by non-experts”97. This holds true for DPIAs, and there are situations in which you may need (or want) to conduct a DPIA without a DPO. As such, you should ensure that your defined (and preferably documented) methodology is suitable for anyone in the organisation (including auditors) to follow, regardless of their technical knowledge or skills.

The ICO’s guidance defines a number of specific steps in the PIA process98:

  1. Identify the need for a PIA.
  2. Describe the information flows.
  3. Identify the privacy and related risks.
  4. Identify and evaluate the privacy solutions.
  5. Sign off and record the PIA outcomes.
  6. Integrate the outcomes into the project plan.
  7. Consult with internal and external stakeholders as needed throughout the process.

These simple steps provide a good overview of the process and are relatively straightforward for anyone to follow. Given that the guidance is simply that – guidance, not a prescribed method – most organisations could reasonably put together their own DPIA methodology based on these steps. Some additional research may be necessary to understand the finer points of data protection and privacy, but it should be well within the means of most organisations to actually achieve this. We’ll now go through these phases briefly in order to introduce the various topics and considerations relevant to DPIAs.

1. Identify the need for a DPIA

Identifying the need for a DPIA is the critical first step, as the organisation will need to determine whether a) the law requires one, or b) the needs of the organisation demand one. In the first case, this will be determined by examining the relevant laws. For our purposes, this would be the GDPR, which states:

 

Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.99

This is the short version, of course, and there are several references throughout the Regulation that clarify when DPIAs should be conducted, notably in Recital 91. There are three primary conditions for conducting a DPIA100:

 

a)  When a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person.

b)  When processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10.

c)  When systematically monitoring a publicly accessible area on a large scale.

Because PIAs were never a legal requirement under the DPA, this is new territory. Previously, a PIA could have been deemed ‘necessary’ if the planned processing might otherwise impact the organisation itself. Under the GDPR, the primary concern is to reduce harm to the data subject.

A DPIA may also be necessary to meet the organisation’s own risk management requirements. It’s quite likely that many companies will establish their own additional criteria to trigger a DPIA, perhaps where the processing in question is extremely expensive and any risk of a breach might make it a risky business decision, or if the organisation has a very low risk appetite or simply wants to ensure it stays on the right side of the law. Whatever your reasons, you should document your criteria or define a repeatable process for determining whether a DPIA/PIA is necessary.

2. Describe the information flows

The second step, describing the information flows, relates to data mapping, which we’ll look at in much more detail in Chapter 7.

3. Identify the privacy and related risks

This is a common component in all risk management strategies: know your threats and how they might exploit your vulnerabilities. In essence, you should be attempting to catalogue the range of threats, and their related vulnerabilities, to the rights and freedoms of the data subjects whose data you collect and/or process.

4. Identify and evaluate the privacy solutions

For each identified risk to the personal data, you should make what is called a “risk decision”: do we accept or reject the risk, do we transfer it (through insurance) or do we take steps to reduce the impact or likelihood of the threat successfully exploiting the vulnerability by selecting and implementing one or more controls? The value of ISO 27002, the standard which provides guidance on implementing the controls listed in Annex A of ISO 27001, is that its control set is comprehensive and covers all the most likely areas of required activity, from HR through to physical and logical security.

The decision to select and apply controls will depend on a number of factors: the likelihood of the risk and its potential impact, the cost of remediation, and so on. Some of these cannot be thoroughly examined without knowing also how to control the risk, so you may need to identify both the risk and the solution(s) before deciding whether it is appropriate to remediate the risk. Once a risk decision is made, you can create a risk treatment plan (RTP), which essentially outlines the operational steps to be taken – together with details of accountabilities, measures, etc. – to translate the risk decision into reality.

5. Sign off and record the DPIA outcomes

The outcomes of the DPIA (steps 1-4) should be recorded and signed off by whoever is responsible for those decisions. This means that you should record the risk decision and the corresponding risk treatment plan, alongside each risk. Provide a copy of the consolidated risk treatment plan to top management for sign off and resource commitment. Implement the RTP, report to top management on progress, maintain the RTP and ensure – through internal audit and, where relevant, testing – that the selected controls continue to work effectively to meet the organisational risk management objectives. There is, of course, a link here to the organisational risk management approach, discussed later in this manual.

The importance of recording good information and producing a formal report cannot be understated. A formal report will outline the measures to address the data protection issues raised by the PIA, and gives organisations accountability and transparency for such issues, allowing individuals to learn more about how the PIA affects them and their work.

The report can also form the basis for further audits and post-implementation reviews, as well as a reference for future PIAs, so it is vital that all information and the subsequent outcomes of the PIA are recorded to a high standard.

6. Integrate the DPIA outcomes into the project plan

In this step, your earlier decisions become defined actions. This may entail prioritising the decisions or reviewing the DPIA in more detail to correctly and effectively mitigate the identified risks.

This step also accounts for the actual implementation of the project plan, which sets up the processing function(s) that the DPIA examines. This means that the implementation plan will be modified and updated to include the results of the DPIA. Depending on the nature of the processing function(s), this may require more or less technical work (such as programming/coding work, etc.), and may require you to re-examine project deadlines and dependencies.

Furthermore, some measures that you implement may require maintenance or periodic observation, so these should be accounted for in the relevant operational procedures.

7. Consult with stakeholders as needed throughout the DPIA process

The final step is non-linear. Regardless of your approach to the DPIA, you should always remember that you are attempting to minimise the impact of your processes on the rights and freedoms of data subjects and stakeholders should be consulted appropriately throughout the process. The ICO’s guidance has a good example list of stakeholders you should consider involving in your DPIA.

You should also ensure that you have access to a resource that represents the data subjects themselves as stakeholders. Depending on the processing in question, this may be someone within the organisation who operates as a devil’s advocate, an external consultant with expertise in data protection and privacy, a group of anonymous data subjects – anyone capable of appreciating the data subjects’ concerns.

PIAs are a good foundation for developing a DPIA methodology. While they have been developed in order to meet the requirements of a variety of different data protection laws around the world, the core practices are completely sound and there should be little difficulty adapting these practices for the specific needs of the GDPR.

The PIA model is especially useful because DPIAs currently do not have a specification: there is no central source to explain, in detail, how they must be done101. While this is technically also true of PIAs – they are ‘only’ best practice, after all – there is a body of work available in a multitude of languages and accounting for various legal jurisdictions that organisations can seek out for guidance.

Furthermore, supplementary information and training are available from sources across Europe and much of the rest of the world, so it is relatively straightforward to get help if you need it.

The primary concern in using a PIA model as the basis for conducting a DPIA will be making sure that you account for all of the Regulation’s requirements. The actual DPIA process will be expanded in more detail over the coming chapters, including critical references to the relevant clauses and recitals in the GDPR.

When to conduct a DPIA

The three primary conditions identified in the GDPR for when a DPIA is required could be paraphrased as below:

 

a)  When evaluating a natural person using automated processing (including profiling) in order to make decisions or have legal impacts on the subject.

b)  When processing large quantities of special categories of data, or personal data relating to criminal convictions and offences.

c)  When systematically monitoring a publicly accessible area on a large scale.102

It should be noted that the Regulation states that these are required “in particular” – you should not assume that these are the only times that DPIAs are necessary. Recital 91 provides more detail on the context for the use of DPIAs:

  1. When there’s large-scale processing across a geographical area, e.g. an organisation wants to collect information on everyone in Scotland who falls within a specific demographic.
  2. When new technologies are being used on a large scale, e.g. an organisation has developed a new algorithm for sorting large quantities of personal data prior to the data being encrypted.
  3. When there’s a high level of risk to the data subjects’ rights and freedoms, or to their ability to exercise their rights and freedoms, e.g. processing personal information that results in a list of people who could then be targeted by criminals.
  4. When processing based on profiling is used to make decisions regarding specific natural persons, e.g. automated processing that collates information about someone’s socio-economic status so that they can then be ordered into groups for future education opportunities.
  5. When processing of special categories of personal data, biometric data or data on criminal convictions and offences is used to make decisions regarding specific natural persons, e.g. automated processing that collates information about someone’s medical history so that their health insurance rates can be adjusted.
  6. When monitoring publicly accessible areas on a large scale, especially when using optic-electronic devices (such as CCTV, infrared cameras, etc.) or the competent supervisory authority considers there to be a high risk to the rights and freedoms of data subjects, e.g. a fitness club wants to put a range of cameras around its carpark, which also serves customers of a vegan food supply store and a community centre.

The key terms throughout the recital are “large scale” and “high risk”, the criteria for which could be difficult to determine. The simple option is to consult a DPO who should have sufficient experience and expertise to determine such things. If you don’t have access to a DPO, the alternative is to ask the supervisory authority.

The UK’s ICO provides some guidance on how “big data” is identified103. It states that big data is “characterised by volume, variety and velocity of data, and by the use of algorithms, using ‘all’ the data and repurposing data”. This definition is expanded on in the report, and is likely to remain true for organisations based in the UK. For organisations elsewhere in Europe, the relevant supervisory authority likely has their own definition, but it’s unlikely to be too far removed from this.

The supervisory authority should generally be considered the primary source for clarification on questions like these, and supervisory authorities are required to produce “a list of the kind of processing operations which are subject to the requirement for a [DPIA]” and may also produce “a list of the kind of processing operations for which no [DPIA] is required”104.

In addition to the listed requirements for DPIAs, Member States may require public authorities to conduct DPIAs on the basis of regulations it may enact covering specific processing operations105.

In addition to the Regulation’s requirements for when to conduct a DPIA, you may wish to consider voluntarily conducting one in a number of situations as DPIAs are a core part of good practice in complying with the Regulation, especially with regard to data protection by design and by default. Depending on your organisation’s risk appetite, you might think about conducting a DPIA whenever you determine a new processing activity or begin using a new processing technology. In some instances, you may be able to look into DPIAs on similar processing or technologies to discover whether there are any notable findings.

A more obvious condition for a voluntary DPIA would be in preparation for compliance with the GDPR. Every organisation should examine their current and planned processing activities and technologies to determine whether any of them warrant examination via a DPIA. Identifying all of your current processes will come as part of your initial data mapping exercise, which will be discussed in Chapter 7.

The ICO’s guidance provides a list of questions an organisation might ask about any new project to determine whether a DPIA is advisable. It’s a little on the cautious side, but any organisation could easily come up with a similar set of questions for its own purposes. A small sample of the sorts of things the ICO recommends asking:

 

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

 

Will the project compel individuals to provide information about themselves?

 

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 you using new technology which might be perceived as being privacy intrusive? For example, the use of biometrics or facial recognition.

 

Is the information about individuals of a kind particularly likely to raise privacy concerns or expectations? For example, health records, criminal records or other information that people would consider to be particularly private.

 

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

It’s also worth mentioning that a DPIA can examine a number of processes at once. This is obviously simpler when those processes are related or linked, but it’s quite acceptable for a single assessment to determine the impact of a range of data processing operations/functions.

Who needs to be involved

It is the responsibility of the data controller to ensure DPIAs are carried out “where processing operations are likely to result in a high risk to the rights and freedoms of natural persons”107. It is the controller’s responsibility because the controller determines the purpose of the processing.

The DPO is a central figure in DPIAs. The Regulation states that “the controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment”108. What this doesn’t say is that seeking out a DPO (or someone with comparable expertise) should be considered best practice for any DPIA. The Regulation specifies certain aspects of your DPIA (in Clause 7 of Article 35), but it doesn’t tell you how to actually do one, or provide the insight necessary to really get to grips with privacy and data protection.

Asset and process owners should certainly be involved. They will be responsible for the actual processing and/or the personal data being processed, so it’s critical that they have a thorough understanding of all of the risks, including those that you might consider negligible and leave untreated.

A whole range of functions within the organisation might also be involved: risk management, service delivery, infrastructure, and so on. It will all depend on the organisation, the scale and nature of the processing, its criticality to the business, and, of course, the organisation’s stance with regard to compliance.

It’s also quite likely you’ll want to involve a number of stakeholders. These don’t need to be involved in any great depth at all stages of the DPIA, but they will need to be available at the key moments to provide feedback or input.

It’s worth remembering that, like any other business process, having too many people directly involved can ruin the process; it gets bogged down in irrelevant details, decisions are made by committee instead of by authority, the objectives of the process are lost as internal politics derail the discussion and decisions that should have taken days end up taking weeks. This sort of “paralysis by analysis” will be familiar to most organisations.

The DPIA process should be proportional to the size of the organisation, its turnover and the scale of the processing. It’s reasonable to assume that the CEO of a major international organisation will hurl bodies at the problem quite happily if it will save 4% of global turnover. As long as the DPIA process is well managed and led, this should not pose too great a problem.

Data protection by design and by default

The Regulation states that “the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default”109.

DPIAs are an important part of data protection by design and by default, which is a process of ensuring that all personal data collection, processing, storage and destruction measures are designed to secure privacy. The UK’s ICO describes data protection by design as “an approach to projects that promotes privacy and data protection compliance from the start”110. This is expanded in the GDPR to include “by default”, which essentially insists that the organisation ensures that all such projects take data protection into account.

According to the Regulation, the controller should establish whatever measures are necessary to “implement data-protection principles […] in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects”111. This is expanded more clearly in the following clause to encompass each of the data protection principles:

 

The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.112

The Regulation mandates putting measures in place to ensure that the data subjects’ rights and freedoms are preserved simply because the processing has been designed that way. It’s quite a logical step, and often applied to other design practices that, depending on the industry, are also seen as essential, such as safety by design in an industrial setting, or hygiene by design in healthcare practices.

Conducting PIAs or DPIAs are an important part of this. If you know what the risks are to the data subjects’ rights, it’s much simpler to establish measures that will protect them. As such, you should ensure that your DPIA methodology will provide outputs that can be turned into preventive measures and applied to the processing design from the very start.

In the 1990s, the Information & Privacy Commissioner (IPC) of Ontario developed a comprehensive primer on privacy by design113, which has been regularly updated and remains an authoritative source on ensuring privacy in business applications by default. It establishes seven key principles around which data protection by design should be built:

  1. Proactive not reactive; preventative not remedial
  2. Privacy as the default setting
  3. Privacy embedded into design
  4. Full functionality – positive-sum, not zero-sum
  5. End-to-end security – full lifecycle protection
  6. Visibility and transparency – keep it open
  7. Respect for user privacy – keep it user-centric

The Privacy by Design document formed the foundation of many further publications and additional guidance focusing on the concept of promoting privacy and data protection compliance from the start of a project and throughout its lifecycle. The document itself has also been translated into a range of languages to improve its worldwide reach.

With the prevalence of materials and support available to help you establish data protection by design and by default, your final concern will be generating evidence that this takes place and is appropriately applied. Much like anything else associated with your privacy compliance framework, some records should be generated to provide this evidence. The Regulation, however, provides a second option: certification schemes.

The Regulation states that “an approved certification mechanism […] may be used as an element to demonstrate compliance”114. It’s only “an element”, but the Regulation actually allows quite a lot of compliance to be proven through certification schemes. If you’d like to pursue this, you should contact your supervisory authority to find out if any certification schemes are available in your jurisdiction.

________________________

94 GDPR, Recital 83.

95 Conducting privacy impact assessments,https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf.

96 France’s CNIL, for instance, recently released its own guidance: www.cnil.fr/fr/node/15798.

97 Conducting privacy impact assessments, p. 10.

98 Conducting privacy impact assessments, p. 11.

99 GDPR, Article 35, Clause 1.

100 GDPR, Article 35, Clause 3.

101 Article 35 of the GDPR does describe what needs to be included in the DPIA, but not how the DPIA should be conducted. This is an important distinction.

102 Derived from GDPR, Article 35, Clause 3.

103 “Big Data and Data Protection”, https://ico.org.uk/media/1541/big-data-and-data-protection.pdf.

104 GDPR, Article 35, Clauses 4-5.

105 GDPR, Recital 93.

106 Conducting privacy impact assessments, p. 33.

107 GDPR, Recital 84.

108 GDPR, Article 35, Clause 2.

109 GDPR, Recital 78.

110 https://ico.org.uk/for-organisations/guide-to-data-protection/privacy-by-design/.

111 GDPR, Article 25, Clause 1.

112 GDPR, Article 25, Clause 2.

113 Privacy by Design, Ann Cavoukian, Information & Privacy Commissioner, Ontario, Canada, www.ipc.on.ca/resource/privacy-by-design/.

114 GDPR, Article 25, Clause 3.