GDPR - GPC - Blog 14

14 Blog Fourteen, Data Breaches

Article 33(1) is where all this happens.

“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.”

So dissecting this the conditionality’s are;

1) In the case of a personal data breach

Personal data (remind me what is Personal data?)

Breaches can only apply to personal data. If its not personal data, its not a breach.


So what is a “breach”?


Article 4(2) defines it 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.”


Surely this is obvious.



Should also be relatively clear but includes concepts such as reduced completeness, i.e. if part of a data set is lost.


If personal data has been altered or corrupted, fair enough.


Loss of personal data should be interpreted to include the DC losing control over it as well as loss of actual possession, so loosing an access password to a laptop you still possess is the same as physically loosing it.

Unauthorised or unlawful

Includes disclosure of personal data to recipients who are not authorised to receive it or any other form of processing which violates the GDPR.


Temporal aspects, computer says wait.

An incident resulting in personal data being temporarily unavailable is also a type of breach, the lack of access to the data can cause problems, GDPR Guidance gives us a pertinent example; “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”.

2) without delay and where feasible within 72 hrs

So that means as soon as reasonably possible, but it may not always be so, because investigations cannot always be immediately exhaustively scoped, one thing leads to another, and unlikely to be fully concluded.

Common misconception, within 72 hrs - No

As written GDPR does not require every report to be within 72 hrs. It is very clear that the 72 deadline is when “feasible” and the same clause in the Article then says in its next sentence; “Where the notification to the supervisory authority is not made within 72 hours, it shall be  accompanied by reasons for the delay”. So, it can be later than 72 hrs but you must explain why.

Also, Article 33(4) allows for “Phased” reporting. So, its clear that a sensible approach would be to report what you can, at least start the process within 72 hrs.

In data breach reporting to the ICO, its better to report what you can as soon as possible, i.e. phased reporting rather than send in an incomplete and nonsense report to simply beat the deadline.

Earlier reporting gives the ICO the earliest opportunity to intervene, which she may do if sufficiently troubled. If she perceives a potentially serious breach she will turn from passive recipient to active participant in the investigation.

If you are making an initial report, part of phased reporting, make that clear to the ICO. Otherwise they’ll criticise you for filing an incomplete report.

3) “…….unless the personal data breach is unlikely to result in a risk….”

…risk to rights and freedoms of natural persons.


And that’s a phrase we’ve seen before; risk to rights and freedoms, see Blog 13. The rights and freedoms are; “to data protection and privacy but also can include other fundamental rights such as freedom of speech, thought, movement, protection from discrimination, right to liberty, conscience and religion.”

And any one single one will do


Please note unlike before there is no large-scale criterion, a data breach can occur to one data subject. If its their identified naked image replacing your practices web site home page that’s not only a breach, it’s a notifiable one. 


The threshold for data breach reporting lies at the level of the individual whereas the threshold for a DPIA is at large scale, because the former has happened but the latter is proposed. Seems logical.

So, if its unlikely to have threatened our patients or staff’s (yes GDPR is about staff as well) rights and freedoms a data breach does not have to be reported.

So there can be breaches and reportable breaches?


So what happens with non reportable breaches?

Skip ahead, you’ll see why in a minute.

13, So what do we have to report?


Article 33(3) sets out the minimum information to be reported:

(a) 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) the name and contact details of the data protection officer or other contact point where more information can be obtained;

(c) the likely consequences of the personal data breach;

(d) 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


And for non reportable breaches?

For all, yes all, breaches you have to keep documentary records comprising; the facts relating to the personal data breach, its effects and the remedial action taken. This applies to reportable as well as non–reportable. So, you’ll perceive that you still must investigate non-reportable breaches, its that “think DPIA” again. The information you must document for a non-reportable as compared to a reportable is so similar you might as well record everything for everything. Your records of breaches will form part evidence of your complying with GDPR.

Issue of when “became aware”.


There may arise the issue of when you became aware. It may not immediately be apparent that a breach has occurred, a door to a room is found unlocked, it takes 3 hrs to look through the CCTV to see if anyone entered the room, or a PC is found unattended with a smart card still active, it may take a while to check to see which records have recently been accessed. On the other hand, you see a chap in a hoody driving off in a dirty N plate Astra van with your main server in the boot, you know immediately somethings gone awry.

Time to enquire


So, you are allowed 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”.

Accordingly, it should be clear that there is an obligation on the controller to act immediately on any initial alert and establish whether or not a breach has, in fact, occurred.

Once you’ve confirmed


Once you’ve established that a breach has occurred and the conditions in Article 33(1) have been met, you must then notify the ICO.

Once reported, keep reporting


If you have sent in a report then keep sending in updates until the matter has been fully investigated and all necessary actiosn taken. It may be that as part of phased reporting you mau downgrade the risk to a non-reportable risk and thus conclude the event. There is no penalty for reporting an incident that ultimately transpires not to be a breach

Have you got any examples?

Yes but best take the ones prepared beforehand by the EU GDPR team, for example a non-reportable breach; 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. So a loss (the breach) has occurred but the risk is mitigated, ergo no report. Document it yes, learn from it but no need to bother the ICO.

For a reportable breach, see the naked image on your practice web site.

What about our processors, the people who run our systems, GPSoC suppliers etc?

As processors they must notify you of any breach they become aware of and must comply with any investigation, reporting and remedial actions.

Informing the subject(s)

If the breach is “likely” to risk stuff then the DS(s) must also be informed.

Hold up


What a volte face? For reporting to the ICO the condition is unless its “unlikely to risk”. For DSs its if its “likely to risk”. Now to my mind those two are the same, “unless unlikely” = “likely”, the one being the double negative of the other but GDPR guidance suggests otherwise. They write that unless unlikely has a lower threshold than likely and that they therefore expect more breaches to be reported to the ICO than are reported to the DS(s) themselves.

Hmm, no comment, but as a GP I’d suspect anything that I’m going to report to the ICO I would want to also be reporting to the DS(s).

So, when, what and how much?

Well if you decide you need to report to the DS(s) themselves you must do it “without undue delay” (no 72 hrs mentioned here, just get on with it) and the minimum you must report is (b), (c) and (d) of para 13 above. It has to be in clear plain language.

Except in three particular circumstances;


  1. Where the data breach was a loss of encrypted data, such as on a fob, but where the encryption key remains secure, Article 34(3)(a).
  2. Subsequent to the breach the DC implements changes that mitigate the risk, i.e. upgrade your doorlocks, Article 34(3)(b).
  3. Disproportionate effort, i.e too many DSs or too diverse to contact, in this case, which frankly is unlikely to be available to a GP, the informing of individuals can be replaced by a leaflt drop or similar “public communication” Article 34(3)(c).

So we don’t have to inform DS(s) individually in those 3 circumstances?



Unless the ICO, having been alerted by your Article 33(1) notification, and reviewing your report, decides that actually the DS(s) ought to be informed. Then she can require you to communicate with the DS(s).


Any communicating with DS(s) about breaches either individually or en masse must be in plain simple language, accessible and alone. They must not be hidden buried alongside a pizza delivery flyer, they must be up front single purpose mea culpa. Communicating en-masse could include

direct messaging (e.g. email, SMS, direct message), prominent website banners or notification, postal communications and prominent advertisements in print media. However, GDPR recognises that DCs “are best placed to determine the most appropriate contact channel to communicate”. You know your patients best, you will know how to communicate with who (or their relatives etc).

and that is the end of this communication.

Dr Paul Cundy

GPC IT Policy Lead

15th April 2018

1, Article 4(1) personal data means any information relating to an identified or identifiable natural person (aka the data subject, DS)

an identifiable natural person is; one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;












All Content and Images are  the Copyright property of
The Mid Mersey Local Medical Committee. 
© 2014 - 2022. All Rights Reserved.