Regulation 2016/6791 (GDPR) will apply from 25 May 2018. Article 35 of the GDPR introduces the concept of a Data Protection Impact Assessment (DPIA).

A DPIA is a process designed to describe the processing, assess the necessity and proportionality of a processing and to help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data3 (by assessing them and determining the measures to address them). DPIA are important tools for accountability, as they help controllers not only to comply with requirements of the GDPR, but also to demonstrate that appropriate measures have been taken to ensure compliance with the Regulation. In other words, a DPIA is a process for building and demonstrating compliance.

Under the GDPR, non-compliance with DPIA requirements can lead to fines imposed by the competent supervisory authority. Failure to carry out a DPIA when the processing is subject to a DPIA, carrying out a DPIA in an incorrect way, or failing to consult the competent supervisory authority where required, can each result in an administrative fine of up to 10M€, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.

Here below a summary of guidelines recently offered by WP29.

A.-     What does a DPIA address. A DPIA may concern a single data processing operation. However, Article 35(1) states that “a single assessment may address a set of similar processing operations that present similar high risks”. Recital 92 adds that “there are circumstances under which it may be reasonable and economical for the subject of a data protection impact assessment to be broader than a single project, for example where public authorities or bodies intend to establish a common application or processing platform or where several controllers plan to introduce a common application or processing environment across an industry sector or segment or for a widely used horizontal activity”.

This means that a single DPIA could be used to assess multiple processing operations that are similar in terms of the risks presented, provided adequate consideration is given to the specific nature, scope, context and purposes of the processing.

B.-     Is a DPIA mandatory? It is mandatory where a processing is “likely to result in a high risk”.

It is particularly relevant when a new data processing technology is being introduced.

In cases where it is not clear whether a DPIA is required, the WP29 recommends that a DPIA is carried out nonetheless as a DPIA is a useful tool to help data controllers comply with data protection law.

Even though a DPIA could be required in other circumstances, Article 35(3) provides some examples when a processing is “likely to result in high risks”:

(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 natural person or similarly significantly affect the natural person10;

(b) 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 1011; or

(c) a systematic monitoring of a publicly accessible area on a large scale”.

As the words “in particular” in the introductory sentence of Article 35(3) GDPR indicate, this is meant as a non-exhaustive list. There may be “high risk” processing operations that are not captured by this list, but yet pose similarly high risks. Those processing operations should also be subject to DPIAs. For this reason, the criteria developed below sometimes go beyond a simple explanation of what should be understood by the three examples given in Article 35(3) GDPR.

In order to provide a more concrete set of processing operations that require a DPIA due to their inherent high risk, taking into account the particular elements of Articles 35(1) and 35(3)(a) to (c), the list to be adopted at the national level under article 35(4) and recitals 71, 75 and 91, and other GDPR references to “likely to result in a high risk” processings, the following criteria should be considered:

1)       evaluation or scoring, including profiling and predicting, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (recitals 71 and 91);

2)       automated-decision making with legal or similar significant effect: processing that aims at taking decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person”;

3)       systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through “a systematic monitoring of a publicly accessible area”;

4)       sensitive data: this includes special categories of data as defined in Article 9 (for example information about individuals’ political opinions), as well as personal data relating to criminal convictions or offences;

5)       data processed on a large scale: the GDPR does not define what constitutes large-scale, though recital 91 provides some guidance. In any event, the WP29 recommends that the following factors, in particular, be considered when determining whether the processing is carried out on a large scale:

a. the number of data subjects concerned, either as a specific number or as a proportion of the relevant population;

b. the volume of data and/or the range of different data items being processed;

c. the duration, or permanence, of the data processing activity;

d. the geographical extent of the processing activity;

6)       Datasets that have been matched or combined, for example originating from two or more data processing operations performed for different purposes and/or by different data controllers in a way that would exceed the reasonable expectations of the data subject;

7)       data concerning vulnerable data subjects (recital 75): the processing of this type of data can require a DPIA because of the increased power imbalance between the data subject and the data controller, meaning the individual may be unable to consent to, or oppose, the processing of his or her data;

8)       innovative use or applying technological or organisational solutions, like combining use of finger print and face recognition for improved physical access control, etc.

9)       data transfer across borders outside the European Union (recital 116), taking into consideration, amongst others, the envisaged country or countries of destination, the possibility of further transfers or the likelihood of transfers based on derogations for specific situations set forth by the GDPR;

10)     when the processing in itself “prevents data subjects from exercising a right or using a service or a contract” (Article 22 and recital 91). This includes processings performed in a public area that people passing by cannot avoid, or processings that aims at allowing, modifying or refusing data subjects’ access to a service or entry into a contract.

►      The WP29 considers that the more criteria are met by the processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and therefore to require a DPIA. As a rule of thumb, a processing operation meeting less than two criteria may not require a DPIA due to the lower level of risk, and processing operations which meet at least two of these criteria will require a DPIA.

However, in some cases, a processing meeting only one of these criteria will require a DPIA. Conversely, if the controller believes that despite the fact that the processing meets at least two criteria, it is considered not to be “likely high risk”, he has to thoroughly document the reasons for not carrying out a DPIA.

In addition, a data controller subject to the obligation to carry out the DPIA “shall maintain a record of processing activities under its responsibility” including inter alia the purposes of processing, a description of the categories of data and recipients of the data and “where possible, a general description of the technical and organisational security measures referred to in Article 32(1)” (Article 30(1)) and must assess whether a high risk is likely, even if they ultimately decide not to carry out a DPIA.

Supervisory authorities are required to establish, make public and communicate a list of the processing operations that require a DPIA to the European Data Protection Board (EDPB) (Article 35(4)).

C.-     When a DPIA is not required. A DPIA is not required in the following cases:

-        where the processing is not "likely to result in a high risk to the rights and freedoms of natural persons";

-        when the nature, scope, context and purposes of the processing are very similar to the processing for which DPIA have been carried out. In such cases, results of DPIA for similar processing can be used;

-        where a processing operation has a legal basis in EU or Member State law and has stated that an initial DPIA does not have to be carried out, where the law regulates the specific processing operation and where a DPIA, according to the standards of the GDPR, has already been carried out as part of the establishment of that legal basis;

-        where the processing is included on the optional list (established by the supervisory authority) of processing operations for which no DPIA is required. Such a list may contain processing activities that comply with the conditions specified by this authority, in particular through guidelines, specific decisions or authorizations, compliance rules, etc. (e.g. in France, authorizations, exemptions, simplified rules, compliance packs…). In such cases, and subject to re-assessment by the competent supervisory authority, a DPIA is not required, but only if the processing falls strictly within the scope of the relevant procedure mentioned in the list and continues to comply fully with the relevant requirements.

C.-     What about already existing processing operations? DPIAs are needed for those created after May 2018 or that change significantly.

The requirement to carry out a DPIA applies to processing operations meeting the criteria in Article 35 and initiated after the GPDR becomes applicable on 25 May 2018.

WP29 strongly recommends to carry out DPIAs for processing operations already underway prior to May 2018. In addition, where necessary, “the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operation” (Article 35(11)21).

Moreover, this would be the case where a significant change to the processing operation has taken place after May 2018, for example because a new technology has come into use or because personal data is being used for different purpose. In cases like this, the processing in effect becomes a new data processing operation and could require a DPIA.

The DPIA should certainly be reviewed when there is a change of the risk presented by the processing operation.

Risks can change as a result of change to one of the components of the processing operation (data, supporting assets, risk sources, potential impacts, threats, etc.) or because the context of the processing evolves (purpose, functionalities, etc.). Data processing systems can evolve quickly and new vulnerabilities can arise. Therefore it should be noted that the revision of a DPIA is not only useful for continuous improvement, but also critical to maintain the level of data protection in a changing environment over longer time.

Finally, a DPIA may also become necessary because the organisational or societal context for the processing activity has changed, for example because the effects of certain automated decisions have become more significant, new categories of natural persons become vulnerable to discrimination or the data is intended to be transferred to data recipients located in a country which has left the EU.

As a matter of good practice, a DPIA should be continuously carried out on existing processing activities. However, it should be re-assessed after 3 years, perhaps sooner, depending on the nature of the processing and the rate of change in the processing operation and general circumstances. Such assessment is also recommended for data processing which have taken place before May 2018 and where therefore not subject to a DPIA, to make sure that 3 years after this date or sooner, depending on the context, the risks for the rights and freedoms are still mitigated. data is being used for different purpose. In cases like this, the processing in effect becomes a new data processing operation and could require a DPIA.

The DPIA should certainly be reviewed when there is a change of the risk presented by the processing operation.

Risks can change as a result of change to one of the components of the processing operation (data, supporting assets, risk sources, potential impacts, threats, etc.) or because the context of the processing evolves (purpose, functionalities, etc.). Data processing systems can evolve quickly and new vulnerabilities can arise. Therefore it should be noted that the revision of a DPIA is not only useful for continuous improvement, but also critical to maintain the level of data protection in a changing environment over longer time.

Finally, a DPIA may also become necessary because the organisational or societal context for the processing activity has changed, for example because the effects of certain automated decisions have become more significant, new categories of natural persons become vulnerable to discrimination or the data is intended to be transferred to data recipients located in a country which has left the EU.

As a matter of good practice, a DPIA should be continuously carried out on existing processing activities. However, it should be re-assessed after 3 years, perhaps sooner, depending on the nature of the processing and the rate of change in the processing operation and general circumstances. Such assessment is also recommended for data processing which have taken place before May 2018 and where therefore not subject to a DPIA, to make sure that 3 years after this date or sooner, depending on the context, the risks for the rights and freedoms are still mitigated.

D.-     At what moment should DPIA be carried out. The DPIA should be carried out “prior to the processing”.

The DPIA should be started as early as practical in the design of the processing operation even if some of the processing operations are still unknown. As the DPIA is updated throughout the lifecycle project, it will ensure that data protection and privacy are considered and promote the creation of solutions which promote compliance. It can also be necessary to repeat individual steps of the assessment as the development process progresses because the selection of certain technical or organizational measures may affect the severity or likelihood of the risks posed by the processing.

E.-     Who is obliged to carry out the DPIA? The data controller, with the DPO and the data processor(s)

The controller is responsible to ensure that the DPIA is carried out.

Carrying out the DPIA may be done by someone else, inside or outside the organization, but the controller remains ultimately accountable for that task.

The controller must also seek the advice of the Data Protection Officer (DPO), where designated and this advice, and the decisions taken, should be documented within the DPIA. The DPO should also monitor the performance of the DPIA (further guidance is provided in the WP29 Guidelines on Data Protection Officer 16/EN WP 243).

If the processing is wholly or partly performed by a data processor, the processor should assist the controller in carrying out the DPIA and provide any necessary information.

The controller must “seek the views of data subjects or their representatives”, “where appropriate”. The WP29 considers that:

-        those views could be sought through a variety of means, depending on the context (e.g. an internal or external study related to the purpose and means of the processing operation, a formal question to the staff representatives or trade/labour unions or a survey sent to the data controller’s future customers);

-        if the data controller’s final decision differs from the views of the data subjects, its reasons for going ahead or not should be documented;

-        the controller should also document its justification for not seeking the views of data subjects, if it decides that this is not appropriate.

Finally, it is good practice to define and document other specific roles and responsibilities, depending on internal policy, processes and rules.

F.-     What is the methodology to carry out a DPIA? Different methodologies but common criteria.

The GDPR sets out the minimum features of a DPIA (Article 35(7), and recitals 84 and 90):

- “a description of the envisaged processing operations and the purposes of the 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;

demonstrate compliance with this Regulation”.

Compliance with a code of conduct (Article 40) has to be taken into account (Article 35(8)) when assessing the impact of a data processing operation. This can be useful to demonstrate that adequate measures have been chosen or put in place, provided that the code of conduct is appropriate to the processing operation.

All the relevant requirements set out in the GDPR provide a broad, generic framework for designing and carrying out a DPIA. The practical implementation of a DPIA will depend on the requirements set out in the GDPR which may be supplemented with more detailed practical guidance. This opens the way for scalability, meaning that even a small data controller can design and implement a suitable DPIA.

Recital 90 of the GDPR outlines a number of components of the DPIA which overlap with well-defined components of risk management (e.g. ISO 3100025). In risk management terms, a DPIA aims at “managing risks” to the rights and freedoms of natural persons, using the following three processes, by:

-        establishing the context: “taking into account the nature, scope, context and purposes of the processing and the sources of the risk”;

-        assessing the risks: “assess the particular likelihood and severity of the high risk”;

-        treating the risks: “mitigating that risk” and “ensuring the protection of personal data”, and “demonstrating compliance with this Regulation”.

G.-     Conclusions and recommendations. DPIAs are a useful way for data controllers to implement data processing systems that comply with the GDPR and can be mandatory for some types of processings.

They are scalable and can take different forms, but the GDPR sets out the basic requirements of an effective DPIA. Data controllers should see the carrying out of a DPIA as a useful and positive activity that aids legal compliance.

Article 24(1) sets out the basic responsibility of the controller in terms of complying with the GDPR: “taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary”.

The DPIA is a key part of complying with the Regulation where high risk data processing is planned or is taking place. This means that data controllers should use the criteria set out in this document to determine whether or not a DPIA has to be carried out. Internal data controller policy could extend this list beyond the GDPR’s legal requirements. This should result in greater trust and confidence of data subjects and other data controllers.

The GDPR does not specify which DPIA process must be followed but instead allows for data controllers to introduce a framework which complements their existing working practices provided it takes account of the components described in Article 35(7).

Such a framework can be bespoke to the data controller or common across a particular industry. Previously published frameworks developed by EU DPAs and EU sector-specific frameworks include (but are not limited to):

■       Examples of EU generic frameworks:

- DE: Standard Data Protection Model, V.1.0 – Trial version, 2016.

https://www.datenschutzzentrum.de/uploads/SDM-Methodology_V1_EN1.pdf

- ES: Guía para una Evaluación de Impacto en la Protección de Datos Personales (EIPD), Agencia española de protección de datos (AGPD), 2014.

https://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/Guias/Guia_EIPD.pdf

- FR: Privacy Impact Assessment (PIA), Commission nationale de l’informatique et des libertés (CNIL), 2015.

https://www.cnil.fr/fr/node/15798

- UK: Conducting privacy impact assessments code of practice, Information Commissioner’s Office (ICO), 2014.

https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf

■       Examples of EU sector-specific frameworks:

- Privacy and Data Protection Impact Assessment Framework for RFID Applications28.

http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2011/wp180_annex_en.pdf

- Data Protection Impact Assessment Template for Smart Grid and Smart Metering systems

http://ec.europa.eu/energy/sites/ener/files/documents/2014_dpia_smart_grids_forces.pdf

An international standard will also provide guidelines for methodologies used for carrying out a DPIA (ISO/IEC 2913430).

In the Guidelines the WP29 proposes also some criteria which data controllers can use to assess whether or not a DPIA, or a methodology to carry out a DPIA, is sufficiently comprehensive to comply with the GDPR.