1

Contents
1. Legal framework ....................................................................................................... 3
1.1. GDPR ................................................................................................................. 3
2. When is a DPIA required? ........................................................................................ 6
2.1. Basics ................................................................................................................ 6
2.2. Cases where a DPIA is mandatory .................................................................... 6
2.2.1. Further considerations regarding the need to conduct a DPIA .................... 7
2.2.2. Conducting a DPIA for several similar data processing systems ................. 7
2.2.3. Positive and negative lists for DPIA ............................................................. 8
2.3. Timing of DPIA ................................................................................................... 8
2.4. Review of the DPIA ............................................................................................ 9
2.5. Consultation with data protection authority pursuant Art 36 GDPR .................... 9
3. Who is responsible to conduct a DPIA? .................................................................. 10
3.1. Basis ................................................................................................................ 10
3.2. Participation in the DPIA .................................................................................. 10
4. How to conduct a DPIA ........................................................................................... 11
4.1. Basis ................................................................................................................ 11
4.2. Implementation of a DPIA ................................................................................ 11
4.3. Minimum content of a DPIA.............................................................................. 12
4.4. The DPIA Process............................................................................................ 13
4.5. Inclusion of data subjects or their representatives ........................................... 14
4.6. The report on the implementation of a privacy impact assessment .................. 16
5. Conclusions and practical tips ................................................................................ 18
6. External Sources & WEBLINKS.............................................................................. 19
6.1. Books and Articles ........................................................................................... 19
6.2. Documents of the Article 29 Working Party ...................................................... 19
6.3. Web Links ........................................................................................................ 19

2
 1. Legal framework
1.1. General Data Protection Regulation (GDPR)
Article 35

Data protection impact assessment

1. 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. A single assessment may address a set
of similar processing operations that present similar high risks.

2. The controller shall seek the advice of the data protection officer, where designated,
when carrying out a data protection impact assessment.

3. A data protection impact assessment referred to in paragraph 1 shall in particular be

required in the case of:

(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 person;

(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 10; or

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

4. The supervisory authority shall establish and make public a list of the kind of
processing operations which are subject to the requirement for a data protection impact
assessment pursuant to paragraph 1. The supervisory authority shall communicate
those lists to the Board referred to in Article 68.

5. The supervisory authority may also establish and make public a list of the kind of
processing operations for which no data protection impact assessment is required. The
supervisory authority shall communicate those lists to the Board.

3
6. Prior to the adoption of the lists referred to in paragraphs 4 and 5, the competent
supervisory authority shall apply the consistency mechanism referred to in Article 63
where such lists involve processing activities which are related to the offering of goods
or services to data subjects or to the monitoring of their behaviour in several Member
States or may substantially affect the free movement of personal data within the Union.

7. The assessment 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; and

(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.

8. Compliance with approved codes of conduct referred to in Article 40 by the relevant

controllers or processors shall be taken into due account in assessing the impact of the
processing operations performed by such controllers or processors, in particular for the
purposes of a data protection impact assessment.

9. Where 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.

10. Where processing pursuant to point (c) or (e) of Article 6(1) has a legal basis in
Union law or in the law of the Member State to which the controller is subject, that law
regulates the specific processing operation or set of operations in question, and a data
protection impact assessment has already been carried out as part of a general impact
assessment in the context of the adoption of that legal basis, paragraphs 1 to 7 shall not
apply unless Member States deem it to be necessary to carry out such an assessment
prior to processing activities.

4
11. 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 operations.

Art 35 GDPR is closely linked to Art 24, 25, and 32. The main difference between Art 32
and Art 35 is that Art 32 (Security of data processing) is targeting risks linked to
detrimental events such as attacks, while a Data Protection Impact Assessment (DPIA)
based on Art 35 is focusing primarily on risks, emerging from regular data
processing.

DPIA is an important tool for the implementation of data protection by technological

means (data protection by design) as laid down in Art 25, Sec 1. Both are based on the
principle of precaution, i.e. to identify risks already in the early design phases to
consider relevant countermeasures before any data processing systems are
implemented and become operational.

DPIA is a tool to identify and analyse such risks. In cases where a DPIA is not
mandatory, an analysis of related risks is nonetheless required, to adequately
implement Art 25 and Art 32. Both regulation explicitly refer to rights and freedoms of
natural persons. The depth and required documentation of the risk analysis to be
conducted depends on the complexity and the risk proneness of the processing. We
recommend providing a documentation of the risk analysis in writing.

The implementation of the data protection by design principle reaches beyond the risks
identified in advance in a state-of-the-art risk analysis and comprises decisions made at
a later stage ad hoc by system developers (privacy engineering) when implementing
principles of data minimization.

5
2. When is a DPIA1 required?
2.1. Basics
A DPIA has to be performed prior to processing of personal data carrying a high risk for
rights and freedoms of natural persons.

In principle a DPIA has to be conducted for any form of data processing, unless it can
be determined a priori that rights and freedoms of natural persons are not affected by a
particular data processing operation.

For which type of data processing such a risk has to be assumed is e.g. laid down in
points listed in Art 35, Para 3 or in recital 91. The emphasis here is on the use of so-
called new technologies, a vague legal concept, introduced in the GDPR with regard to
DPIA. A risk assessment not only has to consider existing risk constellations, but also
the probability of future events, to be identified in a prognostic assessment. The results
of the assessment have to be documented.

Article 35 (1), last sentence, in conjunction with recital 92, provides an important point of
view for assessing the need for a DPIA: "Under certain circumstances, it may be
reasonable and economically appropriate not to apply a privacy impact assessment
solely to a particular project but to broaden their thematic scope. For example, when
public authorities or other public bodies want to create a joint application or processing
platform, or when multiple stakeholders want to implement a joint application or
processing environment for an entire business sector, market segment or widespread
horizontal activity."

2.2. Cases where a DPIA is mandatory

Art 35 Sec 3 lists the mandatory cases for a DPIA:

(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 person;

1
The following text ist strongly based on the Publication in German Language of Kastelitz, M.,
Hötzendorfer, W., Riedl, R., Ausgewählte Fragen der Durchführung einer Datenschutz-
Folgenabschätzung gemäß Art 35 DSGVO, Jahrbuch Datenschutzrecht 2017, 113ff.

6
 (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 10; or
(c) a systematic monitoring of a publicly accessible area on a large scale.

2.2.1. Further considerations regarding the need to conduct a DPIA

Recital 91 lists further cases requiring a DPIA:

Processing operations

(a) which potentially involve a large number of people, and/or a high level of risk and/or
using a large-scale technology in line with the state-of-the-art;

b) which involve a high level of risk and make it difficult for data subjects to exercise
their rights;

(c) where personal data are processed for taking decisions regarding specific natural
persons following any systematic and extensive evaluation of personal aspects relating
to natural persons based on profiling those data or following the processing of special
categories of personal data, biometric data, or data on criminal convictions and offences
or related security measures;

(d) which involve a high level of risk because they prevent the persons concerned from
exercising a right or use of a service or performance of a contract;

(e) which pose a high risk because they are systematically large scale.

2.2.2. Conducting a DPIA for several similar data processing systems

Art 35 Sec 1 states that a single DPIA can be performed for processing systems with
similar risk level. When assessing such a similarity the overall purpose of the data
processing in each individual case has to be considered. Recital 92 states that under
consideration of economic costs DPIA can have a broader thematic scope, giving
members in a specific industry sector or market segment the opportunity to cover
applications or processing environments or widely shared horizontal practices with a
single DPIA.

7
2.2.3. Positive and negative lists for DPIA
It can be assumed that regulatory agencies will publish positive/negative lists to guide
the decision whether a DPIA is required in a specific case. These lists will define types
of processing requiring a DPIA (“positive lists”) and cases where a DPIA is not required
(“negative lists”). Both lists have to be forwarded by the national regulatory bodies to the
European data protection board as part of the regime of regulatory coherence (Art 35
Sec 4) to provide for better harmonisation throughout the EU.

It has to be noted that Art 29 Working Party (WP29) recommends to conduct a DPIA
also in cases, where it seems unclear whether a DPIA is required to help meeting the
legal requirements for proper data protection.

2.3. Timing of DPIA

Timing and method applied for a DPIA have to be determined by the controller. Legal
sanctions are foreseen for failing to perform a DPIA. It is recommended to start
preparation for DPIA at the earliest possible stage of a project. Each department or
relevant staff members involved in data processing have to initiate the relevant
processes. Training is recommended to raise awareness about the need for DPIA within
the organisation.

Considering measures for risk minimisation at an early stage of any project, involving
data processing can help to keep bureaucratic efforts at a reasonably low level.

A DPIA can guide the search for adequate solutions and can help to implement – as
mentioned above – data protection requirements effectively and in due time through
proper technological solutions (data protection by design) and the choice of default
settings considering data protection.

Provided comprehensive and intensive preparations a DPIA will guide an envisaged

project from the stage of early ideas to its final operational implementation and
demonstrates the iterative nature of the DPIA process.

Whether a DPIA was required for processing activities that have been operative prior to
the general applicability of GDPR (May 25, 2018) is an open question. Taking the literal
wording (“prior to”), a DPIA is required only for processes becoming operative after May
25, 2018 or that undergo significant changes after this date.

8
Since in these cases the data processing system is already operative, a pre-check is
not possible. Furthermore, these operations do not exist in an unregulated space
(assuming all legal regulations and reporting requirements of the previous legal
framework have been considered).

Nonetheless WP29 strongly recommends to perform DPIA for processing systems

already in use to avoid legal uncertainties and even legal sanctions.

2.4. Review of the DPIA

After a DPIA has been performed the implementation of the measures suggested has to
be reviewed, if deemed necessary a review of the data processing itself may be
necessary to identify any new elements of the risks related to the processing of data.
Recital 89 states that a review of the DPIA may be needed in due time after a first
assessment. When conducting a DPIA, a time frame for routine checks or future
renewals should be part of the documentation.

Technological developments, new legal regulation and changes in the processing

routines have to be considered. Should a risk materialise, a new DPIA has to be
performed.

The duty to perform a DPIA is part of the data controller’s obligation, documenting their
accountability. Documentation and report should not only provide information about the
DPIA conducted, but also list any reasons for not preforming a full DPIA or for
terminating a DPIA after having identified high risks for data subjects.

2.5. Consultation with data protection authority pursuant Art 36 GDPR

The data controller has to consult with the Data Protection Authority (DPA) should the
DPIA reveal major risks and should the controller not know how to take any remedial
measures to mitigate such risks. The DPA has to respond to this request for
consultation within fourteen weeks. For complex and innovative projects, it is
recommended to start a DPIA at the earliest possible stage so any recommendation
from the DPA can be considered in the implementation of the project plan.

9
3. Who is responsible to conduct a DPIA?
3.1. Basis
The responsibility of conducting a DPIA is with the controller – in this case the local
public authority. Initially the Commission’s proposal assigned responsibility for the DPIA
to the data processor acting by the controller’s order. In contrast, Recital 95 merely
claims for the processor to assist the controller, where necessary and upon request, in
ensuring compliance with the obligations deriving from the data protection impact
assessment.

In practice, it will therefore be appropriate to contractually require a processor, if

available and already selected, to the involvement and active support throughout the
DPIA process. This is also beyond Article 28 (3) (f), which provides that the contract on
the processing (or other legal instrument) should provide for the processor, taking into
account the nature of the processing and the information at his disposal, to ensure
compliance with the obligations Articles 32 to 36. Often, only the processor will have the
necessary information to assess the respective aspects of processing. In doing so, the
risk of disclosure of trade and business secrets must be taken into account. Again, a
corresponding contractual regulation is recommended. If processing of data by joint
controllers is foreseen, the DPIA in the sense of Art. 35, para. 1, subpara. 2 may also be
carried out by one of the controllers – which does not release other controllers of the
responsibilities.

3.2. Participation in the DPIA

The DPIA should be organised as a project and as such should be equipped with the
necessary material and human resources by a corresponding high level of
management. When compiling the project team, particular attention must be paid to the
complexity of the project, the required specialist knowledge and the required knowledge
about the specific project and its environment. In practice, a team of lawyers, IT staff,
CISO, data protection officer, the department that has requested processing ("data
owner"), etc. can be put together.

Particular attention is paid to ensuring the avoidance of conflicts of interest. Thus, those
who deal with data processing in the future are not to be considered as independent,
but on the other hand can provide valuable input to the design of the privacy impact
assessment. Implementation can be done by an internal team as well as by external
third parties. Ideally, an independent body should be involved.

10
The controller must seek the advice of the Data Protection Officer. Pursuant to Article
39 (1) (c), advice on the DPIA and the monitoring of its implementation are among the
statutory duties of the DPO, but only on request and not in a leading position.

Therefore, there is an obligation on the controller to obtain the advice of the Data
Protection Officer. At what time and to which degree the data protection officer needs to
be involved in the process is the controller’s decision. A subsequent review of the final
report would also be sufficient. In practice, the timely involvement of the data protection
officer, not least due to his expertise, is strongly recommended.

Depending on the organization of the controller, it is advisable to have the DPIA

approved on management level or the corresponding authorised body.

4. How to conduct a DPIA

4.1. Basis
It has to be pointed out that the GDPR does not prescribe any specific form or concrete
method of designing a data protection impact assessment which is currently being
intensively discussed at national and European level. WP29 states that different design
options can be used to support the implementation of the provisions of the GDPR and
refers to examples of existing (generic or sector-specific) DPIA process models in
Annex 1.2

4.2. Implementation of a DPIA

The controller is therefore basically free in how to carry out the DPIA process and can
adapt it to the existing internal procedures, provided that the local public authoritiy takes
into account the four requirements contained in Article 35 (7) of the GDPR (a) to (d) as
minimum requirements of a DPIA, which the Article 29 Working Party describes in more
detail and takes into account additionally the point "interested parties are involved" (see
Art 35 para 2) and the view of the data subjects [see Art 35 para 9]):

2 WP29, WP 248, 15: Different methodologies (see Annex 1 for examples of data protection and
privacy impact assessment methodologies) could be used to assist in the implementation of the basic
requirements set out in the GDPR (Annex 1).

11
(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; and

(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.

4.3. Minimum content of a DPIA

Article 35 (7) (a) to (d) GDPR in conjunction with recitals 84 and 90 thus requires as
minimum:

(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; and

(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.

Letters (c) and (d) are manifestations of the GDPR’s so-called "risk-based approach",
which are relevant not only in the implementation of a DPIA but also in the context of
Articles 24, 25 and 32 GDPR. In other words, the DPIA is a specific example of the risk-

12
based approach to data processing, for data, in short, that is expected to entail a high
risk to the rights and freedoms of natural persons and calls for more extensive risk
assessment and treatment. In principle, however, any other admissibility check on data

processing is also inherent in such a risk assessment, including adequate technical and
organisational measures that minimize risk, before they are implemented (see only Art.
24 (1) GDPR).

4.4. The DPIA Process

The DPIA should be seen as a process (not just a report) that should be started as soon
as possible to influence the design of the subject ("project"). As a result, an impact
assessment also differs from an audit that evaluates a project ex-post and usually
comes too late to "buffer" the data protection needs that DPIA should produce.

There are now numerous proposals for the implementation of a DPIA process, which in
one way or another are similar to the results of the PIAF study (2012)3, which mapped
the Privacy Impact Assessment methodologies in seven countries (including Derivation
of "Best Practice" recommendations and core elements of a Privacy Impact Assessment
process) for the EU Commission, among others. The following core elements were
identified:

1. Determining whether a PIA is necessary (threshold analysis).

2. Identifying the PIA team and setting terms of reference.
3. Description of the proposed project [and identification of stakeholders].
4. Analysis of the information flows and other privacy impacts.
5. Consultation with stakeholders.
6. Risks management [Identification of risks and possible solutions].
7. Legal compliance check.
8. Formulation of recommendations.
9. Preparation and publication of the report [e.g., on the organisation’s website].
10. Implementation of recommendations.
11. External [Third-party] review and/or audit.
12. Revisiting PIA if the project in question changes [Updating the PIA if there are
changes in the project].

3
De Hert/Kloza/Wright (Hrsg), PIAF, Recommendations for a privacy impact assessment framework for the European Union,
Deliverable D3 (2012), http://piafproject.eu/ref/PIAF_D3_final.pdf; more available at http://piafproject.eu/Deliverables.html.

13
The DPIA model for smart grids and smart metering systems, which is explicitly referred
to in Recommendation 2014/724/EU of the European Commission, provides for the
following steps:4

1. Step 1 Pre-assessment and criteria determining the need to conduct a DPIA.

2. Step 2 Initiation.
3. Step 3 Identification, characterisation and description of smart grid systems /
applications processing personal data.
4. Step 4 Identification of relevant risks.
5. Step 5 Data protection risk assessment.
6. Step 6 Identification and recommendation of controls and residual risks.
7. Step 7 Documentation and drafting of the DPIA Report.
8. Step 8 Review and maintenance.

The new ISO / IEC 29134 standard provides guidelines for a process for conducting
Privacy Impact Assessments and for the structure and content of a PIA report. The
process is divided into the following four sub-processes:

1. Threshold analysis.
2. Preparation of the PIA.
3. Perform the PIA.
4. Follow-up of the PIA.

In which and how many sections a DPIA process is divided is rather a matter of taste,
further suggestions range for example from three or four phases over six to seven
stages. Rather, what is important is the comprehensible structure and process of the
process, which in particular takes into account the requirements of Art. 35 (7) GDPR
and the recommendations of the Article 29 Working Party.

4.5. Inclusion of data subjects or their representatives

Pursuant to Article 35 (9), where appropriate, the controller shall seek the views of the
data subjects or their representatives on the intended processing, without prejudice to
the protection of commercial or public interest or the safety of the processing

4 Commission Recommendation 2014/724/EU of 10 October 2014 on the Data Protection Impact

Assessment Template for Smart Grid and Smart Metering Systems, ABl L 2014/300, 63.

14
operations. The inclusion of the word "where appropriate" in the context of the trialogue
negotiations makes it unclear under what circumstances the position of the person
concerned or their

representative should be obtained in concrete terms and in which cases (permissible)

this can be waived.

The way in which the opinion is requested is context-sensitive and the WP29
recognises different ways of doing so, such as conducting a study (internal or external),
formal interviews with staff representatives or trade unions and submitting a
questionnaire to future customers of the controller. From the wording itself, it is only
possible to derive the viewpoint (in the original version of the commission states "of
opinion"), but not the obligation to take account or even a (new) consent requirement
(beyond the Labour Constitution Act (ArbVG)) of the works council as representative of
the persons concerned. Nevertheless, the controller will have to deal with the views of
the data subjects or their representatives and will have to address them in the impact
assessment. Whether consumer protection associations can also be subsumed under
the term "representative" is controversial in the literature.5

In any event, the obligation to consult expressis verbis is without prejudice to the
protection of commercial or public interests or the safety of processing operations.
Therefore, the controller may restrict or refuse in extremis the obligation to provide
information on the intended processing under Article 35 (9) to the persons or
representatives concerned (which, in the latter case, will lead to the fact that a priori
involvement in the sense of Article 35 (9) will not be possible, since the existence of
sufficient information is a sine qua non for the opinion of the persons concerned or their
representatives).

For the implementation of the Data Protection Impact Assessment, it is recommended

to document in the report for evidence purposes why no or only a limited content point
of view has been obtained or the opinion obtained has not or only partially been taken
into account.

5 Martini in Paal/Pauly (Hrsg), Datenschutz-Grundverordnung (2016) Art 35 Rz 60; dagegen (mangels

rechtlicher Verbundenheit) Laue/Nink/Kremer, Das neue Datenschutzrecht in der betrieblichen
Praxis (2016) 245 Rz 99.

15
4.6. The report on the implementation of a privacy impact assessment
It should be noted at this point that the DPIA report is not the actual goal of a DPIA, but
a "means to an end" to document the process (internal and external). The reporting
should not be underestimated – it documents the implementation and the results, and a
mere

"PR DPIA report" is to be avoided for reasons of compliance. The report can also serve
as a guide and checklist in the conduct of the DPIA.

Art. 35 GDPR contains, somewhat surprisingly, no explicit requirement to prepare a

report on the conduct of a DPIA. However, the fact that there is a duty of documentation
for the controller is undoubted and follows implicitly from Article 35 (7) GDPR, and also
from Article 5 (2) GDPR (accountability) in conjunction with Article 24 (1) GDPR and
Article 36 (3) (e) (which requires the supervisor to provide "the data protection impact
assessment referred to in Article 35"). Also, the review required by Article 35 (11) to
assess whether processing is carried out in accordance with the DPIA requires that the
results of the impact assessment be maintained. In addition, reporting on PIAs carried
out is in line with global good practice in this area (see section IV.1 below), which is
evidently based on the DPIA provided for in Art. 35 GDPR.

Accompanying the DPIA process with documentation in the sense of a "living

document" is recommended, beginning with the documentation of the threshold value
analysis, in case of no necessity of carrying out a DPIA has been found. Even if this
analysis shows that a DPIA is not required and the process is aborted, the controller will
be responsible for its accountability and evidence. This written documentation may be
submitted to the supervisor in any future process and will track internal considerations
and assessments.

In terms of content, the DPIA report essentially sets out the procedure (including
presentation of the facts in the sense of a systematic description of the entire subject of
the test - "target of evaluation") and the results of the DPIA process. As in the case of
the DPIA process itself, the GDPR does not provide for any specific rules for the design
of a DPIA report. However, as minimum content, the criteria listed by the Article 29 Data
Protection Working Party in Annex 2 of WP 248, which are essentially based on Article
35 (7), are predetermined. ISO / IEC 29134 recommends the following contents of the
report on a Privacy Impact Assessment, with a focus on risk assessment:

1. Relevant privacy requirements.

2. Description of the scope.

16
 3. Description of the risk criteria used.
4. Participants in the implementation.
5. Consulted stakeholders.

This is also supported by Recital 90, which states, inter alia, as follows: "[t]hat 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"
6
In the very detailed PIAF study, the minimum content of a PIA report is as follows:

1. Introduction and background information including who undertook the PIA, her
contact details and where to find further information and other sources of help
and advice.
2. A description of the project, of the information flows and of the impacts on
privacy.
3. Results of the consultation of stakeholders.
4. Description of the risk assessment and risk mitigation phases, including the
alternatives considered.
5. Analysis of legal compliance.
6. Recommendations.
7. Annexes, if necessary.

If the report or a final draft is available, the question may arise as to what has to happen
to the person responsible (internally), above all whether and by whom this is to be
"approved" - a practically relevant point which remains unmentioned in the GDPR. The
ICO explicitly stipulates the following in its Code of Practice: "[o]btain appropriate signoff
within the organisation". Since the person responsible has to carry out the DPIA, it
follows that appropriately authorized representatives of the responsible person are
involved in the DPIA and also have the ultimate responsibility. The management level
will usually have final decision-making authority over the subject and nature of the DPIA
project. As a minimum variant, the project management or data protection officer should
report to the "highest management level", as provided for in Art. 38 (3) GDPR.

6 De Hert/Kloza/Wright (Hrsg), PIAF, Recommendations for a privacy impact assessment framework

for the European Union, Deliverable D3 (2012) 31, http://piafproject.eu/ref/PIAF_D3_final.pdf.

17
The GDPR has no obligation to publish the DPIA, but WP29 recommends its
publication (at least in part) in order to increase confidence in data processing and to
promote transparency. In particular, publication is encouraged in cases where part of
the public will be affected by the (planned) processing.

5. Conclusions and practical tips








7
ICO, Big data, artificial intelligence, machine learning and data protection (2017), 99 f,
https://ico.org.uk/media/for-organisations/documents/2013559/big-data-ai-ml-and-data-protection.pdf.

18
6. External Sources & WEBLINKS
6.1. Books and Articles
 Kastelitz, M., Hötzendorfer, W., Riedl, R., Ausgewählte Fragen der
Durchführung einer Datenschutz-Folgenabschätzung gemäß Art 35 DSGVO,
Jahrbuch Datenschutzrecht 2017, 113ff.
 De Hert, Paul/Kloza, Dariusz/Wright, David, Recommendations for a privacy
impact assessment framework for the European Union
http://www.piafproject.eu/ref/PIAF_D3_final.pdf
 Wright, David/De Hert, Paul (Ed.), Privacy Impact Assessment, Springer
Science & Business Media, Dordrecht, Heidelberg, London, New York 2012
 De Hert/Kloza/Wright (Ed.), PIAF, Recommendations for a privacy impact
assessment framework for the European Union, Deliverable D3 (2012),
http://piafproject.eu/ref/PIAF_D3_final.pdf; more available at
http://piafproject.eu/Deliverables.html.
 Martini in Paal/Pauly (Ed.), Datenschutz-Grundverordnung (2016) Art 35 Rz 60;
dagegen (mangels rechtlicher Verbundenheit) Laue/Nink/Kremer, Das neue
Datenschutzrecht in der betrieblichen Praxis (2016) 245 Rz 99.

6.2. Documents of the Article 29 Working Party

 Artikel-29-Working Party, WP 248, April 4, 2017: 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
http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
 WP 248, as last Revised and adopted on 4 October 2017 (rev.01): 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
https://www.dsb.gv.at/documents/22758/112500/Guidelines_on_Data_Protection
_Impact_Assessment_(DPIA).pdf/ed5daa8c-d388-43a6-9842-629b8175a99c

6.3. Web Links

 Brussels Laboratory for Data Protection and Privacy Impact Assessments
http://www.vub.ac.be/LSTS/dpialab/
 ICO, Big data, artificial intelligence, machine learning and data protection (2017),
99 f, https://ico.org.uk/media/for-organisations/documents/2013559/big-data-ai-
ml-and-data-protection.pdf.

19