On New Year’s Eve 2015, I hosted a dinner party for 12 guests. My friends had a variety of dietary needs: vegetarian, gluten-free, dairy-free and tomato-free. I had considered these beforehand, and prepared dishes which addressed them. I don’t recall facing the same concerns 15 years ago – except perhaps catering for the odd vegetarian – but then my friends were not so aware of dietary options or intolerances, plus I didn’t hold such large or sophisticated dinner parties.
The guests remain my friends so I am hopeful they enjoyed the food. But what if I had not checked in advance and built these requirements into the meal? Those who were allergic or intolerant to certain ingredients could have had significant medical problems. Others might have chosen not to eat my meal, which would be a shame after the time and effort I had put into it. They might also have been quite annoyed at me. Or perhaps I could have ordered a take-away instead – a costly option and not really what I wanted to achieve. All in all, my dinner party would have been a failure.
Hang on, you are probably thinking, I thought I had tuned in to an article about privacy impact assessments (PIAs)? Well, PIAs are not so different to my story. For my dinner party project, I needed to identify and assess dietary risks, then find and apply solutions to those risks prior to the meal. With PIAs, the project is (more usually) a new system or activity involving the use of personal data, and the risks are data protection and privacy. In both cases, the assessment needs to follow through the project process – writing the recipe, sourcing ingredients and equipment, pulling them all together, and finally implementing the meal, system or activity.
PIAs are not something organisations did a lot (or any) of 15 years ago, although key compliance issues were still considered. Moving from then to now, awareness and significance of data protection has increased. More sophisticated technology has enabled more sophisticated data processing, on a greater scale, and in more intrusive ways. Not addressing the risks may cause damage or distress to individuals, low take-up of a project by customers, damage to relationships and reputation, and time and costs in fixing errors (as well as penalties for non-compliance). A project may partly or wholly fail. These are some of the drivers for carrying out PIAs, and for them to become a new legal requirement under EU data protection law.
Existing PIA frameworks
In the UK, the Information Commissioner’s Office has promoted PIAs for a number of years, although the Data Protection Act 1998 does not require PIAs to be carried out. The ICO published a PIA Handbook in 2007, which was replaced in 2014 by a more up-to-date PIA Code of Practice. Some sectors have additional PIA requirements or guidance. For example, government departments were required to adopt PIAs following a data handling review by the Cabinet Office in 2008. PIAs and PIA methodologies are also promoted in many other countries around the world.
A lot of organisations have therefore already integrated PIAs into project and risk management procedures, following existing recommendations and guidance. Other organisations may not yet be so familiar with PIAs, as they are not yet compulsory for most sectors. Either way, EU organisations will need to adopt new PIA procedures, or review and adapt existing procedures, in order to meet the new requirements.
New legal requirement under the GDPR
The compromise text of the EU General Data Protection Regulation (GDPR) was published on 15 December 2015. At the time of writing, it is expected to have final approval soon, and then come in force in early 2018. Article 33(1) contains the new obligation for conducting impact assessments:
‘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 for the rights and freedoms of individuals, 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…’
As the GDPR is a data protection law, the requirement is for a data protection impact assessment (DPIA). This applies to the processing of personal data recorded in electronic or paper-based format. There may also be privacy issues associated with non-personal information, for example communications data or information about corporate entities; and relevant legal requirements include communications laws, direct marketing rules and confidentiality requirements. Wider privacy issues can also arise from, for example, surveillance, bodily testing or searching, which may also trigger human rights and other privacy laws. Often these matters go hand-in-hand with data protection issues, as personal data is recorded as a result of the relevant activities, but separate privacy concerns can also arise. Therefore, whilst this article focuses on data protection impact assessments under the GDPR, PIAs may also address wider privacy risks.
When a DPIA will need to be carried out
Article 33 requires a DPIA to be carried out where processing is ‘likely to result in a high risk‘. Article 33(2) contains a list of cases where DPIAs shall, in particular, be carried out:
‘(a) 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 individual or similarly significantly affect the individual;
(b) processing on a large scale of special categories of data referred to in Article 9(1), or of data relating to criminal convictions and offences referred to in Article 9a;
(c) a systematic monitoring of a publicly accessible area on a large scale.’
The first of these would capture many data analysis activities, for example where an evaluation of a person’s characteristics or behaviour impacts the services they may receive or how they are treated. The definition of ‘profiling‘ lists performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location and movements as matters which may be analysed or predicted.
Large-scale use of sensitive types of data is captured by (b). As well as the existing categories of sensitive personal data under the DPA, this now captures genetic and biometric data.
Thirdly, large-scale public monitoring would require a DPIA, which may include use of CCTV, drones or body-worn devices.
In addition, under Articles 33(2a) and 33(2b), the supervisory authority (the ICO in the UK) shall establish a list of the kind of processing operations where a DPIA is required and may establish a list of processing operations where no DPIA is required. The lists are subject to (where appropriate) co-operation with other EU supervisory authorities and the EU Commission, and must take into account opinions of the (new) European Data Protection Board.
Article 33 requires the DPIA to be carried out ‘prior to the processing‘; in other words, prior to starting the relevant activities. A post-implementation review would be too late (although may still be of benefit if a DPIA was not undertaken previously).
Organisations will therefore need to identify whether projects or activities which arise fall within a category described above or may otherwise result in a high risk. Even within organisations which do not regularly carry out high-risk data processing, changes to existing activities can turn previously low risks into high ones. For example, adopting new technology to assist with an established business procedure can affect how personal data is used.
Identifying the need for a DPIA is commonly achieved by an initial assessment during project planning (as is also recommended within the ICO’s PIA Code of Practice). At that stage, business teams can identify intended uses of personal data and assess potential data protection risks. The outcome determines whether or not to proceed further with a DPIA.
Of course, even if an initial assessment does not determine a high risk or trigger specific DPIA requirements under the GDPR, organisations may wish to continue with an assessment to address lower data protection risks and ensure compliance.
Exception to the DPIA requirement
Article 33(5) contains a potential exception for regulated activities carried out pursuant to a legal obligation or public interest. The controller may not be required to carry out a DPIA if one has already been carried out as part of setting the legal basis for those activities. Recital 71 refers to activities of doctors and attorneys in using health and client data – it is unclear whether this is touching on the same point – it seems to indicate that such processing activities shall not be considered as being on a ‘large scale‘ rather than being a specific exception.
Procedure for carrying out a DPIA
Article 33(1a) provides that the controller shall seek the advice of the data protection officer, where designated (in accordance with Article 35), when carrying out a DPIA.
Article 33(3) provides that the DPIA shall contain at least:
‘(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 referred to in paragraph 1;
(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.‘
These steps are comparable to those within the ICO’s PIA Code of Practice, which is useful in considering what they might mean in practice. Firstly, an organisation must describe the proposed flows of information involved in the activity or project, ensuring it is clear how and why personal data is being used at each stage. Diagrams as well as written descriptions can be useful to convey this. Secondly, an organisation must assess whether the proposed use is of data necessary and proportionate to its legitimate purposes; for example, are there alternative ways to achieve the same project objectives?
Next it is clear that a DPIA involves a risk assessment. This involves considering the potential impacts of proposed activities on the relevant individuals and the organisation, and the likelihood of such impacts arising. Impacts may include, for example, loss or misuse of data, intrusion into private lives, lack of transparency and non-compliance. Solutions must then be found to avoid or mitigate risks and demonstrate compliance. These may include introducing additional elements into the project (such as anonymisation, pseudonymisation or security measures), or changing aspects of the project (such as collecting less data or doing fewer processing operations).
Organisations may use risk assessment methodologies already in place for other legal or organisational risks, or may create tailored risk assessments for the purpose of DPIA procedures.
Article 33(3a) provides that compliance with approved codes of conduct shall be taken into account in assessing data protection impacts. Codes of conduct relating to different sectors or types of activity may be approved under Article 38.
Consultation with data subjects
Article 33(4) requires controllers, ‘where appropriate‘ to ‘seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of the processing operations’.
This means consulting with those whose privacy is affected by the proposed activities, as it is these privacy risks that the DPIA is seeking to address. However, it may not always be appropriate to do this, for example when protecting overriding interests to keep aspects of the proposed project confidential. Public sector organisations, in particular, may already have formal consultation processes, and the ICO’s PIA Code of Practice also gives guidance on consultation, but this may be a new consideration for some organisations.
Data processors
Article 26(2) sets out requirements for the terms of contracts between data controllers and data processors (which are more detailed than the current requirements under the DPA). These include that the processor shall assist the controller in ensuring compliance with requirements for DPIAs.
The processor’s role may be particularly important, for example, where it is providing technology central to the relevant project, as it will be in the best position to identify and address privacy and security risks relating to its own technology.
Consultation with supervisory authorities
Article 34 contains a procedure for consultation with the supervisory authority (the ICO in the UK) as a result of (or potentially as part of) a DPIA. Recital 74 indicates the intention for consultation where the controller considers that high risks cannot be mitigated by reasonable means. However, Article 34 states that consultation is required where the processing would result in a high risk in the absence of mitigating measures. As DPIAs are required only for high-risk activities, this could mean consultation is always needed following required DPIAs. Further clarity on the intended interpretation would therefore be useful, as it is likely to have a big impact on timetables and resources for controllers and the ICO.
As part of the consultation, the supervisory authority must give advice to the controller where it is of the opinion that the intended activities would not comply with the GDPR. If appropriate mitigating measures have been established, therefore, perhaps no further action is required. Advice must generally be given within eight weeks although this may be extended in complex circumstances. The authority may also use its other powers (eg to investigate further or order compliance).
The ICO already provides support to organisations which wish to consult on data protection matters, but the GDPR will require a more formal process and resources for DPIA consultation. For controllers, consultation could assist in finding solutions, though it could also delay or restrict projects.
Post-implementation reviews
Article 33(8) provides:
‘Where necessary, the controller shall carry out a review to assess if the processing of personal data is performed in compliance with the data protection impact assessment at least when there is a change of the risk represented by the processing operations.’
Regular post-implementation reviews or audits can be used to assess whether the risks have changed, and ensure the solutions identified during the DPIA have been and continue to be adopted appropriately.
Data protection by design and by default
Article 23 contains general requirements for data protection by design and by default. These mean that measures designed to address the data protection principles should be implemented into processing activities, and that the default position should be to limit the amount of data used and the processing activities to those which are necessary for the relevant purposes. Carrying out DPIAs, even where particularly high risks have not been identified, may be a good way to demonstrate these matters are being addressed.
EU Directive for the police and criminal justice sector
The GDPR has been prepared alongside the new Data Protection Directive for the police and criminal justice sector, which will separately need to be implemented into UK law. Articles 25a and 26 of the Directive contain requirements similar to those in the GDPR in relation to DPIAs and consultation with the supervisory authority.
What to do now
DPIAs will not become a legal requirement under the GDPR for a couple of years yet. However, there are benefits in starting (or continuing) now to build DPIA (or PIA) processes into existing project and risk management procedures. As well as the existing advantages of DPIAs, this will enable them to be part of business as usual when the new law arrives. In addition, DPIAs conducted now will ensure that high-risk data processing activities in existence when the GDPR takes effect will have had the prior assessment envisaged by the new requirements.
It is, of course, still early days in working out how the detail of the provisions discussed above will be interpreted in practice, and we can expect further guidance at UK and EU level (including the required lists of activities which will require a DPIA). Existing PIA guidance, such as within the ICO’s Code of Practice, should help organisations to get on track, and procedures can be refined further as we get more clarity on the specific GDPR requirements.
Meanwhile, as I write this, I have discovered that one of my dinner guests this evening is intolerant to dairy products, and is probably not going to want the macaroni cheese I was planning. So this afternoon I am back on dietary impact assessments.
Olivia Whitcroft is the principal of OBEP (www.obep.uk), a law firm specialising in technology contracts, data protection and intellectual property. Contact: olivia.whitcroft@obep.uk, @ObepOlivia
