Is there a standardized method for carrying out a DPIA? Are there outlines, templates or tools in support of carrying out a DPIA?
Home » The GDPR » Main Tools and Actions » Data Protection Impact Assessment (DPIA) » Is there a standardized method for carrying out a DPIA? Are there outlines, templates or tools in support of carrying out a DPIA?

With DPIAs being a relatively new instrument introduced at the EU level with the GDPR, there is still ample discussion of how exactly a DPIA should be carried out and there exists several different schools of thought. Some national supervisory authorities have issued guidance on the topic, or even specific tools and templates. While a DPIA is primarily evaluated by the competent (i.e., typically national) supervisory authority, the guidance provided here cannot go in the merit of what is available in all member states. Instead, guidance is provided based on the opinion of the Article 29 Data Protection Working Party on the DPIA (wp248rev.01)[1] that has been formally adopted[2] by the European Data Protection Board[3]. According to Article 70(1) GDPR, “The Board shall ensure the consistent application of this Regulation” and is therefore the best source for advice at European level.

The Figure to illustrate the iterative process for carrying out a DPIA that is provided by the Working Party has already been shown in Figure 1 above. It is a cycle containing the following steps:

  1. Description of the envisaged processing.
  2. Assessment of the necessity and proportionality.
  3. Measures already envisaged.
  4. Assessment of the risks to the rights and freedoms [of natural persons].
  5. Measures envisaged to address the risks.
  6. Documentation.
  7. Monitoring and review.

The Working Party explains that there is flexibility in how a DPIA is structured:

“The GDPR provides data controllers with flexibility to determine the precise structure and form of the DPIA in order to allow for this to fit with existing working practices. There are a number of different established processes within the EU and worldwide which take account of the components described in recital 90. However, whatever its form, a DPIA must be a genuine assessment of risks, allowing controllers to take measures to address them.”[4]

The Working Party gives examples of currently known approaches in their Annex I[5]. These include both, generic national and sector-specific DPIA “frameworks”. “The [Working Party] encourages the development of sector-specific DPIA frameworks.”[6]

Controllers are thus free to choose the most suitable structure and format for a DPIA, as long as certain requirements are fulfilled: “It is up to the data controller to choose a methodology, but this methodology should be compliant with the criteria provided in Annex 2.”[7] The Working Party “proposes [these] 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”[8].

Usually, the different methodologies come with outlines, templates, and/or tools.

The remainder of this section therefore concentrates on these criteria for an acceptable DPIA provided by the Working Party.

The criteria mostly reflect the structure and content of Article 35(7) but provide additional detail and interpretation. The following reports the content with some rewording and minor restructuring for clarity[9]:

  1. Systematic description of the processing (Article 35(7)(a) GDPR)
  2. Assessment of necessity and proportionality (Article 35(7)(b) and (d) GDPR)
  3. Management of the risks to the rights and freedoms of data subjects (Article 35(7)(c) and (d) GDPR)
  4. Involvement of interested parties (Articles 35(2) and 35(9) GDPR)

Each of these is discussed in more detail in subsections in the following.

Can I follow the standard approach by ISO?

ISO has issued the international standard ISO/IEC 29134:2017 “Information technology — Security techniques — Guidelines for privacy impact assessment.” As usual for ISO standards, the text of the standard is not available publicly but only for paying customers. ISO standards are global in nature and thus cater to a variety concepts of “privacy”. It is unlikely that the standard adopts a legal view and impossible that a single standard satisfies the necessarily different legal requirements from different legislations. Should the ISO approach be suitable for a given controller, it is therefore advised that in addition, legal guidance specific to the GDPR is consulted in parallel.

Of general relevance for all these subsections is the second sentence of Recital 90 GDPR. It is reported here with highlighting and structure (bullets) added by the authors:

“That impact assessment should include, in particular, the measures, safeguards and mechanisms envisaged for:

  • mitigating that risk,
  • ensuring the protection of personal data and
  • demonstrating compliance with this Regulation.”

In other words:

  • The focus of the DPIA is on measures, safeguards, and mechanism.
  • These are applied to:
    • risks,
    • protection of personal data, in other words compliance with the GDPR, and
    • demonstration of compliance.

What is important to notice is that a DPIA is not only focused on identifying, assessing, and mitigating risks, but also with compliance and demonstration of compliance. The latter is particularly evident in letter (b) of Article 35(7) and the according subsection “2. Assessment of necessity and proportionality” that is described below.

Systematic description of the processing

Providing further detail to Article 35(7)(a) GDPR, the Working Party breaks down the description of the processing involved into the following elements[10]:

  • Nature, scope, context and purposes of the processing (Recital 90 GDPR);
  • personal data, recipients and storage period;
  • functional description of the processing operation;
  • technical and human resources employed in the processing(hardware, software, networks, people, paper or paper transmission channels);
  • compliance with approved codes of conduct (Article 35(8) GDPR).

Important to note regarding the first bullet is that Article 35(7)(a) reads “purposes of the processing, including, where applicable, the legitimate interest pursued by the controller”

While most of the concepts listed here are likely well understood, the exact meaning of (i) nature, (ii) scope, and (iii) context may be more elusive. Since there is no authoritative interpretation of these terms, the following provides one possible interpretation in the hope it proves helpful.

(i) Nature: There may be multiple aspects related to the nature of processing, including the following:

  • The processing paradigm;
  • the infrastructure paradigm;
  • level of automation;
  • form of “effect”;
  • the level of innovation.

Processing paradigms can range from imperative (i.e., “traditional” applications), over rule-based/declarative (e.g., expert systems), to machine-learning-based artificial intelligence.

The infrastructure paradigm can range from a desktop application over a client-server application, to a cloud-based solution, all showing different levels of distribution.

The level of automation can range from providing supports to human actors to fully automatic operation without any possibility of human intervention.

The form of “effect” describes the “output” of the processing. This may range from pure information (in information systems), over the creation of a status (e.g., right to vote) that determines the possible actions of a person, over the management of virtual assets of a person (e.g., a bank account), to cyber-physical systems that directly affect the physical world in which the person lives or the person herself.

The level of innovation can range from staying within realism where risks and their mitigation are well-understood, to deploying new technologies and methods whose consequences have yet to be found out and that may come with yet unknown side-effects and risks.

(ii) Scope: What is inside and outside of the scope of the processing activity determines its impact. In data protection, the scope has to be considered relative to the affected persons. This encompasses multiple aspects, including the following:

  • Which and how many persons are affected?
  • Which aspects of life of these persons are affected?
    • For what duration and with what frequency are these aspects captured?
    • With what precision are these aspects captured?

Which and how many persons are affected evidently determine the impact of the processing activity. Which kind of persons is affected is interesting in regard of whether some of these are vulnerable and require special kinds of protection. Apart from the absolute number of persons, relative numbers pertaining to geographic areas or groups of users.

The affected aspects of life are closely related to the involved categories of data. Evidently, different aspects of life come with different levels of sensitivity and thus risk. In the GDPR, the special categories of data (Article 9) together with data about criminal convictions (Article 10) are identified as particularly sensitive. The impact of the data processing does not only depend on the kinds of aspects are in the scope of the processing, but also what range of aspects of an individual are addressed. An isolated aspect usually has a much smaller impact than the processing of a profile that provides a complete picture of a person’s life.

The temporal scope, most prominently the duration over which these aspects are captured, also determines the impact. This is closely related to storage periods and erasure of data. When a certain type of data is collected more than just once, the frequency is also important. This is most evident when considering location data, where a tracking once every few days is largely different from a tracking every few minutes.

The precision with which aspects of a person’s life are captured also determines the impact of the processing activity. This is for example evident when looking at location where knowing the country where a person is located has much less impact than knowing the precise coordinates. Similarly, knowing that a person is of age has much less impact than knowing the date of birth.

(iii) Context: Understanding a processing activity and its risks is often impossible without knowing its context. Different aspects of context can, among others, be:

  • Legal;
  • Technical
  • Economical;
  • Societal.

Part of the legal context is the legal basis for processing according to Article 6 GDPR and possibly Article 9 GDPR. Also relevant here are possible certifications according to Article 42 GDPR, approved Codes of Conduct according to Article 40 GDPR (see Article 35(8)) and Binding Corporate Rules according to Article 47 GDPR. The legal context may also include authoritative opinions by the European Data Protection Board according to Article 64 GDPR or court decisions that are relevant to the assessment of impact. Note that the Working Party has listed the codes of conduct in a separate element, likely since it is explicitly required in Article 35(8) GDPR.

There are two aspects that contribute to the technical context:

  • Other processing activities by the same or by different controllers that interact with the processing activity, and
  • The state of the art of technology to defend and attack.

In some cases, it is impossible to assess a processing activity in isolation. This is typically the case with distributed systems where different controllers operate different components. A good example is federated identity management where an identity provider operates a component that can only be understood when also considering users and relying parties. Here and in many cases, privacy is often determined by the communication protocols used between components and thus processing activities. This is illustrated by the existence of specifically designed privacy enhancing protocols[11]. If one were to assess the impact without considering the context, these particularly relevant protocols would fall into the gaps between controllers and thus DPIAs.

It is self-evident that the state of the art of technology has to be considered to understand the impact of processing. Accordingly, the GDPR mandates to take into account the state of the art in both, Article 32 on the security of processing, and Article 25 on data protection by design and by default (see the “Data Protection by Design and by Default” subsection in the “Main Concepts” section of the General Part of these Guidelines). In security (that is one aspect of data protection), to understand risks, it is crucial to understand the current threat landscape that describes the ease of attack and the availability and efficiency of defensive measures. To minimize the impact of processing on data subjects according to data protection by design, it is crucial to know the available technical possibilities.

The societal context describes the influence that persons and organizations potentially have on the processing activities. This includes the question of who might be interested in using the processed data for other purposes. This includes aspects of how motivated and resourceful[12] potential players are to do so. It is important to note that the context is not limited to external players but also includes internal staff that might have motive to use data for other purposes.

Assessment of necessity and proportionality

Providing further detail to Article 35(7)(b) GDPR, the Working Party breaks down the assessment of necessity and proportionality into several sub-points in two major groups[13]. It is important to note that all these points are concerned with measures envisaged to comply with the GDPR.[14] For easier understanding, these points are classified here as follows:

Points relating to:

  1. Generic obligations from Chapter 2 GDPR “Principles” (see the “Main Principles” section of the General Part of these Guidelines)
  2. Specific obligations from Chapter 3 GDPR “Rights of the data subject” (see the “Data subjects’ rights” section of the General Part of these Guidelines)
  3. Specific obligations from Chapter 4 GDPR “Controller and processor”
  4. Specific obligations from Chapter 5 GDPR “Transfers of personal data to third countries or international organizations” (see the “Transfers of data to third countries” subsection in the “Main tools and actions” section of the General Part of these Guidelines)

These are described in the following in more detail:

1. Principles:

The points providby the Article 29 Working Party in this section closely correspond to the generic principles (a) through (f) of data protection provided in Article 5(1) GDPR with the following differenced:

  • The more concrete Article 6 is used instead to cover lawfulness, instead of 5(1)(a) itself.
  • Article 5(1)(d) on “accuracy” is omitted, likely since the data subject right to rectification covers the same aspects in a more concrete manner.
  • Article 5(1)(f) on security (‘integrity and confidentiality’) is omitted, likely since it is covered later in “management of the risks to the rights and freedoms of data subjects”

The DPIA is now required for each principle (see the “Main Principles” section of the General Part of these Guidelines). , what measures were taken to comply with it. In the following, an incomplete selection of examples for such measures is given:

Measures to demonstrate compliance with “purpose limitation” described in Article 5(1)(b) consist of specifying the explicit purposes of processing. This description has to be precise and concrete. To demonstrate compliance, it should be justified why these purposes are legitimate and that the impact on data subjects has been minimized by keeping the purposes as narrow as necessary.

An additional important aspect of Article 5(1)(b) is that data shall “not [be] further processed in a manner that is incompatible with those purposes”. Since disclosure is considered to be processing (see Article 4(2) GDPR), this means that personal data shall only be disclosed to persons and parties as necessary for and justified by the stated purposes. Measures that show compliance with this requirement include the documentation of who (employees of the controller and third party recipients) needs access to the data and processing and how access rights are managed and updated in practice. This complements the measures to mitigate threats of illegitimate access that are part of the section “management of risks” that is described further down.

Measures to guarantee the lawfulness of processing consist of documentation of the chosen legal basis according to Articles 6(1) and possibly 9(2) GDPR.

Where Article 6(1)(a) “consent” is used as a legal basis, the documentation should include how this consent was collected (e.g., a form or a dialog) together with a justification how the requirement for consent given in Articles 7 and 8 GDPR are fulfilled. In the case where Article 9(2)(a) “explicit consent” is chosen, a justification how the requirements for this special form of consent are met should be added. The best support for this is provided by the Article 29 Working Party in their “Guidelines on Consent”[15].

Where Article 6(1)(f) “legitimate interests pursued by the controller or by a third party” is chosen, it is very important to note that the legal basis states “except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.” To be sure that the interests of data subject do not override the legitimate interest of the controller, an additional “balancing test” (see Balancing test section in Actions and Tools chapter) is required. What such a balancing test is and how to conduct it was described by the Article 29 Working Party in their Opinion WP217[16].

Measures to demonstrate compliance with Article 5(1)(c) “data minimization” are justifications that the collected and processed personal data is adequate, relevant and limited to what is necessary to reach the stated purposes (see the “Data minimization” subsection in the Principles section of the General Part of these Guidelines).

Measures to demonstrate compliance with Article 5(1)(e) “storage limitation” (see the “Storage limitation” subsection in the Principles section of the General Part of these Guidelines). consist of documentation that justifies that the data is stored only as long as necessary for the purposes (and then erased) and that pseudonymization and anonymization that reduce/eliminate the identifiability of data subjects is applied as soon as possible for the purposes (see the “Identification, pseudonimization and anonymization” subsection in the “Main Concepts” section of the General Part of these Guidelines).

While not explicitly included among the point by the Working Party, a desirable additional measure would be the documentation of persons and recipients to whom the data are legitimately disclosed.

2. Rights of the data subject: (see the “Data subjects’ rights” chapter of the General Part of these Guidelines)

The points provided by the Article 29 Working Party in this section take up almost the complete set of articles of Chapter 3 “Rights of the data subject”. This includes Articles 12-14 GDPR that are mostly concerned with transparency, as well as Articles 15 through 21 which are concerned with specific data subject rights.

Measures to demonstrate compliance with the obligations pertaining to Chapter 3 consist of a documentation of the information that is provided to data subjects and the technical or organizational means available to data subjects to exercise these rights.

Somewhat surprisingly, the Working Party did not include Article 22 GDPR among their points, although “automated individual decision-making, including profiling” obviously bears high risks for data subjects. It is therefore recommended to address the compliance with this article anyhow, if applicable. A suitable measure could be to document how data subject can access the “right to obtain human intervention” that is mentioned in Article 22(3).

3. Obligations of the controller and processor:

The points provided by the Article 29 Working Party in this section consist solely of two Articles out of Chapter 4 GDPR “Controller and processor”, namely Articles 28 and 36.

Article 28 is concerned processors. Measures that demonstrate compliance with this article include for example[17] the following:

  • Documentation of the guarantees provided by the processor “to implement appropriate technical and organizational measures in such a manner that processing will meet the requirements of this Regulation” (Article 28(1) GDPR).
  • Measures (such as contractual clauses) that guarantee that “processor [do] not engage another processor without prior specific or general written authorization of the controller.” (Article 28(2) GDPR).
  • Documentation of a “contract or other legal act” that governs the processing by the processors. This includes clauses that guarantee the requirements laid out in Article 28(3)(a) through (h).

Article 36 is concerned with “prior consultation” of the competent supervisory authority if the residual risk after implementing suitable mitigation measures is still high. The measure to demonstrate compliance with this Article is to document such consultation and its outcome.

Beyond the two Articles of Chapter 3 GDPR that were explicitly listed among the points by the Working Party, additional measures are both possible and desirable. Some examples are the following:

  • Measures to demonstrate compliance with Article 25 “data protection by design and by default” can include documentation how data protection was integrated already in the conception and design of the processing activity. This can for example consist in data protection requirements that were stated for a custom development or tender, or an analysis of data protection compliance during a selection process (see the “Data Protection by Design and by Default” subsection in the “Main Concepts” section of the General Part of these Guidelines).
  • Measures to demonstrate compliance with Articles 33 and 34 on notification and communication pertaining to data breaches could consist in the documentation of internal procedures to handles such situations.

4. Transfers of personal data to third countries or international organizations :

In this section, the Article 29 Working Party provides a single point that refers to the whole Chapter 5 of the GDPR. Measures to demonstrate compliance in this section document safeguards in place that protect data subjects in the situation where their data is transferred to areas where the GDPR is not directly enforceable. Among the concrete measures are the documentation that there is an adequacy decision by the Commission in place (Article 45 GDPR), the adherence to legally binding corporate rules (Article 47 GDPR), or the use of other legally binding and enforceable instrument (Article 46 GDPR) (see the “Transfers of data to third countries” subsection in the “Main tools and actions” section of the General Part of these Guidelines)

Management of the risks to the rights and freedoms of data subjects

Article 35(7)(c) mandates the “assessment of the risks to the rights and freedoms of data subjects”. Recital 84 further states that the controller carrying out a DPIA should “evaluate, in particular, the origin, nature, particularity and severity of that risk”. On this basis, the Article 29 Working Party stresses that such assessment needs to be made from the perspective of the data subject and provides the following approach:

  • A list of risks that need to be assessed and
  • a series of steps that constitute such an assessment

A DPIA must thus address these steps for each of the risks.

The Working party lists the following risks:

  1. illegitimate access [to personal data],
  2. undesired modification [of personal data], and
  3. disappearance of data.

Evidently, these risks paraphrase the wording of Article 5(1)(f) on the principle of “integrity and confidentiality”. It is also consistent with “confidentiality, integrity, availability and resilience of processing systems and services” that is stated in Article 32(1)(b) GDPR. It is also possible to see a direct equivalence to the protection goals used in IT security, namely confidentiality, integrity, and availability.

For the assessment of each risk, the Working Party states the following components:

  1. identification of risk sources (in accordance with Recital 90)
  2. identify potential impacts of each risk to the rights and freedoms of natural persons
  3. identify threats that could lead to these risks
  4. estimate the likelihood and severity of the risks (in accordance with Recital 90).

On this basis, considering the estimated likelihood and severity of each risk, appropriate mitigation measures have to be conceived, implemented, and documented in the DPIA (as mandated by Article 35(7)(d) and Recital 90).

Since the principles of “integrity and confidentiality” (see the “Integrity and confidentiality” subsection in the Principles section of the General Part of these Guidelines). as well as the listed threats are typical for IT security, the measures documented here are well known from that discipline. The major difference to security is the estimation of severity or impacts that are evaluated relative to the affected persons rather than the organization responsible for the processing. The fact that only this section is concerned with IT security further illustrates the difference that was already addressed above.

Involvement of interested parties

According to Article 35(2), “[t]he controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment.”

Also, according to Article 35(9), “[w]here appropriate, the controller shall 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 processing operations.”

This section of the DPIA documents that these two requirements were indeed met by the controller. When views of the data subjects or representatives were sought, the documentation should justify why these views should be considered as reasonably representative of the data subjects concerned. When views were not sought, the documentation should clarify why this was not useful or possible.
 

References

1wp248rev.01, ARTICLE 29 DATA PROTECTION WORKING PARTY, Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679, Adopted on 4 April 2017, As last Revised and Adopted on 4 October 2017, https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=611236 (last visited 14/01/2020). ↑

2Endorsement of GDPR WP29 guidelines by the EDPB, https://edpb.europa.eu/news/news/2018/endorsement-gdpr-wp29-guidelines-edpb_en, Brussels, 25 May 2018, Bullet point 6. ↑

3https://edpb.europa.eu/ ↑

4wp248rev.01, page 17, Section III.D.c), 4th paragraph, Highlighting by authors. ↑

5Annex I of wp248rev.01, page 21. ↑

6wp248rev.01, page 17, Section III.D.c), 6th paragraph, Highlighting by authors. ↑

7wp248rev.01, page 17, Section III.D.c), 6th paragraph, Highlighting by authors. ↑

8wp248rev.01, page 22, Annex II, 1st paragraph. ↑

9The criteria are provided in a wording is that of evaluation criterion. In this document, the wording is changed to titles that reflect the structure. For example, “a systematic description of the processing is provided” is changed to “systematic description of the processing”. Also, the single top-level entry corresponding to both, Article 35(7)(c) and (d) is split into two separate entry. ↑

10Adapted from wp248rev.01, page 22, Annex II. ↑

11This is illustrated by the cryptographic technique of p+rivate set intersection (see https://en.wikipedia.org/wiki/Private_set_intersection). ↑

12Resourceful here includes technical capability and economical capacity, as well as the availability of additional information accessible to a player. ↑

13Adapted from wp248rev.01, page 22, Annex II. ↑

14See wp248rev.01, page 22, Annex 2, 1st bullet point under “necessity and proportionality are assessed”. ↑

15wp259rev.01, ARTICLE 29 DATA PROTECTION WORKING PARTY, Guidelines on Consent under Regulation 2016/679, Adopted on 28 November 2017, As last Revised and Adopted on 10 April 2018, https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=623051 (last visited 29/01/2020) ↑

16wp217, ARTICLE 29 DATA PROTECTION WORKING PARTY, Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC, Adopted on 9 April 2014, https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_en.pdf (last visited 29/01/2020). Note that while this opinion refers to the Data Protection Directive much rather than the GDPR, the concepts and methods should equally apply. ↑

17The list of examples is not meant to be exhaustive. ↑

Skip to content