Holder’s Duties
ICO Guidance Deleting personal data
20140226
Version: 1.1
2
Introduction
The Data Protection Act 1998 (the DPA) is based around eight
principles of good information handling. These give people specific
rights in relation to their personal information and place certain
obligations on those organisations that are responsible for
processing it.
An overview of the main provisions of the DPA can be found in The
Guide to Data Protection.
This is part of a series of guidance, which goes into more detail than
the Guide, to help organisations to fully understand their obligations
and promote good practice.
This guidance explains what organisations need to do to make sure
they comply with the DPA when they archive or delete personal
data.
Overview
This guidance sets out how organisations can ensure
compliance with the DPA, in particular the fifth data
protection principle, when archiving or deleting personal
information.
It sets out what we mean by deletion, archiving and
putting personal data ‘beyond use’.
What the DPA says
The DPA does not define ‘delete’ or ‘deletion’ – but a plain English
interpretation implies ‘destruction’. In the days of paper records it
was relatively easy to say whether information had been deleted or
not, for example through incineration. The situation can be less
certain with electronic storage, where information that has been
‘deleted’ may still exist, in some form or another, within an
organisation’s systems.
Deleting personal data
20140226
Version: 1.1
3
The deletion of personal data is an important activity in data
protection, given the fifth data protection principle’s requirement
that “personal data processed for any purpose or purposes shall not
be kept for longer than is necessary for that purpose or those
purposes”.
In some cases an organisation may be required by law to delete an
individual’s personal data.
The ICO’s Personal information online code of practice says:
“It is good practice to make it clear to people what will
happen to their information when they close their account –
i.e. if it will be deleted irretrievably or simply deactivated or
archived. Remember that if you do archive personal data, the
rules of data protection, including subject access rights, still
apply to it.
If you offer users the option to delete personally identifiable
information uploaded by them, the deletion must be real i.e.
the content should not be recoverable in any way, for
example, by accessing a URL from that site. It is bad practice
to give a user the impression that a deletion is absolute, when
in fact it is not.”
Physical deletion or something else?
It is certainly the case that organisations should be absolutely clear
with individuals about what they mean by deletion and what
actually happens to personal data once they have deleted it.
This guidance is intended to counteract the problem of organisations
informing people that their personal data has been deleted when, in
fact, it is merely archived and could be re-instated.
It is also intended to encourage organisations to put safeguards in
place for information that has been deleted but is still in fact in an
organisation’s possession. This guidance reflects our general line on
deletion and will be relevant to all organisations that have to, or
wish to, delete personal data.
Deleting personal data
20140226
Version: 1.1
4
Deletion and archiving
There is a significant difference between deleting information
irretrievably, archiving it in a structured, retrievable manner or
retaining it as random data in an un-emptied electronic
wastebasket. Information that is archived, for example, is subject
to the same data protection rules as ‘live’ information, although
information that is in effect inert is far less likely to have any unfair
or detrimental effect on an individual than live information.
However, the ICO will adopt a realistic approach in terms of
recognising that deleting information from a system is not always a
straightforward matter and that it is possible to put information
‘beyond use’, and for data protection compliance issues to be
‘suspended’ provided certain safeguards are in place:
information has been deleted with no intention on the part of
the data controller to use or access this again, but which may
still exist in the electronic ether. For example, it could be
waiting to be over-written with other data.
o this information is no longer live. As such, data
protection compliance issues are no longer applicable.
(A parallel situation might be a bag of shredded paper
waste. Although it may be possible to re-constitute the
information from the fragments, this would be
extremely difficult and it is unlikely that the organisation
would have any intention of doing this.)
information that should have been deleted but is in fact still
held on a live system because, for technical reasons, it is not
possible to delete this information without also deleting other
information held in the same batch.
o in cases like this the organisation holding the
information may be prohibited by law from using it in
the same way that it might use live information. This
could happen if a court has ordered the deletion of
information relating to a particular individual but this
cannot be done without deleting information about other
individuals held in the same batch.
Deleting personal data
20140226
Version: 1.1
5
Putting information ‘beyond use’
The ICO will be satisfied that information has been ‘put beyond use’,
if not actually deleted, provided that the data controller holding it:
is not able, or will not attempt, to use the personal data to
inform any decision in respect of any individual or in a manner
that affects the individual in any way;
does not give any other organisation access to the personal
data;
surrounds the personal data with appropriate technical and
organisational security; and
commits to permanent deletion of the information if, or when,
this becomes possible.
We will not require data controllers to grant individuals subject
access to the personal data provided that all four safeguards above
are in place. Nor will we take any action over compliance with the
fifth data protection principle.
It is, however, important to note that where data put beyond use is
still held it might need to be provided in response to a court order.
Therefore data controllers should work towards technical solutions
to prevent deletion problems recurring in the future.
Other considerations
Other relevant ICO guidance includes:
Deleting your data
More information
Additional guidance is available on our guidance pages if you need
further information on other parts of the DPA.
This guidance has been developed drawing on ICO experience.
Because of this it may provide more detail on issues that are often
referred to the Information Commissioner than on those we rarely
see. The guidance will be reviewed and considered from time to
Deleting personal data
20140226
Version: 1.1
6
time in line with new decisions of the Information Commissioner,
Tribunals and courts.
It is a guide to our general recommended approach, although
individual cases will always be decided on the basis of their
particular circumstances.
If you need any more information about this or any other aspect of
data protection, please contact us, or visit our website at
www.ico.org.uk.
Cases
Murphy v Callinan
Scope of Duty of Care
[2018] IESC 59 (30 November 2018)
JUDGMENT of Ms. Justice Baker delivered on the 30 th day of November, 2018
1. This is an appeal from the dismissal of these plenary proceedings by MacMenamin J. on 9 May 2012 on the application for non-suit brought by the defendants at the conclusion of the plaintiff’s evidence.
2. The plaintiff, a litigant in person, runs a motor trading business. He commenced the action by plenary summons dated 24 October 2006, after his motor insurance policy with ARB Underwriting Ltd. (“ARB”), the third named defendant, was cancelled as he was considered to have falsely stated on the policy application form that he had never been convicted of any motoring offence or of any criminal non-motoring offence. The information on foot of which the policy was cancelled came to the attention of ARB from the first defendant, a member of An Garda Síochána who, at all material times, acted in his professional capacity.
3. The proceedings were issued against six defendants, four of whom, the first, fourth, fifth, and sixth will be collectively referred to as the “State defendants”. The second named defendant was, at all material times, acting as an employee of ARB, and she and the third defendant will be collectively referred to as “ARB” as the claim against her relates to her actions in the course of her employment.
Background
4. The plaintiff never contested the cancellation of the motor insurance policy and accepted the returned premia. After the cancellation, he exercised his right of access pursuant to the then operative data protection legislation, the Data Protection Act 1988, as amended by the Data Protection (Amendment) Act 2003 transposing Directive 95/46/EC on the Protection of Individuals with Regard to the Processing of Personal Data (“the 1988 Act”) and thereafter requested that the State defendants and ARB erase/rectify data showing criminal convictions for fraud.
5. The plaintiff’s claim before MacMenamin J., as well as the related judicial review proceedings, have at their core a contention as to the accuracy of the records of the previous convictions of the plaintiff held by the State defendants and ARB and an assertion that the State should no longer keep record of stale or old convictions.
6. The Plaintiff’s pleaded claims against the State defendants are, in essence, twofold:
(i) A claim in injurious falsehood that, in breach of section 20(1) of the Defamation Act 1961 (the “1961 Act”), the first defendant knew, or ought to have known, that the information held by An Garda Síochána concerning his past convictions was false and inaccurate and that communication of that data would damage the Plaintiff’s vehicle dealership business and was unlawful.
(ii) A claim in negligence, breach of duty, and breach of Constitutional rights as a result of the communication of incorrect data to the second and third defendants.
7. The plaintiff’s claim against ARB is for damages for breach of statutory duty under the 1988 Act on account of its pleaded failure to rectify identified errors in the data it holds concerning him.
8. It is important to observe that the complaints concern events in 2006 and requests under the 1988 Act made between June and September of that year, and the Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation) (“GDPR”) and changes made by the Data Protection Act 2018 are not engaged.
9. MacMenamin J. dismissed the plaintiff’s claim in the light of the evidence and applied the principles identified by the Supreme Court in Hetherington v. Ultra Tyre Services Ltd. [1993] 2 IR 535, and O’Toole v. Healy [1993] 2 IR 544, although he noted that a court was not, as a result of the approach identified in those authorities, precluded from engaging in some degree in an analysis or scrutiny of the evidence.
10. No error is identified in that approach taken by the trial judge.
The judicial review proceedings
11. The appellant issued separate proceedings by way of judicial review on 23 January 2007 (the “Judicial Review proceedings”) involving the same parties and, essentially, the same facts as those upon which he relies in these plenary proceedings.
12. The Judicial Review proceedings were heard and determined in the High Court and an ex tempore judgment was delivered by Charleton J. on 25 July 2008. He made the factual determination that both answers given by the plaintiff on the proposal form were wrong “whether as a result of being filled in quickly or by an agent”.
13. The applicant’s appeal of that decision was dismissed by the Supreme Court and an ex tempore judgment was given by Fennelly J. on 12 June 2009 with which the other judges agreed.
The plenary proceedings and the findings of the High Court
14. The plaintiff continued to pursue this plenary action after the determination by the Supreme Court of the Judicial Review proceedings and ARB made an application for dismissal on the grounds of res judicata . Having taken the view that “as a matter of justice” the plaintiff “should be given the opportunity of completing his evidence […] being cross-examined […] and calling his son”, MacMenamin J. fairly postponed the consideration of the application until the plaintiff finished his oral evidence. Only two witnesses gave evidence, the plaintiff and his son, and the matter then proceeded as an application for a non-suit by the State defendants before any evidence was called by the defendants and where they had indicated that they would go into evidence if the application was refused.
15. The grounds of that application by the State defendants were that the plaintiff had not made out a prima facie case and/or that the plaintiff’s claim (or part thereof) was res judicata and/or an abuse of process.
16. ARB’s application that the matters were res judicata was then revisited and re-submitted.
17. In his written judgment dismissing the plaintiff’s claim against the second and third defendants for damages, MacMenamin J. found, inter alia :
(a) That the plenary action and the earlier judicial review proceedings cannot be dissociated from each other as the issue in the judicial review was the integrity of the conviction records;
(b) That the plaintiff was in fact convicted of an offence pursuant to s. 18 of the Theft and Fraud Offences Act 2001 in the District Court for possession of a stolen chequebook. On appeal, the Circuit Court found the facts proved and, without proceeding to a conviction, dismissed the charge under the Probation Act and that this order of the Circuit Court on appeal was not equivalent to a finding of not guilty;
(c) That the plaintiff did have recorded criminal convictions for matters other than traffic road offences, and “a couple” of convictions under the Road Traffic Acts from the early 1990s;
(d) That the plaintiff had failed to make out any loss.
18. At p. 17 of his ruling, the conclusion of MacMenamin J. was that the matter was res judicata in its strict sense, as the matters in issue had already been determined in a way that met the test set out in the authorities, that courts had “exercised their judicial mind on the issue”, the words used by Shaw L.J. in Bradshaw v McMullan [1920] 2 IR 412. In the alternative, he concluded that the plaintiff should not be permitted to proceed with this action on the grounds that to do so would be an abuse of court process.
19. In regard to the claim against the State defendants for injurious falsehood, MacMenamin J. did not rely on a finding of res judicata and made other findings against the plaintiff which were dispositive, inter alia :
(a) The proofs had not been met and no evidence was adduced either by interrogatories or by direct evidence of an unlawful publication;
(b) That the evidence adduced on the conviction order under s 18 of the Theft and Fraud Offences Act 2001 and the road traffic offences establishes the truth of the relevant statements.
20. In dismissing the plaintiff’s claim against the State defendants for negligence, breach of duty, and breach of constitutional rights, MacMenamin J. found, inter alia :
a) That the claims “overlap in every respect those which were made in the judicial review proceedings”;
b) That the plaintiff “simply has not addressed the question as to whether it is open to him to by-pass the Commissioner, and simply pursue an action for negligence or breach of constitutional rights” and this amounted to “contributory negligence” on his part;
c) That the plaintiff failed to make out any negligence or loss and that “any loss which he sustained was as a result of his own actions”.
21. The conclusion of MacMenamin J. in regard to the claim against ARB was that the plaintiff had not made a prima facie case with regard to his claim for negligence or injurious falsehood and that the complaints regarding data breach “should, appropriately, in the first instance, have been dealt with by the Data Commissioner”.
The grounds of appeal
22. The grounds of appeal are argued as deriving from what the appellant describes as “incompetent record keeping” of the Garda Commissioner, and the appeal against the defendants generally is that they ought to be held accountable by a competent court for their breaches of his rights as data subject.
23. The appellant pleads ten grounds of appeal which I propose quoting in full:
“(1) The State defendants breach of the An Garda Síochána Act 2005 triggered the initiation of the action. They were not held accountable for the breach.
(2) In the face of admission and evidence produced by the State defendants of nine wrongful convictions on the Court Outcomes record kept on the plaintiff for a period of circa 34 years, a total of fourteen entries erased, numerous alterations and ongoing wrongful entries on the Court Outcomes record kept of the plaintiff, in defiance of the plaintiff’s constitutional right to his good name the court failed to remedy the matters or hold the State defendants accountable.
(3) The fourth named defendant’s incompetent record keeping in relation to the Plaintiff is itself evidence of negligence.
(4) The fourth named defendant’s incompetent method of processing the Court Outcomes database is itself evidence of negligence.
(5) The court enunciated on the issue raised by “PM9” of my Book of Exhibits in my favour during the hearing and determined the issue against me in the written judgment.
(6) Incontrovertible evidence was offered to the court that the matter is not res judicata.
(7) The remedies given by the Data Protection Acts are in addition to not to the exclusion of any remedies in tort sec. 7 DPA 1988.
(8) In the circumstance of the case herein, it is not necessary to allege or prove special damage in the tort of injurious falsehood. Section 20(1) of the Defamation Act 1961.
(9) Despite evidence adduced of both sets of defendants abusing the process of the court throughout the proceedings they were not held accountable.
(10) The determination of the High Court undermines the integrity of the domestic jurisprudence in that it is open to the lawbreakers and tortfeasors to pursue the victim of their lawlessness for their legal costs.”
24. They can be usefully considered under the following headings:
(i) As against the State defendants, that the failure to erase or correct its records regarding the criminal convictions of the appellant amounted to a breach of his constitutional right to a good name, and is negligent. (Grounds 1 to 5 inclusive and Ground 9);
(ii) That the remedies under the 1988 Act in regard to a data breach do not exclude the remedies for which s. 7 of the Act of 1988 provides (Ground 7);
(iii) That the trial judge misdirected himself in law in failing to have regard to the fact that the plaintiff’s claim for damages for injurious falsehood did not require proof of special damage on account of the provisions of s. 20 of the 1961 Act; (Ground 8);
(iv) That the trial judge misdirected himself in coming to a determination that some of the matters raised in the plenary proceedings were res judicata . (Ground 6).
Abuse of process: Ground 7
25. The appellant identifies inaccuracies in the databases held by An Garda Síochána, and also points to the fact that some of the records held by An Garda Síochána are of such antiquity as to amount to stale convictions for the purposes of the Criminal Justice (Spent Convictions and Certain disclosures) Act 2016.
26. A number of corrections were made to the appellant’s personal data held by the Garda Commissioner, some of which arose from the fact that another person of the same name with the same day and month of birth, but a different year, is recorded as having convictions which were wrongly attributed to him. Those errors were rectified following his complaints in 1999 as a result of which twenty-two entries which appeared in a printout he received from An Garda Síochána in 1999 were reduced, altered, and corrected so the relevant data in July 2001 showed nine entries only. The plaintiff subsequently sought corrections and erasures in correspondence with An Garda Síochána in 2001 and 2006 and the relevant database in 2006, when the proceedings commenced, showed two classes of records, thirteen entries in all of which eight were what he described as “old” and five “recent”. He had, in the meantime, made a complaint that the alternation of the old Punt records to Euro amounted to an unlawful alteration of the record and in breach of his rights, gave the impression that the records “endows the offences with a modern character”, and obscures the fact that they relate to incidents from the mid-1990s.
27. For the reasons that will be apparent, I do not propose examining each of the various incidents and complaints regarding the databases of which the plaintiff complains. These complaints were the subject matter of the judicial review proceedings in which Mr. Murphy sought an order of mandamus directed to the Garda Commissioner and ARB to correct or erase some of his personal data, and the grounding affidavit in which he exhibited his data subject request and responses ran to several pages.
28. The Supreme Court endorsed the approach of Charleton J. in regard to the primacy of the statutory remedy both on account of the scheme of the 1988 Act, which conferred certain powers on the then Data Protection Commissioner and provided for an appeal to the High Court against a determination, but also because, as Charleton J. had held, the right to seek erasure or correction is one derived from the data protection legislation and without which no general right in law exists. Fennelly J. agreed with that proposition and the conclusion of Charleton J. that “the Act in my view creates a remedy within itself”.
29. The judicial review proceedings were not dealing with the relief in damages sought by the plaintiff in the plenary action, but only with the claim of the plaintiff for an order of mandamus , and I will return later to the question as to whether the conclusions of the Judicial Review proceedings can amount to an operative res judicata in the claim for damages. But I will first deal with the question of whether the plenary action is an abuse of process.
30. MacMenamin J. noted that the plaintiff had given no satisfactory account in the course of the hearing before him, or in cross-examination, when it was put to him, as to why he did not pursue his complaint with the Data Protection Commissioner, even after the Supreme Court delivered its judgment in 2012. He records that the plaintiff’s answer, when probed, was that he had “wanted to bring this action on so that somebody would be looking at the records and deciding what is right and wrong”. MacMenamin J. noted, at para. 72 of his ruling, that the task of engaging with the records is vested in the Data Protection Commissioner and that to permit the plaintiff to pursue a remedy other than through that means would be to “countenance an abuse of process”.
31. The appellant argues that the plenary action was wrongly characterised as an abuse of process and that the courts retain the jurisdiction to award damages for breach of duty arising from a data breach. He relies on s. 7 of the 1988 Act, which provides as follows:
“For the purposes of the law of torts and to the extent that that law does not so provide, a person, being a data controller or a data processor, shall, so far as regards the collection by him of personal data or information intended for inclusion in such data or his dealing with such data, owe a duty of care to the data subject concerned:
Provided that, for the purposes only of this section, a data controller shall be deemed to have complied with the provisions of section 2 (1) (b) of this Act if and so long as the personal data concerned accurately record data or other information received or obtained by him from the data subject or a third party and include (and, if the data are disclosed, the disclosure is accompanied by)-
(a) an indication that the information constituting the data was received or obtained as aforesaid,
(b) if appropriate, an indication that the data subject has informed the data controller that he regards the information as inaccurate or not kept up to date, and
(c) any statement with which, pursuant to this Act, the data are supplemented.”
32. In simple terms, that section imposes a duty of care on a processor or controller of data, and creates a presumption that that duty of care has been complied with by a data controller who accurately records data or other information received or obtained by him or her from the data subject or a third party in the circumstances outlined.
33. The plaintiff’s claim in negligence is pleaded broadly against the State defendants, and more narrowly against the ARB defendants, but essentially, it is founded in an assertion that the relevant parties had an obligation to process and protect the plaintiff’s data in a fair manner and, in particular in the light of his allegations, to keep it accurate, complete, and up to date. That general proposition is one that indeed finds reflection in the policies and provisions of the data protection legislation generally, albeit the provisions of the Data Protection Act 2018 create a more complex scheme of protection.
34. Section 7 of the 1988 Act has the effect that the court is entitled to award damages for breach of duty to a data subject arising from the negligent processing of police data. Accordingly, in my view, MacMenamin J. was not correct insofar as he held that the claim in damages is not well founded as it seeks to bypass a statutory scheme and that the claim is an abuse of process.
35. Section 7 preserves the judicial remedy for breach of the duty of care by the data controller. A claim for damages for breach of the duty of care is not an abuse of process merely on account of the fact that there exists a statutory scheme by which correction, erasure or other alternation of data may be achieved. Thus, it seems to me that the appellant must succeed on ground 7 of his notice of appeal. But the matter does not end there.
The claim in negligence: Grounds 1 to 5 incl., and ground 9
36. The claim for damages is grounded in tort, and the 1988 Act does not create a new cause of action or strict liability.
37. Feeney J. considered the matter in some detail in his judgement in Collins v. FBD Insurance Plc. [2013] IEHC 137, where he allowed an appeal from an order of the Circuit Court which had awarded the plaintiff damages pursuant to s. 7 of the 1988 Act. The question for determination by the High Court was whether the plaintiff was entitled to damages pursuant to s. 7 of the 1988 Act and, if so, the quantum of such damages.
38. That judgment was not opened to us in the appeal but seems to me to correctly state the legal principles and I propose to therefore consider it in some detail. In Collins v. FBD Insurance Plc ., the claim also concerned a dispute between the plaintiff and the insurers who provided him with motor insurance. The plaintiff had complained to the Data Protection Commissioner in regard to certain breaches of his data rights. The plaintiff, in the course of the High Court appeal, acknowledged that he had suffered no out-of-pocket expenses or special damages arising from the breaches of the data protection legislation which had been subject to a determination by the Data Protection Commissioner. The claim therefore was one for general damages. At para. 4.4 of his judgment, Feeney J. concluded as follows:
“Section 7 is limited and goes no further than providing for a duty of care that is a duty of care within the law of torts. To obtain a compensation for a breach of duty of care, it is necessary for a claimant to establish that there has been a breach, that there has been damage and that the breach caused such damage. The tort of negligence, unlike the tort of trespass to person, requires proof of damage. Such requirement is demonstrated in the judgment of Clark J. in Larkin v. Dublin City Council [2008] 1 IR 391…. A person seeking compensation arising from a breach of statutory duty under an Act must establish that the loss or damage that such person has suffered flowed from the breach, unless the statutory duty involved is one of strict liability. Here, the statute does not provide for strict liability and for me to interpret s. 7 of the Data Protection Acts as enabling a claimant to benefit from an award of damages for non-pecuniary loss, would be for me to expand the scope of s. 7 beyond that provided for in the Act or required by the Directive. The Directive in issue in this case requires for there to be compensation for damage suffered and s. 7 does not extend beyond that obligation. Section 7 provides an obligation of duty of care and allows for a remedy under the law of torts and the law of torts generally provides for compensation to be based upon certain criteria which includes the proof of damage.”
39. A plaintiff claiming breach of a duty of care in the management or processing of data is not relieved of the obligation to show that there has been a breach and to establish a causative connection between the breach and a loss. The 1988 Act does not create a new tort, and a breach of the rights of a data subject is not actionable in itself without proof of negligence or breach of a duty of care, or proof of loss.
40. As stated by Feeney J. in Collins v. FBD Insurance Plc ., at para. 3.6:
“It is also the case that s. 7 in the Irish legislation does not, on the face of it, provide for compensation for strict liability or for the automatic payment of compensation but limits compensation to the existence of a duty of care within the law of torts. It is consistent with the general principles of the Irish law of torts that a person seeking compensation arising from a breach of statutory duty must establish that the loss or damage which they have sustained flowed from that breach unless the statutory duty involved is one of strict liability. The Directive does not provide for strict liability or the automatic payment of compensation nor does s. 7 of the Irish legislation so provide, either by its express terms or by reference to a duty of care within the law of torts”.
41. I agree with that statement of the legal effect of the provisions of s. 7 of the 1988 Act.
42. MacMenamin J., in paras. 47 et seq. of his judgment, considered that the plaintiff had not adduced any evidence that the data was processed or obtained in an unfair manner by ARB or its servants or agents. He asked the rhetorical question “where was the unfairness?”, and noted that the plaintiff had not adduced even prima facie evidence that any unfairness occurred in the processing of his personal data by ARB. It is essential, in that context, to bear in mind that the plaintiff makes no complaint that the cancellation of his policy was wrongful, and his complaint relates solely to the accuracy of the records.
The new data protection regime followed the coming into force on May 25 2018 of the GDPR. The Data Protection Act 2018 implementing GDPR permits an individual to seek compensation from the court for breaches of data subject rights even in the absence of any material damage or financial loss. But s. 7 of the 1988 Act, on which the plaintiff relies, whilst it did expressly create a duty of care on a data controller in regard to personal data, did not make the breach of data subject rights actionable without proof of negligence or a causative connection to an alleged material damage or other loss.
43. Further, MacMenamin J. correctly determined a data subject must engage fairly with a data controller, and the plaintiff offered no explanation as to why he did not respond to the open offer from ARB made in open court to correct any errors he could identify. MacMenamin J. was correct to find that the failure to avail of the statutory remedy did amount to contributory negligence.
44. For these reasons, I consider that MacMenamin J. was perfectly correct in his ruling that the claim of the plaintiff had to fail on account of the fact that he adduced no evidence of negligence or of loss.
Res judicata: Ground 6
45. As the Judicial Review proceedings did not concern the right of a data subject to seek damages in the general law of tort and did not consider the provisions of s. 7 of the 1988 Act, the argument that the claim in the plenary proceedings must fail by reason of it being res judicata is wrong at law. The appellant, to that extent, succeeds in ground 6.
The claim for damages for injurious falsehood: Ground 8
46. The key to the conclusion to which MacMenamin J. came in relation to the plaintiff’s claim in injurious falsehood was that the plaintiff had adduced no evidence regarding any publication of the allegedly incorrect data and, as I have observed, the only oral evidence heard was evidence from the plaintiff himself and conversations between him and the first defendant. While the plaintiff is correct that as a matter of law it was not necessary for him to establish any special loss where the claim is one of injurious falsehood, MacMenamin J. determined the claim and that that had to fail for absence of evidence of publication.
47. I see no error in the approach of MacMenamin J. who, as he was required to, accepted the plaintiff’s case at its highest and tested the claim in particular against the uncontroverted finding that the plaintiff had failed to adduce evidence of publication. The plaintiff is a litigant in person and may well have considered that the affidavit evidence in the Judicial Review proceedings or that the replies for particulars or other pleadings amount to evidence of publication. The stark fact is that they are not, and the plaintiff’s evidence at the plenary hearing failed to establish an essential proof of the tort of which he claimed. MacMenamin J. was correct in the approach he took.
Bias
48. In the course of his oral submission to this Court, the plaintiff appellant made an assertion that two of the judges who sat on the Supreme Court panel in the Judicial Review proceedings were objectively biased for the reasons identified there by him. The plaintiff appellant alleged that two members of the Supreme Court had relevant links to him, and that one member of that Court had acted for him in the past. He did not identify how the nature of his alleged prior interactions with the relevant judges were of such a nature as to give rise to a perception of bias, and it seems from his oral submissions that the links of which he complained were purely professional.
49. The allegations of alleged bias were not raised before the Supreme Court which determined the Judicial Review proceedings in 2012, and the appellant offers no explanation as to why he permitted the Supreme Court to engage upon the hearing of the appeal without any complaint from him, and it seems to me to be simply too late for him to now pursue the argument. In Goode Concrete v. CRCH Plc. [2015] IESC 70, the Supreme Court emphasised the desirability that an application regarding alleged bias be made to the relevant court alleged to be guilty of such bias. Furthermore, I am unclear as to the purpose of the argument of alleged bias.
50. Quite apart from that consideration, the decision of the Supreme Court in the Judicial Review proceedings is final and this Court may not now engage upon any consideration of that decision which would fail to respect its final and conclusive nature.
Other matters raised in the appeal
51. In the course of the hearing before this Court, the appellant drew our attention to correspondence with An Garda Síochána in 2017 and 2018 regarding recent data protection access request to it on account of what he identified as incorrect entries. These matters and complaints post-date the proceedings now under appeal, and cannot fall for consideration here.
52. That approach must also be taken to the argument made by the plaintiff appellant that some of the recorded convictions ought to be treated as spent under the Criminal Justice (Spent Convictions and Certain disclosures) Act 2016 which was not in existence at the time the present proceedings were commenced or concluded.
Conclusion
53. The appellant has a strongly held and well-articulated complaint regarding the storage and processing of certain personal data by the defendants. He complains that the State defendants wrongly retained and continued to retain incorrect data concerning his previous criminal convictions and on account of the failure to treat some of the very old records as “spent”.
54. MacMenamin J. determined inter alia that the action was an abuse of process and the issue of res judicata arose, and for the reason stated, I do not consider that he was correct in this.
55. However, he was correct in his primary determination that the plaintiff had not established a prima facie case on the evidence. In regard to the claim in negligence and for breach of the duty of care under s.7 of the 1988 Act, because the appellant had not shown any negligence or unfairness in the processing of his personal data, nor had he established any loss. In the claim for injurious falsehood, because the appellant had failed to establish the essential element of publication.
56. MacMenamin J. was accordingly correct to accede to the application by the defendants for a non-suit.
57. Therefore, I conclude that the appeal must fail, albeit that the appellant must succeed in grounds 6 and 7 of his notice of appeal.
Article 29 Group Guidance on Data Protection Officers
ARTICLE 29 DATA PROTECTION WORKING PARTY
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data
protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC.
The secretariat is provided by Directorate C (Fundamental rights and rule of law) of the European Commission, Directorate
General Justice and Consumers, B-1049 Brussels, Belgium, Office No MO59 05/35
Website: http://ec.europa.eu/justice/data-protection/index_en.htm
16/EN
WP 243 rev.01
Guidelines on Data Protection Officers (‘DPOs’)
Adopted on 13 December 2016
As last Revised and Adopted on 5 April 2017
2
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO
THE PROCESSING OF PERSONAL DATA
set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995,
having regard to Articles 29 and 30 thereof,
having regard to its Rules of Procedure,
HAS ADOPTED THE PRESENT GUIDELINES:
3
1 Introduction
The General Data Protection Regulation (‘GDPR’),1 due to come into effect on 25 May 2018, provides
a modernised, accountability-based compliance framework for data protection in Europe. Data
Protection Officers (‘DPO’s) will be at the heart of this new legal framework for many organisations,
facilitating compliance with the provisions of the GDPR.
Under the GDPR, it is mandatory for certain controllers and processors to designate a DPO.2 This will
be the case for all public authorities and bodies (irrespective of what data they process), and for other
organisations that – as a core activity – monitor individuals systematically and on a large scale, or that
process special categories of personal data on a large scale.
Even when the GDPR does not specifically require the appointment of a DPO, organisations may
sometimes find it useful to designate a DPO on a voluntary basis. The Article 29 Data Protection
Working Party (‘WP29’) encourages these voluntary efforts.
The concept of DPO is not new. Although Directive 95/46/EC3 did not require any organisation to
appoint a DPO, the practice of appointing a DPO has nevertheless developed in several Member States
over the years.
Before the adoption of the GDPR, the WP29 argued that the DPO is a cornerstone of accountability
and that appointing a DPO can facilitate compliance and furthermore, become a competitive advantage
for businesses.4 In addition to facilitating compliance through the implementation of accountability
tools (such as facilitating data protection impact assessments and carrying out or facilitating audits),
DPOs act as intermediaries between relevant stakeholders (e.g. supervisory authorities, data subjects,
and business units within an organisation).
DPOs are not personally responsible in case of non-compliance with the GDPR. The GDPR makes it
clear that it is the controller or the processor who is required to ensure and to be able to demonstrate
that the processing is performed in accordance with its provisions (Article 24(1)). Data protection
compliance is a responsibility of the controller or the processor.
1Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of
natural persons with regard to the processing of personal data and on the free movement of such data, and
repealing Directive 95/46/EC (General Data Protection Regulation), (OJ L 119, 4.5.2016). The GDPR is relevant
for the EEA and will apply after its incorporation into the EEA Agreement.
2 The appointment of a DPO is also mandatory for competent authorities under Article 32 of Directive (EU)
2016/680 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons
with regard to the processing of personal data by competent authorities for the purposes of the prevention,
investigation, detection or prosecution of criminal offences or the execution of criminal penalties, and on the free
movement of such data, and repealing Council Framework Decision 2008/977/JHA (OJ L 119, 4.5.2016, p. 89–
131), and national implementing legislation. While these guidelines focus on DPOs under the GDPR, the
guidance is also relevant regarding DPOs under Directive 2016/680, with respect to their similar provisions.
3 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of
individuals with regard to the processing of personal data and on the free movement of such data (OJ L 281,
23.11.1995, p. 31).
4 See http://ec.europa.eu/justice/data-protection/article-29/documentation/otherdocument/files/2015/20150617_appendix_core_issues_plenary_en.pdf
5
The controller or the processor also has a crucial role in enabling the effective performance of the
DPO’s tasks. Appointing a DPO is a first step but DPOs must also be given sufficient autonomy and
resources to carry out their tasks effectively.
The GDPR recognises the DPO as a key player in the new data governance system and lays down
conditions for his or her appointment, position and tasks. The aim of these guidelines is to clarify the
relevant provisions in the GDPR in order to help controllers and processors to comply with the law,
but also to assist DPOs in their role. The guidelines also provide best practice recommendations,
building on the experience gained in some EU Member States. The WP29 will monitor the
implementation of these guidelines and may complement them with further details as appropriate.
2 Designation of a DPO
2.1 . Mandatory designation
Article 37(1) of the GDPR requires the designation of a DPO in three specific cases: 5
a) where the processing is carried out by a public authority or body;6
b) where the core activities of the controller or the processor consist of processing operations,
which require regular and systematic monitoring of data subjects on a large scale; or
c) where the core activities of the controller or the processor consist of processing on a large
scale of special categories of data7 or8 personal data relating to criminal convictions and
offences.9
In the following subsections, the WP29 provides guidance with regard to the criteria and terminology
used in Article 37(1).
Unless it is obvious that an organisation is not required to designate a DPO, the WP29 recommends
that controllers and processors document the internal analysis carried out to determine whether or not a
DPO is to be appointed, in order to be able to demonstrate that the relevant factors have been taken
into account properly.10 This analysis is part of the documentation under the accountability principle. It
may be required by the supervisory authority and should be updated when necessary, for example if
the controllers or the processors undertake new activities or provide new services that might fall
within the cases listed in Article 37(1).
When an organisation designates a DPO on a voluntary basis, the requirements under Articles 37 to 39
will apply to his or her designation, position and tasks as if the designation had been mandatory.
5 Note that under Article 37(4), Union or Member State law may require the designation of DPOs in other
situations as well.
6 Except for courts acting in their judicial capacity. See Article 32 of Directive (EU) 2016/680.
7 Pursuant to Article 9 these include personal data revealing racial or ethnic origin, political opinions, religious or
philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the
purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex
life or sexual orientation.
8 Article 37(1)(c) uses the word ‘and’. See Section 2.1.5 below for explanation on the use of ‘or’ instead of
‘and.’
9 Article 10.
10 See Article 24(1).
6
Nothing prevents an organisation, which is not legally required to designate a DPO and does not wish
to designate a DPO on a voluntary basis to nevertheless employ staff or outside consultants with tasks
relating to the protection of personal data. In this case it is important to ensure that there is no
confusion regarding their title, status, position and tasks. Therefore, it should be made clear, in any
communications within the company, as well as with data protection authorities, data subjects, and the
public at large, that the title of this individual or consultant is not a data protection officer (DPO). 11
The DPO, whether mandatory or voluntary, is designated for all the processing operations carried out
by the controller or the processor.
2.1.1 ‘PUBLIC AUTHORITY OR BODY’
The GDPR does not define what constitutes a ‘public authority or body’. The WP29 considers that
such a notion is to be determined under national law. Accordingly, public authorities and bodies
include national, regional and local authorities, but the concept, under the applicable national laws,
typically also includes a range of other bodies governed by public law.12 In such cases, the designation
of a DPO is mandatory.
A public task may be carried out, and public authority may be exercised13 not only by public
authorities or bodies but also by other natural or legal persons governed by public or private law, in
sectors such as, according to national regulation of each Member State, public transport services, water
and energy supply, road infrastructure, public service broadcasting, public housing or disciplinary
bodies for regulated professions.
In these cases, data subjects may be in a very similar situation to when their data are processed by a
public authority or body. In particular, data can be processed for similar purposes and individuals
often have similarly little or no choice over whether and how their data will be processed and may thus
require the additional protection that the designation of a DPO can bring.
Even though there is no obligation in such cases, the WP29 recommends, as a good practice, that
private organisations carrying out public tasks or exercising public authority designate a DPO. Such a
DPO’s activity covers all processing operations carried out, including those that are not related to the
performance of a public task or exercise of official duty (e.g. the management of an employee
database).
11 This is also relevant for chief privacy officers (‘CPO’s) or other privacy professionals already in place today in
some companies, who may not always meet the GDPR criteria, for instance, in terms of available resources or
guarantees for independence, and, if they do not, they cannot be considered and referred to as DPOs.
12 See, e.g. the definition of ‘public sector body’ and ‘body governed by public law’ in Article 2(1) and (2) of
Directive 2003/98/EC of the European Parliament and of the Council of 17 November 2003 on the re-use of
public-sector information (OJ L 345, 31.12.2003, p. 90).
13 Article 6(1)(e).
7
2.1.2 ‘CORE ACTIVITIES’
Article 37(1)(b) and (c) of the GDPR refers to the ‘core activities of the controller or processor’.
Recital 97 specifies that the core activities of a controller relate to ‘primary activities and do not relate
to the processing of personal data as ancillary activities’. ‘Core activities’ can be considered as the
key operations necessary to achieve the controller’s or processor’s goals.
However, ‘core activities’ should not be interpreted as excluding activities where the processing of
data forms an inextricable part of the controller’s or processor’s activity. For example, the core activity
of a hospital is to provide health care. However, a hospital could not provide healthcare safely and
effectively without processing health data, such as patients’ health records. Therefore, processing these
data should be considered to be one of any hospital’s core activities and hospitals must therefore
designate DPOs.
As another example, a private security company carries out the surveillance of a number of private
shopping centres and public spaces. Surveillance is the core activity of the company, which in turn is
inextricably linked to the processing of personal data. Therefore, this company must also designate a
DPO.
On the other hand, all organisations carry out certain activities, for example, paying their employees or
having standard IT support activities. These are examples of necessary support functions for the
organisation’s core activity or main business. Even though these activities are necessary or essential,
they are usually considered ancillary functions rather than the core activity.
2.1.3 ‘LARGE SCALE’
Article 37(1)(b) and (c) requires that the processing of personal data be carried out on a large scale in
order for the designation of a DPO to be triggered. The GDPR does not define what constitutes largescale processing, though recital 91 provides some guidance.14
Indeed, it is not possible to give a precise number either with regard to the amount of data processed or
the number of individuals concerned, which would be applicable in all situations. This does not
exclude the possibility, however, that over time, a standard practice may develop for identifying in
more specific and/or quantitative terms what constitutes ‘large scale’ in respect of certain types of
common processing activities. The WP29 also plans to contribute to this development, by way of
sharing and publicising examples of the relevant thresholds for the designation of a DPO.
In any event, the WP29 recommends that the following factors, in particular, be considered when
14 According to the recital, ‘large-scale processing 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’ would be included, in particular. On the other hand, the
recital specifically provides that ‘the processing of personal data should not be considered to be on a large scale
if the processing concerns personal data from patients or clients by an individual physician, other health care
professional or lawyer’. It is important to consider that while the recital provides examples at the extremes of the
scale (processing by an individual physician versus processing of data of a whole country or across Europe);
there is a large grey zone in between these extremes. In addition, it should be borne in mind that this recital
refers to data protection impact assessments. This implies that some elements might be specific to that context
and do not necessarily apply to the designation of DPOs in the exact same way.
8
determining whether the processing is carried out on a large scale:
The number of data subjects concerned – either as a specific number or as a proportion of the
relevant population
The volume of data and/or the range of different data items being processed
The duration, or permanence, of the data processing activity
The geographical extent of the processing activity
Examples of large-scale processing include:
processing of patient data in the regular course of business by a hospital
processing of travel data of individuals using a city’s public transport system (e.g. tracking via
travel cards)
processing of real time geo-location data of customers of an international fast food chain for
statistical purposes by a processor specialised in providing these services
processing of customer data in the regular course of business by an insurance company or a
bank
processing of personal data for behavioural advertising by a search engine
processing of data (content, traffic, location) by telephone or internet service providers
Examples that do not constitute large-scale processing include:
processing of patient data by an individual physician
processing of personal data relating to criminal convictions and offences by an individual
lawyer
2.1.4 ‘REGULAR AND SYSTEMATIC MONITORING’
The notion of regular and systematic monitoring of data subjects is not defined in the GDPR, but the
concept of ‘monitoring of the behaviour of data subjects’ is mentioned in recital 2415 and clearly
includes all forms of tracking and profiling on the internet, including for the purposes of behavioural
advertising.
However, the notion of monitoring is not restricted to the online environment and online tracking
should only be considered as one example of monitoring the behaviour of data subjects. 16
WP29 interprets ‘regular’ as meaning one or more of the following:
Ongoing or occurring at particular intervals for a particular period
Recurring or repeated at fixed times
15 ‘In order to determine whether a processing activity can be considered to monitor the behaviour of data
subjects, it should be ascertained whether natural persons are tracked on the internet including potential
subsequent use of personal data processing techniques which consist of profiling a natural person, particularly
in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences,
behaviours and attitudes’.
16
Note that Recital 24 focuses on the extra-territorial application of the GDPR. In addition, there is also a
difference between the wording ‘monitoring of their behaviour’ (Article 3(2)(b)) and ‘regular and systematic
monitoring of data subjects’ (Article 37(1)(b)) which could therefore be seen as constituting a different notion.
9
Constantly or periodically taking place
WP29 interprets ‘systematic’ as meaning one or more of the following:
Occurring according to a system
Pre-arranged, organised or methodical
Taking place as part of a general plan for data collection
Carried out as part of a strategy
Examples of activities that may constitute a regular and systematic monitoring of data subjects:
operating a telecommunications network; providing telecommunications services; email retargeting;
data-driven marketing activities; profiling and scoring for purposes of risk assessment (e.g. for
purposes of credit scoring, establishment of insurance premiums, fraud prevention, detection of
money-laundering); location tracking, for example, by mobile apps; loyalty programs; behavioural
advertising; monitoring of wellness, fitness and health data via wearable devices; closed circuit
television; connected devices e.g. smart meters, smart cars, home automation, etc.
2.1.5 SPECIAL CATEGORIES OF DATA AND DATA RELATING TO CRIMINAL CONVICTIONS AND
OFFENCES
Article 37(1)(c) addresses the processing of special categories of data pursuant to Article 9, and
personal data relating to criminal convictions and offences set out in in Article 10. Although the
provision uses the word ‘and’, there is no policy reason for the two criteria having to be applied
simultaneously. The text should therefore be read to say ‘or’.
2.2. DPO of the processor
Article 37 applies to both controllers17 and processors18 with respect to the designation of a DPO.
Depending on who fulfils the criteria on mandatory designation, in some cases only the controller or
only the processor, in other cases both the controller and its processor are required to appoint a DPO
(who should then cooperate with each other).
It is important to highlight that even if the controller fulfils the criteria for mandatory designation its
processor is not necessarily required to appoint a DPO. This may, however, be a good practice.
Examples:
A small family business active in the distribution of household appliances in a single town
uses the services of a processor whose core activity is to provide website analytics services
and assistance with targeted advertising and marketing. The activities of the family business
and its customers do not generate processing of data on a ‘large scale’, considering the small
number of customers and the relatively limited activities. However, the activities of the
processor, having many customers like this small enterprise, taken together, are carrying out
17 The controller is defined by Article 4(7) as the person or body, which determines the purposes and means of
the processing.
18 The processor is defined by Article 4(8) as the person or body, which processes data on behalf of the
controller.
10
large-scale processing. The processor must therefore designate a DPO under Article 37(1)(b).
At the same time, the family business itself is not under an obligation to designate a DPO.
A medium-size tile manufacturing company subcontracts its occupational health services to an
external processor, which has a large number of similar clients. The processor shall designate
a DPO under Article 37(1)(c) provided that the processing is on a large scale. However, the
manufacturer is not necessarily under an obligation to designate a DPO.
The DPO designated by a processor also oversees activities carried out by the processor organisation
when acting as a data controller in its own right (e.g. HR, IT, logistics).
2.3. Designation of a single DPO for several organisations
Article 37(2) allows a group of undertakings to designate a single DPO provided that he or she is
‘easily accessible from each establishment’. The notion of accessibility refers to the tasks of the DPO
as a contact point with respect to data subjects19, the supervisory authority20 but also internally within
the organisation, considering that one of the tasks of the DPO is ‘to inform and advise the controller
and the processor and the employees who carry out processing of their obligations pursuant to this
Regulation’.21
In order to ensure that the DPO, whether internal or external, is accessible it is important to make sure
that their contact details are available in accordance with the requirements of the GDPR.22
He or she, with the help of a team if necessary, must be in a position to efficiently communicate with
data subjects23 and cooperate24 with the supervisory authorities concerned. This also means that this
communication must take place in the language or languages used by the supervisory authorities and
the data subjects concerned. The availability of a DPO (whether physically on the same premises as
employees, via a hotline or other secure means of communication) is essential to ensure that data
subjects will be able to contact the DPO.
According to Article 37(3), a single DPO may be designated for several public authorities or bodies,
taking account of their organisational structure and size. The same considerations with regard to
resources and communication apply. Given that the DPO is in charge of a variety of tasks, the
controller or the processor must ensure that a single DPO, with the help of a team if necessary, can
perform these efficiently despite being designated for several public authorities and bodies.
19 Article 38(4): ‘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’.
20 Article 39(1)(e): ‘act as a contact point for the supervisory authority on issues relating to processing,
including the prior consultation referred to in Article 36 and to consult, where appropriate, with regard to any
other matter’.
21 Article 39(1)(a).
22 See also Section 2.6 below.
23 Article 12(1): ’The controller shall take appropriate measures to provide any information referred to in
Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data
subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in
particular for any information addressed specifically to a child. ’
24 Article 39(1)(d) : ‘to cooperate with the supervisory authority’
11
2.4. Accessibility and localisation of the DPO
According to Section 4 of the GDPR, the accessibility of the DPO should be effective.
To ensure that the DPO is accessible, the WP29 recommends that the DPO be located within the
European Union, whether or not the controller or the processor is established in the European Union.
However, it cannot be excluded that, in some situations where the controller or the processor has no
establishment within the European Union25, a DPO may be able to carry out his or her activities more
effectively if located outside the EU.
2.5. Expertise and skills of the DPO
Article 37(5) provides that the DPO ‘shall be designated on the basis ofprofessional qualities and, in
particular, expert knowledge of data protection law and practices and the ability to fulfil the tasks
referred to in Article 39’. Recital 97 provides that the necessary level of expert knowledge should be
determined according to the data processing operations carried out and the protection required for the
personal data being processed.
Level of expertise
The required level of expertise is not strictly defined but it must be commensurate with the sensitivity,
complexity and amount of data an organisation processes. For example, where a data processing
activity is particularly complex, or where a large amount of sensitive data is involved, the DPO may
need a higher level of expertise and support. There is also a difference depending on whether the
organisation systematically transfers personal data outside the European Union or whether such
transfers are occasional. The DPO should thus be chosen carefully, with due regard to the data
protection issues that arise within the organisation.
Professional qualities
Although Article 37(5) does not specify the professional qualities that should be considered when
designating the DPO, it is a relevant element that DPOs must have expertise in national and European
data protection laws and practices and an in-depth understanding of the GDPR. It is also helpful if the
supervisory authorities promote adequate and regular training for DPOs.
Knowledge of the business sector and of the organisation of the controller is useful. The DPO should
also have a good understanding of the processing operations carried out, as well as the information
systems, and data security and data protection needs of the controller.
In the case of a public authority or body, the DPO should also have a sound knowledge of the
administrative rules and procedures of the organisation.
25 See Article 3 of the GDPR on the territorial scope.
12
Ability to fulfil its tasks
Ability to fulfil the tasks incumbent on the DPO should be interpreted as both referring to their
personal qualities and knowledge, but also to their position within the organisation. Personal qualities
should include for instance integrity and high professional ethics; the DPO’s primary concern should
be enabling compliance with the GDPR. The DPO plays a key role in fostering a data protection
culture within the organisation and helps to implement essential elements of the GDPR, such as the
principles of data processing26, data subjects’ rights27, data protection by design and by default28,
records of processing activities29, security of processing30, and notification and communication of data
breaches. 31
DPO on the basis of a service contract
The function of the DPO can also be exercised on the basis of a service contract concluded with an
individual or an organisation outside the controller’s/processor’s organisation. In this latter case, it is
essential that each member of the organisation exercising the functions of a DPO fulfils all applicable
requirements of Section 4 of the GDPR (e.g., it is essential that no one has a conflict of interests). It is
equally important that each such member be protected by the provisions of the GDPR (e.g. no unfair
termination of service contract for activities as DPO but also no unfair dismissal of any individual
member of the organisation carrying out the DPO tasks). At the same time, individual skills and
strengths can be combined so that several individuals, working in a team, may more efficiently serve
their clients.
For the sake of legal clarity and good organisation and to prevent conflicts of interests for the team
members, it is recommended to have a clear allocation of tasks within the DPO team and to assign a
single individual as a lead contact and person ‘in charge’ for each client. It would generally also be
useful to specify these points in the service contract.
2.6. Publication and communication of the DPO’s contact details
Article 37(7) of the GDPR requires the controller or the processor:
to publish the contact details of the DPO and
to communicate the contact details of the DPO to the relevant supervisory authorities.
The objective of these requirements is to ensure that data subjects (both inside and outside of the
organisation) and the supervisory authorities can easily and directly contact the DPO without having to
contact another part of the organisation. Confidentiality is equally important: for example, employees
may be reluctant to complain to the DPO if the confidentiality of their communications is not
guaranteed.
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)).
26 Chapter II.
27 Chapter III.
28 Article 25.
29 Article 30.
30 Article 32.
31 Articles 33 and 34.
13
The contact details of the DPO should include information allowing data subjects and the supervisory
authorities to reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a
dedicated e-mail address). When appropriate, for purposes of communications with the public, other
means of communications could also be provided, for example, a dedicated hotline, or a dedicated
contact form addressed to the DPO on the organisation’s website.
Article 37(7) does not require that the published contact details should include the name of the DPO.
Whilst it may be a good practice to do so, it is for the controller or the processor and the DPO to
decide whether this is necessary or helpful in the particular circumstances.32
However, communication of the name of the DPO to the supervisory authority is essential in order for
the DPO to serve as contact point between the organisation and the supervisory authority (Article
39(1)(e).
As a matter of good practice, the WP29 also recommends that an organisation informs its employees
of the name and contact details of the DPO. For example, the name and contact details of the DPO
could be published internally on organisation’s intranet, internal telephone directory, and
organisational charts.
3 Position of the DPO
3.1. Involvement of the DPO in all issues relating to the protection of personal data
Article 38 of the GDPR provides that the controller and the processor shall ensure that the DPO is
‘involved, properly and in a timely manner, in all issues which relate to the protection of personal
data’.
It is crucial that the DPO, or his/her team, is involved from the earliest stage possible in all issues
relating to data protection. In relation to data protection impact assessments, the GDPR explicitly
provides for the early involvement of the DPO and specifies that the controller shall seek the advice of
the DPO when carrying out such impact assessments. 33 Ensuring that the DPO is informed and
consulted at the outset will facilitate compliance with the GDPR, promote a privacy by design
approach and should therefore be standard procedure within the organisation’s governance. In
addition, it is important that the DPO be seen as a discussion partner within the organisation and that
he or she be part of the relevant working groups dealing with data processing activities within the
organisation.
Consequently, the organisation should ensure, for example, that:
The DPO is invited to participate regularly in meetings of senior and middle management.
32 It is notable that Article 33(3)(b), which describes information that must be provided to the supervisory
authority and to the data subjects in case of a personal data breach, unlike Article 37(7), specifically also requires
the name (and not only the contact details) of the DPO to be communicated.
33 Article 35(2).
14
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.
3.2. Necessary resources
Article 38(2) of the GDPR requires the organisation to support its DPO by ‘providing resources
necessary to carry out [their] tasks and access to personal data and processing operations, and to
maintain his or her expert knowledge’. The following items, in particular, are to be considered:
Active support of the DPO’s function by senior management (such as at board level).
Sufficient time for DPOs to fulfil their duties. This is particularly important where an internal
DPO is appointed on a part-time basis or where the external DPO carries out data protection in
addition to other duties. Otherwise, conflicting priorities could result in the DPO’s duties
being neglected. Having sufficient time to devote to DPO tasks is paramount. It is a good
practice to establish a percentage of time for the DPO function where it is not performed on a
full-time basis. It is also good practice to determine the time needed to carry out the function,
the appropriate level of priority for DPO duties, and for the DPO (or the organisation) to draw
up a work plan.
Adequate support in terms of financial resources, infrastructure (premises, facilities,
equipment) and staff where appropriate.
Official communication of the designation of the DPO to all staff to ensure that their existence
and function are known within the organisation.
Necessary access to other services, such as Human Resources, legal, IT, security, etc., so that
DPOs can receive essential support, input and information from those other services.
Continuous training. DPOs must be given the opportunity to stay up to date with regard to
developments within the field of data protection. The aim should be to constantly increase the
level of expertise of DPOs and they should be encouraged to participate in training courses on
data protection and other forms of professional development, such as participation in privacy
fora, workshops, etc.
Given the size and structure of the organisation, it may be necessary to set up a DPO team (a
DPO and his/her staff). In such cases, the internal structure of the team and the tasks and
responsibilities of each of its members should be clearly drawn up. Similarly, when the
function of the DPO is exercised by an external service provider, a team of individuals
working for that entity may effectively carry out the tasks of a DPO as a team, under the
responsibility of a designated lead contact for the client.
In general, the more complex and/or sensitive the processing operations, the more resources must be
given to the DPO. The data protection function must be effective and sufficiently well-resourced in
relation to the data processing being carried out.
15
3.3. Instructions and ‘performing their duties and tasks in an independent manner’
Article 38(3) establishes some basic guarantees to help ensure that DPOs are able to perform their
tasks with a sufficient degree of autonomy within their organisation. In particular,
controllers/processors are required to ensure that the DPO ‘does not receive any instructions regarding
the exercise of[his or her] tasks.’ Recital 97 adds that DPOs, ‘whether or not they are an employee of
the controller, should be in a position to perform their duties and tasks in an independent manner’.
This means that, in fulfilling their tasks under Article 39, DPOs must not be instructed how to deal
with a matter, for example, what result should be achieved, how to investigate a complaint or whether
to consult the supervisory authority. Furthermore, they must not be instructed to take a certain view of
an issue related to data protection law, for example, a particular interpretation of the law.
The autonomy of DPOs does not, however, mean that they have decision-making powers extending
beyond their tasks pursuant to Article 39.
The controller or processor remains responsible for compliance with data protection law and must be
able to demonstrate compliance.34 If the controller or processor makes decisions that are incompatible
with the GDPR and the DPO’s advice, the DPO should be given the possibility to make his or her
dissenting opinion clear to the highest management level and to those making the decisions. In this
respect, Article 38(3) provides that the DPO ‘shall directly report to the highest management level of
the controller or the processor’. Such direct reporting ensures that senior management (e.g. board of
directors) is aware of the DPO’s advice and recommendations as part of the DPO’s mission to inform
and advise the controller or the processor. Another example of direct reporting is the drafting of an
annual report of the DPO’s activities provided to the highest management level.
3.4. Dismissal or penalty for performing DPO tasks
Article 38(3) requires that DPOs should ‘not be dismissed or penalised by the controller or the
processor for performing [their] tasks’.
This requirement strengthens the autonomy of DPOs and helps ensure that they act independently and
enjoy sufficient protection in performing their data protection tasks.
Penalties are only prohibited under the GDPR if they are imposed as a result of the DPO carrying out
his or her duties as a DPO. For example, a DPO may consider that a particular processing is likely to
result in a high risk and advise the controller or the processor to carry out a data protection impact
assessment but the controller or the processor does not agree with the DPO’s assessment. In such a
situation, the DPO cannot be dismissed for providing this advice.
Penalties may take a variety of forms and may be direct or indirect. They could consist, for example,
of absence or delay of promotion; prevention from career advancement; denial from benefits that other
employees receive. It is not necessary that these penalties be actually carried out, a mere threat is
sufficient as long as they are used to penalise the DPO on grounds related to his/her DPO activities.
34 Article 5(2).
16
As a normal management rule and as it would be the case for any other employee or contractor under,
and subject to, applicable national contract or labour and criminal law, a DPO could still be dismissed
legitimately for reasons other than for performing his or her tasks as a DPO (for instance, in case of
theft, physical, psychological or sexual harassment or similar gross misconduct).
In this context it should be noted that the GDPR does not specify how and when a DPO can be
dismissed or replaced by another person. However, the more stable a DPO’s contract is, and the more
guarantees exist against unfair dismissal, the more likely they will be able to act in an independent
manner. Therefore, the WP29 would welcome efforts by organisations to this effect.
3.5. Conflict of interests
Article 38(6) allows DPOs to ‘fulfil other tasks and duties’. It requires, however, that the organisation
ensure that ‘any such tasks and duties do not result in a conflict of interests’.
The absence of conflict of interests is closely linked to the requirement to act in an independent
manner. Although DPOs are allowed to have other functions, they can only be entrusted with other
tasks and duties provided that these do not give rise to conflicts of interests. This entails in particular
that the DPO cannot hold a position within the organisation that leads him or her to determine the
purposes and the means of the processing of personal data. Due to the specific organisational structure
in each organisation, this has to be considered case by case.
As a rule of thumb, conflicting positions within the organisation may include senior management
positions (such as chief executive, chief operating, chief financial, chief medical officer, head of
marketing department, head of Human Resources or head of IT departments) but also other roles lower
down in the organisational structure if such positions or roles lead to the determination of purposes
and means of processing. In addition, a conflict of interests may also arise for example if an external
DPO is asked to represent the controller or processor before the Courts in cases involving data
protection issues.
Depending on the activities, size and structure of the organisation, it can be good practice for
controllers or processors:
to identify the positions which would be incompatible with the function of DPO
to draw up internal rules to this effect in order to avoid conflicts of interests
to include a more general explanation about conflicts of interests
to declare that their DPO has no conflict of interests with regard to its function as a DPO, as a
way of raising awareness of this requirement
to include safeguards in the internal rules of the organisation and to ensure that the vacancy
notice for the position of DPO or the service contract is sufficiently precise and detailed in
order to avoid a conflict of interests. In this context, it should also be borne in mind that
conflicts of interests may take various forms depending on whether the DPO is recruited
internally or externally
17
4 Tasks of the DPO
4.1. Monitoring compliance with the GDPR
Article 39(1)(b) entrusts DPOs, among other duties, with the duty to monitor compliance with the
GDPR. Recital 97 further specifies that DPO ‘should assist the controller or the processor to monitor
internal compliance with this Regulation’.
As part of these duties to monitor compliance, DPOs may, in particular:
collect information to identify processing activities
analyse and check the compliance of processing activities
inform, advise and issue recommendations to the controller or the processor
Monitoring of compliance 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.
4.2. Role of the DPO 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 pursuant to Article 35’.
The WP29 recommends that the controller should seek the advice of the DPO, on the following issues,
amongst others 35:
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
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 account36.
35 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.
18
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.
4.3. Cooperating with the supervisory authority and acting as a contact point
According to Article 39(1)(d) and (e), the DPO should ‘cooperate with the supervisory authority’ and
‘act as a contact point for the supervisory authority on issues relating to processing, including the
prior consultation referred to in Article 36, and to consult, where appropriate, with regard to any
other matter’.
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.
4.4. Risk-based approach
Article 39(2) requires that the DPO ‘have due regard to the risk associated with the processing
operations, taking into account the nature, scope, context and purposes of processing’.
This article recalls a general and common sense principle, which may be relevant for many aspects of
a DPO’s day-to-day work. In essence, it requires DPOs to prioritise their activities and focus their
efforts on issues that present higher data protection risks. This does not mean that they should neglect
monitoring compliance of data processing operations that have comparatively lower level of risks, but
it does indicate that they should focus, primarily, on the higher-risk areas.
This selective and pragmatic approach should help DPOs advise the controller what methodology to
use when carrying out a DPIA, which areas should be subject to an internal or external data protection
audit, which internal training activities to provide to staff or management responsible for data
processing activities, and which processing operations to devote more of his or her time and resources
to.
36 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’.
19
4.5. Role of the DPO in record-keeping
Under Article 30(1) and (2), it is the controller or the processor, not the DPO, who is required to
‘maintain a record of processing operations under its responsibility’ or ‘maintain a record of all
categories of processing activities carried out on behalf of a controller’.
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 established under many current national laws and
under the data protection rules applicable to the EU institutions and bodies.37
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 or the processor. 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.
37 Article 24(1)(d), Regulation (EC) 45/2001 .
20
5 ANNEX –
DPO GUIDELINES: WHAT YOU NEED TO KNOW
The objective of this annex is to answer, in a simplified and easy-to-read format, some of the key
questions that organisations may have regarding the new requirements under the General Data
Protection Regulation (GDPR) to appoint a DPO.
Designation of the DPO
1 Which organisations must appoint a DPO?
The designation of a DPO is an obligation:
if the processing is carried out by a public authority or body (irrespective of what data is being
processed)
if the core activities of the controller or the processor consist of processing operations, which
require regular and systematic monitoring of data subjects on a large scale
if the core activities of the controller or the processor consist of processing on a large scale of
special categories of data or personal data relating to criminal convictions and offences
Note that Union or Member State law may require the designation of DPOs in other situations as well.
Finally, even if the designation of a DPO is not mandatory, organisations may sometimes find it useful
to designate a DPO on a voluntary basis. The Article 29 Data Protection Working Party (‘WP29’)
encourages these voluntary efforts. When an organisation designates a DPO on a voluntary basis, the
same requirements will apply to his or her designation, position and tasks as if the designation had
been mandatory.
Source: Article 37(1) of the GDPR
2 What does ‘core activities’ mean?
‘Core activities’ can be considered as the key operations to achieve the controller’s or processor’s
objectives. These also include all activities where the processing of data forms as inextricable part of
the controller’s or processor’s activity. For example, processing health data, such as patient’s health
records, should be considered as one of any hospital’s core activities and hospitals must therefore
designate DPOs.
On the other hand, all organisations carry out certain supporting activities, for example, paying their
employees or having standard IT support activities. These are examples of necessary support functions
for the organisation’s core activity or main business. Even though these activities are necessary or
essential, they are usually considered ancillary functions rather than the core activity.
Source: Article 37(1)(b) and (c) of the GDPR
21
3 What does ‘large scale’ mean?
The GDPR does not define what constitutes large-scale processing. The WP29 recommends that the
following factors, in particular, be considered when determining whether the processing is carried out
on a large scale:
the number of data subjects concerned – either as a specific number or as a proportion of the
relevant population
the volume of data and/or the range of different data items being processed
the duration, or permanence, of the data processing activity
the geographical extent of the processing activity
Examples of large scale processing include:
processing of patient data in the regular course of business by a hospital
processing of travel data of individuals using a city’s public transport system (e.g. tracking via
travel cards)
processing of real time geo-location data of customers of an international fast food chain for
statistical purposes by a processor specialised in these activities
processing of customer data in the regular course of business by an insurance company or a bank
processing of personal data for behavioural advertising by a search engine
processing of data (content, traffic, location) by telephone or internet service providers
Examples that do not constitute large-scale processing include:
processing of patient data by an individual physician
processing of personal data relating to criminal convictions and offences by an individual lawyer
Source: Article 37(1)(b) and (c) of the GDPR
4 What does ‘regular and systematic monitoring’ mean?
The notion of regular and systematic monitoring of data subjects is not defined in the GDPR, but
clearly includes all forms of tracking and profiling on the internet, including for the purposes of
behavioural advertising. However, the notion of monitoring is not restricted to the online environment.
Examples of activities that may constitute a regular and systematic monitoring of data subjects:
operating a telecommunications network; providing telecommunications services; email retargeting;
data-driven marketing activities; profiling and scoring for purposes of risk assessment (e.g. for
purposes of credit scoring, establishment of insurance premiums, fraud prevention, detection of
money-laundering); location tracking, for example, by mobile apps; loyalty programs; behavioural
advertising; monitoring of wellness, fitness and health data via wearable devices; closed circuit
television; connected devices e.g. smart meters, smart cars, home automation, etc.
WP29 interprets ‘regular’ as meaning one or more of the following:
ongoing or occurring at particular intervals for a particular period
recurring or repeated at fixed times
constantly or periodically taking place
WP29 interprets ‘systematic’ as meaning one or more of the following:
occurring according to a system
22
pre-arranged, organised or methodical
taking place as part of a general plan for data collection
carried out as part of a strategy
Source: Article 37(1)(b) of the GDPR
5 Can organisations appoint a DPO jointly? If so, under what conditions?
Yes. A group of undertakings may designate a single DPO provided that he or she is ‘ easily accessible
from each establishment’. The notion of accessibility refers to the tasks of the DPO as a contact point
with respect to data subjects, the supervisory authority and also internally within the organisation. In
order to ensure that the DPO is accessible, whether internal or external, it is important to make sure
that their contact details are available. The DPO, with the help of a team if necessary, must be in a
position to efficiently communicate with data subjects and cooperate with the supervisory authorities
concerned. This means that this communication must take place in the language or languages used by
the supervisory authorities and the data subjects concerned. The availability of a DPO (whether
physically on the same premises as employees, via a hotline or other secure means of communication)
is essential to ensure that data subjects will be able to contact the DPO.
A single DPO may be designated for several public authorities or bodies, taking account of their
organisational structure and size. The same considerations with regard to resources and
communication apply. Given that the DPO is in charge of a variety of tasks, the controller or the
processor must ensure that a single DPO, with the help of a team if necessary, can perform these
efficiently despite being designated for several public authorities and bodies.
Source: Article 37(2) and (3) of the GDPR
6 Where should the DPO be located?
To ensure that the DPO is accessible, the WP29 recommends that the DPO be located within the
European Union, whether or not the controller or the processor is established in the European Union.
However, it cannot be excluded that, in some situations where the controller or the processor has no
establishment within the European Union, a DPO may be able to carry out his or her activities more
effectively if located outside the EU.
7 Is it possible to appoint an external DPO?
Yes. The DPO may be a staff member of the controller or the processor (internal DPO) or fulfil the
tasks on the basis of a service contract. This means that the DPO can be external, and in this case,
his/her function can be exercised based on a service contract concluded with an individual or an
organisation.
When the function of the DPO is exercised by an external service provider, a team of individuals
working for that entity may effectively carry out the DPO tasks as a team, under the responsibility of a
designated lead contact and ‘person in charge’ of the client. In this case, it is essential that each
member of the external organisation exercising the functions of a DPO fulfils all applicable
requirements of the GDPR.
23
For the sake of legal clarity and good organisation and to prevent conflicts of interests for the team
members, the Guidelines recommend to have, in the service contract, a clear allocation of tasks within
the external DPO team and to assign a single individual as a lead contact and person ‘in charge’ of the
client.
Source: Article 37(6) of the GDPR
8 What are the professional qualities that the DPO should have?
The DPO shall be designated on the basis of professional qualities and, in particular, expert knowledge
of data protection law and practices and the ability to fulfil his or her tasks.
The necessary level of expert knowledge should be determined according to the data processing
operations carried out and the protection required for the personal data being processed. For example,
where a data processing activity is particularly complex, or where a large amount of sensitive data is
involved, the DPO may need a higher level of expertise and support.
Relevant skills and expertise include:
expertise in national and European data protection laws and practices including an in-depth
understanding of the GDPR
understanding of the processing operations carried out
understanding of information technologies and data security
knowledge of the business sector and the organisation
ability to promote a data protection culture within the organisation
Source: Article 37(5) of the GDPR
Position of the DPO
9 What resources should be provided to the DPO by the controller or the processor?
The DPO must have the resources necessary to be able to carry out his or her tasks.
Depending on the nature of the processing operations and the activities and size of the organisation,
the following resources should be provided to the DPO:
active support of the DPO’s function by senior management
sufficient time for DPOs to fulfil their tasks
adequate support in terms of financial resources, infrastructure (premises, facilities,
equipment) and staff where appropriate
official communication of the designation of the DPO to all staff
access to other services within the organisation so that DPOs can receive essential support,
input or information from those other services
continuous training
24
Source: Article 38(2) of the GDPR
10 What are the safeguards to enable the DPO to perform her/his tasks
in an independent manner? What does ‘conflict of interests’ mean?
Several safeguards exist in order to enable the DPO to act in an independent manner:
no instructions by the controllers or the processors regarding the exercise of the DPO’s tasks
no dismissal or penalty by the controller for the performance of the DPO’s tasks
no conflict of interest with possible other tasks and duties
The other tasks and duties of a DPO must not result in a conflict of interests. This means, first, that the
DPO cannot hold a position within the organisation that leads him or her to determine the purposes
and the means of the processing of personal data. Due to the specific organisational structure in each
organisation, this has to be considered case by case.
As a rule of thumb, conflicting positions within the organisation may include senior management
positions (such as chief executive, chief operating, chief financial, chief medical officer, head of
marketing department, head of Human Resources or head of IT departments) but also other roles lower
down in the organisational structure if such positions or roles lead to the determination of purposes
and means of processing. In addition, a conflict of interests may also arise for example if an external
DPO is asked to represent the controller or processor before the Courts in cases involving data
protection issues.
Source: Article 38(3) and 38(6) of the GDPR
Tasks of the DPO
11 What does ‘monitoring compliance’ mean?
As part of these duties to monitor compliance, DPOs may, in particular:
collect information to identify processing activities
analyse and check the compliance of processing activities
inform, advise and issue recommendations to the controller or the processor
Source: Article 39(1)(b) of the GDPR
12 Is the DPO personally responsible for non-compliance with data protection
requirements?
No. DPOs are not personally responsible for non-compliance with data protection requirements. It is
the controller or the processor who is required to ensure and to be able to demonstrate that processing
25
is performed in accordance with this Regulation. Data protection compliance is the responsibility of
the controller or the processor.
13 What is the role of the DPO with respect to data protection impact assessments and
records of processing activities?
As far as the data protection impact assessment is concerned, the controller or the processor should
seek the advice of the DPO, on the following issues, amongst others:
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
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 data protection requirements
As far as the records of processing activities are concerned, it is the controller or the processor, not the
DPO, who is required to maintain records of processing operations. However, nothing prevents the
controller or the processor from assigning the DPO with the task of maintaining the records of
processing operations under the responsibility of the controller or the processor. Such records 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.
Source: Article 39(1)(c) and Article 30 of the GDPR
Done in Brussels, on 13 December 2016
For the Working Party,
The Chairwoman
Isabelle FALQUE-PIERROTIN
As last revised and adopted on 05 April 2017
For the Working Party
The Chairwoman
Isabelle FALQUE-PIERROTIN
ARTICLE 29 DATA PROTECTION WORKING PARTY
This Working Party w as set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data
protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC.
The secretariat is provided by Directorate C (Fundamental Rights and Union Citizenship) of the European Commission,
Directorate General Justice, B-1049 Brussels, Belgium, Office No MO-59 02/013.
Website: http://ec.europa.eu/justice/data-protection/index_en.htm
18/EN
WP250rev.01
Guidelines on Personal data breach notification under Regulation 2016/679
Adopted on 3 October 2017
As last Revised and Adopted on 6 February 2018
2
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO THE
PROCESSING OF PERSONAL DATA
set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995,
having regard to Articles 29 and 30 thereof,
having regard to its Rules of Procedure,
HAS ADOPTED THE PRESENT GUIDELINES:
3
TABLE OF CONTENTS
INTRODUCTION
The General Data Protection Regulation (the GDPR) introduces the requirement for a personal data
breach (henceforth “breach”) to be notified to the competent national supervisory authority1 (or in the
case of a cross-border breach, to the lead authority) and, in certain cases, to communicate the breach
to the individuals whose personal data have been affected by the breach.
Obligations to notify in cases of breaches presently exist for certain organisations, such as providers
of publicly-available electronic communications services (as specified in Directive 2009/136/EC and
Regulation (EU) No 611/2013)2. There are also some EU Member States that already have their own
national breach notification obligation. This may include the obligation to notify breaches involving
categories of controllers in addition to providers of publicly available electronic communication
services (for example in Germany and Italy), or an obligation to report all breaches involving personal
data (such as in the Netherlands). Other Member States may have relevant Codes of Practice (for
example, in Ireland3). Whilst a number of EU data protection authorities currently encourage
controllers to report breaches, the Data Protection Directive 95/46/EC4, which the GDPR replaces,
does not contain a specific breach notification obligation and therefore such a requirement will be new
for many organisations. The GDPR now makes notification mandatory for all controllers unless a
breach is unlikely to result in a risk to the rights and freedoms of individuals 5. Processors also have an
important role to play and they must notify any breach to their controller6.
The Article 29 Working Party (WP29) considers that the new notification requirement has a number
of benefits. When notifying the supervisory authority, controllers can obtain advice on whether the
affected individuals need to be informed. Indeed, the supervisory authority may order the controller to
inform those individuals about the breach7. Communicating a breach to individuals allows the
controller to provide information on the risks presented as a result of the breach and the steps those
individuals can take to protect themselves from its potential consequences. The focus of any breach
response plan should be on protecting individuals and their personal data. Consequently, breach
notification should be seen as a tool enhancing compliance in relation to the protection of personal
data. At the same time, it should be noted that failure to report a breach to either an individual or a
supervisory authority may mean that under Article 83 a possible sanction is applicable to the
controller.
1 See Article 4(21) of the GDPR
2 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32009L0136 and http://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32013R0611
3 See https://www.dataprotection.ie/docs/Data_Security_Breach_Code_of_Practice/1082.htm
4 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:31995L0046
5 The rights enshrined in the Charter of Fundamental Rights of the EU, available at http://eurlex.europa.eu/legal-content/EN/TXT/?uri=CELEX:12012P/TXT
6 See Article 33(2). This is similar in concept to Article 5 of Regulation (EU) No 611/2013 which states that a
provider that is contracted to deliver part of an electronic communications service (without having a direct
contractual relationship with subscribers) is obliged to notify the contracting provider in the event of a personal
data breach.
7 See Articles 34(4) and 58(2)(e)
6
Controllers and processors are therefore encouraged to plan in advance and put in place processes to
be able to detect and promptly contain a breach, to assess the risk to individuals8, and then to
determine whether it is necessary to notify the competent supervisory authority, and to communicate
the breach to the individuals concerned when necessary. Notification to the supervisory authority
should form a part of that incident response plan.
The GDPR contains provisions on when a breach needs to be notified, and to whom, as well as what
information should be provided as part of the notification. Information required for the notification
can be provided in phases, but in any event controllers should act on any breach in a timely manner.
In its Opinion 03/2014 on personal data breach notification9, WP29 provided guidance to controllers
in order to help them to decide whether to notify data subjects in case of a breach. The opinion
considered the obligation of providers of electronic communications regarding Directive 2002/58/EC
and provided examples from multiple sectors, in the context of the then draft GDPR, and presented
good practices for all controllers.
The current Guidelines explain the mandatory breach notification and communication requirements of
the GDPR and some of the steps controllers and processors can take to meet these new obligations.
They also give examples of various types of breaches and who would need to be notified in different
scenarios.
I. Personal data breach notification under the GDPR
A. Basic security considerations
One of the requirements of the GDPR is that, by using appropriate technical and organisational
measures, personal data shall be processed in a manner to ensure the appropriate security of the
personal data, including protection against unauthorised or unlawful processing and against accidental
loss, destruction or damage10.
Accordingly, the GDPR requires both controllers and processors to have in place appropriate
technical and organisational measures to ensure a level of security appropriate to the risk posed to the
personal data being processed. They should take into account the state of the art, the costs of
implementation and the nature, the scope, context and purposes of processing, as well as the risk of
varying likelihood and severity for the rights and freedoms of natural persons11. Also, the GDPR
requires all appropriate technological protection an organisational measures to be in place to establish
immediately whether a breach has taken place, which then determines whether the notification
obligation is engaged12.
Consequently, a key element of any data security policy is being able, where possible, to prevent a
breach and, where it nevertheless occurs, to react to it in a timely manner.
8 This can be ensured under the monitoring and review requirement of a DPIA, which is required for processing
operations likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1) and (11).
9 See Opinion 03/2014 on Personal Data Breach Notification http://ec.europa.eu/justice/data-protection/article-
29/documentation/opinion-recommendation/files/2014/wp213_en.pdf
10 See Articles 5(1)(f) and 32.
11 Article 32; see also Recital 83
12 See Recital 87
7
B. What is a personal data breach?
1. Definition
As part of any attempt to address a breach the controller should first be able to recognise one. The
GDPR defines a “personal data breach” in Article 4(12) 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.”
What is meant by “destruction” of personal data should be quite clear: this is where the data no longer
exists, or no longer exists in a form that is of any use to the controller. “Damage” should also be
relatively clear: this is where personal data has been altered, corrupted, or is no longer complete. In
terms of “loss” of personal data, this should be interpreted as the data may still exist, but the controller
has lost control or access to it, or no longer has it in its possession. Finally, unauthorised or unlawful
processing may include disclosure of personal data to (or access by) recipients who are not authorised
to receive (or access) the data, or any other form of processing which violates the GDPR.
Example
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 ofa
set of personal data has been encrypted by ransomware, or has been encrypted by the controller using
a key that is no longer in its possession.
What should be clear is that a breach is a type of security incident. However, as indicated by Article
4(12), the GDPR only applies where there is a breach of personal data. The consequence of such a
breach is that the controller will be unable to ensure compliance with the principles relating to the
processing of personal data as outlined in Article 5 of the GDPR. This highlights the difference
between a security incident and a personal data breach – in essence, whilst all personal data breaches
are security incidents, not all security incidents are necessarily personal data breaches 13.
The potential adverse effects of a breach on individuals are considered below.
2. Types of personal data breaches
In its Opinion 03/2014 on breach notification, WP29 explained that breaches can be categorised
according to the following three well-known information security principles14:
“Confidentiality breach” – where there is an unauthorised or accidental disclosure of, or
access to, personal data.
“Integrity breach” – where there is an unauthorised or accidental alteration of personal data.
“Availability breach” – where there is an accidental or unauthorised loss of access15 to, or
destruction of, personal data.
13 It should be noted that a security incident is not limited to threat models where an attack is made on an
organisation from an external source, but includes incidents from internal processing that breach security
principles.
14 See Opinion 03/2014
15 It is well established that “access” is fundamentally part of “availability” . See, for example, NIST SP800-
53rev4, which defines “availability” as : “Ensuring timely and reliable access to and use of information,”
8
It should also be noted that, depending on the circumstances, a breach can concern confidentiality,
integrity and availability of personal data at the same time, as well as any combination of these.
Whereas determining if there has been a breach of confidentiality or integrity is relatively clear,
whether there has been an availability breach may be less obvious. A breach will always be regarded
as an availability breach when there has been a permanent loss of, or destruction of, personal data.
Example
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 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.
The question may be asked whether a temporary loss of availability of personal data should be
considered as a breach and, if so, one which needs to be notified. Article 32 of the GDPR, “security of
processing,” explains that when implementing technical and organisational measures to ensure a level
of security appropriate to the risk, consideration should be given, amongst other things, to “the ability
to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and
services,” and “the ability to restore the availability and access to personal data in a timely manner in
the event of a physical or technical incident”.
Therefore, a security incident resulting in personal data being made unavailable for a period of time is
also a type of breach, as the lack of access to the data can have a significant impact on the rights and
freedoms of natural persons. To be clear, where personal data is unavailable due to planned system
maintenance being carried out this is not a ‘breach of security’ as defined in Article 4(12).
As with a permanent loss or destruction of personal data (or indeed any other type of breach), a breach
involving the temporary loss of availability should be documented in accordance with Article 33(5).
This assists the controller in demonstrating accountability to the supervisory authority, which may ask
to see those records16.However, depending on the circumstances of the breach, it may or may not
require notification to the supervisory authority and communication to affected individuals. The
controller will need to assess the likelihood and severity of the impact on the rights and freedoms of
natural persons as a result of the lack of availability of personal data. In accordance with Article 33,
the controller will need to notify unless the breach is unlikely to result in a risk to individuals’ rights
and freedoms. Of course, this will need to be assessed on a case-by-case basis.
Examples
available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf. CNSSI-4009 also refers
to: “The property of being accessible and useable upon demand by an authorized entity.” See
https://rmf.org/images/4-CNSS-Publications/CNSSI-4009.pdf. ISO/IEC 27000:201 6 also defines “availability”
as “Property of being accessible and usable upon demand by an authorized entity”:
https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-4:v1:en
16 See Article 33(5)
9
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.
It should be noted that although a loss of availability of a controller’s systems might be only
temporary and may not have an impact on individuals, it is important for the controller to consider all
possible consequences of a breach, as it may still require notification for other reasons.
Example
Infection by ransomware (malicious software which encrypts the controller’s data until a ransom is
paid) 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.
3. The possible consequences of a personal data breach
A breach can potentially have a range of significant adverse effects on individuals, which can result in
physical, material, or non-material damage. The GDPR explains that this can include loss of control
over their personal data, limitation of their rights, discrimination, identity theft or fraud, financial loss,
unauthorised reversal of pseudonymisation, damage to reputation, and loss of confidentiality of
personal data protected by professional secrecy. It can also include any other significant economic or
social disadvantage to those individuals17.
Accordingly, the GDPR requires the controller to notify a breach to the competent supervisory
authority, unless it is unlikely to result in a risk of such adverse effects taking place. Where there is a
likely high risk of these adverse effects occurring, the GDPR requires the controller to communicate
the breach to the affected individuals as soon as is reasonably feasible 18.
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.”
Further guidelines on assessing the risk of adverse effects to individuals are considered in section IV.
If controllers fail to notify either the supervisory authority or data subjects of a data breach or both
even though the requirements of Articles 33 and/or 34 are fulfilled, then the supervisory authority is
17 See also Recitals 85 and 75
18 See also Recital 86.
10
presented with a choice that must include consideration of all of the corrective measures at its
disposal, which would include consideration of the imposition of the appropriate administrative fine 19,
either accompanying a corrective measure under Article 58(2) or on its own. Where an administrative
fine is chosen, its value can be up to 10,000,000 EUR or up to 2 % if the total worldwide annual
turnover of an undertaking under Article 83(4)(a) of the GDPR. It is also important to bear in mind
that in some cases, the failure to notify a breach could reveal either an absence of existing security
measures or an inadequacy of the existing security measures. The WP29 guidelines on administrative
fines state: “The occurrence of several different infringements committed together in any particular
single case means that the supervisory authority is able to apply the administrative fines at a level
which is effective, proportionate and dissuasive within the limit of the gravest infringement”. In that
case, the supervisory authority will also have the possibility to issue sanctions for failure to notify or
communicate the breach (Articles 33 and 34) on the one hand, and absence of (adequate) security
measures (Article 32) on the other hand, as they are two separate infringements.
II. Article 33 – Notification to the supervisory authority
A. When to notify
1. Article 33 requirements
Article 33(1) provides 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. ”
Recital 87 states20:
“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.”
2. When does a controller become “aware”?
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
19 For further details, please see WP29 Guidelines on the application and setting of administrative fines,
available here: http://ec.europa.eu/newsroom/just/document.cfm?doc_id=47889
20
Recital 85 is also important here.
11
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 attacked the controller has clear evidence
that a breach has occurred and there is no doubt that it has become aware.
After first being informed of a potential breach by an individual, a media organisation, or another
source, or when it has itself detected a security incident, the controller may undertake a short period of
investigation in order to establish whether or not a breach has in fact occurred. During this period of
investigation the controller may not be regarded as being “aware”. However, it is expected that the
initial investigation should begin as soon as possible and establish with a reasonable degree of
certainty whether a breach has taken place; a more detailed investigation can then follow.
Once the controller has become aware, a notifiable breach must be notified without undue delay, and
where feasible, not later than 72 hours. During this period, the controller should assess the likely risk
to individuals in order to determine whether the requirement for notification has been triggered, as
well as the action(s) needed to address the breach. However, a controller may already have an initial
assessment of the potential risk that could result from a breach as part of a data protection impact
21 See Recital 87
12
assessment (DPIA)22 made prior to carrying out the processing operation concerned. However, the
DPIA may be more generalised in comparison to the specific circumstances of any actual breach, and
so in any event an additional assessment taking into account those circumstances will need to be
made. For more detail on assessing risk, see section IV.
In most cases these preliminary actions should be completed soon after the initial alert (i.e. when the
controller or processor suspects there has been a security incident which may involve personal data. ) –
it should take longer than this only in exceptional cases.
Example
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.
The controller should therefore have internal processes in place to be able to detect and address a
breach. For example, for finding some irregularities in data processing the controller or processor may
use certain technical measures such as data flow and log analysers, from which is possible to define
events and alerts by correlating any log data23. It is important that when a breach is detected it is
reported upwards to the appropriate level of management so it can be addressed and, if required,
notified in accordance with Article 33 and, if necessary, Article 34. Such measures and reporting
mechanisms could be detailed in the controller’s incident response plans and/or governance
arrangements. These will help the controller to plan effectively and determine who has operational
responsibility within the organisation for managing a breach and how or whether to escalate an
incident as appropriate.
The controller should also have in place arrangements with any processors the controller uses, which
themselves have an obligation to notify the controller in the event of a breach (see below).
Whilst it is the responsibility of controllers and processors to put in place suitable measures to be able
to prevent, react and address a breach, there are some practical steps that should be taken in all cases.
Information concerning all security-related events should be directed towards a responsible
person or persons with the task of addressing incidents, establishing the existence of a breach
and assessing risk.
Risk to individuals as a result of a breach should then be assessed (likelihood of no risk, risk
or high risk), with relevant sections of the organisation being informed.
Notification to the supervisory authority, and potentially communication of the breach to the
affected individuals should be made, if required.
At the same time, the controller should act to contain and recover the breach.
Documentation of the breach should take place as it develops.
Accordingly, it should be clear that there is an obligation on the controller to act on any initial alert
and establish whether or not a breach has, in fact, occurred. This brief period allows for some
22 See WP29 Guidelines on DPIAs here: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
23
It should be noted that log data facilitating auditability of, e.g., storage, modifications or erasure of data may
also qualify as personal data relating to the person who initiated the respective processing operation.
13
investigation, and for the controller to gather evidence and other relevant details. However, once the
controller has established with a reasonable degree of certainty that a breach has occurred, if the
conditions in Article 33(1) have been met, it must then notify the supervisory authority without undue
delay and, where feasible, not later than 72 hours24. If a controller fails to act in a timely manner and it
becomes apparent that a breach did occur, this could be considered as a failure to notify in accordance
with Article 33.
Article 32 makes clear that the controller and processor should have appropriate technical and
organisational measures in place to ensure an appropriate level of security of personal data: the ability
to detect, address, and report a breach in a timely manner should be seen as essential elements of these
measures.
3. Joint controllers
Article 26 concerns joint controllers and specifies that joint controllers shall determine their respective
responsibilities for compliance with the GDPR25. This will include determining which party will have
responsibility for complying with the obligations under Articles 33 and 34. WP29 recommends that
the contractual arrangements between joint controllers include provisions that determine which
controller will take the lead on, or be responsible for, compliance with the GDPR’s breach notification
obligations.
4. Processor obligations
The controller retains overall responsibility for the protection of personal data, but the processor has
an important role to play to enable the controller to comply with its obligations; and this includes
breach notification. Indeed, Article 28(3) specifies that the processing by a processor shall be
governed by a contract or other legal act. Article 28(3)(f) states that the contract or other legal act
shall stipulate that the processor “assists the controller in ensuring compliance with the obligations
pursuant to Articles 32 to 36 taking into account the nature of processing and the information
available to the processor”.
Article 33(2) makes it clear that if a processor is used by a controller and the processor becomes
aware of a breach of the personal data it is processing on behalf of the controller, it must notify the
controller “without undue delay”. It should be noted that the processor does not need to first assess the
likelihood of risk arising from a breach before notifying the controller; it is the controller that must
make this assessment on becoming aware of the breach. The processor just needs to establish whether
a breach has occurred and then notify the controller. The controller uses the processor to achieve its
purposes; therefore, in principle, the controller should be considered as “aware” once the processor
has informed it of the breach. The obligation on the processor to notify its controller allows the
controller to address the breach and to determine whether or not it is required to notify the supervisory
authority in accordance with Article 33(1) and the affected individuals in accordance with Article
34(1). The controller might also want to investigate the breach, as the processor might not be in a
position to know all the relevant facts relating to the matter, for example, if a copy or backup of
personal data destroyed or lost by the processor is still held by the controller. This may affect whether
the controller would then need to notify.
The GDPR does not provide an explicit time limit within which the processor must alert the
controller, except that it must do so “without undue delay”. Therefore, WP29 recommends the
24 See Regulation No 1182/71 determining the rules applicable to perio ds, dates and time limits, available at:
http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:31971R1182&from=EN
25 See also Recital 79.
14
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.
As is explained above, the contract between the controller and processor should specify how the
requirements expressed in Article 33(2) should be met in addition to other provisions in the GDPR.
This can include requirements for early notification by the processor that in turn support the
controller’s obligations to report to the supervisory authority within 72 hours.
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.
B. Providing information to the supervisory authority
1. Information to be provided
When a controller notifies a breach to the supervisory authority, Article 33(3) states that, at the
minimum, it should:
“(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. ”
The GDPR does not define categories of data subjects or personal data records. However, WP29
suggests categories of data subjects to refer to the various types of individuals whose personal data
has been affected by a breach: depending on the descriptors used, this could include, amongst others,
children and other vulnerable groups, people with disabilities, employees or customers. Similarly,
categories of personal data records can refer to the different types of records that the controller may
process, such as health data, educational records, social care information, financial details, bank
account numbers, passport numbers and so on.
Recital 85 makes it clear that one of the purposes of notification is limiting damage to individuals.
Accordingly, 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.
Where precise information is not available (e.g. exact number of data subjects affected) this should
not be a barrier to timely breach notification. The GDPR allows for approximations to be made in the
number of individuals affected and the number of personal data records concerned. The focus should
be directed towards addressing the adverse effects of the breach rather than providing precise figures.
15
Thus, when it has become clear that here has been a breach, but the extent of it is not yet known, a
notification in phases (see below) is a safe way to meet the notification obligations.
Article 33(3) states that the controller “shall at least” provide this information with a notification, so a
controller can, 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.
2. Notification in phases
Depending on the nature of a breach, further investigation by the controller may be necessary to
establish all of the relevant facts relating to the incident. Article 33(4) therefore states:
“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.”
This means that the GDPR recognises that controllers will not always have all of the necessary
information concerning a breach within 72 hours of becoming aware of it, as full and comprehensive
details of the incident may not always be available during this initial period. As such, it allows for a
notification in phases. It is more likely this will be the case for more complex breaches, such as some
types of cyber security incidents where, for example, an in-depth forensic investigation may be
necessary to fully establish the nature of the breach and the extent to which personal data have been
compromised. Consequently, in many cases the controller will have to do more investigation and
follow-up with additional information at a later point. This is permissible, providing the controller
gives reasons for the delay, in accordance with Article 33(1). WP29 recommends that when the
controller first notifies the supervisory authority, the controller should also inform the supervisory
authority if the controller does not yet have all the required information and will provide more details
later on. The supervisory authority should agree how and when additional information should be
provided. This does not prevent the controller from providing further information at any other stage, if
it becomes aware of additional relevant details about the breach that need to be provided to the
supervisory authority.
The focus of the notification requirement is to encourage controllers to act promptly on a breach,
contain it and, if possible, recover the compromised personal data, and to seek relevant advice from
the supervisory authority. Notifying the supervisory authority within the first 72 hours can allow the
controller to make sure that decisions about notifying or not notifying individuals are correct.
However, the purpose of notifying the supervisory authority is not solely to obtain guidance on
whether to notify the affected individuals. It will be obvious in some cases that, due to the nature of
the breach and the severity of the risk, the controller will need to notify the affected individuals
without delay. For example, if there is an immediate threat of identity theft, or if special categories of
personal data26 are disclosed online, the controller should act without undue delay to contain the
26 See Article 9.
16
breach and to communicate it to the individuals concerned (see section III). In exceptional
circumstances, this might even take place before notifying the supervisory authority. More generally,
notification of the supervisory authority may not serve as a justification for failure to communicate the
breach to the data subject where it is required.
It should also be clear that after making an initial notification, a controller could update the
supervisory authority if a follow-up investigation uncovers evidence that the security incident was
contained and no breach actually occurred. This information could then be added to the information
already given to the supervisory authority and the incident recorded accordingly as not being a breach.
There is no penalty for reporting an incident that ultimately transpires not to be a breach.
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.
It should be noted that a phased approach to notification is already the case under the existing
obligations of Directive 2002/58/EC, Regulation 611/2013 and other self-reported incidents.
3. Delayed notifications
Article 33(1) makes it clear that where notification to the supervisory authority is not made within 72
hours, it shall be accompanied by reasons for the delay. This, along with the concept of notification in
phases, recognises that a controller may not always be able to notify a breach within that time period,
and that a delayed notification may be permissible.
Such a scenario might take place where, for example, a controller experiences multiple, similar
confidentiality breaches over a short period of time, affecting large numbers of data subjects in the
same way. A controller could become aware of a breach and, whilst beginning its investigation, and
before notification, detect further similar breaches, which have different causes. Depending on the
circumstances, it may take the controller some time to establish the extent of the breaches and, rather
than notify each breach individually, the controller instead organises a meaningful notification that
represents several very similar breaches, with possible different causes. This could lead to notification
to the supervisory authority being delayed by more than 72 hours after the controller first becomes
aware of these breaches.
Strictly speaking, each individual breach is a reportable incident. However, to avoid being overly
burdensome, the controller may be able to submit a “bundled” notification representing all these
breaches, provided that they concern the same type of personal data breached in the same way, over a
relatively short space of time. If a series of breaches take place that concern different types of
personal data, breached in different ways, then notification should proceed in the normal way, with
each breach being reported in accordance with Article 33.
Whilst the GDPR allows for delayed notifications to an extent, this should not be seen as something
that regularly takes place. It is worth pointing out that bundled notifications can also be made for
multiple similar breaches reported within 72 hours.
C. Cross-border breaches and breaches at non-EU establishments
1. Cross-border breaches
17
Where there is cross-border processing27 of personal data, a breach may affect data subjects in more
than one Member State. Article 33(1) makes it clear that when a breach has occurred, the controller
should notify the supervisory authority competent in accordance with Article 55 of the GDPR28.
Article 55(1) says that:
“Each supervisory authority shall be competent for the performance of the tasks assigned to and the
exercise of the powers conferred on it in accordance with this Regulation on the territory of its own
Member State.”
However, Article 56(1) states:
“Without prejudice to Article 55, the supervisory authority of the main establishment or of the single
establishment of the controller or processor shall be competent to act as lead supervisory authority for
the cross-border processing carried out by that controller or processor in accordance with the
procedure provided in Article 60.”
Furthermore, Article 56(6) states:
“The lead supervisory authority shall be the sole interlocutor of the controller or processor for the
cross-border processing carried out by that controller or processor.”
This means that whenever a breach takes place in the context of cross-border processing and
notification is required, the controller will need to notify the lead supervisory authority29. Therefore,
when drafting its breach response plan, a controller must make an assessment as to which supervisory
authority is the lead supervisory authority that it will need to notify30. This will allow the controller to
respond promptly to a breach and to meet its obligations in respect of Article 33. It should be clear
that in the event of a breach involving cross-border processing, notification must be made to the lead
supervisory authority, which is not necessarily where the affected data subjects are located, or indeed
where the breach has taken place. When notifying the lead authority, the controller should indicate,
where appropriate, whether the breach involves establishments located in other Member States, and in
which Member States data subjects are likely to have been affected by the breach. If the controller has
any doubt as to the identity of the lead supervisory authority then it should, at a minimum, notify the
local supervisory authority where the breach has taken place.
2. Breaches at non-EU establishments
Article 3 concerns the territorial scope of the GDPR, including when it applies to the processing of
personal data by a controller or processor that is not established in the EU. In particular, Article 3(2)
states31:
27 See Article 4(23)
28 See also Recital 122.
29 See WP29 Guidelines for identifying a controller or processor’s lead supervisory authority, available at
http://ec.europa.eu/newsroom/document.cfm?doc_id=44102
30
A list of contact details for all European national data protection authorities can be found at:
http://ec.europa.eu/justice/data-protection/bodies/authorities/index_en.htm
31 See also Recitals 23 and 24
18
“This Regulation applies to the processing of personal data of data subjects who are in the Union by a
controller or processor not established in the Union, where the processing activities are related to:
(a) the offering of goods or services, irrespective of whether a payment of the data subject is required,
to such data subjects in the Union; or
(b) the monitoring of their behaviour as far as their behaviour takes place within the Union.”
Article 3(3) is also relevant and states 32:
“This Regulation applies to the processing of personal data by a controller not established in the
Union, but in a place where Member State law applies by virtue of public international law.”
Where a controller not established in the EU is subject to Article 3(2) or Article 3(3) and experiences
a breach, it is therefore still bound by the notification obligations under Articles 33 and 34. Article 27
requires a controller (and processor) to designate a representative in the EU where Article 3(2)
applies. In such cases, WP29 recommends that notification should be made to the supervisory
authority in the Member State where the controller’s representative in the EU is established33.
Similarly, where a processor is subject to Article 3(2), it will be bound by the obligations on
processors, of particular relevance here, the duty to notify a breach to the controller under Article
33(2).
D. Conditions where notification is not required
Article 33(1) makes it clear that breaches that are “unlikely to result in a risk to the rights and
freedoms of natural persons” do not require notification to the supervisory authority. An example
might be where personal data are already publically available and a disclosure of such data does not
constitute a likely risk to the individual. This is in contrast to existing breach notification requirements
for providers of publically available electronic communications services in Directive 2009/136/EC
that state all relevant breaches have to be notified to the competent authority.
In its Opinion 03/2014 on breach notification34, WP29 explained that a confidentiality breach of
personal data that were encrypted with a state of the art algorithm is still a personal data breach, and
has to be notified. However, if the confidentiality of the key is intact – i.e., the key was not
compromised in any security breach, and was generated so that it cannot be ascertained by available
technical means by any person who is not authorised to access it – then the data are in principle
unintelligible. Thus, the breach is unlikely to adversely affect individuals and therefore would not
require communication to those individuals35. However, even where data is encrypted, a loss or
alteration can have negative consequences for data subjects where the controller has no adequate
backups. In that instance communication to data subjects would be required, even if the data itself was
subject to adequate encryption measures.
32 See also Recital 25
33 See Recital 80 and Article 27
34 WP29, Opinion 03/2014 on breach notification, http://ec.europa.eu/justice/data-protection/article-
29/documentation/opinion-recommendation/files/2014/wp213_en.pdf
35 See also Article 4(1) and (2) of Regulation 611/2013.
19
WP29 also explained this would similarly be the case if personal data, such as passwords, were
securely hashed and salted, the hashed value was calculated with a state of the art cryptographic keyed
hash function, the key used to hash the data was not compromised in any breach, and the key used to
hash the data has been generated in a way that it cannot be ascertained by available technological
means by any person who is not authorised to access it.
Consequently, if personal data have been made essentially unintelligible to unauthorised parties and
where the data are a copy or a backup exists, a confidentiality breach involving properly encrypted
personal data may not need to be notified to the supervisory authority. This is because such a breach is
unlikely to pose a risk to individuals’ rights and freedoms. This of course means that the individual
would not need to be informed either as there is likely no high risk. However, it should be borne in
mind that while notification may initially not be required if there is no likely risk to the rights and
freedoms of individuals, this may change over time and the risk would have to be re-evaluated. For
example, if the key is subsequently found to be compromised, or a vulnerability in the encryption
software is exposed, then notification may still be required.
Furthermore, it should be noted that if there is a breach where there are no backups of the encrypted
personal data then there will have been an availability breach, which could pose risks to individuals
and therefore may require notification. Similarly, where a breach occurs involving the loss of
encrypted data, even if a backup of the personal data exists this may still be a reportable breach,
depending on the length of time taken to restore the data from that backup and the effect that lack of
availability has on individuals. As Article 32(1)(c) states, an important factor of security is the “the
ability to restore the availability and access to personal data in a timely manner in the event of a
physical or technical incident”.
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.
However, a failure to comply with Article 33 will exist where a controller does not notify the
supervisory authority in a situation where the data has not actually been securely encrypted.
Therefore, when selecting encryption software controllers should carefully weigh the quality and the
proper implementation of the encryption offered, understand what level of protection it actually
provides and whether this is appropriate to the risks presented. Controllers should also be familiar
with the specifics of how their encryption product functions. For instance, a device may be encrypted
once it is switched off, but not while it is in stand-by mode. Some products using encryption have
“default keys” that need to be changed by each customer to be effective. The encryption may also be
considered currently adequate by security experts, but may become outdated in a few years’ time,
meaning it is questionable whether the data would be sufficiently encrypted by that product and
provide an appropriate level of protection.
III. Article 34 – Communication to the data subject
A. Informing individuals
20
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:
“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.
Annex B of these Guidelines provides a non-exhaustive list of examples of when a breach may be
likely to result in high risk to individuals and consequently instances when a controller will have to
notify a breach to those affected.
B. 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.
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 their
access credentials have been compromised. Again, a controller can choose to provide information in
addition to what is required here.
36 See also Recital 86.
21
C. Contacting individuals
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).
Dedicated messages should be used when communicating a breach to data subjects and they should
not be sent with other information, such as regular updates, newsletters, or standard messages. This
helps to make the communication of the breach to be clear and transparent.
Examples of transparent communication methods include direct messaging (e.g. email, SMS, direct
message), prominent website banners or notification, postal communications and prominent
advertisements in print media. A notification solely confined within a press release or corporate blog
would not be an effective means of communicating a breach to an individual. WP29 recommends that
controllers should choose a means that maximizes the chance of properly communicating information
to all affected individuals. Depending on the circumstances, this may mean the controller employs
several methods of communication, as opposed to using a single contact channel.
Controllers may also need to ensure that the communication is accessible in appropriate alternative
formats and relevant languages to ensure individuals are able to understand the information being
provided to them. For example, when communicating a breach to an individual, the language used
during the previous normal course of business with the recipient will generally be appropriate.
However, if the breach affects data subjects who the controller has not previously interacted with, or
particularly those who reside in a different Member State or other non-EU country from where the
controller is established, communication in the local national language could be acceptable, taking
into account the resource required. The key is to help data subjects understand the nature of the breach
and steps they can take to protect themselves.
Controllers are best placed to determine the most appropriate contact channel to communicate a
breach to individuals, particularly if they interact with their customers on a frequent basis. However,
clearly a controller should be wary of using a contact channel compromised by the breach as this
channel could also be used by attackers impersonating the controller.
At the same time, Recital 86 explains that:
“Such communications to data subjects should be made as soon as reasonably feasible and in close
cooperation with the supervisory authority, respecting guidance provided by it or by other relevant
authorities such as law-enforcement authorities. For example, the need to mitigate an immediate risk
of damage would call for prompt communication with data subjects whereas the need to implement
appropriate measures against continuing or similar personal data breaches may justify more time for
communication.”
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.
22
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).
D. Conditions where communication is not required
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 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 effort37 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 38. 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.
IV. Assessing risk and high risk
A. Risk as a trigger for notification
37 See WP29 Guidelines on transparency, which will consider the issue of disproportionate effort, available at
http://ec.europa.eu/newsroom/just/document.cfm?doc_id=48850
38 See Article 5(2)
23
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 physical, material or non-material damage for the individuals
whose data have been breached. 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 occur39.
B. 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.
39 See Recital 75 and Recital 85.
40 See WP Guidelines on DPIAs here: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137
24
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 criteria41:
The type of breach
The type of breach that has occurred may affect the level of risk presented to individuals. For
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
41 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://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:173:0002:0008:en:P DF
25
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 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 (see section V, below).
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
26
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 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 plan42.
V. Accountability and record keeping
A. Documenting breaches
Regardless of whether or not a breach needs to be notified to the supervisory authority, the controller
must keep documentation of all breaches, as Article 33(5) explains:
“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.”
This is linked to the accountability principle of the GDPR, contained in Article 5(2). The purpose of
recording non-notifiable breaches, as well notifiable breaches, also relates to the controller’s
obligations under Article 24, and the supervisory authority can request to see these records.
Controllers are therefore encouraged to establish an internal register of breaches, regardless of
whether they are required to notify or not43.
Whilst it is up to the controller to determine what method and structure to use when documenting a
breach, in terms of recordable information there are key elements that should be included in all cases.
As is required by Article 33(5), the controller needs to record details concerning the breach, which
42
ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches ,
https://www.enisa.europa.eu/publications/dbn-severity
43 The controller may choose to document breaches as part of if its record of processing activities which is
maintained pursuant to article 30. A separate register is not required, provided the information relevant to the
breach is clearly identifiable as such and can be extracted upon request.
27
should include its causes, what took place and the personal data affected. It should also include the
effects and consequences of the breach, along with the remedial action taken by the controller.
The GDPR does not specify a retention period for such documentation. Where such records contain
personal data, it will be incumbent on the controller to determine the appropriate period of retention in
accordance with the principles in relation to the processing of personal data44 and to meet a lawful
basis for processing45. It will need to retain documentation in accordance with Article 33(5) insofar as
it may be called to provide evidence of compliance with that Article, or with the accountability
principle more generally, to the supervisory authority. Clearly, if the records themselves contain no
personal data then the storage limitation principle 46 of the GDPR does not apply.
In addition to these details, WP29 recommends that the controller also document its reasoning for the
decisions taken in response to a breach. In particular, if a breach is not notified, a justification for that
decision should be documented. This should include reasons why the controller considers the breach
is unlikely to result in a risk to the rights and freedoms of individuals 47. Alternatively, if the controller
considers that any of the conditions in Article 34(3) are met, then it should be able to provide
appropriate evidence that this is the case.
Where the controller does notify a breach to the supervisory authority, but the notification is delayed,
the controller must be able to provide reasons for that delay; documentation relating to this could help
to demonstrate that the delay in reporting is justified and not excessive.
Where the controller communicates a breach to the affected individuals, it should be transparent about
the breach and communicate in an effective and timely manner. Accordingly, it would help the
controller to demonstrate accountability and compliance by retaining evidence of such
communication.
To aid compliance with Articles 33 and 34, it would be advantageous to both controllers and
processors to have a documented notification procedure in place, setting out the process to follow
once a breach has been detected, including how to contain, manage and recover the incident, as well
as assessing risk, and notifying the breach. In this regard, to show compliance with GDPR it might
also be useful to demonstrate that employees have been informed about the existence of such
procedures and mechanisms and that they know how to react to breaches.
It should be noted that failure to properly document a breach can lead to the supervisory authority
exercising its powers under Article 58 and, or imposing an administrative fine in accordance with
Article 83.
B. Role of the Data Protection Officer
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.
44 See Article 5
45 See Article 6 and also Article 9.
46 See Article 5(1)(e).
47 See Recital 85
48 See WP Guidelines on DPOs here: http://ec.europa.eu/newsroom/jus t/item-detail.cfm?item_id=50083
28
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.
VI. Notification obligations under other legal instruments
In addition to, and separate from, the notification and communication of breaches under the GDPR,
controllers should also be aware of any requirement to notify security incidents under other associated
legislation that may apply to them and whether this may also require them to notify the supervisory
authority of a personal data breach at the same time. Such requirements can vary between Member
States, but examples of notification requirements in other legal instruments, and how these inter-relate
with the GDPR, include the following:
Regulation (EU) 910/2014 on electronic identification and trust services for electronic
transactions in the internal market (eIDAS Regulation)49.
Article 19(2) of the eIDAS Regulation requires trust service providers to notify their supervisory body
of a breach of security or loss of integrity that has a significant impact on the trust service provided or
on the personal data maintained therein. Where applicable—i.e., where such a breach or loss is also a
personal data breach under the GDPR—the trust service provider should also notify the supervisory
authority.
Directive (EU) 2016/1148 concerning measures for a high common level of security of
network and information systems across the Union (NIS Directive)50.
Articles 14 and 16 of the NIS Directive require operators of essential services and digital service
providers to notify security incidents to their competent authority. As recognised by Recital 63 of
NIS51, security incidents can often include a compromise of personal data. Whilst NIS requires
competent authorities and supervisory authorities to co-operate and exchange information that
context, it remains the case that where such incidents are, or become, personal data breaches under the
49 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG
50 See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG
51 Recital 63: “Personal data are in many cases compromised as a result of incidents. In this context,
competent authorities and data protection authorities should cooperate and exchange information on all
relevant matters to tackle any personal data breaches resulting from incidents.”
29
GDPR, those operators and/or providers would be required to notify the supervisory authority
separately from the incident notification requirements of NIS.
Example
A cloud service provider notifying a breach under the NIS Directive may also need to notify a
controller, if this includes a personal data breach. Similarly, a trust service provider notifying under
eIDAS may also be required to notify the relevant data protection authority in the event of a breach.
Directive 2009/136/EC (the Citizens’ Rights Directive) and Regulation 611/2013 (the Breach
Notification Regulation).
Providers of publicly available electronic communication services within the context of Directive
2002/58/EC52 must notify breaches to the competent national authorities.
Controllers should also be aware of any additional legal, medical, or professional notification duties
under other applicable regimes.
52 On 10 January 2017, the European Commission proposed a Regulation on Privacy and Electronic
Communications which will replace Directive 2009/136/EC and remove notification requirements. However,
until this proposal is approved by the European Parliament the existing notification requirement remains in
force, see https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-privacy-and-electroniccommunications
30
VII. Annex
A. Flowchart showing notification requirements
Is the breach likely to
result in a high risk to
individuals’ rights and
freedoms?
Controller detects/is made aware of a
security incident and establishes if
personal data beach has occurred.
Is the breach likely
to result in a risk to
individuals’ rights?
and freedoms?
Yes No
No requirement to notify supervisory authority
or individuals.
Notify competent supervisory authority.
If the breach affects individuals in more than
one Member State, notify the lead supervisory
authority.
Yes
No
No requirement to notify
individuals.
Notify affected individuals and, where required, provide
information on steps they can take to protect themselves from
consequences of the breach.
All breaches recordable under Article 33(5). Breach should be documented and
record maintained by the controller.
The controller becomes “aware” of a
personal data breach and assesses risk
to individuals.
31
B. Examples of personal data breaches and who to notify
The following non-exhaustive examples will assist controllers in determining whether they need to
notify in different personal data breach scenarios. These examples may also help to distinguish
between risk and high risk to the rights and freedoms of individuals.
Example
Notify the
supervisory
authority?
Notify the data
subject? Notes/recommendations
i. A controller stored a
backup of an archive
of personal data
encrypted on a USB
key. The key is stolen
during a break-in.
No. No. As long as the data are
encrypted with a state of
the art algorithm, backups
of the data exist the
unique key is not
compromised, and the
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
maintains an online
service. As a result of
a cyber attack on that
service, personal data
of individuals are
exfiltrated.
The controller has
customers in a single
Member State.
Yes, report to the
supervisory authority
if there are likely
consequences to
individuals.
Yes, report to
individuals depending
on the nature of the
personal data affected
and if the severity of
the likely
consequences to
individuals is high.
iii. A brief power
outage lasting several
minutes at a
controller’s call centre
meaning customers are
unable to call the
controller and access
their records.
No. No. This is not a notifiable
breach, but still a
recordable incident under
Article 33(5).
Appropriate records
should be maintained by
the controller.
iv. A controller suffers
a ransomware attack
which results in all
data being encrypted.
No back-ups are
available and the data
cannot be restored. On
investigation, it
becomes clear that the
ransomware’s only
Yes, report to the
supervisory authority,
if there are likely
consequences to
individuals as this is a
loss of availability.
Yes, report to
individuals,
depending on the
nature of the personal
data affected and the
possible effect of the
lack of availability of
the data, as well as
other likely
If there was a backup
available and data could
be restored in good time,
this would not need to be
reported to the
supervisory authority or
to individuals as there
would have been no
permanent loss of
availability or
32
functionality was to
encrypt the data, and
that there was no other
malware present in the
system.
consequences. confidentiality. However,
if the supervisory
authority became aware
of the incident by other
means, it may consider an
investigation to assess
compliance with the
broader security
requirements of Article
32.
v. An individual
phones a bank’s call
centre to report a data
breach. The individual
has received a monthly
statement for someone
else.
The controller
undertakes a short
investigation (i.e.
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.
Yes. Only the individuals
affected are notified if
there is high risk and
it is clear that others
were not affected.
If, after further
investigation, it is
identified that more
individuals are affected,
an update to the
supervisory authority
must be made and the
controller takes the
additional step of
notifying other
individuals if there is
high risk to them.
vi. A controller
operates an online
marketplace and has
customers in multiple
Member States. The
marketplace suffers a
cyber-attack and
usernames, passwords
and purchase history
are published online
by the attacker.
Yes, report to lead
supervisory authority
if involves crossborder processing.
Yes, as could lead to
high risk.
The controller should
take action, e.g. by
forcing password resets
of the affected accounts,
as well as other steps to
mitigate the risk.
The controller should
also consider any other
notification obligations,
e.g. under the NIS
Directive as a digital
service provider.
vii. A website hosting
company acting as a
data processor
identifies an error in
the code which
As the processor, the
website hosting
company must notify
its affected clients (the
controllers) without
If there is likely no
high risk to the
individuals they do
not need to be
The website hosting
company (processor)
must consider any other
notification obligations
(e.g. under the NIS
33
controls user
authorisation. The
effect of the flaw
means that any user
can access the account
details of any other
user.
undue delay.
Assuming that the
website hosting
company has
conducted its own
investigation the
affected controllers
should be reasonably
confident as to
whether each has
suffered a breach and
therefore is likely to 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.
notified. Directive as a digital
service provider).
If there is no evidence of
this vulnerability being
exploited with any of its
controllers a notifiable
breach may not have
occurred but it is likely to
be recordable or be a
matter of non-compliance
under Article 32.
viii. Medical records
in a hospital are
unavailable for the
period of 30 hours due
to a cyber-attack.
Yes, the hospital is
obliged to notify as
high-risk to patient’s
well-being and privacy
may occur.
Yes, report to the
affected individuals.
ix. Personal data of a
large number of
students are
mistakenly sent to the
wrong mailing list
with 1000+ recipients.
Yes, report to
supervisory authority.
Yes, report to
individuals depending
on the scope and type
of personal data
involved and the
severity of possible
consequences.
x. A direct marketing
e-mail is sent to
recipients in the “to:”
or “cc:” fields, thereby
enabling each recipient
to see the email
address of other
recipients.
Yes, notifying the
supervisory authority
may be obligatory if a
large number of
individuals are
affected, if sensitive
data are revealed (e.g.
a mailing list of a
psychotherapist) or if
other factors present
high risks (e.g. the
mail contains the
initial passwords).
Yes, report to
individuals depending
on the scope and type
of personal data
involved and the
severity of possible
consequences.
Notification may not be
necessary if no sensitive
data is revealed and if
only a minor number of
email addresses are
revealed.