Reporting data breaches under GDPR

Here is a summary, for accountancy practices, of the latest guidelines on GDPR data breaches – what to report, when to report it and who to report it to.

GDPR imposes a new obligation on data controllers to report data breaches. In this article we summarise guidelines recently published by the GDPR Article 29 Working Party. By clarifying key concepts and describing how data controllers should act in a number of example scenarios, it will help accountancy practices comply with the new data protection regulations.

On 3 October 2017 the Working Party published guidelines on data breaches under GDPR, including the new obligation to report such data breaches within 72 hours. This is a summary of the main points in that publication, including key concepts.

What is a data breach?

A personal data breach is a breach of security leading to the destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

When does it have to be reported?

A data controller must report a breach unless the breach is unlikely to result in a risk to individuals.

Who does it have to be reported to?

The GDPR introduces a duty to report data breaches to the relevant supervisory authority within 72 hours of the organisation becoming aware of it. There is also a requirement to report the breach to any affected individuals where there is a high risk that they will suffer adverse effects.

Who is the relevant supervisory authority?

In the vast majority of cases, data breaches in the UK would be reported to the Information Commissioner’s Office (ICO). However, there may be circumstances in which other jurisdictions would be involved.

What obligation do data processors have?

Where a data processor suffers a breach, their obligation is to report it to the data controller, not the supervisory authority or to individuals.

What constitutes a data breach?

What constitutes a reportable data breach is widely defined in the GDPR: ‘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…’.

The guidelines set out some examples of different kinds of breaches:

  • Loss or destruction breach – an example of this kind of breach would be where a device containing a copy of a controller’s customer database has been lost or stolen. Another example would be where the only copy of a 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.
  • Confidentiality breach – this describes a situation in which there is an unauthorised or accidental disclosure of, or access to, personal data.
  • Availability breach – this happens where there is an accidental or unauthorised loss of access to, or destruction of, personal data. For example, experiencing a power failure or denial of service attack which renders personal data unavailable, either permanently or temporarily.
  • Integrity breach – this would involve an unauthorised or accidental alteration of personal data.

When is the controller deemed to have become aware of a breach?

The guidelines give some examples to help understand when the clock starts running on the 72 hour countdown:

  • Loss of a CD/hard drive with unencrypted data – it’s often not possible to know whether unauthorised people have gained access. Nevertheless, this kind of case would have to be notified since there’s a reasonable degree of certainty that a breach has occurred; the controller would become ‘aware’ when it realised the CD/hard drive had been lost.
  • 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 breach then there can be no doubt that it has become aware.
  • 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.
  • A cybercriminal contacts the controller after having hacked its system in order to ask for a ransom – in that case, the controller has clear evidence that a breach has occurred and there is no doubt that it has become aware.

When does a breach NOT need to be reported?

There is no need to report a breach if it’s ‘unlikely to result in a risk to the rights and freedoms of natural persons’. Controllers only need to report directly to the individuals whose data has been breached when the breach poses a ‘high risk’.

There are examples throughout the guidelines and an appendix of examples of what may, or may not, need to be reported. For example the following would not be notifiable events:

  • A breach involving data which is already in the public domain, where there is no likely risk to individuals.
  • A loss of encrypted data, provided that the key is not compromised.
  • Loss of access to personal data as a result of a brief power outage lasting a few minutes. Although not reportable, this is still a recordable incident under Article 33(5).

This article covers only a summary of some of the main concepts covered in the guidelines; you can download a copy of the full guidelines from the European Commission website.

Software to help accountancy practices and their clients with GDPR compliance

We’ve partnered with a leading online solutions provider to support accountancy practices and their clients in their journey to initial compliance and ongoing governance.

CCH GDPR Compliance is a cloud-based system that brings together everything you need for GDPR in one place. Simple checklists and workflows generated by the software steer you through each aspect of compliance. The system helps you log, report and manage data breaches and it allows you to update all your privacy notices from a single location.

In future articles we’ll be looking at other aspects of GDPR and providing useful guides and checklists.

Click here for all things GDPR

Recent articles

View by topic