The ICO have been discussing data breach reporting under GDPR in a new webinar.

Here are the key points:

• GDPR introduces mandatory breach reporting.  This applies to accidental breaches and internal breaches – not just those that are deliberate or are about losing personal data externally.  Don’t forget about integrity and availability breaches (e.g. damage to records due to fire or flood as well as ransomware).  Temporary loss of data, according to EDPB Guidance can be a personal data breach.
• This does not mean that you have to report all general breaches of GDPR (eg. failure to present a suitable privacy notice).  Breach reporting only applies to breach of confidentiality, integrity or availability of data: the so-called the “CIA Triad”.  Similarly, breach notifications do not apply in relation to records relating to deceased persons (not covered by GDPR).
• The 72 hour timeline kicks in from “awareness” of the breach.  This equates to having a “reasonable degree of certainty” that the breach has occurred.  The ICO gave an example of a customer who complains that he/she has received someone else’s information.  This would constitute “awareness”.  It may be less clear, at the initial stage, whether an IT issue has resulted in a personal data breach as that may require more forensic/detailed investigation.
• In addition to deciding whether or not to notify a breach, you should always undertake a risk assessment to identify the scope and extent of the breach, contain it and stop it repeating or harming individuals.  This risk assessment will also impact the shape of the overall response.
• If a personal data breach has occurred and you are aware of it, it is then necessary to decide the level of risk associated with it to determine whether or not to notify the ICO.  In order to require notification, there should be more than a remote chance of harm.  If there is more than a remote chance of harm, then this would make the risk to rights and freedoms of individuals likely, triggering Article 33.  Equally, mere inconvenience is not enough.
• Article 33 sets out a number of pieces of information that should be provided with a notification.  It’s no excuse not to be able to provide this, even within 72 hour timeline.  So basic information will be required even if further information will be provided later as permitted by GDPR.
• The 72 hour deadline is “72 real hours” – so this includes evenings and weekends.  If a breach comes to your attention on Friday morning, it will need to be reported by Monday afternoon.  Extra resources are likely to be required to respond promptly.
• The ICO response will be quick (same day/next day) for serious breaches.  Less serious breaches may mean the ICO gets back to you in a couple weeks.
• You can report a breach by phone (available during working hours), or web form (available 24/7).  You don’t have to use the official ICO web form, but the ICO prefers it if you do as it contains all the relevant information.
• You always have to record breaches in your data breach log – the ICO can come and inspect this later if they wish.
• The ICO acknowledge the risk of “notification fatigue” and say that that’s the reason why notification to data subjects under Article 34 is only required where there is a likely high risk to rights and freedoms of relevant individuals.
• The sectors that have typically notified data breaches since 25 May are health, education, general business, local government and some law firms.
• The ICO repeat their general advice that “not every breach needs to be reported”.  It’s also the controller’s decision as to whether or not to report.  They also mention practical points such as an example where someone reported a loss of payslips and rang back a couple of hours later to say they had found them!  Better not to do this.
• The webinar also covered a number of live questions: One question was whether to report the situation where access rights to particular data have been inappropriately broad, but there is no evidence of actual unauthorised access.  The ICO think that this could be reportable if the situation had been allowed to last for a long time so there is, therefore, a significant risk of unauthorised access.  Presumably, if this happened for a short time, you could argue that the likelihood of unauthorised access was very limited.
• Someone else asked about data sent to an old address and then finding that the data subject had moved addresses without telling the controller.  This is not a breach of security, although you could separately ask yourself whether sending sensitive information by post is an appropriate security risk in the first place.