Privacy Impact Assessment

Privacy impact assessments (PIAs) are tools which can help organizations identify the most effective way to comply with their data protection obligations and meet individuals’ expectations of privacy. An effective PIA will allow organizations to identify and fix problems at an early stage, reducing the associated costs and damage to reputation which might otherwise occur. PIAs are an integral part of taking privacy by design approach.

Key points:

A PIA is a process which assists organizations in identifying and minimizing the privacy risks of new projects or policies.
Conducting a PIA involves working with people within the organization, with partner organizations and with the people affected to identify and reduce privacy risks.
The PIA will help to ensure that potential problems are identified at an early stage, when addressing them will often be simpler and less costly.
Conducting a PIA should benefit organizations by producing better policies and systems and improving the relationship between organizations and individuals.
A privacy impact assessment states what personally identifiable information (PII) is collected and explains how that information is maintained, how it will be protected and how it will be shared.

A PIA should identify:

Whether the information being collected complies with privacy-related legal and regulatory compliance requirements.

The risks and effects of collecting, maintaining and disseminating PII.
Protections and processes for handling information to alleviate any potential privacy risks.
Options and methods for individuals to provide consent for the collection of their PII.
PIAs are not something organizations 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 organizations have therefore already integrated PIAs into project and risk management procedures, following existing recommendations and guidance. Other organizations may not yet be so familiar with PIAs, as they are not yet compulsory for most sectors.

Either way, EU organizations 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 behaviors 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, behavior, location and movements as matters which may be analyzed 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).

Organizations 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 organizations 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, organizations 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 organization 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 organization 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 organization, 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).

Organizations may use risk assessment methodologies already in place for other legal or organizational 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 organizations, 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 organizations.

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 organizations 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 organizations to get on track, and procedures can be refined further as we get more clarity on the specific GDPR requirements.

Related Posts via Taxonomies

• Guida al GDPR per chi non ne vuol sapere: dice il controller “lei non sa chi sono io”
• Shrems II, Data transfer, and the USA: wheels are rolling.
• Guida al GDPR per chi non ne vuol sapere: ma quante carrozze ha questo treno?
• Guida al GDPR per chi non ne vuole sapere: devi iniziare, ma cosa devi fare?
• Guida al GDPR per chi non ne vuole sapere: Non ci saranno rinvii se non a giudizio….
• Perchè il gdpr è importante per la massaia di Voghera, per me e per te
• Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio ?
• Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)?
• Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)
• The IoT Files – Privacy

To the official site of Related Posts via Taxonomies.

Privacy Impact Assessment by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.