New guidance on reporting data security breaches

Insight

04.02.2021

In this article we examine the Guidelines issued by the European Data Protection Board (EDPB) on 14 January 2021 on when to report data security breaches to regulators and affected individuals. When you have suffered a data security breach you immediately come under pressure to consider these questions. Choosing the wrong path can often have serious consequences. The Guidelines are helpful in establishing what the collective group of EU data protection regulators think are the key considerations.

The issue

You have experienced a data security breach, but should you report it to a regulator and to affected individuals? The tests to determine whether you should are set out in Articles 33 and 34 of the EU General Data Protection Regulation (GDPR) and, now post-Brexit, its UK equivalent (UK GDPR). Article 33 requires you to report to a regulator “unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” And you don’t have long to think about it – a maximum of 72 hours from discovery of the breach, unless you have a very good reason to delay reporting. For notification to affected individuals, Article 34 sets a higher bar for determining whether to report the breach to them – is the personal data breach “likely to result in a high risk to the rights and freedoms of natural persons”? Again, you don’t have long, but Article 34 is more vague on a timeframe by specifying that the notification must be made to individuals “without undue delay”.

Go / no go

This all looks fairly simple and straightforward in assessing the level of risk. However, since GDPR first took effect nearly three years ago, in practice the decisions on a “go/no go” on reporting to regulators and affected individuals has often proved very difficult. Failing to report when you should is a breach of GDPR in itself. However, reporting to a regulator where you do not need to can lead to probing questions from the regulator which reveal other areas of non-compliance. In addition, over-reporting to affected individuals can encourage them to make claims for compensation, with the distress caused by receiving the notification itself sometimes being the basis for such a claim.

So, how do you make this decision? Documenting how you did so is important so that you can refer back to it if the decision is later questioned by regulators or others (remembering that you have to record data security breaches anyway, and the steps taken to address them, even if they do not reach the thresholds for reporting). Keeping a decision not to report under review is also important as more facts emerge – this is often not a one-time review, particularly where you are relying on others to keep you informed, for example, when another controller or your processor has suffered a breach which has compromised data you have entrusted to them. The EDPB Guidelines also recognise that reports can be made in stages as facts emerge – the threshold for reporting is clearly reached early on, but not all background facts are known, so there is a continuing engagement with the regulator as material developments occur.

EDPB Guidelines

More help with this decision-making process has been provided by the EDPB in its new Guidelines, which you will find here.

The Guidelines contain a helpful reminder of the regulators’ views that a personal data security breach is not just about the unauthorised accessing or taking of data, but also when data is made inaccessible (eg in a ransomware attack) or is altered in an unauthorised way.

The Guidelines set a series of fictitious data security breaches which are based on common examples which the EDPB members have seen. It is very granular, but helpful in that respect and worth a thorough review if you are responsible for handling these issues in your organisation. One approach you could take is to ask yourself whether any of the examples provided could occur in your organisation and what you would do in terms of reporting if they did. This sort of scenario testing can be very helpful in determining how you would respond to a data security breach and is likely to earn you credit with regulators. It should also help you to spot and close existing vulnerabilities. Each example in the Guidelines is accompanied by the steps that the EDPB recommends should have been taken to prevent the breach or better deal with it once it has occurred.

Reference to some of the fictitious data security breaches will help to illustrate the EDPB’s views on reporting requirements:

A ransomware attack where the data concerned was encrypted by the organisation (and hence not readable by the hackers), was not taken by the hackers and was stored in backup so that it was not inaccessible to the organisation in any event except for a few hours whilst systems were restored – there is no need to report to regulators or affected individuals. At the other end of the scale where ransomware attacks involve hackers reviewing and taking unencrypted data, some of it special category data, and systems are disabled for some time then that would need to be reported to regulators and affected individuals.
A very common example of an employee accessing customer data they needed to do their job, but then taking that data with them once they had left employment and using it in their new job to make contact with customers – this should be reported to a regulator according to the EDPB, but not to the affected customers. However, a notification may need to be made to the affected customers if the data is particularly sensitive (more than just contact data) or there is evidence that the data might be used for some other purpose or if this is unclear because no steps have been taken by the former employer to prevent the further use of the data.
Another common example of personal data being sent to a recipient by mistake. In the example provided, the error was spotted very quickly and the data was not used by the recipient, nor was it particularly sensitive or involve a large amount of data – there is no need to report to the regulator or the affected individuals. Presumably the position might be different if the other factors come into play.
The theft of encrypted laptops which contain a password protected app storing sensitive data about children which was separately held in back-up – there is no need to report to the regulator or affected individuals given the extent to which the data was protected and otherwise available to the controller from backup. At the other end of the scale is an example of the theft of an unencrypted electronic notebook which stored data without password protection – there is an need to report this to the regulator and the affected individuals.
Reminding us that this is not just about electronic records, there is a further example of the theft of paper records concerning sensitive medical data which was not stored in a locked draw or room or subject to any prior safeguarding assessment – there is a need to report to the regulator and to the affected individuals.
A person contacting a service provider impersonating an account holder and securing re-direction of billing information to them, with the service provider only becoming aware of this when contacted by the account holder, where in the meantime the person acquiring the information could have used it in ways adverse to the account holder (eg to learn something about them or set up other accounts in their name) – there is a need to report this to a regulator and to the affected individual.

These are just a few of the eighteen examples used by the Guidelines to explain the principles which the EDPB is applying. Some are more obvious than others.

Brexit

Of course, it is right to point out that after Brexit the ICO is no longer part of the EDPB and the Guidelines are therefore potentially less persuasive for UK based organisations. However, the ICO is likely to continue to have regard to the views of the EDPB, and the Guidelines are in any event not out of line with our experience with the ICO. Do not forget as well (see our further point below) that organisations based outside the EU might still be directly regulated by GDPR and be caught by the Guidelines in that respect. In other words, it would be foolhardy to ignore them.

The ICO’s separate, and briefer, guidance is here.

Reporting to multiple regulators

Finally, do not forget that reporting to regulators is not always a question of reporting to only one national regulator (the ICO in the UK for data purposes). You might need to consider reporting to another national regulator as well (eg if you are subject to financial regulation in the UK then you should consider the reporting requirements to the Financial Conduct Authority). Additionally, you may need to report to multiple regulators or authorities depending on factors such as where affected customers are based. For example, an organisation based outside the EU, but directly regulated by GDPR, may need to report to the full range of EU regulators where affected individuals are located. In that respect, they will not be able to take advantage of the “one-stop shop” mechanism of reporting only to a data protection regulator in the EU who is the lead supervisory authority. Also, think more widely about data breach reporting requirements in other countries which might be impacted, for example, those that apply on a State by State basis in the USA.

If you require further information about anything covered in this briefing, please contact Ian De Freitas, or your usual contact at the firm on +44 (0)20 3375 7000.

This publication is a general summary of the law. It should not replace legal advice tailored to your specific circumstances.