DPO Handbook The DPO Tasks

The DPO Handbook
Guidance for data protection officers in the public and quasi public
sectors on how to ensure compliance with the European Union
General Data Protection Regulation
(Regulation (EU) 2016/679)
Elaborated for the EU funded “T4DATA” programme

(Grant Agreement number: 769100 — T4DATA — REC DATA 2016/REC DATA 2016 01)
by
Douwe Korff
Emeritus Professor of International Law, London Metropolitan University
Associate, Oxford Martin School, University of Oxford
&
Marie Georges
Independent international data protection expert
(ex CNIL, EU, Council of Europe, etc.)
Members of the Fundamental Rights Experts Europe (FREE) Group
Drawing on major contributions by the Italian Data Protection Authority

& the project partners
(As approved by the Commission,July 2019)

Douwe Korff& Marie Georges
The DPO Handbook
CONTENTS
Page:
Introduction
PART ONE – The origins and meaning of data protection
1.1 Confidentiality, privacy/private life and data protection: different but
but complementary concepts in the age of digitalisation
1.1.1 Confidentiality and privacy/private life
1.1.2 “Data protection”
1.2 The first data protection laws, principles and international instruments
1.2.1 The first data protection laws
1.2.2 The basic principles
1.2.3 The 1981 Council of Europe Data Protection Convention and its Additional Protocol
1.3 European data protection law in the 1990s and early 2000s
1.3.1 Data protection in the European Community
1.3.2 The main 1995 EC Data protection Directive
1.3.3 The 1997 Telecommunications Data Protection Directive, the 2002 EC e Privacy Direct
ive and the 2009 amendments to the e Privacy Directive 2002 EC e Privacy Directive
1.3.4 Third Pillar data protection instruments
1.3.5 Data protection instruments in the Second Pillar
1.3.6 Data protection rules for the EU institutions
1.4 Data protection law for the future
1.4.1 The EU General Data Protection Regulation of 2016
1.4.2 The proposed EU e Privacy Regulation
1.4.3 The Law Enforcement Data Protection Directive of 2016
1.4.4 Data protection in relation to the Common Foreign and Security Policy
1.4.5 New data protection rules for the EU institutions
1.4.6 Transfers of personal data between the different regimes
1.4.7 The “Modernised” Council of Europe Data Protection Convention of 2018
PART TWO – The General Data Protection Regulation
2.1 Introduction
2.2 Status and approach of the GDPR: direct applicability with
“specification” clauses
2.3 The accountability principle
2.3.1 The new duty to be able to demonstrate compliance
2.3.2 Means of demonstrating compliance
2.3.3 Evidentiary value of the various means of demonstrating compliance
2.4 The Data Protection Officer
2.4.1 Background
2.4.2 The duty to appoint a Data Protection Officer
2.4.3 Qualifications, qualities and position of the DPO
2.4.4 Functions and tasks of the DPO (Overview)
Contents continued overleaf
Contents continued:
4
(CC)
Douwe Korff & Marie Georges/Final Text as approved – 190723
The DPO Handbook
PART THREE – Practical guidance on the tasks of the DPO or that

will in practice involve the DPO (“The DPO Tasks”)
Preliminary task:
Scoping the controller’s environment
Organisational functions:
Task 1: Creating a register of personal data processing operations
Attachment: Sample format of a detailed personal data processing record
Task 2: Reviewing the personal data processing operations
Task 3: Assessing the risks posed by the personal data processing operations
Task 4: Dealing with operations that are likely to result in a “high risk”: carrying
out a Data Protection Impact Assessment (DPIA)
Monitoring of compliance functions:
Task 5: Repeating Tasks 1 – 3 (and 4) on an ongoing basis
Task 6: Dealing with personal data breaches
Attachment: Examples of personal data breaches and who to notify
Task 7: Investigation task (including handling of internal complaints)
Advisory functions:
Task 8: Advisory task – general
Task 9: Supporting and promoting “Data Protection by Design & Default”
Task 10: Advise on and monitoring of compliance with data protection policies,
joint controller , controller controller and controller processor
contracts, Binding Corporate Rules and data transfer clauses
Task 11: Involvement in codes of conduct and certifications
Cooperation with and consultation of the DPA:
Task 12: Cooperation with the DPA
Handling data subject requests:
Task 13: Handling data subject requests
Information and raising awareness:
Task 14: Information and awareness raising tasks
Task 15: Planning and reviewing the DPO’s activities
o–O–o
5
(CC)
The DPO Handbook
PART THREE
Practical guidance on the tasks of the DPO
or that will in practice involve the DPO
(“The DPO Tasks”)
This part of the handbook seeks to provide practical guidance on thetasks of the DPO, or
that will in practice involve the DPO, already listed in section 2.5.4, above, and again set
out below. For the sake of brevity, we will from time to time refer to them as “The DPO
Tasks”. As noted in that section, the fifteen tasks are derived from the list of tasks set out in
broad terms in Article 39 GDPR, grouped under the seven functions of the DPO, identified
by the EDPS. In the various sections discussing the task, we provide examples illustrating
them, relating to actual practice.
The DPO’s tasks:
Preliminary task:
Scoping the controller’s environment
Organisational functions:
Task 1: Creating a register of personal data processing operations
Task 2: Reviewing the personal data processing operations
Task 3: Assessing the risks posed by the personal data processing operations
Task 4: Dealing with operations that are likely to result in a “high risk”:
carrying out a Data Protection Impact Assessment (DPIA)
Monitoring of compliance functions:
Task 5: Repeating Tasks 1 – 3 (and 4) on an ongoing basis
Task 6: Dealing with personal data breaches
Task 7: Investigation task (including handling of internal complaints)
Advisory functions:
Task 8: Advisory task – general
Task 9: Supporting and promoting “Data Protection by Design & Default”
Task 10: Advise on and monitoring of compliance with data protection policies,
joint controller , controller controller and controller processor
contracts, Binding Corporate Rules and data transfer clauses
Task 11: Involvement in codes of conduct and certifications
Cooperation with and consultation of the DPA:
Task 12: Cooperation with the DPA
Handling data subject requests:
Task 13: Handling data subject requests
Information and raising awareness:
Task 14: Information and awareness raising tasks
Task 15: Planning and reviewing the DPO’s activities
144
(CC)
The DPO Handbook
Preliminary task:
Preliminary task of the DPO: scoping the controller’s environment &
mapping the organisation’s processing activities in broad terms
A DPO can only carry out her tasks in relation to her employer if she is fully cognisant of (i)
the internal distribution and allocation of tasks and responsibilities in relation to (or which
may involve) any processing of personal data; (ii) the external links and arrangements of
that organisation with other organisations; and (iii) the legalframework(s) for those.
Prior to undertaking her main other tasks – except for the carrying out of the initial
inventory (register) of personal data processing operations, listed first under the next
heading (Task 1), which can be done in parallel – the DPO must therefore map those internal
and external links and lines of responsibility in relation to all and every personal data
processing operation, and put those in the wider context of her organisation’s role and
aims, and thoroughly familiarise herself with the relevant rules.
To clarify the internal structures and roles, the DPO must first of all obtain and study the
organogram of her organisation, which management should be able to supply her with.
EXAMPLE: Organogram of a hospital
Source: Principles of Health Science, https://www.youtube.com/watch?v=FpQEwbAV3Qw
However, organograms will usually only identify the relevant units and departments in the
most general of terms: “human resources”, “finance and accounts”, “legal”, “customer
management”, etc. (with many public bodies adopting the terminology of private entities,
e.g., by referring to welfare claimants as “customers” of the welfare office). They are a
useful starting point, but little more than that. In in depth discussions with senior
management, including the organisation’s legal and ICT officer(s) and, where appropriate,
regional or national offices, the DPO should clarify in more detail what exactly the different
units and departments are responsible for, including in particular for what purposes each of
the units and departments needs, and actually processes, personal data; under what
architecture of internal and external technologies this is done; and whether this involves
any external technological services or means (including cloud computing). This is where the
preliminary scoping overlaps with the carrying out of the inventory of personal data
processing operations in Task 1 – but at the preliminary stage, the relevant personal data
145
(CC)
The DPO Handbook
processing operations need only be identified in broad terms, with reference to the purpose
for each such operation, and the technologies used. Moreover, the DPO should at this
preliminary phase also already obtain an initial idea of what exact tasks and responsibilities
each unit or department has in respect of each personal data operation – i.e., she should
identify who is the “business owner” of each operation (to the use the EDPS’s terminology).
EXAMPLES:302
The Spanish data protection authority, the AEDP, list the following as examples of official
(statutorily required) personal data registers maintained by local authorities:
Population register
Register of people liable to pay local taxes
Register of recipients of benefits (e.g., housing benefit or disability benefit)
Register of clients of social services (e.g., child welfare)
Registers of imposition of fines (e.g., parking fines)
Register of permits and licences issued (e.g., to run a bar)
Register of local police units and officers
Register of people signed up with local authorities’ employment bureaux;
Register of children in local education
Register of people issued with official documents (e.g., births, marriages, deaths)
Register of people buried in local cemeteries
Register of users of libraries run by the local authorities
Register of people who have signed up to receive notifications about cultural events
As well of course as:
Accounts
Human resources
Etcetera
The data protection authority provides the following examples of laws or regulations
underpinning the processing of personal data in relation to some of the personal data
registers maintained by Spanish local authorities, given above:303
Register: Underpinning law/regulations:
Population register Law on local population registers
Register of people liable to pay local taxes Law on local haciendas
Human resources data Regulations covering this activity
In some circumstances, there may be other legal bases for the processing, e.g.:
Register: Other legal bases:
Register of people signed up to cultural events Consent & local regulation
Register of users of local authorities’ libraries Contract & local regulation
302
Based on: Protección de Datos y Administración Local (Data Protection and Local Administration) a
sectoral guide issued by the Spanish data protection authority, AEPD, 2017, p. 8 (our translation and edit),
available at:
https://www.aepd.es/media/guias/guia proteccion datos administracion local.pdf
303
AEPD, Sectoral Guide on Data Protection and Local Administration (previous footnote), p. 11.
146
(CC)
The DPO Handbook
In addition, it is important that at this stage the DPO (with the help of IT and security staff)
also thoroughly familiarises herself with the technical ICT systems, architecture and
policies of her organisation: the computers (or where they still are used, the manual filing
systems) used and whether these include portable and/or mobile devices (and/or personal
“own devices” of relevant staff – for which a “Bring Your Own Device [BYOD] policy has to
be [put] in place); whether PCs or devices are used online or only offline, on site or also off
site; what security software and encryption is used, and whether it is fully up to date; what
the external links and facilities are (including the use of cloud servers, especially if they are
based outside the EU/EEA, e.g., in the USA – in which case the relevant data transfer
arrangements and contracts need to be checked); whether any of the processing is done by
processors (in which case the contracts with them will need to be reviewed);304 what the
physical security measures are (doors, rooms, network and PC passwords, etc.); whether
security policies and training is in place; etc., etc. At this preliminary stage those many issues
need not all be addressed and resolved – but they should at least be noted, mapped and
recorded.
Next, the DPO should try to clarify all the external links that her organisation has to other
organisations. Those generally come in two types: (a) the (sister/mother/daughter)
organisations that the DPO’s organisation has formal links with, within what will (in the
public sector) usually be an overall hierarchical framework. A local authority may be
formally under the immediate jurisdiction of a regional body, which in turn is under the
control or supervision of a provincial or federal state body, that at the highest level fits
within a wider country wide public agency, under a national ministry. However, there will be
major differences in the arrangements from country to country, or even within a country,
including as concerns the relative autonomy that the various bodies have, also in relation to
the establishment and management of their personal data processing operations – this is
exactly why the DPO should thoroughly familiarise herself with the particular arrangements
for her particular organisation.
The framework for all the relevant public bodies belonging to a certain hierarchy will be
largely defined in formal law, at a range of levels: constitution, statute law, statutory
instruments (secondary, binding legislation), ministerial ordnances and instructions, as well
as in possible non binding or non statutorily underpinned administrative arrangements,
304
The Spanish data protection authority, AEPD, in a contribution to this handbook, gives as examples of
processing operations that are often outsourced by local authorities (i.e., in which, in data protection terms,
the processing is done by a processor):
• The preparation of the staff payrolls [continues overleaf]
• The destruction of documentation or media
• The control of video surveillance cameras
• Tax collection management
• Maintenance of computer equipment
• Data processing of the Municipal Population Register:
• Data processing of municipal taxes:
• Processing of human resources data: applicable to public service regulations.
• The subscription through a service offered by a City Council on its website to receive communications related
to cultural activities.
• Enrolment in a job bank.
(The AEDP also notes cloud computing, as already noted in the text.)
147
(CC)
The DPO Handbook
agreements,305 guidance and policy statements, etc. The processing of personal data by the
DPO’s organisation may also be covered by a code of conduct, of which there are various
types. Again, the DPO should acquire as full and detailed an understanding of those rules
and arrangements and codes – and of the processes through which they are adopted,
applied and reviewed and amended – as possible, again if needs be with the help of the
legal officer(s) of her organisation (and/or by attending courses on the relevant issues if she
is not fully cognisant of these issues when taking up her position).
There will also be other DPOs in the other organisations belonging to the relevant hierarchy
– and it will be crucial for our” DPO to become fully engaged with them, in a DPO network.
Where there is as yet no such network, the DPO should work towards its creation. All the
DPOs should of course establish close and good links with the national data protection
authority (DPA), including any senior staff members within the DPA with specific
responsibilities in relation to public authorities/the kind of public authority to which the
DPO’s organisation belongs.
The arrangements made by the French data protection authority, the CNIL, for a national
network of DPOs, with a dedicated “extranet”, is a good example of a DPA supporting such
networking and interactions.306
Then there are links to external organisations that are outside of the DPO’s organisation’s
hierarchy. Those can include other public authorities in a different hierarchy – for instance,
there can be links between educational establishments and welfare institutions, or the
police, or between educational authorities in one country and similar organisations in
another. Again, there will be (or ought to be) laws covering such links with such bodies, or
other formal, binding arrangements and agreements (such as data sharing arrangements
and agreements between educational institutions and welfare organisations). The DPO
should again obtain full details of all such arrangements whenever these involve or may
involve the processing of personal data – and should indeed review them, to see if they
adequately reflect, confirm and implement the requirements of the GDPR and of any
relevant national data protection laws and rules – and indeed of more general human
rights law.307 The DPO may not be able to challenge a deficient law or legal arrangement as
such, but could – and should – notify her employer, and probably the relevant DPA, of her
view that the law is deficient.
Sometimes, the links between, and the cooperation between, formally distinct entities are
based on informal, non public arrangements. However, this is problematic from a data
protection point of view.
305
Those agreements could include agreements between public bodies under which one public body
processes personal data on behalf of another public body, i.e., acts as a processor for the latter body. See the
discussion in the text of controller to controller , controller to processor and data transfer contracts.
306
See section 2.3.3, under the heading “Formal training and certification”, above, and footnote 456,
below.
307
Cf. the European Court of Human Rights judgment in Copland v. the UK of 3 April 2007, in which the
Court held that a vaguely phrased provision in a law granting a public authority broad competence in a certain
area (in casu, the provision of higher and further education) did not constitute “law” in terms of the European
Convention on Human Rights:
http://hudoc.echr.coe.int/eng?i=001 79996 (see in particular para. 47.)
148
(CC)
The DPO Handbook
As the Article 29 Working Party noted in its opinion on the concepts of controller and
processor:308
[There is] a growing tendency towards organisational differentiation in most relevant
sectors. In the private sector, the distribution of financial or other risks has led to on
going corporate diversification, which is only enhanced by mergers and acquisitions. In
the public sector, a similar differentiation is taking place in the context of
decentralisation or separation of policy departments and executive agencies. In both
sectors, there is a growing emphasis on the development of delivery chains or service
delivery across organisations and on the use of subcontracting or outsourcing of
services in order to benefit from specialisation and possible economies of scale. As a
result, there is a growth in various services, offered by service providers, who do not
always consider themselves responsible or accountable. Due to organisational choices
of companies (and their contractors or subcontractors) relevant databases may be
located in one or more countries within or outside the European Union.
This leads to difficulties in relation to division of responsibilities and the attribution of
controlship. The Working Party said the entities involved should provide “sufficient clarity”
about this division of responsibilities and effective attribution of (various forms and levels
of) controlship – which in practice means that the entities involved should discuss these
matters, agree on these divisions and attributions, and record this in the form of a formal
arrangement that can (and on request of course should) be provided to the relevant DPA or
DPAs and (perhaps in simplified form) to data subjects and the general public.
As part of the preliminary scoping task, the DPO should again check whether any such
formal arrangements are in place, and if so, whether they (a) really reflect the practical
divisions and attributions of responsibilities and (b) fully meet the requirements of the
GDPR. If there is no formal arrangement in place, the DPO should advise that one be drawn
up urgently (and she should be involved in the discussion, agreement and recording). If only
informal arrangements are in place, the DPO should advise that they be replaced by formal
ones.
Moreover, when the links and arrangements with other entities amount to or include
controller – controller and/or controller – processor arrangements, those should be
underpinned by relevant (GDPR compliant) controller – controller and/or controller –
processor contracts; and when the links and arrangements with other entities involve
transfers of personal data to non EU/EEA countries (so called “third countries”), the
transfers should be based on relevant (GDPR compliant) data transfer clauses (either
standard clauses approved by the relevant DPA or DPAs or by the EDPB, or ad hoc clauses
that conform to the GDPR).
Where such contracts or clauses are in existence, the DPO should review them to see if they
comply with the GDPR, and where there are no such contracts or clauses, but there should
be, the DPO should advise that they be concluded urgently.
These tasks of the DPO in relation to formal agreements, controller – to controller and
controller – to processor contracts and data transfer clauses (and in other related respects)
308
Article 29 Working Party, Opinion 1/2010 on the concepts of "controller" and "processor" (WP169,
adopted on 16 February 2010), p. 6, available at:
http://ec.europa.eu/justice/article 29/documentation/opinion recommendation/files/2010/wp169_en.pdf
149
(CC)
The DPO Handbook
are further discussed at 3.x, below. Here, it will suffice to note that the DPO should identify
such issues in the preliminary scoping task, to then be addressed thereafter.
Finally, the DPO’s organisation will have links with external (private and public sector)
suppliers of goods or services, ranging from outsourced data processing, accounting and
website management to the supply of canteen meals, maintenance and repairs, staff
medical and wellbeing support, etc., etc. The work done in these respects will be based on
contracts (either ordinary civil contracts or special public private contracts). Those contracts
will also be the basis for – and ought to specifically address – any processing of personal
data by the parties to those contracts: for the collecting of the relevant personal data to the
sharing and use of those data, to their final destruction or erasure. If the other entity is a
controller in its own right, those contracts (or at least the data protection relevant elements
of those contracts) will, in data protection terms, constitute controller to controller
personal data processing contracts. If the other entity acts merely as a processor for the
DPO’s organisation, the contract will be a controller processor contract. And if under the
contract personal data are transferred to a place outside the EU/EEA (typically, to a “cloud”
server maintained by the contractor), those contracts constitute personal data transfer
contracts.
In the preliminary scoping exercise, the DPO should again identify whether there are such
contracts, and then, shortly after the scoping exercise, review them, and where they are
missing or deficient in GDPR terms, advise that they should be drawn up or revised.
Mapping the organisation’s processing activities in broad terms
Once the DPO has carried out the general scoping of her organisation (as set out above), she
will be able to map the organisation’s personal data processing activities in broad terms, as
a crucial step towards the creation of a detailed register of all those activities and all the
individual personal data processing operations, carried out in Task 1 (discussed next). This
should lead to a chart such as the one provided overleaf, by Dr.Abdollah Salleh, setting out
the “Functional Components of a Clinical Information System” (used in the first T4DATA
training, in a presentation by the Italian data protection authority, the Garante del
Privacy).309
309
Luigi Carrozzi, presentation to the first “T4DATA” training session, June 2018, slides on “Practical
Guidance for DPOs – The register of data processing operations”.
150
(CC)
The DPO Handbook
EXAMPLE:
Map of an organisation’s [here: a hospital’s] personal data processing activities
Source: Dr Abdollah Salleh, https://drdollah.com/hospital information system his/
Note that the above map is more closely related to personal data processing operations
than the organogram of a hospital, provided earlier.
151
(CC)
The DPO Handbook
Organisational tasks:
TASK 1: Creating a register of personal data processing operations
Subject to a limited exemption discussed below under that heading, under Article 30 GDPR,
each controller must “maintain a record of processing activities under its responsibility”,
listing various details of each operation such as the name of the controller (and, one may
add, of the “business owner”) of the operation, the purpose(s) of the operation, the
categories of data subjects, personal data and recipients, etc. This duty to keep a register of
processing operations is closely linked to the accountability principle, discussed at 2.2,
above, by facilitating effective supervision by the relevant data protection authority
(“supervisory authority”) – as is underlined by Recital (82) of the GDPR:310
In order to demonstrate compliance with this Regulation, the controller or processor
should maintain records of processing activities under its responsibility.
Each controller and processor should be obliged to cooperate with the supervisory
authority and make those records, on request, available to it, so that it might serve
for monitoring those processing operations.
In other words, as the Italian data protection authority, the Garante, puts it:311
[The register is a] measure to demonstrate compliance to GDPR
The reference to “processing operations under [the controller’s] responsibility” suggests
that the record (often also referred to as register) must cover all such processing
operations, and this is indeed expressly stipulated in the German version of the GDPR.312
This also makes sense because, as the Garante also points out:313
The overall picture of information assets “personal data” and the related of processing
operation provided by the register, is the first step to accountability since it enables
the evaluation of risk on rights and freedom of individuals and to implement
appropriate technical and organizational measures to ensure a level of security
appropriate to the risk.
Although, as with most other requirements of the GDPR, this is formally a duty of the
controller rather than the DPO, in practice it will be the DPO who will either be in charge of
this work (in close cooperation with the controller’s relevant staff), or who will at the very
least be closely involved in it and oversee it. As the Article 29 Working Party (WP29) put
it:314
In practice, DPOs often create inventories and hold a register of processing operations
based on information provided to them by the various departments in their
organisation responsible for the processing of personal data. This practice has been
310
Luigi Carrozzi, presentation to the first “T4DATA” training session, June 2018, slides on “Practical
Guidance for DPOs – The register of data processing operations
311
Idem.
312
“JederVerantwortliche und gegebenenfalls sein
VertreterführeneinVerzeichnisallerVerarbeitungstätigkeiten, die ihrerZuständigkeitunterliegen.” (emphasis
added).
313
Luigi Carrozzi (footnote 236, above) (original emphasis).
314
WP29, Guidelines on DPOs (footnote 242, above), section 4.4, The DPO’s role in record keeping, p. 18.
152
(CC)
The DPO Handbook
established under many current national laws and under the data protection rules
applicable to the EU institutions and bodies.315
Article 39(1) provides for a list of tasks that the DPO must have as a minimum.
Therefore, nothing prevents the controller or the processor from assigning the DPO
with the task of maintaining the record of processing operations under the
responsibility of the controller. Such a record should be considered as one of the tools
enabling the DPO to perform its tasks of monitoring compliance, informing and
advising the controller or the processor.
In any event, the record required to be kept under Article 30 should also be seen as a
tool allowing the controller and the supervisory authority, upon request, to have an
overview of all the personal data processing activities an organisation is carrying out.
It is thus a prerequisite for compliance, and as such, an effective accountability
measure.
For a new DPO, this requires first of all the (overseeing of the) carrying out of an inventory
of all the processing operations of the organisation that may involve the processing of
personal data and of links with other organisations. This involves considering what data do
constitute such data – which is not always straight forward.316
An initial, basic inventory can usefully be carried out in parallel with the broader scoping of
the organisation and its operational context, in the preliminary task (Task 0), described
above. Subject to the exemption, noted below, this should then be followed by a full
inventory.
The full inventory should lead to the creation of the register (the collection of “records”) of
all of the controller’s personal data processing operations, mentioned in Article 30 (as
discussed a little later in this section, under the heading “Contents and structure of the
register entries”) – which should thereafter (and after the review and assessment noted
next, in Tasks 2 and 3) be kept up to date by the DPO (or the DPO should at least ensure
that it is kept up to date): see the text below, under the heading “(ongoing) Monitoring of
compliance”, after Task 4.
Exemption:
Article 30(5) exempts enterprises and organisations that employ fewer than 250 persons,
and that only process personal data “occasionally”,317 from the duty to maintain a record
of their personal data processing operations. However, this exemption does not apply if:
the processing that the enterprise or organisation carries out is “likely to result in a
risk to the rights and freedoms of data subjects” (note that this does not have to be
a “high risk”, such as triggers the need to hold a Data Protection Impact Assessment
(Task 4): any risk to the rights and freedoms of data subjects, however small, would
require the recording (and reviewing) of the controller’s operations;
the processing is not occasional; or
315
Article 24(1)(d) Regulation (EC) 45/2001 [original footnote]
316
See WP29, Opinion 4/2007 on the concept of personal data (WP136), adopted on 20 June 2007,
available at:
https://ec.europa.eu/justice/article 29/documentation/opinion recommendation/files/2007/wp136_en.pdf
317
In our view, the condition that the small organisation must only carry out personal data processing
“occasionally” follows from the stipulation (discussed in the text) that the exemption does not apply if the
processing by the small organisation is “not occasional”.
153
(CC)
The DPO Handbook
the processing includes sensitive data or data on criminal convictions and offences.
As to the first of these, in the context of DPIAs (which are required when there is a
likelihood of a “high risk to the rights and freedoms of natural persons”: see Task 4, below),
the WP29 has described the term “risk” as:318
a scenario describing an event and its [negative] consequences, estimated in terms of
severity and likelihood –
and explained that:319
the reference to “the rights and freedoms” of data subjects primarily concerns the
rights to data protection and privacy but may also involve other fundamental rights
such as freedom of speech, freedom of thought, freedom of movement, prohibition of
discrimination, right to liberty, conscience and religion.
In April 2018, the WP29 issued a “Position Paper” on Article 30(5) GDPR.320 In this, it stressed
that:
the wording of Article 30(5) is clear in providing that the three types of processing to
which the derogation does not apply are alternative (“or”) and the occurrence of any
one of them alone triggers the obligation to maintain the record of processing
activities.
Therefore, although endowed with less than 250 employees, data controllers or
processors who find themselves in the position of either carrying out processing likely
to result in a risk (not just a high risk) to the rights of the data subjects, or processing
personal data on a non occasional basis, or processing special categories of data under
Article 9(1) or data relating to criminal convictions under Article 10 are obliged to
maintain the record of processing activities. However, such organisations need only
maintain records of processing activities for the types of processing mentioned by
Article 30(5). For example, a small organisation is likely to regularly process data
regarding its employees. As a result, such processing cannot be considered “
occasional” and must therefore be included in the record of processing activities.321
Other processing activities which are in fact “occasional”, however, do not need to be
included in the record of processing activities, provided they are unlikely to result in a
risk to the rights and freedoms of data subjects and do not involve special categories
of data [so called “sensitive data”] or personal data relating to criminal convictions
and offences.
Example:
In Croatia, detailed information on all civil servants and employees of public bodies must by
law be uploaded to a central system, the Public Sector Employee Register. This also applies
318
WP29 Guidelines on DPIAs (footnote 351, below), p. 6.
319
Idem, emphasis added.
320
WP29, Position Paper on the derogations from the obligation to maintain records of processing
activities pursuant to Article 30(5) GDPR, 19 April 2018, available at:
https://ec.europa.eu/newsroom/article29/item detail.cfm?item_id=624045
The Position Paper was not expressly endorsed by the European Data Protection Board when it endorsed a
range of more formal “Opinions” of the WP29 (EDPB, Endorsement 1/2018, see footnote 248, above), but can
still be regarded as authoritative on the issue.
321
The WP29 considers that a processing activity can only be considered as “occasional” if it is not
carried out regularly, and occurs outside the regular course of business or activity of the controller or
processor. See WP29 Guidelines on Article 49 of Regulation 2016/679 (WP262). [original footnote]
154
(CC)
The DPO Handbook
to even the smallest public entities, such as small local communities that may employ only a
very few people. The processing of the data on these few employees by that very small
community is therefore not “occasional” and does not benefit from the record keeping
exemption.
If in doubt, the controller should seek the advice of the DPO on these questions – and the
DPO should be inclined to advise in favour of creating a full record in marginal cases, rather
than risk the organisation being held to have breached the duties enshrined in Article 30(1)
– (4).
Notes:
1. On the question of whether the register of personal data processing operations must be
made accessible to anyone (online or otherwise), or not, see Task 12, “Information and
awareness raising tasks”.
2. The creation of the register as such does not yet involve an assessment of the compliance of
the registered operations with the GDPR: that is done in Task 2 – but of course, the register
should be amended and updated as and when changes are made to the processing
operations recorded in it: see the entry “Monitoring of compliance: Repeating Tasks 1 – 3
(and 4) on an ongoing basis”, at the end of Task 4 (just before Task 5).
Contents and structure of the register entries (records):
The GDPR distinguishes between the registers of controllers and processors.
Contents and structure of the controller register entries (records)
Under Article 30(1) GDPR, the register of personal data processing operations of a controller
is to consist of a collection of records of each such operation; and each such record must
include the following details (words in square brackets and italics added):
a. the name and contact details of the controller and, where applicable, the joint
controller, the controller's representative and the data protection officer;
b. the purposes of the processing;
c. a description of the categories of data subjects and of the categories of personal
data [including whether any of the data fall within the list of “special categories of
data”/sensitive data];
d. the categories of recipients to whom the personal data have been or will be
disclosed including recipients in third countries or international organisations;
e. where applicable, transfers of personal data to a third country or an international
organisation, including the identification of that third country or international
organisation and, in the case of transfers referred to in the second subparagraph of
Article 49(1), the documentation of suitable safeguards;
f. where possible, the envisaged time limits for erasure of the different categories of
data;
g. where possible, a general description of the technical and organisational security
measures referred to in Article 32(1).
This list does not include the legal basis for the processing of the relevant data (Article 6 in
relation to non sensitive data; Article 9 in relation to sensitive data), or legal instruments
used for the contracts with processors, or for data transfers – but these are such crucial
issues in relation to any determination of the legality and GDPR compatibility of any
processing operation that they too should be recorded in the register, in relation to each
155
(CC)
The DPO Handbook
personal data processing operation (defined by reference to the purpose of the processing),
with the validity of the claimed and recorded legal basis checked in due course.
SAMPLE FORMAT OF A BASIC CONTROLLER PERSONAL DATA PROCESSING RECORD322

Note that a separate record must be created for each distinct operation
Part 1 – Information about the controller etc.
CONTROLLER CONTACT DETAILS: Name, Address, Email,

Telephone
JOINT CONTROLLER CONTACT DETAILS:* Name, Address, Email,
Telephone
REPRESENTATIVE CONTACT DETAILS:* Name, Address, Email,
Telephone
(*) If applicable
DATA PROT’N OFFICER CONTACT DETAILS: Name, Address, Email, Telephone
Part 2 – Basic information on the personal data processing operation (PDPO)323
1. Name of the PDPO324

2. Unit responsible
(“business owner”)
3. Purpose of the PDPO
4. Categories of data
subjects
5. Categories of personal
data
6. Does this include
sensitive data?
7. Legal basis for the
processing:*
* Cf. Art. 6 GDPR for non sensitive
322
Expanded from the template form presented by Carrozzi (footnote 236, above) with edits (e.g.,
portrait rather than landscape format) and entries about the name of the operation, the legal bases for the
processing, suitable safeguards for data transfers and details relating to technologies and security added (in
line with further recommendations by Carrozzi).
NB: A sample format of a more detailed (15 page) personal data processing record is attached at the end of
the discussion of the present task.
323
The sample chart above is merely intended to illustrate the recording requirements in broad terms.
The sampledetailed personal data processing record mentioned in the previous footnote and attached to this
Task asks for crucial further detail, e.g., for each category of personal data: the purpose, relevance and source
of the data, etc..
324
From a data protection legal perspective, any personal data processing is operation is best defined on
the basis of the purpose served by the operation (as recorded at 2.). However, in many organisations, the
people performing the operations will often have a specific functional/internal name for the operation –
although the two designations will of course often overlap and can be identical.
156
(CC)
The DPO Handbook
data, Art. 9 for sensitive data
8. Are the data transferred

to a 3rd country or an
international
organisation?
9. In case of transfers
referred to in the 2nd
subparagraph of Article
49(1) GDPR: what suitable
safeguards are provided?
10. Time limits for erasure

11. Details of systems,
applications and
processes (paper/electronic
files; desktop suite/centrally
managed application/ cloud
service/local network; data
transmissions; etc.) and
related technical and
organisational (security)
measures
12. Does the processing

involve the use of (a)
processor(s)? If so
provide full details and a
copy of the relevant
contract(s).
Contents and structure of the processor register entries (records)325

Under Article 30(2) GDPR, the register of personal data processing operations of a processor
is to consist of a collection of records of each such operation; and each such record must
include the following details:
a. the name and contact details of the processor or processors and of each controller
on behalf of which the processor is acting, and, where applicable, of the
controller's or the processor's representative, and the data protection officer;
325
Note that it is increasingly difficult to fully distinguish processors from controllers. Often, entities that
used to provide straight forward processor services (acting purely as instructed by the controller, who
determined the means and purposes) now take on many more responsibilities and may become “joint
controllers”. This is especially the case in relation to providers of cloud services – some of which now even
offer “Artificial Intelligence and Machine Learning (AI/ML) via Machine Learning as a Service (MLaaS)”, see:
http://www.techmarketview.com/research/archive/2018/04/30/machine learning as a service market
overview technology prospects
As discussed in the Preliminary Task, the arrangements between entities involved in such complex
arrangements should be clearly and properly recorded. The forms recording the relevant processing
operations should be reviewed and amended to fit in with these (agreed and recorded) inter entity
arrangements. Entities that are more than straightforward processors should use the detailed form mentioned
in the next footnote.
157
(CC)
The DPO Handbook
b. the categories of processing carried out on behalf of each controller;
c. where applicable, transfers of personal data to a third country or an international
organisation, including the identification of that third country or international
organisation and, in the case of transfers referred to in the second subparagraph of
Article 49(1), the documentation of suitable safeguards;
d. where possible, a general description of the technical and organisational security
measures referred to in Article 32(1).
Below, we again provide a sample format of the kind of record a processor should keep to
meet these requirements.
SAMPLE FORMAT OF A PROCESSOR’S PERSONAL DATA PROCESSING RECORD326

Note that a separate record must be created for each distinct personal data
processing operation for each distinct controller
Part 1 – Information about the processor and any sub processor(s)
PROCESSOR CONTACT DETAILS: Name, Address, Email,

Telephone
SUB PROCESSOR CONTACT DETAILS:* Name, Address, Email,
Telephone
SUB PROCESSOR CONTACT DETAILS:* Name, Address, Email,
Telephone
* If applicable
Part 2 – Information about the controller of the specific PDPO in question
CONTROLLER CONTACT DETAILS: Name, Address, Email,

Telephone
JOINT CONTROLLER CONTACT DETAILS:* Name, Address, Email,
Telephone
REPRESENTATIVE CONTACT DETAILS:* Name, Address, Email,
Telephone
(*) If applicable
NB: The relationship between the controller and the processor, and between
the processor and any sub processor, must be based on a written contract
meeting the requirements of Article 28 GDPR. Processors should keep copies
of the relevant contracts with the filled in form.
326
Again expanded from the template form presented by Carrozzi (footnote 236, above) with edits.
158
(CC)
The DPO Handbook
Part 3 – Details of the personal data processing operation (PDPO)
1. The category (kind of) of

processing that is carried
out for the controller in
relation to the overall
PDPO, including:
the categories of data
subjects;
the categories of
personal data; and
whether this includes
sensitive data.
2. Are the data transferred
to a 3rd country or an
international
organisation?
3. In case of transfers
referred to in the 2nd
subparagraph of Article
49(1) GDPR: what suitable
safeguards are provided?
4. Details of systems,
applications and
processes used (type of
electronic files; desktop
suite/centrally managed
application/ cloud
service/local network;
data transmissions; etc.)
and related technical and
organisational (security)
measures
5. Does the processing
involve the use of (a) sub
processor(s)? If so
provide full details and a
copy of the relevant
contract(s).
Contents and structure of the register:

The DPO should build up the register from the records she receives on each distinct
personal data processing operation. They are normally best sorted by organisation, and
within that by business owner. With each individual record the DPO should keep all the
relevant documentation (as indicated in the template forms, above).
The DPO should note in the register when each record was received, when the relevant
processing operation was reviewed (as is done in Task 2, described next), with the outcome
159
(CC)
The DPO Handbook
of that review and any remedial measures taken; and indicate when the operation should
be due for the next regular (e.g., annual) review.
o–O–o–
Attached: Sample format of a detailed personal data processing record327
327
A more detailed template personal data record is also provided by the Polish DPA, the
Urz dOchronyDanychOsobowych (UODO) on its website, in Polish, at:
https://uodo.gov.pl/pl/123/214 (follow the first link at the bottom of the page.)
160
(CC)
The DPO Handbook
Attachment:
SAMPLE FORMAT OF A DETAILED PERSONAL DATA PROCESSING RECORD
Please use a separate form for each distinct personal data processing operation
NB: If you feel you need to elaborate or clarify a matter, please add a number in the relevant field
and attach a page with those elaborations or clarifications, with reference to that number.
I. GENERAL: * indicates a mandatory field (if applicable)
Controller: (Main controller entity)*

(Name, place of establishment & address,
registration number, etc.)
Associated entities
(Any entities with which the controller is linked
in relation to this operation, e.g.,
mother/daughter companies or linked public
bodies; processors that are involved in this
operation)
Business Unit: (“Business owner”)*

(E.g., HR, Accounts, R&D, Sales, Customer
Support)
Contact person within the unit:
PRIMARY PURPOSE OF THE PERSONAL DATA
PROCESSING OPERATION:*Please specify as
precisely as possible
Are the personal data used or disclosed for any
other (secondary) purpose or purposes?*Please
specify as precisely as possible and add link or
reference to the associated record.
Is this operation performed for all associated
entities alike? Or separately and/or differently
for different entities?*Please specify.
If the operations are different for the different
entities, please use separate forms for each.
Roughly, to how many individuals (data [Add number or “not known”]
subjects) does this operation relate (if
known)?*
Date of submission of this form to the DPO:*
Form & processing operation reviewed by DPO: [Yes/No and date to be entered by the DPO]
Due date for revision/update of this form: [To be specified by the DPO]
161
(CC)
The DPO Handbook
II. DETAILS OF THE PERSONAL DATA PROCESSING OPERATION:
II.1 The data and the data sources [NB: All fields are mandatory if applicable,
unless otherwise indicated]
1. What personal data Tick as appropriate: When, how and from

or categories of personal whom are the data
data are collected and used obtained?
for this operation? E.g.: (data subject=DS)
DWP, upon employing the person
DS, upon enrolment in research
Given & Family Name(s)
Date of Birth
Home address
Work phone number
Private phone number
Work email address
Private email address
Add any further data, below if applicable:*
* See also below, at 2, re sensitive data
Add further rows if necessary

2. Do the data you Tick if the data is expressly When and from whom are
collect and record for the collected and used for the the data obtained?
operation include or operation;
E.g.: (data subject=DS)
indirectly reveal any of the Tick and add (“Indirect”) if
DWP, upon employing the person
the datum is indirectly
following special categories DS, upon enrolment in research
revealed (explain in a note if
of personal data (“sensitive
necessary)
data”)?
Race or ethnic origin
Political opinions or
affiliations
Religious or philosophical
beliefs
Trade union membership
Genetic data
Biometric data
Data concerning the
162
(CC)
The DPO Handbook
person’s health
Data concerning the
person’s sexual
orientation or sex life
Information on criminal
convictions or offences
National identifier*
* E.g., NI Number, Tax Number
Data about debts/credit
score
Data on minors
3. If this is known or
determined: How long are
the (special and other) data
retained? What happens
then?*
* Indicate period or event, e.g., “7 years”
or “Until 5 years after termination of
employment”. Also explain what happens
to the data, e.g., erasure/destruction or
rendered anonymous.
NB: If there are different retention
periods for different data, please indicate
that.
II.2 Disclosures of data

4. To what third parties Recipient third party and Purpose(s) of the
are which of the above data place and country of disclosure(s):
disclosed? And for what establishment:
purposes?
NB: This also applies to the data being
made accessible, especially directly,
online
Re disclosures involving transfers to third
countries, see further below, at II.5
ALL THE DATA LISTED AT II.1
OR: The following data:

(Copy the data from 1 & 2, above)
163
(CC)
The DPO Handbook
II.3 Legal basis for the processing

5. On what legal basis Tick the relevant legal basis Clarification:
are the data processed? and provide clarification in
NB: If there are different legal bases for the next column as relevant.
different data or for different (primary,
secondary or new, unrelated) purposes,
please indicate that (if needs be by
copying and pasting the lists of data from
above to below, with the different legal
bases moved to the second column).
The data subject
consented to the
processing
NB: See also QQs 6 – 9, below.
The processing is
necessary for the
contract between your
organisation and the
data subject
(Or in order to take steps at the request of
the data subject prior to entering into a
contract – e.g., obtaining references)
The processing is
necessary for compliance
with a legal obligation
that your organisation is
subject to *
E.g., employment or tax law – please
specify the law in question
The processing is
necessary in order to
protect the vital interests
of the data subject or of
another person
The processing is
necessary for the
performance of a task
carried out in the public
interest *
* Please specify the source of the task
(typically, a law)
The processing is carried
out in the exercise of
164
(CC)
The DPO Handbook
official authority
* Please specify the source of the task
(typically, a law)
The processing is
necessary for a
legitimate interests of
your organisation (or
another entity) and is not
outweighed by the
interests of the data
subjects
E.g., marketing to your own clients, or
fraud prevention – please spell out.
CONSENT – further detail:

6. If the data are
processed on the basis of
the consent of the data
subjects, how and when is
this consent obtained?
NB: If the consent is provided in paper or
electronic form, please provide a copy of
the relevant text/link
7. What proof is kept
of the consent having been
given?
E.g., are copies kept of paper forms, or
logs of electronic consent?
8. How long is this
proof retained?
9. If in the context of a
contract, more data are
asked for by your
organisation than are
necessary for the contract,
is the data subject told s/he
does not need to provide
the additional data?
NB: Either say “N.A.”, or if this applies,
provide a copy of the relevant text/link
II.4 Informing of the data subjects [NB: This information is not mandatory but
Is helpful in assessing and revising internal data protection policies]
10. Are the data subjects Indicate Yes/No (or “N.A.”) Explain when and how this
informed of the following? NB: If relevant, you can say “Is obvious in
the context” and/or “The data subject
is done
And if so, when and how? Please provide copies of any information
already had this information”
notices or links
That your organisation is
the controller of the
personal data processing
operation?
165
(CC)
The DPO Handbook
Details of your
organisation (e.g., name
and registration
number)?
If applicable, details of
your representative in
the EU?
The contact details of the
DPO?
The main purpose of the
processing?
Any further purpose for
which your organisation
wants (or may want) to
process the data?
If the data were not
obtained directly from
the data subjects, the
source or sources of the
data, and whether those
included publicly
accessible sources (such
as public registers)?
The recipients or
categories of recipients
of the data? NB: Cf. Q4, above
Whether the data are (to
be) transferred to a non
EU/EEA country (e.g., to
a cloud server in the
USA)?
NB: This also applies to the data being
made accessible (especially directly,
online) to entities in non EU/EEA
countries.
If the data are so
transferred, what
safeguards have been put
in place, and where the
data subjects can obtain
copies of those?
NB: Safeguards can be provided in data
transfer contracts or through privacy
codes or privacy seals.
For how long the data
will be retained?
Of their rights to demand
access, rectification or
erasure of their data; to
166
(CC)
The DPO Handbook
ask for their data to be
blocked; to object to
processing?
Of their right to lodge a
complaint with the
relevant Data Protection
Authority?
11. If all or part of the
data are processed on the
basis of consent, are the
data subjects informed of
the following?
That they can withdraw
their consent at any time
(and how to do that)
(without that affecting
the lawfulness of the
prior processing)?
12. If the provision of Indicate Yes/No (or “N.A.”) Explain when and how this
the data is a statutory or NB: If relevant, you can say “Is obvious in is done
the context” and/or “The data subject
contractual requirement (or already had this information” Please provide copies of any information
notices or links
a requirement for the
entering into a contract),
are the data subjects
informed of the following?
Whether they are
required to provide the
data, and what the
consequences are if they
do not provide them?
13. If all or part of the Please provide a brief
data are processed on the summary of the criteria
basis of the “legitimate applied in the balancing test
interest” criterion, are the performed with regard to
data subjects informed of the data subjects’
what the legitimate interest fundamental rights and
in question is? freedoms as per Article
6(1)f GDPR.
14. If the data subjects Please provide a brief
will be the subject of summary of the logic used
automated decision making in the automated decision
or profiling, are they making or profiling.
informed of the following?
That such decision
making or profiling will
take place?
In broad (but meaningful)
167
(CC)
The DPO Handbook
terms, what “logic” is
involved?
What the significance of
the automated decision
making or profiling is and
the envisaged
consequences of the
decision making or
profiling?
II.5 Transborder data flows [NB: An entry in field 17 is not mandatory, but
again useful for internal evaluation]
15. Are any of the Indicate Yes/No and the Explain the purpose of the
personal data transferred country/ies in question. transfer, e.g.: as part of your
to a third [i.e., non EU/EEA] If the transfer is of only organisation’s own
country (or a sector in a some but not all of the data, operations (e.g., in using
third country) or to an specify for each category of cloud based software), or as
international organisation data. part of a disclosure of the
that has been held to data to a third party (please
afford an “adequate” level specify that party/those
of protection under Art. 45 parties)
GDPR?
ALL THE DATA LISTED AT
II.1
OR: The following data:

(Copy the data from 1 & 2, above)

16. Are any of the Indicate Yes/No and Explain the purpose of What safeguard
data transferred to a the country/ies in the transfer, e.g.: as or derogation
third [i.e., non question. part of your underpins the
EU/EEA] country (or a If the transfer is of organisation’s own transfer?
sector in a third only some but not all operations (e.g., in Please provide a
country) or to an of the data, specify using cloud based number as per
168
(CC)
The DPO Handbook
international for each category of software), or as part the list in the
organisation that has data. of a disclosure of the *Note below and
not been held to data to a third party provide a copy of
afford an “adequate” (please specify that any relevant
level of protection party/those parties) document
under Art. 45 GDPR?
NB:If data are transferred for different purposes to different recipients in different countries,
please answer the questions separately for each transfer context.
ALL THE DATA LISTED
AT II.1
OR: The following

data:
(Copy the data from 1 &
2, above)
Add further rows if

necessary
* NOTE: Under the GDPR, transfers to countries that have not been held to provide “adequate” protection may only take place if
“appropriate safeguards” are in place, as listed in the left column, below, or if a derogation applies, as listed in the right column.
Safeguards as per Art. 46 GDPR: Derogations as per Art. 49 GDPR, if safeguards as per Art. 46 are
1. International instrument between public authorities; not available (see EDPB Guidelines in this respect: restrictive
2. Binding Corporate Rules (BCRs); application and interpretation are mandated):
3. Approved standard data transfer clauses; 7. Consent;
4. Code of Conduct; 8. Contract between controller and data subject
5. Certification; 9. Contract between controller and third party
6. Approved ad hoc clauses 10. Necessary for important reasons of public interest
11. Necessary for legal claims;
12. Necessary to protect vital interest of data subject or
others;
13. Transfer is made from a register accessible to the public
17. Are rules in place to Indicate Yes/No and if yes, please provide a copy of the
deal with any judgment of a guidance.
court or tribunal and any
decision of an
administrative authority of
a third country that may be
served on the controller or
any processor, requiring the
controller or processor to
transfer or disclose personal
data?
(Cf. Art. 48 GDPR)
169
(CC)
The DPO Handbook
III. SECURITY AND CONFIDENTIALITY
NB: If the answers to the questions below Please provide details:

differ for different data, please answer them
separately for each distinct data set.
Are the personal data listed at II.1 held on
paper or in electronic format?
If on paper, are they held in a structured
manual collection (data file)?
Where (physically) are the data stored?
(Your offices? At servers at the main
controller? At servers of a linked
organisation? At servers of a third party (e.g.,
a Cloud Service Provider)?
What measures are in place to protect
against unauthorised access to the physical
place(s) where the data are
stored/accessible?
Is there a data security policy in place that
regulates this? (If so, please provide a copy.)
What hardware is used in the processing of
the data?
Who is responsible for the management and
security of this hardware?
Are (any of) the data stored on removable
media/devices? What are those
media/devices? Who is in possession of
them?
Can any of the people with access to the
data use personal devices to access or
process the data?
If so, is there a BYOD policy on this? Please
provide a copy of the policy.
Are all the persons authorised to access the
personal data subject to a duty of
confidentiality (be that under a statutory or
professional set of norms or under
contract)? Please provide details or copies of
any relevant norms or contract clauses.
What software/applications is/are used in
the processing of the data? (E.g., desktop MS
Office suite, centrally managed application,
cloud service, etc.)
170
(CC)
The DPO Handbook
Is this software managed locally or
centrally?
If centrally, who is the central entity?
If that is not you, is there a formal
arrangement between that entity and
your organisation as to the use of the
software?
Please provide a copy of this
arrangement.
Does the software use a “cloud”? If so,
who is the Cloud Service Provider, and
where is that provider legally based?
And where is/are the cloud server/s
physically based? Are the data on the
cloud server fully encrypted? How (i.e.,
using what encryption technology)?
Please provide a copy of the contract
under which this processing takes place.
Who is responsible (i.e., who has
“admin” authority) in relation to this
software? (You? Someone else within
your organisation? Someone in a central
entity with which you are linked?
Anyone else?)
Are the data at any time/in any
circumstances electronically transmitted to
another medium, system or device?
If they are electronically transmitted, is this
done:
over the Internet? If so, are the data
encrypted? How (i.e., using what
encryption technology)?
by means of FTP? How is this secured?
by means of a VPN? How is this
secured?
other – please specify
o–O–o
171
(CC)
The DPO Handbook
TASK 2: Reviewing the personal data processing operations

For the DPO, after having created the register of her organisation’s personal data processing
operation (Task 1), the next step is the carrying out of an in depth review of all the
registered personal data processing operations, to see whether they meet the requirements
of the GDPR in all relevant respects, including in respect of:
purpose specification and limitation;
the validity of any consent (and the existence of documentary proof of consent
having been given) or the applicability of any other legal basis for the processing;
personal data processed and their relevance and necessity in relation to the specified
purpose(s));
data quality (accuracy, up to dateness, etc., of the data, as well as data minimisation
and pseudonymisation);
information provided to the data subject of the controller’s own motion (either
when data are collected from the data subject or otherwise, or on request – also in
relation to data collected from website visitors);
the length of time for which the data are retained in identifiable form and any
information as to de identification;
technical, organisational and physical data security (including physical access
limitation and technical access limitation [user name, passwords, PINs policies, etc.],
encryption, etc.);
cross border data transfers (and the legal and other contractual or other
arrangements for them);
etcetera.
In the light of the findings on the above, the DPO should be able to assess:
whether the processing operation as a whole can be said to comply with the
overriding principle of lawfulness and fairness.
(Note that this GDPR compliance assessment is separate and different from the risk
assessment, described below as Task 3).
The records of the individual personal data processing operations created in Task 1 (in
particular if created in the more detailed format)328 should form the basis of the review, in
that they will lead to the DPO asking and answering of relevant questions including,
specifically:
Is it sufficiently clear which entity is the controller of the personal data processing
operation, and if any other entities are involved, what their respective status is (e.g.,
joint controller, processor, or separate third party controller)? If this is not obvious,
are formal arrangements in place that clarify these issues (cf. Task 1, above)?
Is it sufficiently clear which business unit is the “business owner” in respect of the
personal data processing operation (i.e., which has day to day de facto responsibility
328
As provided for in the sample format of a detailed personal data processing record attached to Task 1.
172
(CC)
The DPO Handbook
for the processing)? Is this set out in a formal document (e.g., specific instructions
from the controller to the unit)?
Is the purpose, or are the purposes, of the personal data processing operation
specified in sufficiently precise terms? Where (i.e., in what kind of document)? If the
personal data used in the processing operation are used for more than one purpose,
what is the primary purpose and what is or are the secondary purpose(s)? Are those
secondary purposes compatible with the primary purpose, or are they separate
purposes?
NB: In assessing the compatibility of any processing for any secondary purpose with the
primary purpose, the DPO must take into account the matters listed in Article 6(4) GDPR.
Are all the purposes for which the personal data are processed fully justified and
legitimate?
Are the personal data that are processed adequate, relevant and necessary for the
primary purpose? How is it ensured that they are and remain accurate and up to
date for this purpose, and what arrangements are made to ensure this and to rectify
or up date or erase inaccurate or out of date information?
Are the measures taken adequate and sufficient? Would it be possible to achieve the
same purpose with less risk to the privacy and other rights of the individuals
concerned?
What personal data are used or disclosed for any secondary purposes or indeed new,
unrelated purposes (typically, to a third party)? Are the personal data that are
processed adequate, relevant and necessary for those secondary or new, unrelated
purposes? (If all the data collected for one [primary] purpose are disclosed
unthinkingly for a/any secondary purpose or purposes or a new, unrelated purpose,
they, or some of them, may well be excessive for that secondary or unrelated
purpose or those secondary or unrelated purposes. Has this been considered?)
NB: Cf. the detailed personal data processing form, at II.2.
Are all the secondary purposes for which the personal data are processed fully
justified and legitimate?
How is it ensured that the data that are used or disclosed for secondary or new,
unrelated purposesareaccurate and up to date for those secondary or new purposes
at the time of first use or disclosure for those purposes, and what arrangements are
made to ensure they remainaccurate and up to date after that first use or disclosure,
and are rectified or up dated or erased as and when they become inaccurate or out
of date? Are the relevant measures adequate and sufficient?
NB: If the data are used or disclosed for more than one secondary or new purpose, these
questions should be answered separately for each separate secondary or new use or
disclosure.
When, how, from whom and in what form are which of the personal data obtained?
E.g.: the data subject, a government department, a (former) employer, etc.; e.g., on
paper, by electronic transfer, etc.
173
(CC)
The DPO Handbook
NB: This question should be answered for both non sensitive and sensitive data, and if
different data are obtained from different sources, this should be indicated. Cf. the detailed
personal data processing form, at II.1 and II.2.
Are those sources appropriate? Could some data that are obtained from third parties
perhaps be better asked of the data subjects themselves?
How long are the personal (non sensitive and sensitive) data retained? What
happens at the end of that period? (E.g.: erasure, destruction, rendering the data
anonymous – or pseudonymous – but note that the latter means the data are still
retained in identifiable form).329 If the data are retained in anonymous or
pseudonymous form, why is that done? (E.g., for research or historical purposes? If
so, the processing for that purpose should be separately assessed for compatibility
with the GDPR.)
NB: The retention period can be specified as a specific time or as an event, e.g., “7 years” or
“Until 5 years after termination of employment”. Note that there are formal standards on
the recommended methods of data erasure/destruction for different categories of data and
data carriers.330 The DPO should check whether those are followed (especially as concerns
sensitive information in either the data protection legal sense or in a broader social or
political sense.
Are the data retention periods appropriate? Or too long? Are the data
erasure/destruction measures in accordance with national and international
standards? If data are retained beyond the normal retention periods in anonymised
or pseudonymised form: (i) is this appropriate in view of the purpose of the
extended retention? Could data retained in pseudonymised form be retained in
fully anonymised form and still be sufficient for the special purpose? How true is any
claim that any data are “anonymised”? (Note that full anonymisation is increasingly
329
Note that under the GDPR (as under the 1995 Data Protection Directive) personal data can only be
said to have been rendered anonymous if they can no longer be linked to a specific individual by anyone – i.e.,
not just by the controller (but also, e.g., by colleagues or relatives or friends who might find the data if
released in supposedly de identified form on the Internet or in discarded paper). In that regard, DPOs should
be aware that more and more data that might seem to be “non personal” or that are said to have been
“rendered anonymous” can increasingly easily be (re )linked to specific individuals. In particular, data in
supposedly “anonymous” “Big Data” datasets are often unexpectedly, and worryingly, re identifiable,
especially if different datasets are linked or “matched”. Furthermore, if even truly non personal datasets are
used to create “profiles” (be that of typical consumers of a particular product, or typical patients, or typical
criminals or terrorists), and those profiles are then applied to datasets to single out individuals that meet the
profile – then that processing too can very seriously affect those individuals, who may be denied insurance, or
a job, or access to a flight or even a country (or worse) on the basis of effectively unchallengeable algorithms.
See: Douwe Korff and Marie Georges, Passenger Name Records, data mining & data protection: the need for
strong safeguards, report for the Council of Europe Consultative Committee on data protection, June 2015,
Council of Europe document T PD(2015)11, section I.iii, The dangers inherent in data mining and profiling,
available at:
https://www.coe.int/t/dghl/standardsetting/dataprotection/TPD_documents/T
PD(2015)11_PNR%20draft%20report%20Douwe%20Korff%20&%20Marie%20Georges_15%2006%202015.pdf
330
See for example:
DIN German Institute for Standardization, Office machines Destruction of data carriers, DIN 66399,
October 2012.
NIST Special Publication 800 88 Revision 1, Guidelines for Media Sanitization, December 2014, at
http://dx.doi.org/10.6028/NIST.SP.800 88r1
US National Security Agency/Central Security Service, Media Destruction Guidance, at
https://www.nsa.gov/ia/mitigation_guidance/media_destruction_guidance/index.shtml
174
(CC)
The DPO Handbook
difficult to achieve, especially in large data sets and more especially if data sets are
allowed to be matched or linked to other data sets.)
To what third parties are which of the above data disclosed? And for what
purposes? Are the data that are disclosed adequate, relevant and necessary for
those purposes, accurate and up to date, and if so, how is it ensured that they
remain so?
NB: The answers to the above may in part cross refer to the answers to the earlier
questions, above.
On what legal basis/bases are the personal data processed?
NB:
For non sensitive data, the legal basis must be one of those specified in Article 6 GDPR, for
sensitive data, one of those specified in Article 9 GDPR.
Note that the “legitimate interest” basis for processing (Art. 6(1)(f)) does not apply to
processing of any data – including non sensitive data – by public authorities in the
performance of their tasks (Art. 6(1), final sentence) and cannot be relied upon by any
controller, whether in the public or private sector, to process sensitive data (cf. Art. 9).
Moreover, if the processing is based on Article 6(1)(c) or (e) (“processing [that] is necessary
for compliance with a legal obligation to which the controller is subject”, “processing [that]
is necessary for the performance of a task carried out in the public interest or in the exercise
of official authority vested in the controller”), this must be based on Union or EU Member
State law (Art. 6(3)). If either of those is the indicated legal basis, the DPO must check
whether the law in question meets the requirements set out in Article 6(3) GDPR.
Is the claimed legal basis appropriate for the processing? Are the relevant conditions for the
application of the legal basis met (e.g., as concerns consent, as further addressed below)?
Note that the legal basis for processing for the primary purpose may be different from the
legal basis for any processing (including use or disclosure) of any of the data for any
secondary or new, unrelated purpose(s) – and the validity of the claimed legal basis must be
assessed separately for each of those.
If the data are processed on the basis of the consent of the data subjects:
how and when is the consent obtained (e.g., in paper or electronic form, by a
direct question or by asking an individual to tick a box)?331
what proof is kept of the consent having been give (e.g., paper copies, logs)?
how and for how long is this proof retained?
if in the context of a contract, more data are asked for by your organisation
than are necessary for the contract, is the data subject told s/he does not need
to provide the additional data?
331
Note that a simple statement on a website that says: “By continuing to use this website, you consent
to the collection and use of your personal data” is no longer sufficient to constitute valid consent under the
GDPR. Not only is there insufficient information on the use of the data – which renders the “consent” invalid as
it is not “informed consent”. But also, it is doubtful whether continuing on the website as such can be said to
constitute an “unambiguous indication of the data subject's wishes” to so consent (cf. the definition of consent
in Art. 4(11) GDPR).
175
(CC)
The DPO Handbook
Are the data subjects informed of all the matters of which they should be informed
(see Article 13 and 14 GDPR, as reflected in the detailed personal data processing
form, at II.4), and if so, when and how?
Is all the relevant information provided? Is that done in the best format? At the best
time? Are mandatory fields clearly distinguished from optional ones?
Are any of the data transferred to a third [i.e., non EU/EEA] country (or a sector in a
third country) or to an international organisation that has been held to afford an
“adequate” level of protection under Art. 45 GDPR?
Does the relevant adequacy decision indeed cover the processing? Is it still valid (cf.
the finding by the CJEU that the “Safe Harbor” adequacy decision was invalid)?
Are any of the data transferred to a third [i.e., non EU/EEA] country (or a sector in a
third country) or to an international organisation that has not been held to afford
an “adequate” level of protection under Art. 45 GDPR? If so, what safeguard or
derogation underpins the transfer?
NB: Under the GDPR, transfers to countries that have not been held to provide “adequate”
protection may only take place if either “appropriate safeguards” are in place, as listed in
Article 46 GDPR, or if a derogation applies, as listed Article 48 GDPR (cf. section II.5 in the
detailed personal data processing form, question 16).
Is/are the safeguard(s) or derogation(s) mentioned correct? Does it/do they meet all
the requirements as listed in the relevant article (Art. 46 or 48)?
Are rules in place to deal with any judgment of a court or tribunal and any decision
of an administrative authority of a third country that may be served on the controller
or any processor, requiring the controller or processor to transfer or disclose
personal data?
NB: Under Article 48 GDPR, judgments and decisions of third countries “may only be
recognised or enforceable in any manner if based on an international agreement, such as a
mutual legal assistance treaty, in force between the requesting third country and the Union
or a Member State, without prejudice to other grounds for transfer pursuant to this
Chapter.” This is a difficult matter to assess for business owners and many controllers and
processors, and guidance should be in place on how business owners and controllers and
processors should act if faced with such a judgment or decision. At the very least, processors
and business owners should immediately refer the matter up to the highest management
level of the controller, and the DPO.
If there is relevant guidance, is it adequate (e.g., if it was adopted prior to the
entering into full application of the GDPR, it may not have mentioned involving the
DPO in the matter, as there may not have been a DPO when the guidance was drawn
up)? If there is as yet no guidance on this, it should be drafted as a matter of
urgency, with the DPO consulted on its contents.
What formal, organisational, practical and technical measures are in place to ensure
the security and confidentiality of the data?
NB: Under Article 23 GDPR, controllers and processors must implement “appropriate
technical and organisational measures to ensure a level of security appropriate to the
risk[s]” that the processing poses to the rights and freedoms of natural persons (including in
particular the data subjects). The article lists various measures such as pseudonymisation
176
(CC)
The DPO Handbook
and encryption, confidentiality clauses, technical measures to ensure the integrity,
availability and resilience of the systems used and restoring capabilities.
The issue will be further addressed in Task 3 (risk assessment). However, an initial
overview of the measures taken (or not taken) should already be obtained in the
context of Task 2, to give a preliminary indication of whether the measures taken
are “appropriate” in the light of “the state of the art, the costs of implementation
and the nature, scope, context and purposes of processing as well as the risk of
varying likelihood and severity for the rights and freedoms of natural persons” (as it
is put in Article 23).
Many (though not all) of the measures are covered by recognised international
standards, such as those listed below. However, it should be noted that those do not
always cover all relevant issues, e.g., they tend to focus on security rather than data
minimisation or purpose limitation.332
Even so, DPOs should be aware of standards such as these – and check to see if
their DPA or the EDPB has commented on them (in a positive or negative way, or
with additions):333
ISO/IEC 27001:2013 Code of practise for information controls
ISO/IEC 29100 Information technology — Security techniques — Privacy
framework
ISO/IEC 27018 Code of practice for PII protection in public clouds acting as PII
processors
ISO/IEC 29134 Guidelines for privacy impact assessment (PIA)
ISO/IEC 29151 Code of practice for the protection of personally identifiable
information
JIS 15001:2006 Personal Information Protection Management System
requirements
BS 10012:2017 Specification for a personal information management system
Further standards are in preparation:
ISO 20889 Privacy enhancing data de identification techniques
ISO 29184 Online privacy notices and consent
ISO 27552 Enhancement to ISO/IEC 27001 for privacy management –
Requirements New title: Extension to ISO/IEC 27001 and ISO/IEC 27002 for
privacy information management – Requirements and guidelines
UNI Reference practice – Guidelines on personal data management in ICT
environments under GDPR
If a “cloud” is used in the processing, consideration should also be given as to
whether the matters have been addressed that are listed in the “Trusted Cloud –
Data Protection Profile for Cloud Services (TCDP)” guidelines issued by the German
government backed pilot project “Data Protection Certification for Cloud Services”
332
Some years ago, DPAs noticed that an ISO paper on security which covered PIN codes did not specify
the number and nature of the characters that should be used. Since then, the DPAs have a policy to interact as
much as possible with ISO groups whose activities relate to any DP subject.
333
Source: Alessandra de Marco, presentation to the first “T4DATA” training session, June 2018, slides on
“Existing standards (on security and privacy)” and “Standards (on privacy) not yet finalised”.
177
(CC)
The DPO Handbook
(although to date those still refer to the German pre GDPR Federal Data Protection
Law, rather than to the GDPR).334
At this stage, the DPO should check whether the controller and/or the business
owners are aware of the above standards, and are aiming to apply them, and if so,
whether there are certifications to that effect. The question of whether they are
actually fully complied with, or indeed should be, can be more fully addressed in
Task 3 (risk assessment).
This review is the first instance of the DPO’s “(Ongoing Monitoring of compliance” function
(further noted under that heading after Task 4).
If in any respect, it is the DPO’s view that a personal data processing operation does not
meet any of the GDPR requirements, the DPO must advise the relevant internally
responsible person or persons of the deficiencies, and propose remedial action (up to and
including stopping the operation altogether if necessary). In case this advice is not followed,
the DPO should refer the issue to top management (see below, under “Advisory tasks”).
Note that this general review of processing operations is a separate issue from the situation
of a personal data breach occurring, as discussed in relation to Task 6 (“Dealing with
personal data breaches”): as explained there, those breaches should be immediately
reported to highest management.
The DPO should keep full records of all her reviews and assessments, and of such advice.
o–O–o
334
See:
https://tcdp.de/data/pdf/14_TCDP_v1.0_EN.pdf (see in particular the list of standards on pp. 14 – 16). The
version available at the time of writing (v.1.0) dates from September 2016, but the authors hope that – after
GDPR underpinned auditing standards and certification procedures have been created – “TCDP certifications
will be converted into certifications pursuant to the General Data Protection Regulation for cloud services.” (p.
7). Cf. also the discussion of the risk factors etc., identified by the European Data Protection Supervisor in
relation to cloud services, discussed in Task 3, below.
178
(CC)
The DPO Handbook
TASK 3: Assessing the risks posed by the personal data processing

operations
As noted at 2.2.1, above, the GDPR imposes a general duty on controllers to “[take] 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” posed by
each personal data processing operation, and to “implement appropriate technical and
organisational measuresto ensure and to be able to demonstrate that processing is
performed in accordance with this Regulation” (Art. 24(1); cf. also Art. 25(1))).
The DPO, too:
shall in the performance of his or her tasks have due regard to the risk associated with
processing operations, taking into account the nature, scope, context and purposes of
processing.
(Art. 39(2))
Compliance with these requirements demand that the relevant risks be ascertained. This
should be done in connection with the carrying out of the inventory of personal data
processing operations and the creation of the register of those operations (Task 1) and,
especially, with the review of those operations (Task 2).
The GDPR does not expressly require the involvement of the DPO in any general risk
assessments: it stipulates such involvement only in relation to the more in depth Data
Protection Impact Assessments (Art. 35(2) – see Task 4, below). However, in practice it
would be highly advisable (to say the least) to involve the DPO also in these more general
risk assessments. Indeed, in practice, the assessment will often depend on the views of the
DPO.
It should be noted that the risks to be assessed are not just the security risks in a narrow
sense – i.e., the likelihood and impact of a data breach335 – but rather, the risks to the rights
and freedoms of the data subjects (and other individuals) that may be posed by the
processing operation. This includes not only their general rights to privacy and private life as
well as their specific data subject rights, but also, depending on the case, their rights to
freedom of expression, freedom of movement, freedom from non discrimination, freedom
from authoritarian power and the right to stay in a democratic society without undue
surveillance by their own, or by other countries, and the right to an effective remedy. The
concept is broad.336
The general risk assessment should also take into account the findings in Task 2. For
instance, if it is found that although a particular processing operation was, as such, lawful
(i.e., had a proper legal basis and served a legitimate interest), but that irrelevant and
excessive data were collected and held for the relevant purpose, contrary to the “data
minimisation” principle – then that can be said to pose a “risk” in itself, i.e., that the
irrelevant and unnecessary data would wrongly be used. In such a case, the appropriate
measure to avoid that risk would be to stop collecting the irrelevant and unnecessary data,
335
A “personaldata breach” is defined in the GDPR as: “a breach of security leading to the accidental or
unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted,
stored or otherwise processed.” (Art. 4(12)). See Task 6, below.
336
Cf. the discussions of the meaning of “risk” and “high risk” in, respectively, Task 1 (under the heading
“Exemptions”) and Task 4.
179
(CC)
The DPO Handbook
and to erase any such data already held. Another example would be the use of still
identifiable data in statistical processing that can be carried out by means of pseudonymised
or even fully anonymised data – in that case, the appropriate measure would be to ensure
that the data used would be properly (seriously) pseudonymised or (preferably) full
anonymised.
All this underlines that for the general review (Task 2) and the risk assessment (the present
Task 3), the controller – in practice, the DPO – must look closely at all aspects of each
distinct personal data processing operation and function.
As proposed by the Italian data protection authority, the Garante, it is useful to follow the
approach adopted by ENISA (the EU Agency for Network and Information Security), which in
turn builds on the widely accepted standard ISO 27005: “Threats abuse vulnerabilities of
assets to generate harm for the organisation”; and to consider in more detailed terms risk
as being composed of the following elements:
Asset (Vulnerabilities, Controls), Threat (Threat Agent Profile, Likelihood) and Impact.
The elements of risk and their relationships can then be illustrated as follows:
Source: ENISA Threat Landscape Report 2016, Figure 4: The elements of risk and their relationships
according to ISO 15408:2005, https://www.enisa.europa.eu/publications/enisa threat landscape
report 2016. See also its 2017 report, https://www.enisa.europa.eu/publications/enisa threat
landscape report 2017.
180
(CC)
The DPO Handbook
As also outlined by the Garante, a proper risk assessment involves four steps:337
1. Definition of the processing operation and its context.
2. Understanding and evaluation of impact.
3. Definition of possible threats and evaluation of their likelihood (threat
occurrence probability).
4. Evaluation of risk (combining threat occurrence probability and impact).
The first (defining the processing operation and its context) were done in Tasks 1 and 2,
above.
The second step involves defining different levels of impact – which can sensibly be left at
four levels, as follows:338
LEVEL of impact Description

Low Individuals may encounter a few minor inconveniences,
which they will overcome without any problem (time spent
re entering information, annoyances, irritations, etc.).
Medium Individuals may encounter significant inconveniences,
which they will be able to overcome despite a few
difficulties (extra costs, denial of access to business services,
fear, lack of understanding, stress, minor physical ailments,
etc.).
High Individuals may encounter significant consequences, which
they should be able to overcome albeit with serious
difficulties (misappropriation of funds, blacklisting by
financial institutions, property damage, loss of employment,
subpoena, worsening of health, etc.).
Very high Individuals which may encounter significant, or even
irreversible consequences, which they may not overcome
(inability to work, long term psychological or physical
ailments, death, etc.).
The Garante notes four main assessment areas in terms of data security, i.e.:
A. Network and technical resources (hardware equipment and software)
B. Processes/procedures related to the data processing operation
C. Different parties and people involved in the processing operation
D. Business sector and scale of the processing
For each assessment area, it asks five questions, a positive answer to which indicates a risk,
as set out in the table, overleaf.339
337
Giuseppe d’Acquisto, presentation to the first “T4DATA” training session on data security, June 2018,
slide on “Risk assessment (a focus on security)”.
338
Idem, slide on “Understanding and evaluating impact”.
339
Idem, slides on each of these four main assessment areas, with further explanation as to why a
positive answer to the question in each case poses a security risk.
181
(CC)
The DPO Handbook
The person assessing the security risk can, from these answers, then calculate the threat
occurrence probability, as indicated in the two charts under that heading, after the table,
overleaf.This score can then be combined with the impact score to arrive at an overall risk
score, as indicated in the chart after those.
THE FOUR MAIN ASSESSMENT AREAS IN TERMS OF DATA SECURITY:
A. Network & B. Processes & C. Parties & D. Business

technical resources: procedures people involved sector & scale
1. Is any part of the 6. Are the roles and 11. Is the processing 16. Do you consider
processing of personal responsibilities with of personal data your business sector
data performed regard to personal performed by a non as being prone to
through the internet? data processing defined number of cyberattacks?
vague or not clearly employees?
defined?
2. Is it possible to 7. Is the acceptable 12. Is any part of the 17. Has your
provide access to an use of the network, data processing organization
internal personal data system and physical operation suffered any
processing system resources within the performed by a cyberattack or other
through the internet
organization contractor/third type of security
(e.g. for certain users
ambiguous or not party (data breach over the last
or groups of users)?
clearly defined processor)? two years?
3. Is the personal data 8. Are the 13. Are the 18. Have you
processing system employees allowed obligations of the received any
interconnected to to bring and use parties/persons notifications and/or
another external or their own devices to involved in personal complaints with
internal (to your
connect to the data processing regard to the
organization) IT
personal data ambiguous or not security of the IT
system or service?
processing system? clearly stated? system (used for the
processing of
personal data) over
the last year?
4. Can unauthorized 9. Are employees 14. Is personnel 19. Does a
individuals easily allowed to transfer, involved in the processing
access the data store or otherwise processing of operation concern a
processing process personal personal data large volume of
environment?
data outside the unfamiliar with individuals and/or
premises of the information security personal data?
organization? matters?
5. Is the personal data 10. Can personal 15. Do persons/ 20. Are there any
processing system data processing parties involved in security best
designed, activities be carried the data processing practices specific to
implemented or out without log files operation neglect to your business sector
maintained without
being created? securely store that have not been
following relevant
and/or destroy adequately
best practices?
personal data? followed?
182
(CC)
The DPO Handbook
THREAT OCCURANCE PROBABILITY (1):
Assessment area: Nr of “yes” answers Level Score
0–1 Low 1
A. Network &
technical resources: 2–3 Medium 2
4–5 High 3
0–1 Low 1
B. Processes &
procedures 2–3 Medium 2
4–5 High 3
0–1 Low 1
C. Parties &
people involved 2–3 Medium 2
4–5 High 3
0–1 Low 1
D. Business
sector & scale 2–3 Medium 2
4–5 High 3
The above scores can then be entered into the following summary chart:
THREAT OCCURANCE PROBABILITY (2):
Overall SUM of scores: Threat occurrence PROBABILITY LEVEL:

4–5 Low
6–8 Medium
9 – 12 High
Finally, these results can then be combined with the “Impact Level” results set out in the
first chart, above, to indicate the overall risk, as follows:
OVERALL RISK ASSESSMENT:
IMPACT LEVEL
Low Medium High/Very High
THREAT Low
OCCURANCE
Medium
PROBABILITY
High
Legend:
[ ]Low risk [ ]Medium risk [ ]High risk
183
(CC)
The DPO Handbook
NOTE HOWEVER that the above risk assessment scheme relates mainly to data security
risks.
That is certainly one major category of risk that is to be assessed and addressed – and not
just once, but on a continual basis, as risks can evolve and mutate over time. Cf. the Note
headed: “Monitoring of compliance: Repeating Tasks 1 – 3 (and 4) on an ongoing basis” at
the end of the discussion of Task 4, just before the discussion of Task 5, below.
However, the GDPR also, more generally, refers to “risk[s] to the rights and freedoms of
natural persons” (see Articles 34, 35 and 36). The first article, Article 34, clearly accepts that
data breaches, as such, can result in such risks, and imposes important rules on how to deal
with them, as discussed in Tasks 4 (DPIAs), 5 (Investigation Task), 10 (Cooperation with the
DPA) and 12 (Information and Awareness Raising Task).
However, it should be noted that “risks to the rights and freedoms of natural persons” do
not flow only from data breaches. The GDPR itself stipulates in Article 35(1) that “high
risks” of this kind can stem, in particular, from:
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;
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
a systematic monitoring of a publicly accessible area on a large scale.
In these cases, preciselybecause such processing operations pose inherently high risks to the
rights and freedoms of individuals, a Data Protection Impact Assessment is required (and in
some cases the relevant DPA or DPAs must be consulted), as discussed in the next task.
More specifically, profile based automated decision making can lead to unfair decisions
(because no one is completely the same as any other individual, and no system would,
hopefully, know everything about a person) or undemocratic decisions with discriminatory
yet unchallengeable outcomes;340 the use of sensitive data can also lead to discrimination
(whether intentional or not);341 the use of even seemingly innocuous sales data can reveal
intimate health issues or pregnancy);342 and systematic monitoring of people in public
places can have a chilling effect on the exercise of fundamental rights such as the rights to
340
See: Douwe Korff & Marie Georges, Passenger Name Records, data mining & data protection: the
need for strong safeguards, report prepared for the Consultative Committee of the Convention for the
Protection of Individuals with regard to Automatic Processing of Personal Data (T PD) of the Council of Europe,
2015, section I.iii, The dangers inherent in data mining and profiling, available at:
https://rm.coe.int/16806a601b
341
Which is why special, especially restrictive, rules on the processing of personal data were included in
the European data protection instruments: see the “NB” in Part One, section 1.2.3, on p. 17, above.
342
See: How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did, Forbes, 16 February
2012, available at:
https://www.forbes.com/sites/kashmirhill/2012/02/16/how target figured out a teen girl was pregnant
before her father did/#2ea04af16668
184
(CC)
The DPO Handbook
freedom of expression, association and protest.343 Indeed, the risks can be combined and
then become mutually reinforcing, as in the use of face recognition technology in the
monitoring of public places by the police, with the aim of “identifying” bad people and
predicting bad behaviour.344
Note that for these risks to materialise, no data breach is required: the risks stem from the
inherently dangerous features of the processing operations themselves, even if performed in
accordance with their specifications and without a data breach as defined in the GDPR. That
is not captured by the (otherwise very useful) risk assessment scheme outlined by the
Garante, reproduced above.
The same is true as concerns lesser “risks to the rights and freedoms of natural persons”,
stemming from processing operations, not listed as inherently posing a “high risk”. This
includes in particular processing operations that do not fully meet the requirements of the
GDPR.
EXAMPLES:
Using personal data collected for one purpose for another, not “compatible”
purpose without a proper legal basis for the secondary processing and/or without
adequately informing the data subjects of the intended secondary uses of their data
– which would be made worse if this involves a disclosure of the data to a third
party.
This can result in the data subjects being denied the opportunity to consent (or not consent,
or object) to the secondary processing, which may affect them in a negative way (e.g., in job
or credit applications). It is also quite likely that personal data obtained in one context are
not sufficiently accurate or relevant for use in an entirely different context.
Retaining and/or using personal data (typically, once they are no longer needed for
their original purpose) in pseudonymised or supposedly anonymised form (typically,
for further use in this form for a new, secondary purpose).
In view of the increasing risk of re identification of even supposedly fully anonymised
data,345 any such retention and use of pseudonymised or supposedly anonymised data must
be regarded as posing risks to the rights and freedoms of the data subjects (which may even
amount to likely “high risks”, requiring a Data Protection Impact Assessment, as discussed in
Task 4). The DPO should most carefully check the risks of re identification of such data in any
343
See the quote from the famous Census judgment of the German Constitutional Court on p. 10 of this
handbook.
344
See: Douwe Korff, First Do No Harm: The potential of harm being caused to fundamental rights and
freedoms by state cybersecurity interventions, section 2.4, Preventive, predictive policing, in: Ben Wagner,
Matthias C. Kettemann and Kilian Vieth (Eds.), Research Handbook on Human Rights & Digital Technology:
Global Politics, Law & International Relations, Centre for Internet and Human Rights, Berlin, due for publication
later in 2018,
345
For an easy to read summary of the issues with de and re identification, see the submission by the
Foundation for Information Policy Research to the UK Government consultation on Making Open Data Real,
October 2011, available at: www.fipr.org/111027opendata.pdf. This refers to the seminal paper on the
problem: Paul Ohm, Broken promises of privacy: responding to the surprising failure of anonymization, 57
UCLA Law Review (2010) 1701, available at:
http://papers.ssrn.com/sol3/paperscfm?abstract_id=1450006.
185
(CC)
The DPO Handbook
specific uses, and impose strong mitigating factors (such as “differential privacy”)346 in
appropriate cases – or refuse to allow the further processing of the data.
Using irrelevant, incorrect or out dated information – with possible similar negative
consequences.
Not giving appropriate weight to “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”, when assessing whether personal data can be processed on
the basis of the “legitimate interest” condition (Art. 6(1)(f) GDPR).
This by definition causes harm to those data subject interests. The use of the “legitimate
interest” criterion as a legal basis for processing therefore always requires particularly close
scrutiny by the DPO in the present task.
NB: The criterion cannot be relied upon by public authorities “in the performance of their tasks” (Art.
6(1), final sentence), but this does not mean that the question never arises in a public sector context,
e.g., in relation to not statutorily required tasks such as emailing citizens about cultural events, using
the population register; or in relation to activities by private entities carrying out tasks “in the public
interest”.
Not properly informing data subjects of all of the many details of which they must be
informed under Articles 13 and 14 GDPR.
This can result in the data subjects not being able to fully exercise their rights under the
GDPR (which are of course precisely the kinds of “interests or fundamental rights and
freedoms of the data subject which require protection of personal data” to be protected).
Transferring personal data to a third country that has not been held to provide
“adequate” protection to personal data, without having appropriate safeguards or a
set of approved Binding Corporate Rules (BCRs) in place, or without otherwise
relying on one of the specified derogations (cf. Article 46 – 48 GDPR). This includes
using a “cloud” service that uses a server (or servers) that are in such third countries.
As the EDPS has pointed out in his detailed advice on the use of cloud services by the EU
institutions (which should also be studied by national public bodies as much of the advice
could be equally applied to them), cloud computing poses specific risks that should be most
carefully addressed by controllers (relying on their DPOs).347 Indeed, his advice suggests
that cloud computing may well have to be regarded as inherently posing high risks and
therefore requiring a Data Protection Impact Assessment. This is noted in the next task.
Outsourcing the processing of personal data by public authorities, in particular if the
data are sensitive in the technical legal sense of the GDPR (“special categories of
346
Differential privacy is an important measure to prevent re identification of data subjects from
datasets – but it only works if applied in a controlled environment, in which researchers are limited in the
queries they can send to the database, see:
https://privacytools.seas.harvard.edu/differential privacy
https://people.eecs.berkeley.edu/~stephentu/writeups/6885 lec20 b.pdf
It does not provide an answer to circumstances in which personal data are released in supposedly fully
anonymised form to the general public, or in which large datasets are otherwise matched without full control.
347
European Data Protection Supervisor (EDPS), Guidelines on the use of cloud computing services by
the European institutions and bodies, March 2018, available at:
https://edps.europa.eu/sites/edp/files/publication/18 03 16_cloud_computing_guidelines_en.pdf
See in particular Annex 4: Data protection specific risks of cloud computing
186
(CC)
The DPO Handbook
data” – Article 9), or sensitive in more general terms, such as financial data or census
data.
The EDPS notes that the use of cloud computing aggravates the risks inherent in outsourcing
of processing.348
If, after the assessment has been carried out, it is the DPO’s view that a personal data
processing operation does pose a risk to relevant interests, the DPO must advise the
relevant internally responsible person or persons of those risks, and propose mitigating or
alternative action. Often, a legitimate purpose can be achieved by different, less intrusive
means, or by the use of less (and less sensitive) data – and in such cases, the DPO should
forcefully suggest that. In case this advice is not followed, the DPO should again refer the
issue to top management (see further under “Advisory tasks”).
Again, the DPO should keep full records of all these risk assessments, and of such advice.
If the DPO’s advice is followed, these records will “demonstrate that processing is
performed in accordance with this Regulation” – i.e., that those risks have indeed been
assessed and that the measures taken in the light of that assessment were appropriate to
those risks (Cf. Art. 24(1) and the discussion of the “duty to demonstrate compliance” with
the GDPR in section 2.2, above).
Note that if the general risk assessment indicates that a proposed processing poses a likely
“high risk” to the rights and freedoms of individuals, the DPO should advise the controller
that a full Data Protection Impact Assessment (DPIA) is required, as discussed next, in Task
4.
Note that, even if a DPIA is not required, the DPO will have to continue to monitor all her
controller’s personal data processing operation on an ongoing basis: see the discussion after
Task 4, under the heading “Monitoring of compliance: Repeating Tasks 1 – 3 (and 4) on an
on going basis”.
Note also that often national legislators will already have tried to address special risks which
they believe are posed by special processing operations or activities, in their national rules –
something which to a large extent can be continued under the “specification clauses” in the
GDPR.349
Examples:
In Croatia, processing of genetic data for the calculation of the risk of disease and other
health aspects of data subjects in relation to the conclusion or execution of life insurance
contracts and contracts with clauses on survival is prohibited and this prohibition cannot
be lifted by the consent of the data subject (Art. 20 of the Law implementing the GDPR).
There, and in other countries, the use of biometric data and closed circuit television (CCTV)
surveillance cameras is also subject to special conditions, such as a requirement of
especially clear and unambiguous consent, and constraints, such as the placing of limits on
data retention.
348
The EDPS Guidelines on the use of cloud computing services by the European institutions and bodies
(previous footnote) “focuses on the use of cloud computing services provided by commercial entities [but] [a]s
such it also addresses, as a natural consequence, the issues raised by the outsourcing of IT services that
process personal data.” (p. 5).
349
See Part Two, section 2.2.
187
(CC)
The DPO Handbook
Such legal conditions should of course also be fully taken into account in any risk
assessment: no controller or DPO could of course ever conclude that a risk was acceptable
even though the special legislative conditions and constraints were not met.
o–O–o
188
(CC)
The DPO Handbook
TASK 4 Dealing with operations that are likely to result in a “high risk”:
carrying out a Data Protection Impact Assessment (DPIA)
What was said above about general risk assessments (Task 3) applies a fortiori to personal
data processing operations which, on the basis of the above general risk assessment, are
held to pose alikely “high risk to the rights and freedoms of natural persons” (Art. 35(1)).
The GDPR makes clear that this may in particular be the case when “new technologies” are
used.
If the preliminary risk assessment carried out in Task 3 does indeed indicate that a particular
personal data processing operation poses such a likely “high risk”, then the controller is
required to carry out a Data Protection Impact Assessment (DPIA) before going ahead with
the operation.
The GDPR stipulates that a DPIA must in any case take place in cases of fully
automated/profile based decision making, large scale processing of sensitive data, or large
scale monitoring of a publicly accessible area (Art. 35(3)). National DPAs must also adopt
lists of operations that will be subject to DPIAs in their territory, and may adopt lists of
operations that will not require one – but these lists have to be submitted to the EDPB, and
can be challenged by other DPAs under the GDPR’s “consistency mechanism” (Art. 35(4) –
(6)). The GDPR also allows the EDPB to issue a negative and positive list of its own, drawing
on the ones submitted to it by the national DPAs (who are required to do so under Article
64(1)(a) GDPR).
In practice, what has happened was that, first of all, the Article 29 Working Party issued
extensive advice and guidelines on the carrying out of a DPIA, both in its Guidelines on DPOs
of December 2016, as revised in April 2017 (WP243 rev1)350 and in its later, more elaborate
Guidelines on DPIAs, adopted on 4 April 2017, as revised and adopted on 4 October 2017
(i.e., all still before the GDPR applied).351 Both were endorsed by the European Data
Protection Board on the day the GDPR came into full application, 25 May 2018.352The EDPS
also provided useful further guidance in his paper on Accountability on the ground353
including a provisional list of processing operations that, in his view, do or do not require a
DPIA.354
The Revised Guidelines on DPIAs, adopted by the WP29 and endorsed by the EDPB, set out
nine criteria that should be taken into account in determining whether a processing
operation is likely to result in a “high risk”, and say that:355
In most cases, a data controller can consider that a processing meeting two criteria
would require a DPIA to be carried out. In general, the WP29 considers that the more
criteria are met by the processing, the more likely it is to present a high risk to the
350
See footnote 242, above.
351
WP29 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 (WP248 rev 1, hereafter referred to
as the WP29 Guidelines on DPIAs), contents page, available at:
http://ec.europa.eu/newsroom/article29/item detail.cfm?item_id=611236
352
353
EDPS, Accountability on the ground Part I: Records, Registers and when to do Data Protection Impact
Assessments (footnote 302, above), section 4, When to carry out a DPIA?, at pp. 9 – 11.
354
Idem, Annex 5.
355
WP29 Guidelines on DPIAs (footnote 351, above), p. 11, emphases added.
189
(CC)
The DPO Handbook
rights and freedoms of data subjects, and therefore to require a DPIA, regardless of
the measures which the controller envisages to adopt.
This is further discussed below, under the heading “How to assess whether a proposed
processing operation is likely to result in a ‘high risk’”, where examples are provided taken
from the WP29 Guidelines and the EDPS paper, under the sub heading “Factors that
indicate ‘high risks’”.
Here, we should note that, next, mostof the national DPAs (22 out of the 28)356 adopted
their own provisional lists, and submitted those to the EDPB for review. The EDPB carried
out those reviews in the light of the WP29 Guidelinesit had endorsed and on 25 September
2018 issued 22 opinions on those lists (one on each draft list).357 The main point consistently
made by the EDPB in these opinions was a recommendation to the DPAs that they should
not include processing operations in the list of operations for which a DPIA is mandatory, if
the operation in question met only one of the criteria for determining whether there was a
likely “high risk”, set out in the Guidelines. Thus, for instance, in its opinion on the draft list
submitted by the United Kingdom, it says:358
The list submitted by the Supervisory Authority of the United Kingdom for an opinion
of the Board states, that the processing of biometric data falls under the obligation to
perform a DPIA on its own. The Board is of the opinion that the processing of
biometric data on its own is not necessarily likely to represent a high risk. However,
the processing of biometric data for the purpose of uniquely identifying a natural
person in conjunction with at least one other criterion requires a DPIA to be carried
out. As such, the Board requests the Supervisory Authority of the United Kingdom to
amend its list accordingly, by adding that the item referencing the processing of
biometric data for the purpose of uniquely identifying a natural person requires a
DPIA to be carried out only when it is done in conjunction of at least one other
criterion, to be applied without prejudice to article 35(3) GDPR.
But of course, a DPIA may be carried out by a controller even if only one of those criteria is
met, without this being an obligation.
The requirement for a DPIA can be obviated in cases in which a law regulates the kind of
operation in question and a general DPIA has been carried out in the context of the
adoption of the law (Art. 35(10)). Furthermore, “[a] single [DPIA] assessment may address a
set of similar processing operations that present similar high risks” (Art. 35(1), last
sentence). As the WP29 summed it up:359
When isn’t a DPIA required? When the processing is not "likely to result in a high risk",
or a similar DPIA exists, or it has been authorized prior to May 2018, or it has a legal
basis, or it is in the list of processing operations for which a DPIA is not required.
356
Austria, Belgium, Bulgaria, Czech Republic, Germany, Estonia, Greece, Finland, France, Hungary,
Ireland, Italy, Lithuania, Latvia, Malta, the Netherlands, Poland, Portugal, Romania, Sweden, Slovakia and the
United Kingdom.
357
All are available through links provided at:
https://edpb.europa.eu/our work tools/consistency findings/opinions_en
358
EDPB, Opinion 22/2018 on the draft list of the competent supervisory authority of the United
Kingdom regarding the processing operations subject to the requirement of a data protection impact
assessment (Article 35.4 GDPR), adopted on 25 September 2018, available at:
https://edpb.europa.eu/sites/edpb/files/files/file1/2018 09 25
opinion_2018_art._64_uk_sas_dpia_list_en.pdf
359
WP29 Guidelines on DPIAs (footnote 351, above), contents page, p. 6.
190
(CC)
The DPO Handbook
Extensive guidance on DPIAs, including methodological guidance, has also been issued by
national DPAs, including those of France, Spain and the UK, and by the German
Datenschutzzentrum (endorsed by the German DPAs).360 The French data protection
authority, the CNIL, has even (in cooperation with other DPAs) developed an open source
DPIA software tool that “aims to help data controllers build and demonstrate compliance to
the GDPR”. As explained on the website:361
Who can use the PIA software?
The tool is mainly addressed to data controllers who are slightly familiar with the PIA
process. In this regard, a stand alone version can be downloaded and easily launched on
your computer.
It is also possible to use the tool on an organisation’s servers in order to integrate it
with other tools and systems already used in house.
What is it?
The PIA tool has been designed around three principles:
A didactic interface to carry out PIAs: the tool relies on a user friendly interface
to allow for a simple management of your PIAs. It clearly unfolds the privacy
impact assessment methodology step by step. Several visualisation tools offer
ways to quickly understand the risks.
A legal and technical knowledge base: the tool includes the legal points ensuring
the lawfulness of processing and the rights of the data subjects. It also has a
contextual knowledge base, available along all the steps of the PIA, adapting the
contents displayed. The data are extracted from the GDPR, the PIA guides and the
Security Guide from the CNIL, to the aspect of the processing studied.
A modular tool: designed to help you build your compliance, you can customise
the tool contents to your specific needs or business sector, for example by
creating a PIA model that you can duplicate and use for a set of similar processing
operations. Published under a free licence, it is possible to modify the source
code of the tool in order to add features or include it into tools used in your
organisation.
There is no space in this handbook to cover all the detailed advice on DPIAs provided for in
the later, more specific WP29 (EDPB endorsed) guidance on DPIAs, or in the national
guidance: the reader is strongly encouraged to study the WP29/EDPB guidance in full, and
360
See the list with links in Annex 1 to the WP29 Guidelines on DPIAs (footnote 351, above). The
methodologies for DPIAs are further discussed below, under that heading.
361
Available, with further information in English, at:
https://www.cnil.fr/en/open source pia software helps carry out data protection impact assesment
The CNIL uses the shorter acronym “PIA” (also in the quoted text, above), presumably because DPIAs originate
from “Privacy Impact Assessments”. Note that the tool has been recently updated. Information on the update
is available here (in French only):
https://www.cnil.fr/fr/loutil pia mis jour pour accompagner lentree en application du rgpd
On that page, the CNIL says the software is available in 14 languages: French, English, Italian, German, Polish,
Hungarian, Finnish, Norwegian, Spanish, Czech, Dutch, Portuguese, Romanian and Greece, and that it has been
endorsed (at least provisionally, in the beta version) by the data protection authorities of Bavaria, Italy,
Finland, Hungary, Poland and Norway. Note however that the software is mainly focused on technical security,
and will be mainly of use to SMEs, rather than to large and very complex entities.
191
(CC)
The DPO Handbook
relevant national advice where relevant, and rely on it in their actions and any advice
given.362
The reader, and especially DPOs, should also take account of the national mandatory DPIA
list published by their respective DPA as that list contains examples of situations where
application of the above guidance and advice has resulted into prescribing the performance
of a DPIA by both public and private entities; DPOs are expected to supervise the carrying
out of a DPIA by the respective controllers whenever they are mandated to do so based on
the said lists. If “white lists” are also issued in the next months (under Article 35(5) GDPR),
these will also be quite helpful as they will rule out the need for the controller to engage in
this exercise for a set of non high risk processing activities.
Below, we will briefly note the guidance in relation to: the different roles and
responsibilities of the controller and the DPO; the question of how to assess whether a
proposed processing operation is likely to result in a “high risk”; the methodologies for
DPIAs, and what to do with the record of the DPIA, in particular if it is concluded that
certain identified high risks cannot be fully mitigated by various possible measures, in which
case the GDPR requires that the relevant DPA be consulted (Art. 36).
The different roles and responsibilities of the controller and the DPO in
relation to DPIAs
In its Guidelines on DPOs, the WP29 again stressed the distinct roles and responsibilities of
the controller and the DPO, also in relation to DPIAs. It wrote:363
4.2. The DPO’s role in a data protection impact assessment
According to Article 35(1), it is the task of the controller, not of the DPO, to carry out,
when necessary, a data protection impact assessment (‘DPIA’). However, the DPO can
play a very important and useful role in assisting the controller. Following the principle
of data protection by design, Article 35(2) specifically requires that the controller ‘shall
seek advice’ of the DPO when carrying out a DPIA. Article 39(1)(c), in turn, tasks the
DPO with the duty to ‘provide advice where requested as regards the [DPIA] and
monitor its performance’.
The WP29 recommends that the controller should seek the advice of the DPO, on the
following issues, amongst others:364
whether or not to carry out a DPIA
what methodology to follow when carrying out a DPIA
whether to carry out the DPIA in house or whether to outsource it
what safeguards (including technical and organisational measures) to apply to
mitigate any risks to the rights and interests of the data subjects
362
See the references in footnotes 249, 318, 351 and 353 and in the previous footnote, above, for the
main advice to be studied.
363
WP29 Guidelines on DPOs (footnote 242, above), section 4.2, pp. 16 – 17, original italics, underlining
in the last paragraph added.
364
Article 39(1) mentions the tasks of the DPO and indicates that the DPO shall have ‘at least’ the
following tasks. Therefore, nothing prevents the controller from assigning the DPO other tasks than those
explicitly mentioned in Article 39(1), or specifying those tasks in more detail. [original footnote]
192
(CC)
The DPO Handbook
whether or not the data protection impact assessment has been correctly
carried out and whether its conclusions (whether or not to go ahead with the
processing and what safeguards to apply) are in compliance with the GDPR
If the controller disagrees with the advice provided by the DPO, the DPIA
documentation should specifically justify in writing why the advice has not been taken
into account.365
The WP29 further recommends that the controller clearly outline, for example in the
DPO’s contract, but also in information provided to employees, management (and
other stakeholders, where relevant), the precise tasks of the DPO and their scope, in
particular with respect to carrying out the DPIA.
The later WP29 Guidelines on DPIAs also stress that DPIAs are to be carried out by “[t]he
controller, with the DPO and processors”.366
In practice, especially in smaller organisations, the DPO will often again play a (if not indeed
the) leading part in the assessment.
How to assess whether a proposed processing operation is likely to result in
a “high risk”
The WP29/EDPB explain that:367
The obligation for controllers to conduct a DPIA in certain circumstances should be
understood against the background of their general obligation to appropriately
manage risks presented by the processing of personal data –
i.e., as also noted above, the question of whether a DPIA should be carried out arises
naturally from the general duty of the controller – carried out with the “advice”, but in
practice generally in reliance on, the DPO – to assess the risks inherent in all the controller’s
personal data processing operations (Task 3, above).
They go on to clarify the concept of “risk” and the protected interests that should be taken
into account:368
A “risk” is a scenario describing an event and its consequences, estimated in terms of
severity and likelihood. “Risk management”, on the other hand, can be defined as the
coordinated activities to direct and control an organization with regard to risk.
Article 35 refers to a likely high risk “to the rights and freedoms of individuals”. As
indicated in the Article 29 Data Protection Working Party Statement on the role of a
risk based approach in data protection legal frameworks, the reference to “the rights
and freedoms” of data subjects primarily concerns the rights to data protection and
privacy but may also involve other fundamental rights such as freedom of speech,
365
Article 24(1) provides that ‘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’. [original footnote, original italics]
366
See WP29 Guidelines on DPIAs (footnote 351, above), section III.D.b).
367
Idem, p. 6.
368
Idem. Note also the reference earlier to ISO 31000:2009, Risk management — Principles and
guidelines, International Organization for Standardization (ISO) ; ISO/IEC 29134 (project), Information
technology – Security techniques – Privacy impact assessment – Guidelines, International Organization for
Standardization (ISO) (WP29 Guidelines on DPIAs, footnote 351, on p. 5).
193
(CC)
The DPO Handbook
freedom of thought, freedom of movement, prohibition of discrimination, right to
liberty, conscience and religion.
The WP29 notes the examples in Article 35(3) of the GDPR of situations that inherently pose
“high risks”, already mentioned: when a controller uses automated, profile based
algorithms to take decisions with legal or other significant effect; when the controller
processes sensitive data or data on criminal convictions “on a large scale”; or when the
controller “systematically monitors” a publicly accessible area “on a large scale”. It the
rightly adds:369
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.
The WP29 lists a number of factors – most but not all related to the three examples in
Article 35 – that suggest that a processing operation poses “high risks”, and gives further,
more specific examples. The EDPS provides further examples, both in his provisional list of
processing operations that will always require a DPIA, and in a template that can be used to
assess whether processing operations that figure neither in his “positive” list (operations
that in his view always require a DPIA) nor in his “negative” one (those that in his view do
not require a DPIA) should be subjected to a DPIA.370 These WP29 and EDPS examples are
set out below (somewhat redacted, with the WP29 examples removed from the text and
moved to the box, and the EDPS examples indicated by an *). We have added some further
examples (or further details or variations), of relevance to public sector controllers in
particular; those examples etc. are set out in italics.
Factors that indicate “high risks”371
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 behaviour, location or movements”
(recitals 71 and 91).
Examples:
A financial institution that screens its customers against a credit reference database
or against an anti money laundering and counter terrorist financing (AML/CTF) or
fraud database.
A bank screening transactions in accordance with applicable law to detect possibly
fraudulent transactions.*
Profiling staff members based on all their transactions in [the organisation’s] case
management system with automatic reassignment of tasks.*
369
Idem, p. 9.
370
The positive and negative lists are set out in Annex 5 to the EDPS Accountability on the ground paper
(footnote 353, above); the Template for threshold assessment/criteria is contained in Annex 6 of that paper.
371
As listed and numbered in WP29 Guidelines on DPIAs (footnote 351, above), pp. 9 – 10. The main
comments in relation to the factors are also taken from those guidelines. Note that the factors somewhat
overlap, or can be combined, as is noted under the factors under the heading “Multi factor high risk
operations”.
194
(CC)
The DPO Handbook
A biotechnology company offering genetic tests directly to consumers in order to

assess and predict the disease/health risks.
A company building behavioural or marketing profiles based on usage or navigation
on its website.
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” (Article
35(3)(a)), in particular (but not only) in cases in which the processing may lead to the
exclusion or discrimination against individuals.
Examples:372
Automated staff appraisal (“if you’re in the lowest 10% of the team for the number
of cases dealt with, you’ll receive a ‘unsatisfactory’ in your appraisal, without
discussion”).*
Identification of “possible” or “probable” tax fraudsters by means of the automatic
attribution of profiles to taxpayers.373
Identification of “possible” or “probable” welfare fraudsters on the basis of a profile
of known fraudsters.
Identification of children “at risk” of growing up to becoming obese or gang members
or criminals, or of girls “likely” to become pregnant in their teens, on the basis of
profiles.374
Identification of young people and adults as “at risk” of being “radicalised”.
3. Systematic monitoring: processing used to observe, monitor or control data subjects,
including data collected through networks or “a systematic monitoring of a publicly
accessible area” (Article 35(3)(c))15. This type of monitoring is a criterion because
the personal data may be collected in circumstances where data subjects may not be
aware of who is collecting their data and how they will be used. Additionally, it may
be impossible for individuals to avoid being subject to such processing in public (or
publicly accessible) space(s).
372
The WP29/EDPB adds that “Processing with little or no effect on individuals does not match this
specific criterion. Further explanations on these notions will be provided in the upcoming WP29 Guidelines on
Profiling.” (p. 9).
373
Such attributions were made in Italy by the Italian Revenue Agency, using a tool called Redditometro.
The profiles were based, amongst others, on assumed expenses made by taxpayers deduced, according to
statistical parameters, from their allocation in specific family categories or geographical areas. This profiling
tool was investigated by the Italian DPA, the Garante. One of the main issues was the low quality of the data
and the resulting high error rate based on unreliable inferences drawn from the data. On the basis of its
investigation, the Garante prescribed that a taxpayer’s real income could only be calculated from actual,
documented expenses, and not deduced from statistically based assumptions of levels of expenses. See:
https://www.garanteprivacy.it/en/home/docweb/ /docweb display/docweb/2765110
374
See the UK Foundation for Information Policy (FIPR), Childrens Databases Safety & Privacy, study for
the UK Information Commissioner, 2006, available at:
https://www.cl.cam.ac.uk/~rja14/Papers/kids.pdf
195
(CC)
The DPO Handbook
Examples:
Internet traffic analysis breaking encryption.*
Covert CCTV.*
Smart CCTV [e.g., using face recognition software] in publicly accessible spaces.*
Data loss prevention tools breaking SSL encryption.*
Processing of metadata (e.g. time, nature and duration of a bank account
transaction) for organisational purposes or to provide budgetary estimates.375
4. Sensitive data or data of a highly personal nature: this includes special categories of
personal data as defined in Article 9 (personal data revealing racial or ethnic origin,
political opinions, religious or philosophical beliefs, or trade union membership,
health , genetic or biometric data, and data on sexual orientation), as well as
personal data relating to criminal convictions or offences as defined in Article 10.
Beyond these provisions of the GDPR, some categories of data can be considered as
increasing the possible risk to the rights and freedoms of individuals. These personal
data are considered as sensitive (as this term is commonly understood) because they
are linked to household and private activities (see the third example, below), or
because they impact the exercise of a fundamental right (see the fourth example) or
because their violation clearly involves serious impacts in the data subject’s daily life
(see the fifth example). In this regard, whether the data has already been made
publicly available by the data subject or by third parties may be relevant. The fact
that personal data is publicly available may be considered as a factor in the
assessment, [taking into account whether the data subject could reasonable expect
that the data might be used by other people for certain purposes: see the seventh
example, below].
Examples:
A general hospital [or a welfare office] keeping patients’ [or welfare claimants’]
medical records.
A private investigator keeping details of criminal convictions or offences, [or a public
authority such as a state educational institution keeping such data in relation to
pupils or students at such institutions].
[A public body or a private entity (such as an employer)] accessing personal
documents, emails, diaries or notes from e readers equipped with note taking
features, owned by staff members [or used by staff for both personal and professional
purposes, as in “Bring Your Own Device [BYOD] situations].
[A public body or a private entity (such as an employer)] accessing very personal
information contained in life logging applications, or using social media information
in contexts that can have significant impact on the individuals concerned, such as
selection people for jobs (or indeed interviews).
Pre recruitment medical exams and criminal records checks.*
Administrative investigations & disciplinary proceedings.*
375
This example is taken from the Italian DPIA list approved by the EDPB.
196
(CC)
The DPO Handbook
Any use of 1:n biometric identification.*

Photos used with facial recognition software or used to infer other sensitive data
[e.g., when they can lead to discrimination in a recruitment context].*
5. Data processed on a large scale: the GDPR does not define what constitutes large
scale, though recital 91 provides some guidance.376 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.
Example:
[National but possibly EU linked] databases on disease surveillance.*
Large scale exchanges of data among public sector controllers (e.g. Ministries, local
and regional authorities, etc.) via electronic networks.377
The large scale collection of genealogical information on families of people belonging
to a particular religious group.378
The creation of very large “lifestyle databases” for marketing purposes (but which
may – or at least can – also be used for other purposes).
The recording by political parties of the perceived voting intentions of very large
numbers of voters (or households) nation or countrywide, on the basis of doorstep
interviews, and the subsequent analysis and use of those data.379
6. Matching or combining datasets, [in particular if they] originat[e] from two or more
data processing operations performed for different purposes and/or [are carried out]
by different data controllers in a way that would exceed the reasonable expectations
of the data subject.
376
The relative clarification in Recital 91 reads: “[L]arge scale processing operations [are operations]
which aim to process a considerable amount of personal data at regional, national or supranational level and
which could affect a large number of data subjects and which are likely to result in a high risk, for example, on
account of their sensitivity, [or] where in accordance with the achieved state of technological knowledge a new
technology is used on a large scale ...”
377
378
Cf. the decision of the French DPA (the CNIL) on the Mormon’s genealogical register, issued in 2013
and reported here:
https://www.nouvelobs.com/societe/20130613.OBS3162/les mormons autorises par la cnil a numeriser l
etat civil francais.html
379
This practice is common and indeed traditional in the UK, as is recognised in Recital 56 of the GDPR.
That recital says that “this may be permitted for reasons of public interest, provided that appropriate
safeguards are established” (emphases added). If anything, this need to assess whether the processing really
serves a legitimate public interest and the requirement to adopt “appropriate safeguards” underline the need
for a serious risk analysis and impact assessment.
197
(CC)
The DPO Handbook
Example:
Covertly cross checking access control logs, computer logs and flexitime declarations
[by an employer] to detect absenteeism.*
A tax office matches its records of tax returns against records of owners of expensive
yachts, to look for people who may possibly be committing tax fraud.380
7. Data concerning vulnerable data subjects (recital 75): the processing of this type of
data is a criterion because of the increased power imbalance between the data
subjects and the data controller, meaning the individuals may be unable to easily
consent to, or oppose, the processing of their data, or exercise their rights.
Vulnerable data subjects may include children (they can be considered as not able to
knowingly and thoughtfully oppose or consent to the processing of their data),
employees , more vulnerable segments of the population requiring special
protection (mentally ill persons, asylum seekers, or the elderly, patients, etc.), and
in any case where an imbalance in the relationship between the position of the data
subject and the controller can be identified.
Examples:
Use of video surveillance and geolocation systems enabling the distance monitoring
of employees’ activities.381
Essentially any processing of personal data on any of the above categories of
vulnerable persons, and certainly any processing of sensitive data on them, or large
scale processing of such data on such people, should be considered as inherently
likely to result in a “high risk”.
8. Innovative use or applying new technological or organisational solutions. The GDPR
makes it clear (Article 35(1) and recitals 89 and 91) that the use of a new technology,
defined in “accordance with the achieved state of technological knowledge” (recital
91), can trigger the need to carry out a DPIA. This is because the use of such
technology can involve novel forms or types of data collection and usage, possibly
invisible and with a high risk to individuals’ rights and freedoms. Indeed, the
personal and social consequences of the deployment of a new technology may be
unknown. A DPIA will help the data controller to understand and to treat such risks –
and the mitigating measures should make it possible for data subjects and the
general public to see how and when and for what purposes the new technologies are
to be used, so that they can guard against those that can undermine individual rights
and freedoms and lead to authoritarian government or mass surveillance by
corporations (or those acting together).
Note: In many such cases of new technologies or practices, the DPAs (or the EDPB) may
issue, or may already have issued, opinions, guidelines or recommendations – and DPOs
should be on the alert to watch out for such new documents. If they believe that no relevant
guidance etc. has yet been issued, they should consult their DPA. See also Tasks 4, 8 and 10,
below.
380
This was done some time ago in the Netherlands, on the assumption that large yachts were typically
bought by tax fraudsters. One person, feeling himself targeted, tauntingly called his ship “Black Money”.
381
198
(CC)
The DPO Handbook
Examples:
Combining use of finger print and face recognition for improved physical access
control.382
New technologies intended to track employees’ time and attendance, including those
that process of biometric data as well as others such as mobile device tracking.383
Processing of data generated through the use of “Internet of Things” applications
(connected, “smart” devices and things) if the use of the data has (or can have) a
significant impact on individuals’ daily lives and privacy.
Machine learning.*
Connected cars.*
Social media screening of applicants for posts.*
9. 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 processing
operations that aim at allowing, modifying or refusing data subjects’ access to a
service or entry into a contract.
Examples:
A bank screening its customers against a credit reference database in order to decide
whether to offer them a loan.
A financial institution or credit reference agency taking into account the age
difference between spouses in a marriage to determine creditworthiness (which can
impede the free exercise of the fundamental right to marriage – and was therefore
prohibited in France by the French DPA, the CNIL (which had to assess the system
because, since it took decisions bases on profiles, was subject to “prior authorisation”
by the CNIL).
Exclusion databases.*
Credit screening.*
Multi factor high risk operations
The factors listed above can overlap or be combined, e.g., “systematic monitoring” can
overlap with, and be combined with, automated profile based decision making, and may
involve “large scale” processing of “sensitive data”. The WP29 provides a number of
examples of operations with such combined factors (or criteria) for which a DPIA is required,
and examples of operations in which one or more of the above factors (or criteria) are
present, but where no DPIA is needed, as follows:384
382
The WP29 and several national DPAs have issued detailed advice on this requiring, among other
matters, that the biological data should be stored on the micro processing chip in the data subject’s device,
rather than centrally by the controller. See: WP29 Working document on biometrics (WP80, adopted on 1
August 2003), p. 6, available at:
383
See WP29 Opinion 2/2017 on data processing at work (WP249, adopted on 8 June 2017), section 5.5,
Processing operations relating to time and attendance, at pp. 18 – 19, available at:
www.ec.europa.eu/newsroom/document.cfm?doc_id=45631
384
WP29 Guidelines on DPIAs (footnote 351, above), pp. 11 – 12.
199
(CC)
The DPO Handbook
Examples of processing Possible Relevant criteria DPIA likely to be

required?
- Sensitive data or data of a highly
A hospital processing its patients’ genetic
personal nature.
and health data (hospital information
- Data concerning vulnerable data
system).
subjects.
- Data processed on a large scale.
- Systematic monitoring.
The use of a camera system to monitor
- Innovative use or applying
driving behaviour on highways. The
technological or organisational
controller envisages to use an intelligent
solutions.
video analysis system to single out cars
and automatically recognize license
plates.
- Systematic monitoring.
A company systematically monitoring its
employees’ activities, including the
subjects.
monitoring of the employees’ work
station, internet activity, etc.
- Evaluation or scoring.
The gathering of public social media data
- Data processed on a large scale. Yes
for generating profiles.
- Matching or combining of datasets.
personal nature:
An institution creating a national level
- Automated decision making with
credit rating or fraud database.
legal or similar significant effect.
- Prevents data subject from
exercising a right or using a service
or a contract.
personal nature:
- Sensitive data.
Storage for archiving purpose of
pseudonymised personal sensitive data
subjects.
concerning vulnerable data subjects of
- Prevents data subjects from
research projects or clinical trials
exercising a right or using a service
or a contract.
A processing of “personal data from
personal nature.
patients or clients by an individual
physician, other health care professional
subjects.
or lawyer” (Recital 91).
- Data processed on a large scale.
An online magazine using a mailing list to
send a generic daily digest to its
subscribers with their consent, and which No
includes an easy means to opt out of
further mailings.
An e commerce website displaying
adverts for vintage car parts involving
limited profiling based on items viewed or
purchased on its own website – again,
with an easy opt out facility.
200
(CC)
The DPO Handbook
Methodologies for DPIAs:

The aims of a DPIA are:
(i) to precisely identify the (high) risks involved in the proposed processing
operation, taking into account the nature of the data and the processing, the
scope, context and purposes of the processing and the sources of the risk – not
only in normal circumstances, but also in special circumstances; and in the short ,
medium and long term;385
(ii) to evaluate the identified (high) risks, in particular its origin, nature, and
particularity, and the likelihood and possible severity of the risk;386
(iii) to identify what measures can be taken to mitigate the (high) risks that are
appropriate in terms of available technology and costs of implementation, and to
propose such measures;387 and
(iv) to record the findings, evaluation and measures taken (or not taken, with the
reasons for that), so as to be able to “demonstrate compliance” with the
requirements of the GDPR under the “accountability” principle in relation to the
assessed processing.388
Article 35(7) GDPR stipulates that (the record of) a DPIA must contain “at least” the
following:
(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.
The WP29 stresses that:389
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. The DPIA implementation is therefore scalable.
This means that even a small data controller can design and implement a DPIA that
is suitable for their processing operations.
385
Cf. Recital 90.
386
Cf. Recital 84 and ISO 31000.
387
Cf. Recital 84.
388
As the WP29 puts it: “[A] DPIA is a process for building and demonstrating compliance.” – WP29
Guidelines on DPIAs (footnote 351, above), p. 4. For further detail on the accountability principle and the
associated “demonstration of compliance” duties, see Part 2 of the handbook.
389
WP29 Guidelines on DPIAs (footnote 351, above), p. 17, emphasis added.
201
(CC)
The DPO Handbook
Controllers can therefore (in consultation with their DPO) choose a methodology for any
DPIA they have to carry out that suits them. They can draw on any experience they may
have with more technical risk assessments, e.g., under ISO 31000. However, the WP29
rightly note the different perspective from which DPIAs are to be carried out under the
GDPR and the (in any case, more narrowly security oriented) ISO based assessments:390
[T]he DPIA under the GDPR is a tool for managing risks to the rights of the data
subjects, and thus takes their [i.e., the data subjects’] perspective … Conversely, risk
management in other fields (e.g. information security) is focused on the [risks to the]
organization.
The WP29 provides a number of examples of data protection and privacy impact
methodologies prepared by national DPAs,391 and “encourages the development of sector
specific DPIA frameworks”. It has itself published a DPIA Framework for RFID Applications
and a DPIA Template for Smart Grid and Smart Metering Systems.392
Here, it must suffice to reproduce the Criteria for an acceptable DPIA, set out in the WP29
guidelines:393
Annex 2 – Criteria for an acceptable DPIA
The WP29 proposes the following 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:
a systematic description of the processing is provided(Article 35(7)(a)):
- nature, scope, context and purposes of the processing are taken into account
(Recital 90);
- personal data, recipients and period for which the personal data will be stored
are recorded;
- a functional description of the processing operation is provided;
- the assets on which personal data rely (hardware, software, networks, people,
paper or paper transmission channels) are identified;
- compliance with approved codes of conduct [, certifications and/or BCRs]394 is
taken into account (Article 35(8));
necessity and proportionality are assessed(Article 35(7)(b)):
- measures envisaged to comply with the Regulation are determined (Article
35(7)(d) and recital 90), taking into account:
390
Idem.
391
See again the list with links in Annex 1 to the WP29 Guidelines on DPIAs (footnote 351, above).
392
Idem, footnotes 32 and 33.
393
Idem, Annex 2. The emphases in bold in the main bullet points have been added for clarity.
394
The WP29 notes earlier that:
“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.
Certifications, seals and marks for the purpose of demonstrating compliance with the GDPR of processing
operations by controllers and processors (Article 42), as well as Binding Corporate Rules (BCR), should be taken
into account as well.”
WP29 Guidelines on DPIAs (footnote 351, above), p. 16.
202
(CC)
The DPO Handbook
measures contributing to the proportionality and the necessity of the processing
on the basis of:
specified, explicit and legitimate purpose(s) (Article 5(1)(b));
lawfulness of processing (Article 6);
adequate, relevant and limited to what is necessary data (Article 5(1)(c));
limited storage duration (Article 5(1)(e));
measures contributing to the rights of the data subjects:
information provided to the data subject (Articles 12, 13 and 14);
right of access and to data portability (Articles 15 and 20);
right to rectification and to erasure (Articles 16, 17 and 19);
right to object and to restriction of processing (Article 18, 19 and 21);
relationships with processors (Article 28);
safeguards surrounding international transfer(s) (Chapter V);
prior consultation (Article 36).
risks to the rights and freedoms of data subjects are managed (Article
35(7)(c)):
- origin, nature, particularity and severity of the risks are appreciated (cf. recital
84) or, more specifically, for each risk (illegitimate access, undesired
modification, and disappearance of data) from the perspective of the data
subjects:
risks sources are taken into account (recital 90);
potential impacts to the rights and freedoms of data subjects are identified in case
of events including illegitimate access, undesired modification and disappearance
of data;
threats that could lead to illegitimate access, undesired modification and
disappearance of data are identified;
likelihood and severity are estimated (recital 90);
- measures envisaged to treat those risks are determined (Article 35(7)(d) and
recital 90);
interested parties are involved:
- the advice of the DPO is sought (Article 35(2));
- the views of data subjects or their representatives are sought, where
appropriate (Article 35(9)).
What to do with the record of the DPIA
The first and main purpose of the record of the DPIA (covering all of the above “criteria”) is
to have evidence that a proper, in depth DPIA has been carried out, in accordance with the
GDPR (i.e., meeting the above criteria).
Where the DPIA identifies at the same time both (high) risks and measures that can be
taken to address those risks that are “appropriate” taking into account the likelihood and
severity of the risks and the costs of the measures, and where such measures have indeed
been approved and adopted (and this approval and adoption, too, has been recorded), the
DPIA record can provide an important “element” in an overall demonstration of
203
(CC)
The DPO Handbook
compliance and a “special means” to do this (although this does not amount to a legal
presumption of compliance, and although the DPO will still have to check and monitor, on
an ongoing basis, that the mitigating measures continue to be applied and continue to be
appropriate in the light of practical, organisational or technological developments: see
under this Task, under the heading “Ongoing monitoring of compliance”).
Examples of cases where the DPIA identified both the high risks and the mitigation measures,
which were considered (in casu, by EuroPrise) to be sufficient to allow the processing.
Consequently, both cases would enable the controller to confidently conclude that the outcome of
the DPIA shows that the processing would NOT need to be submitted to the competent DPA for
consultation:395
1. A welfare agency uses voice biometric authentication to counter welfare fraud.
Identification of risks: As the WP29 has pointed out, three of the main risks posed by the use of
biometric data are: (i) the fact that a person’s biometric features are irreplaceable (which means
that an authentication tool based on raw biometric data, once lost, cannot be replaced); (ii) the ease
with which biometric data can be used to match different datasets; and (iii) the possibility that
biometric data can be captured surreptitiously.
Mitigation measures: In a (voice) biometric authentication tool, used to counter welfare fraud, a
unique voice template is used, created from the original (“raw”) biometric data, rather than the raw
data, which are destroyed after enrolment of the data subjects. The voice template is unique to any
specific deployment, and it cannot be used to re create the original (raw) biometric data. This
addresses all three of the above mentioned risks: (i) if the voice template were to be compromised,
a new, different one can be created very simply (with the help of the data subject, who would need
to be re enrolled); (ii) the different voice templates used in different deployments of the same tool
cannot be matched against each other or against other voice data or voice templates; and (iii) the
voice template is created in a face to face enrolment process.
2. A financial institution checks the location of a customer’s mobile phone to see if it is (roughly) in
the same place as the customer’s bank card (which is being used for a transaction that has been
flagged up as suspicious).
Identification of risks: Precise details of someone’s location at a particular time can be highly
revealing of sensitive matters, and the revelation of those details therefore constitutes a serious
interference with the privacy and private life of the individual concerned – as the European Court of
Human Rights confirmed in the Naomi Campbell case.396
Mitigation measures: In the bank card fraud prevention tool, the location data of the mobile phone
are reduced, even before being passed on to the user of that tool (the financial institution), to a very
rough area, typically a country or state. That is sufficient for the tool to work efficiently (i.e., being
able to ascertain with sufficient certainty whether or not the transaction in question is genuine or
fraudulent), while reducing the intrusiveness of the location check to the absolute minimum.
395
These examples are taken from products that have obtained the European Privacy Seal, with the legal
evaluations done by Douwe Korff, see, respectively:
https://www.european privacy seal.eu/EPS en/4F self certification (a four factor authentication tool that
includes a voice biometric solution);
https://www.european privacy seal.eu/eps en/valid pos (a tool that matches the location of a suspicious bank
card transaction with the (rough) location of the card holder’s mobile phone).
In the evaluations, both products were praised for their extensive data minimisation and privacy by design
features, and for the way in which those mitigated the risks associated with, respectively, the use of biometric
data and location checking.
396
ECtHR, MGN v. the UK, judgment of 18 January 2011, available at:
https://hudoc.echr.coe.int/eng#{%22tabview%22:[%22document%22],%22itemid%22:[%22001 102965%22]}
204
(CC)
The DPO Handbook
The record can also be made available (or drawn on) in consultations involving concerned
parties or citizens, or in responses to queries and complaints from data subjects and non
governmental organisations representing data subjects (or the press). In that respect, the
WP29 observes that:397
Publishing a DPIA is not a legal requirement of the GDPR, it is the controller´s
decision to do so. However, controllers should consider publishing at least parts,
such as a summary or a conclusion of their DPIA.
The purpose of such a process would be to help foster trust in the controller’s
processing operations, and demonstrate accountability and transparency. It is
particularly good practice to publish a DPIA where members of the public are
affected by the processing operation. This could particularly be the case where a
public authority carries out a DPIA.
The published DPIA does not need to contain the whole assessment, especially when
the DPIA could present specific information concerning security risks for the data
controller or give away trade secrets or commercially sensitive information. In these
circumstances, the published version could consist of just a summary of the DPIA’s
main findings, or even just a statement that a DPIA has been carried out.
The DPIA record is of particular importance in dealing with any queries from DPAs, whether
acting in their general supervisory capacity or in response to a complaint.
More specifically, where the DPIA identifies at the same time both (high) risks and finds that
there are no measures that can be taken to sufficiently address all those risks (or at least no
measures that are “appropriate” taking into account the likelihood and severity of the risks
and the costs of the measures), the controller is required to consult the DPA (Art. 36) – and
the record of the relevant DPIA must be provided to the DPA:398
where a DPIA reveals high residual risks, the data controller will be required to seek
prior consultation for the processing from the supervisory authority (Article 36(1)). As
part of this, the DPIA must be fully provided (Article 36(3)(e)). The supervisory
authority may provide its advice,399 and will not compromise trade secrets or reveal
security vulnerabilities, subject to the principles applicable in each Member State on
public access to official documents.
Member States may also, under their national law, require controllers to consult the DPA
“in relation to processing by a controller for the performance of a task carried out by the
controller in the public interest, including processing in relation to social protection and
public health” (Art. 36(5)), and this has been done for those latter cases in. e.g., France and
Italy.
If the DPA is not satisfied with the information in the DPIA record (and/or otherwise
provided), the DPA can order the controller to provide any further information it feels it
requires to assess the matter (Cf. Art. 58(1)(a)).
Usually, the DPA will try to help the controller find a solution – i.e., identify measures that
would adequately mitigate the identified (high) risks (in the opinion of the DPA), and
397
WP29 Guidelines on DPIAs (footnote 351, above) p. 18, emphasis in bold original, emphasis in italics
and bold added.
398
Idem.
399
Written advice to the controller is only necessary when the supervisory authority is of the opinion
that the intended processing is not in line with the regulation as per Article 36(2). [original footnote]
205
(CC)
The DPO Handbook
provided that the controller agrees to adopt those measures (and that their adoption and
continuing use is checked and monitored by the DPO), that would resolve the matter (as
should be recorded by the DPO and will of course also be recorded by the DPA).
But alternatively, the DPA can either issue an order to the controller, requiring the
controller to adopt specified measures for the proposed processing operation (Cf. Art.
58(2)(d)), or indeed prohibiting the proposed processing (Art. 58(2)(f)).
The DPO should of course again record any such orders, and check on an on going basis that
they are complied with (and record her findings). But as always, apart from this checking,
monitoring and record keeping, it is ultimately the controller who will be held to account for
any failure to comply.
o–O–o–
206
(CC)
The DPO Handbook
Monitoring of compliance (including investigations of complaints):

TASK 5: Repeating Tasks 1 – 3 (and 4) on an ongoing basis
As the WP29 points out in its (EDPB endorsed) Guidelines on DPOs, Article 39(1)(b) entrusts
the DPO, among other duties, with the duty to “monitor compliance” of her organisation
with the GDPR, andRecital 97 further specifies that DPO “should assist the controller or the
processor to monitor internal compliance with this Regulation”.400 As the very term
“monitor” indicates, this is not a one off but an ongoing responsibility.
However, in line with our discussion on the role of the DPO in Part 2, section 2.3.4, above,
the WP29 also (again) stressed that this:401
does not mean that it is the DPO who is personally responsible where there is an
instance of non compliance. The GDPR makes it clear that it is the controller, not the
DPO, who is required to ‘implement appropriate technical and organisational
measures to ensure and to be able to demonstrate that processing is performed in
accordance with this Regulation’ (Article 24(1)). Data protection compliance is a
corporate responsibility of the data controller, not of the DPO.
The WP29 goes on to say that as part of these duties to monitor compliance, DPOs may, in
particular, on an on going basis:
collect information to identify processing activities,
analyse and check the compliance of processing activities, and
inform, advise and issue recommendations to the controller or the processor.
As it notes in relation to DPIAs (Task 4):402
It has to be stressed that in order to manage the risks to the rights and freedoms of
natural persons, the risks have to be identified, analysed, estimated, evaluated,
treated (e.g. mitigated...), and reviewed regularly.
In other words, Tasks 1 – 4, above (or if there are no likely “high risk” operations, Tasks 1 –
3), are to be repeated on an on going basis, and in particular of course if the organisation
changes any personal data processing operation, or implements any new ones. As the
EDPS puts it (in his advice to EU institutional DPOs):403
Your records have to reflect the reality of your [institution’s] processing operations.
This means that you have to ensure they are up to date. When [your institution is]
planning changes to your processing operations, check if the record needs updating. It
is a good idea to formally include this check in your change management process. It
may also be a good idea to conduct regular reviews independently of planned changes
in order to catch changes that may have gone unnoticed.
The WP29 has illustrated the last part of this sequence in a useful diagram, reproduced
overleaf, with the earlier stages (Tasks 2 and 3) added.
400
WP29 Guidelines on DPOs (footnote 242, above), section 4.1, Monitoring compliance with the GDPR,
on p. 16,7.
401
Idem, original italics.
402
WP29 Guidelines on DPIAs (footnote 351, above), footnote 10 on p. 6, emphasis added.
403
EDPS, Accountability on the ground (footnote 353, above).
207
(CC)
The DPO Handbook
WP29 diagram on the steps to be followed in relation to DPIAs,404 with the earlier steps
(Tasks 2 and 3) added in the top box:
TASK 2: Review of processing operations
Review of processing operations

REGULAR REPEAT CHECKS
TASK 3: Risk assessment (“Monitoring”)
Risk assessment
No risk/risks fully mitigated or minor
No DPIA needed
Note: The exceptions under Art. 35(5), noted in the WP29 diagram, relate to national security, defence, crime
prevention, etc. Art. 35(10) concerns the stipulation that no DPIA is required in relation to processing
regulated by law, if a general DPIA of that processing has been carried out in the lead up to the law (which
does not involve the DPO).
As part of her “monitoring of compliance” duties, the DPO should also make sure she is
aware in any changes in the regulatory and contractual (etc.) framework within which her
organisation operates, as scoped in the preliminary task (Task 0), so that she is able to
identify the impact on any such changes on (the ongoing legality and GDPR compliance of)
her organisation’s personal data processing operations, and can issue appropriate advice to
the relevant persons in her organisation (including top management where appropriate).
404
WP29 Guidelines on DPIAs (footnote 351, above), p. 7.
208
(CC)
The DPO Handbook
Indeed, the DPO should – where appropriate together with other DPOs in her DPO network
and/or with the DPA, and in consultation with her top management – at times be willing to
adopt positions and views on proposed or suggested changes to this framework, such as
proposals by a government that organisations such as hers should be required, enabled or
encouraged to share certain personal data for new purposes.
o–O–o–
209
(CC)
The DPO Handbook
TASK 6: Dealing with personal data breaches

Two of the main, important innovations brought in by the GDPR compared to the 1995 Data
Protection Directive, are (i) a general requirement to notify the relevant (i.e., “competent”)
DPA of any personal data breach that may result in a risk to the rights and freedoms of
individuals; and (ii) a duty to inform data subjects of such breaches in casesin which the
brach is likely to result in a “high risk” to the rights and freedoms of natural persons.
The Article 29 Working Party has issued detailed guidelines on how personal data breaches
should be handled;405 and this guidance was endorsed by the European Data Protection
Board at its first meeting.406 The discussion, below, will extensively draw on and refer to
these guidelines. The examples provided are also all taken from these WP29 Guidelines.407
Notifying the relevant DPA:
The idea of notification of personal data breaches is not new. As noted in section 1.3.3,
above,408 a personal data breach notification duty was already included in the e Privacy
Directive. However, that duty was limited to providers of electronic communications
networks and services.409The GDPR uses the samedefinition of “personal data breach” as is
contained in the e Privacy Directive, but without this limitation:
a breach of security leading to the accidental or unlawful destruction, loss, alteration,
unauthorised disclosure of, or access to, personal data transmitted, stored or
otherwise processed. (Art. 4(12))410
The WP29 Guidelines clarify in some detail what the relevant terms should be taken as
meaning, and sets out the different types of personal data breaches (“confidentiality
breach”; “integrity breach”; “availability breach”)411
Examples
An example of loss of personal data can include where a device containing a copy of a
controller’s customer database has been lost or stolen. A further example of loss may
be where the only copy of a set of personal data has been encrypted by ransomware
(malicious software which encrypts the controller’s data until a ransom is paid), or has
been encrypted by the controller using a key that is no longer in its possession.
Examples of a loss of availability include where data has been deleted either
accidentally or by an unauthorised person, or, in the example of securely encrypted
data, the decryption key has been lost. In the event that the controller cannot restore
405
WP29, Guidelines on Personal data breach notification under Regulation 2016/679 (WP250 rev.01,
adopted on 3 October 2017, as last revised and adopted on 6 February 2018 (hereafter: “WP29 Guidelines on
Data Breach Notification or, in this section, simply “the WP29 Guidelines”), available at:
https://ec.europa.eu/newsroom/article29/item detail.cfm?item_id=612052
406
407
The WP29 Guidelines also discuss notification obligations under other legal instruments: see Section
VI of the Guidelines. These are not further discussed here.
408
In the sub section on “Key features of the e Privacy Regulation”, under the sub heading “Data breach
notification”.
409
As the WP29 Guidelines note in the Introduction, some Member States also already had wider data
breach notification requirements.
410
The e Privacy Directive added after these same words, the words: “in connection with the provision of
a publicly available electronic communications service in the Community” (art. 2(i)).
411
WP29 Guidelines, p. 7, with reference to an earlier (2014) WP29 Opinion on breach notification.
210
(CC)
The DPO Handbook
access to the data, for example, from a backup, then this is regarded as a permanent
loss of availability.
A loss of availability may also occur where there has been significant disruption to the
normal service of an organisation, for example, experiencing a power failure or denial
of service attack, rendering personal data unavailable.
Even a temporary loss of availability can constitute a personal data breach:
Examples
In the context of a hospital, if critical medical data about patients are unavailable,
even temporarily, this could present a risk to individuals’ rights and freedoms; for
example, operations may be cancelled and lives put at risk.
Conversely, in the case of a media company’s systems being unavailable for several
hours (e.g. due to a power outage), if that company is then prevented from sending
newsletters to its subscribers, this is unlikely to present a risk to individuals’ rights and
freedoms.
Infection by ransomware could lead to a temporary loss of availability if the data can
be restored from backup. However, a network intrusion still occurred, and notification
could be required if the incident is qualified as confidentiality breach (i.e. personal
data is accessed by the attacker) and this presents a risk to the rights and freedoms of
individuals.
Article 33(1) stipulates that:

In the case of a personal data breach, the controller shall without undue delay and,
where feasible, not later than 72 hours after having become aware of it, notify the
personal data breach to the supervisory authority competent in accordance with
Article 55, unless the personal data breach is unlikely to result in a risk to the rights
and freedoms of natural persons. Where the notification to the supervisory authority
is not made within 72 hours, it shall be accompanied by reasons for the delay. (Article
33(1)).
A processor must “notify the controller without undue delay after becoming aware of a
personal data breach” (Art. 33(2)). The WP29 recommends that the processor:
promptly notifies the controller, with further information about the breach provided
in phases as more details become available. This is important in order to help the
controller to meet the requirement of notification to the supervisory authority within
72 hours. (WP29 Guidelines, p. 14)
The controller will be regarded as “aware” of the breach once the processor informed him
of this;412 andthe controller must then notify the DPA (as mentioned), unless the caveatthat
the data breach is unlikely to result in a risk to the rights and freedoms of natural persons
applies.
In certain cases, a processor may be acting for a number – perhaps even a large number – of
different controllers, for instance as a cloud data storage provider. The WP29 advises as
follows for such situations:
412
WP Guidelines, p. 14.
211
(CC)
The DPO Handbook
Where the processor provides services to multiple controllers that are all affected by
the same incident, the processor will have to report details of the incident to each
controller.
A processor could make a notification on behalf of the controller, if the controller has
given the processor the proper authorisation and this is part of the contractual
arrangements between controller and processor. Such notification must be made in
accordance with Article 33 and 34. However, it is important to note that the legal
responsibility to notify remains with the controller. (p.14)
The notification of the data breach to the relevant (“competent”) DPA413 “shall at least”:
a. describe the nature of the personal data breach including where possible, the
categories and approximate number of data subjects concerned and the
categories and approximate number of personal data records concerned;
b. communicate the name and contact details of the data protection officer or other
contact point where more information can be obtained;
c. describe the likely consequences of the personal data breach;
d. describe the measures taken or proposed to be taken by the controller to address
the personal data breach, including, where appropriate, measures to mitigate its
possible adverse effects.
(Art. 33(3))
In that respect, the WP29 says that the controller can:414
if necessary, choose to provide further details. Different types of breaches
(confidentiality, integrity or availability) might require further information to be
provided to fully explain the circumstances of each case.
Example
As part of its notification to the supervisory authority, a controller may find it useful to
name its processor if it is at the root cause of a breach, particularly if this has led to an
incident affecting the personal data records of many other controllers that use the
same processor.
In any event, the supervisory authority may request further details as part of its
investigation into a breach.
Moreover:
Where, and in so far as, it is not possible to provide the information at the same time,
the information may be provided in phases without undue further delay. (Art. 33(4))415
Example
A controller notifies the supervisory authority within 72 hours of detecting a breach
that it has lost a USB key containing a copy of the personal data of some of its
customers. The USB key is later found misfiled within the controller’s premises and
recovered. The controller updates the supervisory authority and requests the
notification be amended.
413
For guidance on the notification of cross border breaches and of breaches taking place at non EU
establishments, see section C in the WP29 Guidelines (pp. 16 – 18).
414
WP29 Guidelines, p. 15.
415
For details and further guidance on this issue, see the WP29 Guidelines, pp. 15 – 16.
212
(CC)
The DPO Handbook
Timing of the notification:
The WP29 Guidelines clarify when a controller (or a processor) can be said to have become
“aware” of a data breach, and stresses that there are also duties to anticipate and prepare
for such an event:416
As detailed above, the GDPR requires that, in the case of a breach, the controller shall
notify the breach without undue delay and, where feasible, not later than 72 hours
after having become aware of it. This may raise the question of when a controller can
be considered to have become “aware” of a breach. WP29 considers that a controller
should be regarded as having become “aware” when that controller has a reasonable
degree of certainty that a security incident has occurred that has led to personal data
being compromised.
However, as indicated earlier, the GDPR requires the controller to implement all
appropriate technical protection and organisational measures to establish
immediately whether a breach has taken place and to inform promptly the
supervisory authority and the data subjects. It also states that the fact that the
notification was made without undue delay should be established taking into account
in particular the nature and gravity of the breach and its consequences and adverse
effects for the data subject21. This puts an obligation on the controller to ensure that
they will be “aware” of any breaches in a timely manner so that they can take
appropriate action.
When, exactly, a controller can be considered to be “aware” of a particular breach will
depend on the circumstances of the specific breach. In some cases, it will be relatively
clear from the outset that there has been a breach, whereas in others, it may take
some time to establish if personal data have been compromised. However, the
emphasis should be on prompt action to investigate an incident to determine whether
personal data have indeed been breached, and if so, to take remedial action and
notify if required.
Examples
1. In the case of a loss of a USB key with unencrypted personal data it is often not
possible to ascertain whether unauthorised persons gained access to that data.
Nevertheless, even though the controller may not be able to establish if a
confidentiality breach has taken place, such a case has to be notified as there is a
reasonable degree of certainty that an availability breach has occurred; the controller
would become “aware” when it realised the USB key had been lost.
2. A third party informs a controller that they have accidentally received the personal
data of one of its customers and provides evidence of the unauthorised disclosure. As
the controller has been presented with clear evidence of a confidentiality breach then
there can be no doubt that it has become “aware”.
3. A controller detects that there has been a possible intrusion into its network. The
controller checks its systems to establish whether personal data held on that system
has been compromised and confirms this is the case. Once again, as the controller
now has clear evidence of a breach there can be no doubt that it has become “aware”.
4. A cybercriminal contacts the controller after having hacked its system in order to
ask for a ransom. In that case, after checking its system to confirm it has been
416
WP29 Guidelines, pp. 10 – 11.
213
(CC)
The DPO Handbook
attacked the controller has clear evidence that a breach has occurred and there is no
doubt that it has become aware.
5. An individual informs the controller that they have received an email impersonating
the controller which contains personal data relating to his (actual) use of the
controller’s service, suggesting that the security of the controller has been
compromised. The controller conducts a short period of investigation and identifies an
intrusion into their network and evidence of unauthorised access to personal data.
The controller would now be considered as “aware” and notification to the
supervisory authority is required unless this is unlikely to present a risk to the rights
and freedoms of individuals. The controller will need to take appropriate remedial
action to address the breach.
Documenting and assessing the breach:

The GDPR also stipulates that:
The controller shall document any personal data breaches, comprising the facts
relating to the personal data breach, its effects and the remedial action taken. That
documentation shall enable the supervisory authority to verify compliance with this
Article. (Art. 33(5), emphasis added)
Note that this latter requirement relates to all (“any”) personal data breach: it is not limited
to data breaches of which the DPA has to be notified, i.e., the record must also include any
data breaches that (in the opinion of the controller) were “unlikely to result in a risk to the
rights and freedoms of natural persons”.
In practice, the DPO will have to be closely and deeply involved in these matters. Often, a
suspected breach is likely to be first reported internally to her (and/or to the Chief
Technology or Security Officer) – and the DPO must then (as appropriate, with those other
officers) make the first, immediate assessment of at least the following matters:
- whether there actually has been a personal data breach as defined in the GDPR (see
the definition in Article 4(12), quoted above) –
and if it is established that there was a breach, or that it is likely that there may have
been a breach:
- which (categories of) data subjects were or may have been affected by the breach
and what (categories of) personal data may have been lost or otherwise affected –
NB: The WP29 recommends that these categories also be reported to the DPA in any
breach notification, and indeed that:417
if the types of data subjects or the types of personal data indicate a risk of particular
damage occurring as a result of a breach (e.g. identity theft, fraud, financial loss,
threat to professional secrecy), then it is important the notification indicates these
categories. In this way, it is linked to the requirement of describing the likely
consequences of the breach.
and taking those matters into account:
- whether the breach is “likely” or “unlikely” to result in a risk to the rights and
freedoms of natural persons –
417
214
(CC)
The DPO Handbook
The WP29 discusses the question of when notification is not required in some
detail418 and provides the following example:
Example
A breach that would not require notification to the supervisory authority would be the
loss of a securely encrypted mobile device, utilised by the controller and its staff.
Provided the encryption key remains within the secure possession of the controller
and this is not the sole copy of the personal data then the personal data would be
inaccessible to an attacker. This means the breach is unlikely to result in a risk to the
rights and freedoms of the data subjects in question. If it later becomes evident that
the encryption key was compromised or that the encryption software or algorithm is
vulnerable, then the risk to the rights and freedoms of natural persons will change and
thus notification may now be required.
but if the assessment is that there is a likelihood of such a potential risk:

- whether the risk is a “high risk to the rights and freedoms of [those] natural persons”
(because that would require not just notification of the breach to the DPA, but also
the informing of the data subjects, as noted under the next sub heading).419
As the WP29 points out, the importance of being able to identify a breach, to assess the risk
to individuals, and then notify if required, is emphasised in Recital 87 of the GDPR:
It should be ascertained whether all appropriate technological protection and
organisational measures have been implemented to establish immediately whether a
personal data breach has taken place and to inform promptly the supervisory
authority and the data subject. The fact that the notification was made without undue
delay should be established taking into account in particular the nature and gravity of
the personal data breach and its consequences and adverse effects for the data
subject. Such notification may result in an intervention of the supervisory authority in
accordance with its tasks and powers laid down in this Regulation.
And of course, if the assessments indicate that there was a breach, and that there are risks
to the interests of individuals, then mitigating measures should be urgently sought.
The above matters should alsourgently, at the earliest possible moment, be passed on to
highest management. Indeed, any internal discussions of the above matters should not
delay the informing of highest management as soon as a breach is established.
The fact that those assessments were done, conscientiously, should be carefully
recorded,420 together with the outcomes of the relevant assessments and the reasons for
those assessments; the mitigating measures considered; the fact that the assessments and
the proposed mitigating measures were communicated to highest management; the actual
measures authorised by management and whether, and when, they were carried out; and
of course, the fact that the breach (if found to be notifiable) was notified to the relevant
DPA(s) and when, with a copy of the notification; and where required, the fact that data
418
WP29 Guidelines, pp. 18 – 19. See also the non exhaustive list of examples provided in an annex
(Annex B) to the Guidelines, reproduced below, under the next sub heading.
419
See in particular the discussion under the sub heading “Assessing risk and high risk”.
420
The WP29 suggests, that this be done “in the controller’s incident report plan and/or governance
arrangements” (p. 12). This is further discussed in some detail in the WP29 Guidelines, Section V,
Accountability and record keeping”.
215
(CC)
The DPO Handbook
subjects were informed, and how, with a copy of the relevant notification and any relevant
press release, etc. (as discussed under the next heading).Moreover, as the WP29 Guidelines
say:
Documentation of the breach should take place as it develops (p. 12).
In organisations that have appointed a DPO, she will have an important role to play in these
regards, as the WP29 stresses:421
A controller or processor may have a Data Protection Officer (DPO)48, either as
required by Article 37, or voluntarily as a matter of good practice. Article 39 of the
GDPR sets a number of mandatory tasks for the DPO, but does not prevent further
tasks being allocated by the controller, if appropriate.
Of particular relevance to breach notification, the mandatory tasks of the DPO
includes, amongst other duties, providing data protection advice and information to
the controller or processor, monitoring compliance with the GDPR, and providing
advice in relation to DPIAs. The DPO must also cooperate with the supervisory
authority and act as a contact point for the supervisory authority and for data
subjects. It should also be noted that, when notifying the breach to the supervisory
authority, Article 33(3)(b) requires the controller to provide the name and contact
details of its DPO, or other contact point.
In terms of documenting breaches, the controller or processor may wish to obtain the
opinion of its DPO as to the structure, the setting up and the administration of this
documentation. The DPO could also be additionally tasked with maintaining such
records.
These factors mean that the DPO should play an key role in assisting the prevention of
or preparation for a breach by providing advice and monitoring compliance, as well as
during a breach (i.e. when notifying the supervisory authority), and during any
subsequent investigation by the supervisory authority. In this light, WP29
recommends that the DPO is promptly informed about the existence of a breach and
is involved throughout the breach management and notification process.
The WP29 Guidelines make clear that organisations should not just be reactive in this
regard. Rather, they should have a security policy in place that in advance seeks to avoid
any data breaches, and contains plans to prevent, mitigate and end them. In relation to
personal data processing operations likely to result in a “high risk” to the interests of
individuals, the designing of such a policy can be part of a relevant Data Protection Impact
Assessment (as discussed in Task 4, above).422
Informing the data subjects:

The WP29 clarifies the requirements on the informing of data subjects of a data breach as
follows:
In certain cases, as well as notifying the supervisory authority, the controller is also
required to communicate a breach to the affected individuals.
Article 34(1) states:
421
WP29 Guidelines, Section V.B, pp. 27 – 28.
422
216
(CC)
The DPO Handbook
When the personal data breach is likely to result in a high risk to the rights and
freedoms of natural persons, the controller shall communicate the personal data
breach to the data subject without undue delay.
Controllers should recall that notification to the supervisory authority is mandatory
unless there is unlikely to be a risk to the rights and freedoms of individuals as a result
of a breach. In addition, where there is likely a high risk to the rights and freedoms of
individuals as the result of a breach, individuals must also be informed. The threshold
for communicating a breach to individuals is therefore higher than for notifying
supervisory authorities and not all breaches will therefore be required to be
communicated to individuals, thus protecting them from unnecessary notification
fatigue.
The GDPR states that communication of a breach to individuals should be made
“without undue delay,” which means as soon as possible. The main objective of
notification to individuals is to provide specific information about steps they should
take to protect themselves36. As noted above, depending on the nature of the breach
and the risk posed, timely communication will help individuals to take steps to protect
themselves from any negative consequences of the breach.
An annex (Annex B) to the WP29 Guidelines, which provides a (non exhaustive) list of 10
examples of personal data breaches and who should be notified, is attached to the
discussion of the present task as an Attachment.
The WP29 Guidelines continue as follows:423
Information to be provided
When notifying individuals, Article 34(2) specifies that:
The communication to the data subject referred to in paragraph 1 of this Article
shall describe in clear and plain language the nature of the personal data breach
and contain at least the information and measures referred to in points (b), (c) and
(d) of Article 33(3).
According to this provision, the controller should at least provide the following
information:
a description of the nature of the breach;
the name and contact details of the data protection officer or other contact
point;
a description of the likely consequences of the breach; and
a description of the measures taken or proposed to be taken by the controller
to address the breach, including, where appropriate, measures to mitigate its
possible adverse effects.
Example:
As an example of the measures taken to address the breach and to mitigate its
possible adverse effects, the controller could state that, after having notified the
breach to the relevant supervisory authority, the controller has received advice on
managing the breach and lessening its impact. The controller should also, where
appropriate, provide specific advice to individuals to protect themselves from possible
adverse consequences of the breach, such as resetting passwords in the case where
423
Section III.B, p. 20. Text edited for presentation only.
217
(CC)
The DPO Handbook
their access credentials have been compromised. Again, a controller can choose to
provide information in addition to what is required here.
The Guidelines also clarify that:424
In principle, the relevant breach should be communicated to the affected data
subjects directly, unless doing so would involve a disproportionate effort. In such a
case, there shall instead be a public communication or similar measure whereby the
data subjects are informed in an equally effective manner (Article 34(3)c).
The communications to data subjects should be made “as soon as reasonably feasible and in
close cooperation with the supervisory authority” (Recital 86). As the Guidelines note:425
Controllers might therefore wish to contact and consult the supervisory authority not
only to seek advice about informing data subjects about a breach in accordance with
Article 34, but also on the appropriate messages to be sent to, and the most
appropriate way to contact, individuals.
Linked to this is the advice given in Recital 88 that notification of a breach should
“take into account the legitimate interests of law enforcement authorities where early
disclosure could unnecessarily hamper the investigation of the circumstances of a
personal data breach”. This may mean that in certain circumstances, where justified,
and on the advice of law enforcement authorities, the controller may delay
communicating the breach to the affected individuals until such time as it would not
prejudice such investigations. However, data subjects would still need to be promptly
informed after this time.
Whenever it is not possible for the controller to communicate a breach to an
individual because there is insufficient data stored to contact the individual, in that
particular circumstance the controller should inform the individual as soon as it is
reasonably feasible to do so (e.g. when an individual exercises their Article 15 right to
access personal data and provides the controller with necessary additional
information to contact them).
Exceptions:
As the WP29 Guidelines note:426
Article 34(3) states three conditions that, if met, do not require notification to
individuals in the event of a breach. These are:
The controller has applied appropriate technical and organisational measures
to protect personal data prior to the breach, in particular those measures that
render personal data unintelligible to any person who is not authorised to
access it. This could, for example, include protecting personal data with state
of the art encryption, or by tokenization.
Immediately following a breach, the controller has taken steps to ensure that
the high risk posed to individuals’ rights and freedoms is no longer likely to
materialise. For example, depending on the circumstances of the case, the
controller may have immediately identified and taken action against the
individual who has accessed personal data before they were able to do
424
Section III.C, p. 21; see there for further guidance on the alternative ways to communicate a data
breach to affected data subjects.
425
Idem, pp. 21 – 22.
426
Section III.D, p. 22.
218
(CC)
The DPO Handbook
anything with it. Due regard still needs to be given to the possible
consequences of any breach of confidentiality, again, depending on the nature
of the data concerned.
It would involve disproportionate effort to contact individuals, perhaps where
their contact details have been lost as a result of the breach or are not known
in the first place. For example, the warehouse of a statistical office has
flooded and the documents containing personal data were stored only in
paper form. Instead, the controller must make a public communication or take
a similar measure, whereby the individuals are informed in an equally
effective manner. In the case of disproportionate effort, technical
arrangements could also be envisaged to make information about the breach
available on demand, which could prove useful to those individuals who may
be affected by a breach, but the controller cannot otherwise contact.
In accordance with the accountability principle controllers should be able to
demonstrate to the supervisory authority that they meet one or more of these
conditions. It should be borne in mind that while notification may initially not be
required if there is no risk to the rights and freedoms of natural persons, this may
change over time and the risk would have to be re evaluated.
If a controller decides not to communicate a breach to the individual, Article 34(4)
explains that the supervisory authority can require it to do so, if it considers the
breach is likely to result in a high risk to individuals. Alternatively, it may consider that
the conditions in Article 34(3) have been met in which case notification to individuals
is not required. If the supervisory authority determines that the decision not to notify
data subjects is not well founded, it may consider employing its available powers and
sanctions.
Assessing risk and high risk:
Once again, it may suffice to quote the WP29 Guidelines:427
Although the GDPR introduces the obligation to notify a breach, it is not a
requirement to do so in all circumstances:
Notification to the competent supervisory authority is required unless a
breach is unlikely to result in a risk to the rights and freedoms of individuals.
Communication of a breach to the individual is only triggered where it is likely
to result in a high risk to their rights and freedoms.
This means that immediately upon becoming aware of a breach, it is vitally important
that the controller should not only seek to contain the incident but it should also
assess the risk that could result from it. There are two important reasons for this:
firstly, knowing the likelihood and the potential severity of the impact on the
individual will help the controller to take effective steps to contain and address the
breach; secondly, it will help it to determine whether notification is required to the
supervisory authority and, if necessary, to the individuals concerned.
As explained above, notification of a breach is required unless it is unlikely to result in
a risk to the rights and freedoms of individuals, and the key trigger requiring
communication of a breach to data subjects is where it is likely to result in a high risk
to the rights and freedoms of individuals. This risk exists when the breach may lead to
427
Section IV.A and B, p. 23, references omitted; again somewhat edited for presentation purposes.
219
(CC)
The DPO Handbook
physical, material or non material damage for the individuals whose data have been
breached.
Examples:
Examples of such damage are discrimination, identity theft or fraud, financial loss and
damage to reputation. When the breach involves personal data that reveals racial or
ethnic origin, political opinion, religion or philosophical beliefs, or trade union
membership, or includes genetic data, data concerning health or data concerning sex
life, or criminal convictions and offences or related security measures, such damage
should be considered likely to occur.
Factors to consider when assessing risk
Recitals 75 and 76 of the GDPR suggest that generally when assessing risk,
consideration should be given to both the likelihood and severity of the risk to the
rights and freedoms of data subjects. It further states that risk should be evaluated on
the basis of an objective assessment.
It should be noted that assessing the risk to people’s rights and freedoms as a result of
a breach has a different focus to the risk considered in a DPIA)40. The DPIA considers
both the risks of the data processing being carried out as planned, and the risks in case
of a breach. When considering a potential breach, it looks in general terms at the
likelihood of this occurring, and the damage to the data subject that might ensue; in
other words, it is an assessment of a hypothetical event. With an actual breach, the
event has already occurred, and so the focus is wholly about the resulting risk of the
impact of the breach on individuals.
Example:
A DPIA suggests that the proposed use of a particular security software product to
protect personal data is a suitable measure to ensure a level of security appropriate to
the risk the processing would otherwise present to individuals. However, if a
vulnerability becomes subsequently known, this would change the software’s
suitability to contain the risk to the personal data protected and so it would need to
be re assessed as part of an ongoing DPIA.
A vulnerability in the product is later exploited and a breach occurs. The controller
should assess the specific circumstances of the breach, the data affected, and the
potential level of impact on individuals, as well as how likely this risk will materialise.
Accordingly, when assessing the risk to individuals as a result of a breach, the
controller should consider the specific circumstances of the breach, including the
severity of the potential impact and the likelihood of this occurring. WP29 therefore
recommends the assessment should take into account the following criteria:428
The type of breach
The type of breach that has occurred may affect the level of risk presented to
individuals.
428
Article 3.2 of Regulation 611/2013 provides guidance the factors that should be taken into
consideration in relation to the notification of breaches in the electronic communication services sector, which
may be useful in the context of notification under the GDPR. See:
http://eur lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:173:0002:0008:en:PDF [original footnote]
220
(CC)
The DPO Handbook
Example:
A confidentiality breach whereby medical information has been disclosed to
unauthorised parties may have a different set of consequences for an individual to a
breach where an individual’s medical details have been lost, and are no longer
available.
The nature, sensitivity, and volume of personal data
Of course, when assessing risk, a key factor is the type and sensitivity of personal data
that has been compromised by the breach. Usually, the more sensitive the data, the
higher the risk of harm will be to the people affected, but consideration should also be
given to other personal data that may already be available about the data subject. For
example, the disclosure of the name and address of an individual in ordinary
circumstances is unlikely to cause substantial damage. However, if the name and
address of an adoptive parent is disclosed to a birth parent, the consequences could
be very severe for both the adoptive parent and child.
Breaches involving health data, identity documents, or financial data such as credit
card details, can all cause harm on their own, but if used together they could be used
for identity theft. A combination of personal data is typically more sensitive than a
single piece of personal data.
Some types of personal data may seem at first relatively innocuous, however, what
that data may reveal about the affected individual should be carefully considered. A
list of customers accepting regular deliveries may not be particularly sensitive, but the
same data about customers who have requested that their deliveries be stopped
while on holiday would be useful information to criminals.
Similarly, a small amount of highly sensitive personal data can have a high impact on
an individual, and a large range of details can reveal a greater range of information
about that individual. Also, a breach affecting large volumes of personal data about
many data subjects can have an effect on a corresponding large number of individuals.
Ease of identification of individuals
An important factor to consider is how easy it will be for a party who has access to
compromised personal data to identify specific individuals, or match the data with
other information to identify individuals. Depending on the circumstances,
identification could be possible directly from the personal data breached with no
special research needed to discover the individual’s identity, or it may be extremely
difficult to match personal data to a particular individual, but it could still be possible
under certain conditions. Identification may be directly or indirectly possible from the
breached data, but it may also depend on the specific context of the breach, and
public availability of related personal details. This may be more relevant for
confidentiality and availability breaches.
As stated above, personal data protected by an appropriate level of encryption will be
unintelligible to unauthorised persons without the decryption key. Additionally,
appropriately implemented pseudonymisation (defined in Article 4(5) as “the
processing of personal data in such a manner that the personal data can no longer be
attributed to a specific data subject without the use of additional information,
provided that such additional information is kept separately and is subject to technical
and organisational measures to ensure that the personal data are not attributed to an
identified or identifiable natural person”) can also reduce the likelihood of individuals
221
(CC)
The DPO Handbook
being identified in the event of a breach. However, pseudonymisation techniques
alone cannot be regarded as making the data unintelligible.
Severity of consequences for individuals.
Depending on the nature of the personal data involved in a breach, for example,
special categories of data, the potential damage to individuals that could result can be
especially severe, in particular where the breach could result in identity theft or fraud,
physical harm, psychological distress, humiliation or damage to reputation. If the
breach concerns personal data about vulnerable individuals, they could be placed at
greater risk of harm.
Whether the controller is aware that personal data is in the hands of people whose
intentions are unknown or possibly malicious can have a bearing on the level of
potential risk. There may be a confidentiality breach, whereby personal data is
disclosed to a third party, as defined in Article 4(10), or other recipient in error. This
may occur, for example, where personal data is sent accidentally to the wrong
department of an organisation, or to a commonly used supplier organisation. The
controller may request the recipient to either return or securely destroy the data it
has received. In both cases, given that the controller has an ongoing relationship with
them, and it may be aware of their procedures, history and other relevant details, the
recipient may be considered “trusted”. In other words, the controller may have a level
of assurance with the recipient so that it can reasonably expect that party not to read
or access the data sent in error, and to comply with its instructions to return it. Even if
the data has been accessed, the controller could still possibly trust the recipient not to
take any further action with it and to return the data to the controller promptly and to
co operate with its recovery. In such cases, this may be factored into the risk
assessment the controller carries out following the breach – the fact that the recipient
is trusted may eradicate the severity of the consequences of the breach but does not
mean that a breach has not occurred. However, this in turn may remove the likelihood
of risk to individuals, thus no longer requiring notification to the supervisory authority,
or to the affected individuals. Again, this will depend on case by case basis.
Nevertheless, the controller still has to keep information concerning the breach as
part of the general duty to maintain records of breaches ( … ).
Consideration should also be given to the permanence of the consequences for
individuals, where the impact may be viewed as greater if the effects are long term.
Special characteristics of the individual
A breach may affect personal data concerning children or other vulnerable individuals,
who may be placed at greater risk of danger as a result. There may be other factors
about the individual that may affect the level of impact of the breach on them.
Special characteristics of the data controller
The nature and role of the controller and its activities may affect the level of risk to
individuals as a result of a breach. For example, a medical organisation will process
special categories of personal data, meaning that there is a greater threat to
individuals if their personal data is breached, compared with a mailing list of a
newspaper.
The number of affected individuals
A breach may affect only one or a few individuals or several thousand, if not many
more. Generally, the higher the number of individuals affected, the greater the impact
of a breach can have. However, a breach can have a severe impact on even one
222
(CC)
The DPO Handbook
individual, depending on the nature of the personal data and the context in which it
has been compromised. Again, the key is to consider the likelihood and severity of the
impact on those affected.
General points
Therefore, when assessing the risk that is likely to result from a breach, the controller
should consider a combination of the severity of the potential impact on the rights
and freedoms of individuals and the likelihood of these occurring. Clearly, where the
consequences of a breach are more severe, the risk is higher and similarly where the
likelihood of these occurring is greater, the risk is also heightened. If in doubt, the
controller should err on the side of caution and notify. Annex B provides some useful
examples of different types of breaches involving risk or high risk to individuals.
The European Union Agency for Network and Information Security (ENISA) has
produced recommendations for a methodology of assessing the severity of a breach,
which controllers and processors may find useful when designing their breach
management response plan.429
o–O–o
429
ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches,
https://www.enisa.europa.eu/publications/dbn severity [original footnote]
223
(CC)
The DPO Handbook
Attachment:
Examples of personal data breaches and who to notify (From the WP29 Guidelines)
Example Notify the Notify the data Notes/recommendations

supervisory subject?
authority?
i. A controller stored No. No. As long as the data are

a backup of an encrypted with a state of
archive of personal the art algorithm,
data encrypted on a backups of the data exist
USB key. The key is the unique key is not
stolen during a compromised, and the
break in. data can be restored in
good time, this may not
be a reportable breach.
However if it is later
compromised,
notification is required.
ii. A controller Yes, report to the Yes, report to

maintains an online supervisory authority individuals
service. As a result of if there are likely depending on the
a cyber attack on that consequences to nature of the
service, personal individuals. personal data
data of individuals affected and if the
are exfiltrated. severity of the likely
consequences to
The controller has
individuals is high.
customers in a single
Member State.
iii. A brief power No. No. This is not a notifiable

outage lasting several breach, but still a
minutes at a recordable incident
controller’s call under Article 33(5).
centre meaning
Appropriate records
customers are unable
should be maintained by
to call the controller
the controller.
and access their
records
iv. A controller Yes, report to the Yes, report to If there was a backup
suffers a ransomware supervisory individuals, available and data could
attack which results authority, if there are depending on the be restored in good time,
in all data being likely consequences nature of the this would not need to be
encrypted. No back to individuals as this personal data reported to the
ups are available and is a loss of affected and the supervisory authority or
the data cannot be availability. possible effect of the to individuals as there
restored. On lack of availability of would have been no
investigation, it the data, as well as permanent loss of
224
(CC)
The DPO Handbook
becomes clear that other likely availability or
the ransomware’s consequences. confidentiality. However,
only functionality if the supervisory
was to encrypt the authority became aware
data, and that there of the incident by other
was no other means, it may consider
malware present in an investigation to assess
the system. compliance with the
broader security
requirements of Article
32.
v. An individual Yes. Only the individuals If, after further

phones a bank’s call affected are notified investigation, it is
centre to report a if there is high risk identified that more
data breach. The and it is clear that individuals are affected,
individual has others were not an update to the
received a monthly affected. supervisory authority
statement for must be made and the
someone else. controller takes the
additional step of
The controller
notifying other
undertakes a short
individuals if there is high
investigation (i.e.
risk to them.
completed within 24
hours) and
establishes with a
reasonable
confidence that a
personal data breach
has occurred and
whether it has a
systemic flaw that
may mean other
individuals are or
might be affected.
vi. A controller Yes, report to lead Yes, as could lead to The controller should
operates an online supervisory authority high risk. take action, e.g. by
marketplace and has if involves cross forcing password resets
customers in multiple border processing. of the affected accounts,
Member States. The as well as other steps to
marketplace suffers a mitigate the risk.
cyber attack and
The controller should
usernames,
also consider any other
passwords and
notification obligations,
purchase history are
e.g. under the NIS
published online by
Directive as a digital
the attacker.
service provider.
vii. A website hosting As the processor, the If there is likely no The website hosting
company acting as a website hosting high risk to the company (processor)
225
(CC)
The DPO Handbook
data processor company must notify individuals they do must consider any other
identifies an error in its affected clients not need to be notification obligations
the code which (the controllers) notified. (e.g. under the NIS
controls user without undue delay. Directive as a digital
authorisation. The service provider).
Assuming that the
effect of the flaw
website hosting If there is no evidence of
means that any user
company has this vulnerability being
can access the
conducted its own exploited with any of its
account details of
investigation the controllers a notifiable
any other user.
affected controllers breach may not have
should be reasonably occurred but it is likely to
confident as to be recordable or be a
whether each has matter of non
suffered a breach and compliance under Article
therefore is likely to 32.
be considered as
having “become
aware” once they
have been notified by
the hosting company
(the processor). The
controller then must
notify the supervisory
authority.
viii. Medical records Yes, the hospital is Yes, report to the

in a hospital are obliged to notify as affected individuals.
unavailable for the high risk to patient’s
period of 30 hours well being and
due to a cyber privacy may occur.
attack.
ix. Personal data of a Yes, report to Yes, report to

large number of supervisory individuals
students are authority. depending on the
mistakenly sent to scope and type of
the wrong mailing list personal data
with 1000+ involved and the
recipients. severity of possible
consequences.
x. A direct marketing Yes, notifying the Yes, report to Notification may not be
e mail is sent to supervisory authority individuals necessary if no sensitive
recipients in the “to:” may be obligatory if a depending on the data is revealed and if
or “cc:” fields, large number of scope and type of only a minor number of
thereby enabling individuals are personal data email addresses are
each recipient to see affected, if sensitive involved and the revealed.
the email address of data are revealed severity of possible
other recipients. (e.g. a mailing list of a consequences.
psychotherapist) or if
other factors present
226
(CC)
The DPO Handbook
high risks (e.g. the
mail contains the
initial passwords).
o–O–o
227
(CC)
The DPO Handbook
TASK 7: Investigation task (including the handling of both internal and

external complaints)
Note: This task is separate and distinct from the handling of data subjects’ requests for access,
correction, etc., as addressed in Task 8.
Investigation
Although this is not explicitly mentioned in the GDPR, it follows from the broad descriptions
of the DPO’s overall position and tasks – and in particular from her duty to “monitor
compliance” with the GDPR: Art. 39(1)(b) – that the DPO may, on her own initiative or at the
request of management or, e.g., of the staff representative body or trade union, or indeed
of any individual (from within or without the organisation, or even a whistleblower, who is
hopefully protected in the country concerned) investigate matters and occurrences directly
relating to her tasks and report back to the person or body who commissioned or requested
the investigation and/or to top management. As the EDPS puts it in his Position Paper on
DPOs:430
Monitoring of compliance( … ): the DPO is to ensure the application of the Regulation
within the institution. The DPO may, on his own initiative or at the request of the
institution or body, the controller, the staff committee or any individual investigate
matters and occurrences directly relating to his/her tasks and report back to the
person who commissioned the investigation or to the controller.
The GDPR makes clear – albeit in less explicit terms than the Annex to the EU institutional
data protection regulation – that DPOs must be given all relevant resources and access to
all data and premises, data processing installations and data carriers (with all relevant and
necessary authentication and log access and retention powers) needed to carry out her
tasks (cf. Art. 38(2)), i.e., also in relation to such investigations.431 Similarly, although again
this is stated more explicitly in relation to EU institutional DPOs than to DPOs appointed
under the GDPR, all of the relevant controller’s staff – and indeed any external agencies’
staff, including in particular processors (including cloud service providers used by the
controller) – should fully assist the DPO in any such investigations, and give full
answersand information in response to any questions or requests from the
DPO.432Controllers should make this explicitly clear in internal staff guidance, and include
clear clauses to this effect in their contracts with external providers and processors.
Enforcement
Despite having competence to monitor compliance with the GDPR, to handle complaints,
and to investigate possible breaches of the Regulation, the DPO has limited powers of
enforcement. In principle, as noted, above, if the DPO finds that the GDPR has in some
respect not been complied with by her organisation, or by any external provider or
processor, the DPO should report this to senior management – and it is then the
430
EDPS, Position paper on the role of Data Protection Officers in ensuring effective compliance with
Regulation (EC) 45/2001 (footnote 243, above), p.6, original emphasis in bold.
431
The Annex to Regulation (EU) 45/2001 stipulates that EU institutional DPOs: “shall have access at all
times to the data forming the subject matter of processing operations and to all offices, data processing
installations and data carriers.” (Annex, article 4, second sentence).
432
The Annex to Regulation (EU) 45/2001 stipulates that: “Every controller concerned shall be required to
assist the Data Protection Officer in performing his or her duties and to give information in reply to questions.”
(Annex, Art. 4, first sentence).
228
(CC)
The DPO Handbook
responsibility of senior management to take corrective action including, where appropriate,
sanctions against any staff or agents or processors that have failed in their relevant duties,
e.g., by issuing warnings or other penalties or, in extreme cases, dismissal or termination of
contracts. For instance, if an outside service provider is used to collect data (e.g., through
automated systems operated by the provider), and that provider does not comply with the
GDPR, e.g., in terms of information notices or, worse, by using the collected data
surreptitiously for further (undeclared) purposes, the DPO should propose that the
controller uses another provider, and at the same time alert the DPA.
Failure to take such action will count against the controller (the organisation) in the
consideration of enforcement action by the state data protection authority (DPA), including
in setting the level of any “administrative fine” that may be imposed (cf. Art. 83).
Moreover, one of the tasks of the DPO is to “consult” the relevant DPA “where
appropriate”, with regard to any matter arising (Art. 39(1)(e)). In case of a serious difference
of views between the DPO and her organisation’s top management, when it is the view of
the DPO that a particular processing operation is or will be in (significant) breach of the
GDPR and/or relevant national law, but which management still wants to undertake, or
against which it intends to take no sanction, it would certainly seem to be “appropriate” for
the DPO to exercise this power and (effectively) refer the matter to the DPA. It will then be
up to the DPA to use its – strong – investigative and enforcement powers, including the
possibility to order the non implementation or stopping of the operation, as it (the DPA)
deems appropriate (see Art. 58(2)(d) and (f) in particular).
See further below, under the headings “Cooperation with and consultation of the DPA” and
“Handling queries and complaints”.
o–O–o
229
(CC)
The DPO Handbook
Advisory tasks
TASK 8: Advisory task – general
DPOs must ensure that the Regulation is respected and advise controllers on fulfilling their
obligations. The DPO may therefore inform, offer advice or make recommendations for the
practical improvement of data protection by the organisation and/or on matters concerning
the application of data protection provisions (i.e., of the GDPR and other EU data protection
law – such as, for now, the 2002 e Privacy Directive and, in future, a possible e Privacy
Regulation – and of any national aw expanding on the “specification clauses” in the GDPR or
otherwise applicable); and for the amending and updating of the organisation’s data
protection policies and practices in the light of new legal instruments, decisions, measures
or guidance (cf. Art. 39(1)(a)).
To this end, the DPO should be enabled to closely follow legislative and regulatory
developments in the areas of data protection, data security, etc., so as to alert senior and
relevant lower management of upcoming new EU instruments (such as the e Privacy
Regulation, just mentioned) or new EU level executive or judicial decisions (such as any
relevant new “adequacy” decision by the European Commission relating to third countries
to which the DPO’s organisation transfers data, or relevant judgments by the CJEU); new
EU level guidance (in particular, any opinions or recommendations, etc., issued by the
EDPB); and similar instruments, decisions, measures or guidance issued in the DPO’s own
country (or countries) of establishment. The GDPR indeed requires every controller with a
DPO to provide the DPO with “[all] resources necessary to carry out [his or her] task … and
to maintain his or her expert knowledge” (Art. 38(2)). The DPO should therefore be allowed
– and indeed encouraged – to attend relevant seminars, conferences and meetings, in
particular any organised by the national or regional state data protection authority (or ies).
The DPO may also beconsulted by management, the staff representative body or trade
union, or indeed of any staff member, including of course in particular any “business
owners”/persons within the organisation with specific responsibilities for a specific
processing operation, whenever such a person may want advice – and indeed generally
must be consulted on relevant matters (cf. also Task 7, discussed next).
As the WP29 put it in its Guidance on DPOs (since formally endorsed by the EDPB):433
Consequently, the organisation should ensure, for example, that:
The DPO is invited to participate regularly in meetings of senior and middle
management.
His or her presence is recommended where decisions with data protection
implications are taken. All relevant information must be passed on to the DPO
in a timely manner in order to allow him or her to provide adequate advice.
The opinion of the DPO must always be given due weight. In case of
disagreement, the WP29 recommends, as good practice, to document the
reasons for not following the DPO’s advice.
The DPO must be promptly consulted once a data breach or another incident
has occurred.
Where appropriate, the controller or processor could develop data protection
guidelines or programmes that set out when the DPO must be consulted.
433
WP29, Guidelines on DPOs (footnote 242, above), pp. 13 – 14.
230
(CC)
The DPO Handbook
TASK 9: Supporting and promoting “Data Protection by Design & Default”

As noted in the discussion of Task 6, above, the DPO must generally be consulted on any
matter relating to data protection that arises within her organisation, including in the
drafting of general policy guidelines, etc.
However, there is one matter that is of particular importance in this regard. This is the new
explicit requirement of the GDPR (not yet spelled out in the 1995 Data Protection Directive,
although it could already be, and was, read into that),434 that controllers embed the
principle of “data protection by design and by default” (which includes the principle of
“security by design [and default]”)435 into all their operations. As it is put in Article 25:
Article 25
Data protection by design and by default
1. Taking into account the state of the art, the cost of implementation and the nature,
scope, context and purposes of processing as well as the risks of varying likelihood and
severity for rights and freedoms of natural persons posed by the processing, the
controller shall, both at the time of the determination of the means for processing and
at the time of the processing itself, implement appropriate technical and
organisational measures, such as pseudonymisation, which are designed to implement
data protection principles, such as data minimisation, in an effective manner and to
integrate the necessary safeguards into the processing in order to meet the
requirements of this Regulation and protect the rights of data subjects.
2. The controller shall implement appropriate technical and organisational measures for
ensuring that, by default, only personal data which are necessary for each specific
purpose of the processing are processed. That obligation applies to the amount of
personal data collected, the extent of their processing, the period of their storage and
their accessibility. In particular, such measures shall ensure that by default personal
data are not made accessible without the individual's intervention to an indefinite
number of natural persons.
3. … 436
We can only briefly discuss the principle here. The EDPS sums up the general concept and
its background as follows:437
The term “privacy by design” was originally used by Ann Cavoukian when she was the
Information and Privacy Commissioner of Ontario, Canada. In her concept, privacy by
434
Cf., for instance, the repeated reference to the principle in the WP29 Opinion 8/2014 on the on
Recent Developments on the Internet of Things (WP223), adopted on 16 September 2014, available at:
435
Cf. WP223 (previous footnote), p. 22, penultimate bullet point.
436
The third paragraph stipulates that: “An approved certification mechanism pursuant to Article 42 may
be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this
Article.” This is discussed in relation to Task 9, below.
437
EDPS, Preliminary Opinion on privacy by design (Opinion 5/2018), issued on 31 May 2018, p. 4, para.
17 (original italics),available at:
https://edps.europa.eu/sites/edp/files/publication/18 05
31_preliminary_opinion_on_privacy_by_design_en_0.pdf (emphases added)
Note that the EDPS distinguishes the broader principle of “privacy by design”, which has a “visionary and
ethical dimension”, from the more specific legal “data protection by design” and “data protection by default”
requirements of Article 25 GDPR: p. 1, para. 4.
231
(CC)
The DPO Handbook
design can be broken down into “7 foundational principles”,438 emphasising the need
to be proactive in considering the privacy [or in EU terms: data protection]
requirements as of the design phase throughout the entire data lifecycle, to be
“embedded into the design and architecture of IT systems and business
practices...without diminishing functionality...”, with privacy as the default settings,
end to end security including secure data destruction and strong transparency subject
to independent verification. The principle of privacy by default was elicited as the
second of the foundational principles, establishing that privacy by design involves
“ensuring that personal data are automatically protected in any given IT system or
business practice. If an individual does nothing, their privacy still remains intact. No
action is required on the part of the individual to protect their privacy — it is built into
the system, by default”. This statement, is a powerful operational definition of the
principle of privacy by default, where the individual does not bear the burden of
striving for protection when using a service or a product but enjoys “automatically”
(no need for active behaviour) the fundamental right of privacy and personal data
protection.
In the view of the EDPS, “data protection by design” has several dimensions; to
paraphrase:439
- the first dimension is that personal data processing operations should always
be the outcome of a design project, covering the whole project lifecycle,
within which the data protection risks and requirements should be clearly
identified;
- the second dimension is that the design project should be based on a risk
management approach, within which the assets to be protected are the
individuals whose data are to be processed and in particular their
fundamental rights and freedoms;
- the third dimension is that the measures to be taken to protect those
individuals and rights and freedoms must be appropriate and effective in
relation to those risks, viewed in the light of the data protection principles set
out in Article 5 GDPR, which can be seen as goals to achieve;
- the fourth dimension is the obligation to integrate the identified [necessary,
appropriate and effective] safeguards into the processing.
He adds that:440
All four dimensions are equally important and become an integral part of
accountability and will be subject to supervision from the competent data protection
supervisory authorities where appropriate.
The EDPS stresses the importance of data protection by design and default in relation to a
variety of actors: controllers and processors generally;441 developers of (privacy sensitive)
438
See: The “seven foundational principles” are: 1. Proactive not Reactive, Preventative not Remedial; 2.
Privacy as the Default Setting; Privacy Embedded into Design; 4. Full Functionality — Positive Sum, not Zero
Sum; 5. End to End Security — Full Lifecycle Protection; 6. Visibility and Transparency — Keep it Open; 7.
Respect for User Privacy — Keep it User Centric. [original footnote] https://www.ipc.on.ca/wp
content/uploads/2018/01/pbd.pdf.
439
For the full details of these dimensions as viewed by the EDPS, see his Preliminary Opinion 5/2018
(footnote 437, above), pp. 6 – 7 (paras. 27 – 32).
440
Idem, p. 7, para. 32, emphasis in bold added.
232
(CC)
The DPO Handbook
products and technologies;442 e communication services;443 e identity services;444 providers
of “smart” maters and grids.445 In relation to public administrations, the EDPS stresses
that:446
Article 25 applies to all types of organisations acting as controllers, including public
administrations, which, considering their role to serve the public good, should give
the example in protecting individuals’ fundamental rights and freedoms. The GDPR
stresses the role of data protection by design and by default when public
administrations need to identify their providers of products and services in Recital 78,
stating the “The principles of data protection by design and by default should also be
taken into consideration in the context of public tenders”.Public administration are
called be in the frontline in applying these principles in an accountable way, ready to
demonstrate their implementation, if necessary, to the competent supervisory
authority.
The reference to public tenders is especially important: DPOs should advise their
organisation that in issuing such tenders, public administrations should expressly call for
applicants that can “demonstrate” that their product or service fully complies with the
GDPR (and other relevant EU and national data protection law),447 and that have embedded
“data protection by design and default” in the relevant product or service. It should indeed
be possible to give a competitive advantage to such applicants over and above applicants
with products or services that cannot be shown to meet those requirements.448
The EDPS discusses at some length the various methodologies that have been developed to
implement data protection by design and default.449 These cannot be set out here in full or
even paraphrased – but DPOs should fully familiarise themselves with them (indeed, in
more detail than is provided in the EDPS paper). Suffice it to note that the EDPS rightly links
privacy by design and default to data protection impact assessments (DPIAs), as discussed
in Task 4, above);450 and more generally that, as the EDPS also expressly stresses:451
The role of privacy and data protection officers is central and their involvement is
crucial in a privacy by design approach. They need to be in the loop from the early
stages when organisations plan systems for the processing of personal data, so that
they can support managers, business owners and IT and technology departments as
necessary. Their skill set should match these requirements.
That “skill set” should include being fully educated and trained in the relevant
methodologies and technologies (if needs be, by additional in the job training), and being
441
Idem, p. 7, paras. 35 – 36.
442
Idem, p. 7, para. 37.
443
Idem, pp. 8 – 9, paras. 42 – 44 (with reference to the e Privacy Directive and the proposed e Privacy
Regulation).
444
Idem, p. 9, para. 45 (with reference to the eIDAS Regulation).
445
Idem, pp. 9 – 10, paras. 46 – 50 (with reference to the Smart Meter DPIA Template Recommendation).
446
Idem, p. 8, para. 38, original italics, emphasis in bold added.
447
See the discussion of the “accountability” principle in Part Two, section 2.4, above.
448
This approach is expressly adopted under the Schleswig Holstein data protection law.
449
EDPS, Preliminary Opinion 5/2018 (footnote 437, above), pp. 13 – 15, paras. 63 – 72. See also the
specific references to the U.S. NIST privacy engineering program and its report on privacy engineering and risk
management for U.S. federal systems (p. 11, para. 56, footnotes 76 and 74) and the EU ENISA 2014 analysis of
the (then) state of the art (p. 12, para. 59, footnote 82.
450
Idem, p. 8, paras. 39 – 40.
451
Idem, p. 15, para. 76, emphasis added.
233
(CC)
The DPO Handbook
deeply involved in the design, development, testing and tuning of all privacy sensitive
products, services and actions of their organisation (including tendering, as just noticed), at
all stages.
o–O–o–
234
(CC)
The DPO Handbook
TASK 10: Advise on and monitoring of compliance with data protection

policies, joint controller , controller controller and controller
processor contracts, Binding Corporate Rules and data transfer
clauses
In order to comply with the GDPR, and especially in order to “demonstrate” such
compliance, controllers can and should adopt or sign up to a range of measures. As noted in
section 2.2.2, above, these include:
drawing up and formally adopting internal data protection policies (see Art. 24(2))
to regulate matters such as:
the organisation’s paper forms, web forms and data protection/privacy
statements on websites, the use of cookies and other trackers;
access and alteration logs, etc. in relevant soft and hardware;
the issuing of “patches” for its own software;
etcetera;
adopting administrative agreements (“arrangements”) between public authorities
or bodies, especially if they can be said to be “joint controllers” over certain
processing operations;
drafting and agreeing relevant contracts with other controllers and processors; and
signing up to or drafting standard or individually approved data transfer contracts.
The main point to be re emphasised here is that these are all responsibilities (“compliance
demonstration” means) of the controller rather than the DPO (see the sub section on “The
non responsibility of the DPO for compliance with the GDPR”, in Part Two, section 2.5.4,
above).
However, in practice the DPO should again be closely involved in all these matters. At the
very least, any new DPO – and especially any DPO appointed to an organisation that did not
previously have a DPO – should review any existing documents and instruments of this kind,
to see if they still fully meet all the data protection legal requirements.
On the basis of such a review, she should recommend changes in existing documents etc. –
especially if those were drawn up and adopted prior to the adoption and coming into force
of the GDPR; and she should recommend the drafting and adoption of such documents etc.
where (in her view) there should be such documents etc., but there are not.
And the DPO is formally charged with then monitoring compliance with any policies,
arrangements and contracts adopted or entered into by the controller in relation to
personal data processing (cf. Art. 39(1)(b)).
235
(CC)
The DPO Handbook
TASK 11: Involvement in codes of conduct and certifications

We noted in Part Two, section 2.2.2, above, that adherence to, and full compliance with, an
approved code of conduct or an approved data protection certification, could also serve as
important element or means to demonstrate compliance with the GDPR in relation to the
matters covered in such codes or certifications (without this amounting to legal proof of
compliance).
Again, it will ultimately be up to the controller – not the DPO – to decide whether to sign up
to a relevant code for the sector in which the organisation operates, or whether to seek to
obtain a data protection certification of the type envisaged in the Regulation (see Arts. 40 –
43). However, it would be perfectly acceptable for a DPO to recommend such action.
Indeed, it might be quite appropriate for DPOs of organisations operating in a certain sector
to be involved in the drafting of (a) code(s) of conduct for that sector, although it should
also involve legal counsel and staff members of the sectoral organisation under which wing
the code is drafted (including especially ICT staff if the code touches on technical issues such
as ICT security, encryption, etc.).
The DPO can also assist in the obtaining of a certification by her organisation, by helping to
put together or provide, to the Certification Body in question, “all information and access to
its processing activities which are necessary to conduct the certification procedure” (Art.
42(6)). However, where a certification scheme relies on an evaluation of the personal data
processing operations of the controller by one or moreindependent experts accredited by
the relevant Certification Body (as is done in the main current scheme in the EU, the
European Privacy Seal [EuroPriSe] scheme),452 the DPO cannot act in that role: that would
constitute a conflict of interest.
Note: To some extent, the detailed record of data protection impact assessments (DPIAs),
discussed in Task 4, above, and the continued monitoring of operations, discussed in Task 5, above
(and the records of that continuous monitoring) fulfil a similar function to certifications, in that these
records show that the controller and its staff have carefully looked at all the privacy/data protection
implications of the relevant personal data processing operations; have identified and quantified the
risks involved to the fundamental rights of the individuals affected; and have adopted appropriate
mitigating measures. The advantage of certifications over this is that the evaluation is done by
outside, independent experts. However, much will depend on the quality of the accredited
certification schemes and on how they will inter relate to enforcement by the DPAs.
o–O–o
452
See: https://www.european privacy seal.eu/EPS en/fact sheet
236
(CC)
The DPO Handbook
Cooperation with and consultation of the DPA

TASK 12: Cooperation with the DPA
The DPO has the task of responding to requests from the DPA and, within the sphere of her
competence, cooperate with the DPA at the latter's request or on his/her own initiative (Art.
39(1)(d)).
In this regard, the WP29 said that:453
These tasks refer to the role of ‘facilitator’ of the DPO mentioned in the introduction
to these Guidelines. The DPO acts as a contact point to facilitate access by the
supervisory authority to the documents and information for the performance of the
tasks mentioned in Article 57, as well as for the exercise of its investigative, corrective,
authorisation, and advisory powers mentioned in Article 58. As already mentioned,
the DPO is bound by secrecy or confidentiality concerning the performance of his or
her tasks, in accordance with Union or Member State law (Article 38(5)). However, the
obligation of secrecy/confidentiality does not prohibit the DPO from contacting and
seeking advice from the supervisory authority. Article 39(1)(e) provides that the DPO
can consult the supervisory authority on any other matter, where appropriate.
The EDPS has very usefully expanded further on the equivalent duties of the EU institutional
DPOs, in their relations with the EDPS, as set out in the quotes below with textual
amendments to apply the EDPS’s words, mutatis mutandis, to the relationship between the
Member States’ data protection authorities (DPAs) (and the EDPB) and DPOs appointed
under the GDPR. He first of all notes, in general terms, that:454
The DPO has the task of responding to requests from the [relevant data protection
authority] and, within the sphere of his competence, cooperate with the [DPA] at the
latter's request or on his/her own initiative. This task emphasises the fact that the
DPO facilitates cooperation between the [DPA] and the institution notably in the
frame of investigations, complaint handling or prior checks. The DPO not only has
inside knowledge of the institution, but is also likely to know who the best person to
contact within the institution is. The DPO may also be aware, and duly inform the
[DPA], of recent developments likely to impact the protection of personal data.
The EDPS then elaborates on this in regard to the various matters mentioned in terms that
largely also apply to the issues under the GDPR, as follows:455
IV. Relation DPO – [DPA]
Ensuring compliance with the Regulation will be influenced by the working
relationship between the DPO and the [relevant DPA]. The DPO must not be seen as
an agent of the [DPA], but as a part of the institution/body in which he/she works. As
already mentioned, this idea of proximity puts him/her in an ideal situation to ensure
compliance from the inside and to advise or to intervene at an early stage thereby
avoiding possible intervention from the supervisory body. At the same time the [DPA]
can offer valuable support to DPOs in the performance of their function.456
453
WP29, Guidelines on DPOs (footnote 242, above), p. 18.
454
EDPS, Position paper on DPOs (footnote 243, above),p. 6. Textual changes in square brackets.
455
Idem, Part IV (pp. 10 – 11).
456
Cf. the provision by the French data protection authority, the CNIL, of a special “extranet” for
registered DPOs, accessible only to them with a username and password, which provides them with legal texts
(laws, decrees, etc.) and training and information, including information on new reports or guidance issued by
237
(CC)
The DPO Handbook
The [DPAs can be expected to]457 therefore support[] the idea of developing possible
synergies between DPOs and the [DPAs] which would contribute to achieving the
overall aim of effective protection of personal data within the institutions.…
IV. 1. Ensuring compliance
Ensuring compliance notably starts by raising awareness. As mentioned above, DPOs
play an important role in developing knowledge on data protection issues inside the
institution/body. The [DPAs can be expected to]458 welcomes this and its consequence
in terms of stimulating an efficient preventive approach rather than repressive data
protection supervision.
The DPO also provides advice to the institution/body on practical recommendations
for improvement of data protection within the institution/body or concerning the
interpretation or application of the [GDPR].459 This advisory function is shared with the
[DPAs] who shall advise all [their domestic] institutions/bodies on matters concerning
the processing of personal data ([Article 57(1)(c) GDPR])). In this field the [national
DPOs have already in the past] often been called upon to advise DPOs on specific
issues related to data protection (case by case approach). The [DPAs and the EDPB can
be expected] to produce position papers on certain themes so as to afford guidance to
the institutions/bodies on certain more general topics.460
IV.2 Prior checks
Opinions delivered [by a DPA] in the framework of an [Article 36 GDPR prior
consultation] [and views expressed by DPAs in the process of issuing prior
authorisations as envisaged in Article 36(5) GDPR], are also the occasion for the [DPA]
to monitor and ensure compliance with the [GDPR]. …461
… [B]efore the final adoption of a prior check opinion, the [DPA may]462send[] a
provisional draft to the DPO with information on intended recommendations thereby
opening up room for discussion on efficiency and consequences of intended
the CNIL, and on other legal and practical developments, and allows them to exchange views and hold
discussions. See section 2.3.5, under the heading “Formal training and certification” and footnote 274, above.
457
The original sentence says the EDPS “supports” the idea. The DPAs (and the EDPB) can be expected to
take the same view.
458
The original sentence says the EDPS “welcomes” this approach, but (also in the light of past practice)
the DPAs (and the EDPB) can again be expected to take the same view.
459
The reference in the EDPS paper is to the regulation setting out the data protection rules for the EU
institutions themselves (Regulation (EC) 45/2001) (footnote 148, above), but the same is of course true in
relation to the GDPR as concerns DPOs appointed under that latter regulation. We have made similar
replacements elsewhere in the quote.
460
The original sentence says the EDPS “intends to produce” position papers and guidance. Again, the
national DPAs and the EDPB can be expected to do the same in relation to the GDPR.
mitted sentence reads: “” With regard to DPOs appointed under the GDPR, the national DPAs, but especially
also the new EDPB, will undoubtedly issue similar guidance.
461
The remainder of this paragraph, and the omitted sentence at the beginning of the next paragraph,
deal with the fact that the time gap between the entry into force of the Regulation and the appointment of the
EDPS created a large backlog of cases which are being “prior checked” on an "ex post" basis. It is not clear yet
if similar problems are arising under the GDPR. If so, the EDPS’s call for the DPOs and the regulator to be
“strategic partners” in resolving this should also be heeded in that context.
462
The practice of sending “provisional draft recommendations” to a controller in the context of a “prior
consultation”/“prior authorisation” process is not specified in the GDPR (or indeed in Regulation 45/2001).
However, the very fact that the GDPR refers to “prior consultation” strongly suggests that the DPAs will, under
that instrument, take a similar approach; and this is reflected in the wording in square brackets twice added to
this paragraph.
238
(CC)
The DPO Handbook
recommendations. The [DPAs can be expected] to be attentive to the concerns of the
institution as expressed by the DPO so as to work towards practicable
recommendations.
IV. 3. Enforcement
In the area of implementation of particular data protection measures, synergy
potentials between the DPOs and [DPAs] emerge as regards the adoption of sanctions
and handling of complaints and queries.
As already mentioned, the DPOs have limited powers of enforcement. The [DPA] will
contribute to ensuring compliance with the [GDPR] by taking effective measures in the
field of prior [consultations or authorisations] and of complaints and other inquiries.
Measures are effective if well targeted and feasible: the DPO can also be seen as a
strategic partner in determining the well targeted application of a measure.
The handling of complaints and queries by the DPO at a local level463 is to be
encouraged at least as concerns a first phase of investigation and resolution. The
[DPAs may]464 therefore [be expected to take the view] that DPOs should try to
investigate and resolve complaints at a local level before referring to the [DPA]. The
DPO should also … consult the [DPA] whenever he/she has doubts on the procedure
or content of complaints. This does not however prevent the data subject from
addressing him/herself directly to the [DPA] under [Article 77(1) GDPR]. The limited
powers of enforcement of the DPO also imply that in some cases, the complaint or
query must be escalated to the [DPA]. The [DPA] therefore provides for valuable
support in the field of enforcement. In turn, the DPO can be relied on to provide
information to the [DPA] and to provide follow up on the measures adopted.
IV.4. Measuring effectiveness465
As concerns measuring the effectiveness of the implementation of the data protection
requirements, the DPO must be seen as a useful partner to evaluate progress in this
area. For example, when it comes to measuring performance of internal data
protection supervision, the [DPAs can be expected to] encourage[] DPOs to develop
their own criteria of good supervision (professional standards, specific plans for the
institution, annual work programme...). These criteria will in turn enable the [DPA],
where invited to do so, to evaluate the work of the DPO, but will also serve to enable
him to measure the state of implementation of the [GDPR] within the
institution/body.
It is also likely that DPOs in the public sector will be called upon by their DPAs to
contribute to consultations held by the DPAs, and to provide input when a DPA is
463
Note that the handling of requests and complains from data subjects is further discussed in Task 11,
below.
464
The first two sentences in this paragraph again refer to EDPS promoted practice – but it is again (also
in view of past practice) fully to be expected that the national DPAs will take the same approach (as indicated
in the wording in square brackets).
465
There are no specific requirements, either in Regulation 45/2001 (with regard to the EU institutions),
or in the GDPR (with regard to entities covered by that instrument), for the relevant regulator (respectively,
the EDPS and the national DPAs) to “measure the effectiveness” of the measures adopted by controllers with
the aim of ensuring compliance with the applicable instrument. Within the EU institutional framework, the
EDPS does however (rightly) view this a natural part of his job. It is to be expected that the Member States’
DPAs (and the EDPB) will also “encourage” DPOs to contribute to high level compliance through the adoption
or adhesion of “professional standards, specific plans for the institution, annual work programme”, etc.; as is
again reflected in the wording in square brackets.
239
(CC)
The DPO Handbook
preparing a formal opinion on proposed or draft laws in the area of data protection that
touches on the context within which the DPO operates.
Finally, it should be noted that the DPO plays an important role in helping the DPA in its
carrying out on the spot inspections, in DPO consultations with controllers in specific
sectors, etc. For instance, it is rare for DPAs to carry out inspections without notice – this is
really only done in relation to suspected miscreants who may hide data or other evidence if
given prior warning of an inspection. In practice, DPAs normally pre arrange inspections
with the help of the controller, and in particular the controller’s DPO, who will be able to
ensure that the right people are available and the right places and systems can be
inspected. This is often crucial, especially in relation to complex processing systems where
in depth knowledge of the ICT architecture and internal processes is required for a proper
review. And when a DPA wants to examine in detail the processing of personal data in a
particular context or sector – as most of them do under an annually determined plan and
selection of priorities – they will turn to the DPOs of controllers active in the context or
sector for real insight, holding meetings with them and asking for responses to
consultations. This too is part of what the EDPS calls the “strategic partnership” between
DPOs and DPAs.
o–O–o
240
(CC)
The DPO Handbook
Handling data subject requests

TASK 13: Handling data subject requests and complaints
The GDPR stipulates that:
Data subjects may contact the data protection officer with regard to all issues related
to processing of their personal data and to the exercise of their rights under this
Regulation.
(Art. 38(4))
Data subjects who want to exercise any of their data subject rights – rights of access,
rectification and erasure (“right to be forgotten”), restriction of processing, data portability,
right to object in general and in relation to automated decision making and profiling – in
respect of an organisation, or who have general questions or data protection related
complaints about the organisation, should therefore normally address themselves first of all
to the DPO of that organisation (where there is one).
This is facilitated by the requirement in the GDPR that the contact details of the DPO must
be published by the organisation (Art. 37(7)) and that the controller must ensure “that the
data protection officer is involved, properly and in a timely manner, in all issues which relate
to the protection of personal data [relating to the organisation]” (Art. 38(1)). (Therefore, if a
data subject were to address her or himself to someone else in the organisation, such as
the general counsel or the CEO, those should pass on the request to the DPO.)
Moreover, the independent status of the DPO (Art. 38(3)) should ensure that the request,
query or complaint is handled by the DPO – or by the responsible staff members under the
supervision of the DPO – in an appropriate manner, without bias in favour of the
organisation or against the data subject. In any case, the DPO should either herself write,
or review, the response to the data subject. This should include the advice that, if the data
subject is not content with the response, he or she can raise the issue with the DPA.
This is because, in any case, the data subjects’ right to submit requests, queries and
complaints to the organisation (i.e., to the organisation’s DPO) is without prejudice to their
right to complain to the DPA. Specifically, each DPA is required and empowers, on its own
territory, to:
handle complaints lodged by a data subject … and investigate, to the extent
appropriate, the subject matter of the complaint and inform the complainant of the
progress and the outcome of the investigation …
(Art. 57(1)(f))
In such complaints to the DPA, data subjects can be represented by a relevant not for profit
body (Art. 80), and the above duty and power of the DPA to handle such complaints extends
to cases brought in this way (see the words in Article 57(1)(f), omitted from the above
quote).
In that light, it would make sense for DPOs to also be willing to entertain requests and
complaints from such representative organisations, rather than only from data subjects.
As already noted in relation to Task 10 (Cooperation with the DPA), it is to be expected (also
in the light of past practice) that the national DPAs (like the EDPS in relation to the EU
institutional DPOs) will encourage data subjects (and such organisations) to always first take
241
(CC)
The DPO Handbook
up any issues with the controller, and more specifically with the controller’s DPO, to see if
the matter cannot be already satisfactorily be investigated and resolved in such interactions,
without involving the DPA, subject to the proviso that the DPO should consult the DPA if any
questions arise about the general interpretation and application of the GDPR. But this
should never go so far as to discourage data subjects (or representative organisations) from
raising issues – and of course especially issues of principle – with the DPA.
As the EDPS put it, the regulator and the DPOs are in a “strategic partnership”: the DPAs can
encourage data subjects to first and foremost sort out any issues directly with DPOs; and
DPOs must be able – and are required – to work with the regulator to make sure that
responses to questions and complaints are properly handled and if needs be lead to changes
in the relevant controller’s practices. The DPAs must be able to rely on the DPOs to truly
support data subjects in any complaint; and the DPOs must be able to rely on the DPAs to
ensure that recommendations for change are actually enforced.
This reinforces the delicacy of the position of the DPO, discussed in Part Two, section 2.5:
the DPOs is a bridge between the controller and regulator – and (to somewhat mix
metaphors, unless one reads bridge here as gangway) should not be allowed to fall between
the ship and quay.
0–O–o
242
(CC)
The DPO Handbook
Information and raising awareness

TASK 14: Internal and external information and awareness raising tasks
The GDPR stipulates that the DPO’s tasks shall “at least” include
Inform[ing] and advis[ing] the controller or the processor and the employees who
carry out processing of their obligations pursuant to this Regulation and to other
Union or Member State data protection provisions
(Art. 39(1)(a))
Internally (within the organisation where the DPO works), this implies, on the one hand, the
DPO informing staff members of their rights and, on the other hand, the DPO instructing
controllers and the organisation and staff members – including in particular “business
owners”/persons responsible for specific operation – in their obligations and
responsibilities, and training them in how to meet those.
As the EDPS puts it in a passage already quoted earlier:466
Ensuring compliance notably starts by raising awareness. … DPOs play an important
role in developing knowledge on data protection issues inside the institution/body.
Awareness raising “stimulat[es] an efficient preventive approach rather than repressive
data protection supervision”.467
Measures adopted by the DPO towards these aims can include the issuing of staff
information notes, the organising of internal data protection training sessions – which
should aim to inculcate in the staff an awareness and sensibility towards data protection
and data subject rights – a “data protection reflex” – in all their various roles in society, be
that as an ordinary citizen, a worker, a team leader, or senior manager.
Also, the setting up of an internal data protection informing and teaching web site, and the
drafting and release of privacy statements on staff websites and pages.468
Externally, apart from ensuring that data subjects are provided with relevant information
when data are first collected on them (as provided for in Articles 12 – 14 GDPR), e.g. in clear
website notices, the DPO should also work with any public relations staff to ensure
fulltransparencyabout the organisation’s personal data processing operations: about the
purposes for which it collects and processes personal data; the categories of data subjects
and data involved; the recipients of the data; whether the data are transferred to third
(non EU/EEA) countries; etc.
The GDPR does not require controllers to make the register of their personal data
processing operations fully available to the public.469 However, the GDPR also certainly
does not prohibit it.
The EDPS argues strongly in favour of publication in relation to the EU institutions, in
particular in the light of the fact that (like the 1995 Data Protection Directive) an earlier
regulation did require them to publish their “functionally equivalent” notification details:470
466
EDPS, Position paper on DPOs (footnote 243, above), p. 10.
467
Idem.
468
Idem, p. 5.
469
By contrast, the 1995 Data Protection Directive did require the DPAs to make the details of the
processing operations notified to them publicly available (Art. 21).
243
(CC)
The DPO Handbook
Records are an important tool for checking and documenting that your organisation is in
control of its processing activities. ….
The EDPS strongly recommends that [EU Institutions] make records publicly
accessible, preferably through publication on the internet … .
There are many reasons why the register of records should be public:
it contributes to the transparency of EUIs12;
it helps to strengthen public trust;
it makes knowledge sharing between EUIs easier;
not publishing it would be a step back behind the old [rules].
Very much the same can be said in relation to the register of processing operations to be
maintained by controllers under the GDPR – at the least, as far as public authorities are
concerned. Some Member States may in their national law impose such a duty to publish
the details of the register; but public authorities in countries where this is not compulsory
should still always consider doing so in the light of the EDPS’s observations.
Of course, controllers and processors should not feel obliged to publish information on their
security arrangements that could be used to breach that security (this was already
recognised in the 1995 Data Protection Directive’s provision on the publication of details of
processing operations that had been notified to DPAs).471
Basic information on the organisation’s personal data processing operations should in any
case be easily accessible on the organisation’s website, and also provided in booklets and
forms (including versions accessible to disabled people).
The website and such forms should also clearly provide information about how data
subjects can exercise their rights (including a clear public notice with the contact details of
the DPO – although that does not need to include a name); what codes of conduct the
organisation has signed up and what certifications it has obtained (these matters can be
shown through recognised logos or seals); etcetera.
Any website should of course also fully meet the requirements of EU data protection law,
and any relevant further national law, on matters such as cookies and other trackers, etc.
470
EDPS, Accountability on the ground (footnote 353, above), p. 8, original emphasis.
471
See again Article 21 of the 1995 Data protection Directive, which excludes the information listed in
Article 19(1)(f) – i.e., a general description of the controller’s security measures – from the information to be
made publicly available. Note however that the belief in “security through obscurity” has long since been
discredited, see: https://en.wikipedia.org/wiki/Security_through_obscurity
244
(CC)
The DPO Handbook
TASK 15: Planning and reviewing the DPO’s activities

Finally, given the vast numbers and scope of the DPO’s tasks, he or she should prepare an
annual plan of his or her activities, taking into account the expected time needed to
perform each of them and to devote to foreseeable new developments, while also
allowing for time to be given to unforeseen events; and to regularly revise and up date
this plan.
o–O–o
Douwe Korff & Marie Georges, Cambridge/Paris, December 2018/June 2019
245
(CC)

DPO Handbook The DPO Tasks

Uploaded by

Copyright:

Available Formats

DPO Handbook The DPO Tasks

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DPO Handbook The DPO Tasks

Uploaded by

Copyright:

Available Formats

The DPO Handbook

Elaborated for the EU funded “T4DATA” programme

Members of the Fundamental Rights Experts Europe (FREE) Group

Drawing on major contributions by the Italian Data Protection Authority

(As approved by the Commission,July 2019)

PART THREE – Practical guidance on the tasks of the DPO or that

Source: Principles of Health Science, https://www.youtube.com/watch?v=FpQEwbAV3Qw

Source: Dr Abdollah Salleh, https://drdollah.com/hospital information system his/

SAMPLE FORMAT OF A BASIC CONTROLLER PERSONAL DATA PROCESSING RECORD322

CONTROLLER CONTACT DETAILS: Name, Address, Email,

DATA PROT’N OFFICER CONTACT DETAILS: Name, Address, Email, Telephone

Part 2 – Basic information on the personal data processing operation (PDPO)323

1. Name of the PDPO324

8. Are the data transferred

10. Time limits for erasure

12. Does the processing

Contents and structure of the processor register entries (records)325

SAMPLE FORMAT OF A PROCESSOR’S PERSONAL DATA PROCESSING RECORD326

PROCESSOR CONTACT DETAILS: Name, Address, Email,

Part 2 – Information about the controller of the specific PDPO in question

CONTROLLER CONTACT DETAILS: Name, Address, Email,

DATA PROT’N OFFICER CONTACT DETAILS: Name, Address, Email, Telephone

1. The category (kind of) of

Contents and structure of the register:

Controller: (Main controller entity)*

Business Unit: (“Business owner”)*

II. DETAILS OF THE PERSONAL DATA PROCESSING OPERATION:

1. What personal data Tick as appropriate: When, how and from

Add further rows if necessary

II.2 Disclosures of data

ALL THE DATA LISTED AT II.1

OR: The following data:

Add further rows if necessary

II.3 Legal basis for the processing

CONSENT – further detail:

OR: The following data:

Add further rows if necessary

OR: The following

Add further rows if

III. SECURITY AND CONFIDENTIALITY

NB: If the answers to the questions below Please provide details:

TASK 2: Reviewing the personal data processing operations

TASK 3: Assessing the risks posed by the personal data processing

LEVEL of impact Description

A. Network & B. Processes & C. Parties & D. Business

Assessment area: Nr of “yes” answers Level Score

THREAT OCCURANCE PROBABILITY (2):

Overall SUM of scores: Threat occurrence PROBABILITY LEVEL:

OVERALL RISK ASSESSMENT:

A biotechnology company offering genetic tests directly to consumers in order to

Any use of 1:n biometric identification.*

Examples of processing Possible Relevant criteria DPIA likely to be

Methodologies for DPIAs:

Monitoring of compliance (including investigations of complaints):

TASK 2: Review of processing operations

Review of processing operations

No risk/risks fully mitigated or minor

TASK 6: Dealing with personal data breaches

Even a temporary loss of availability can constitute a personal data breach: