#4 – Data breaches

It seems like data breaches are on everyone’s minds these days. This is not surprising since there was an all-time high of data breach notifications to France’s supervisory authority CNIL in 2021, and cyberattacks increased in the EU during both 2020 and 2021.

Depending on the business sector, and a lot of other factors, it is both common with breaches due to internal and external reasons. Most internal data breaches are caused by mistake, while external breaches by malicious intent.

Then you might ask yourself: What is a breach? With personal data breach, the GDPR means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data being transmitted, stored, or otherwise processed.

As you can see, a breach is much more than just “losing” personal data. There are three common names for these breaches that the EDPB uses. It should be noted that a combination of these three could happen together, and that not every security incident results in a personal data breach. The names of these data breaches are:

• Confidentiality; an unauthorised or accidental disclosure of, or access to, personal data
• Integrity; an unauthorised or accidental alteration of personal data
• Availability; an accidental or unauthorised loss of access to, or destruction of, personal data

When there are any kinds of alerts regarding security, you are supposed to act. It’s imperative to establish if a security breach also resulted in a personal data breach. As a matter of best practice, you should have internal processes and an incident response program (IRP) in place to deal with these matters. It is to demonstrate a sufficient degree of preparedness to detect and address a breach. Then, in the case of any alert, the organisation can follow the pre-formulated plan if there has been a personal data breach. As a part of the plan, you should collect key information related to a data breach in a structured and efficient way. The ideal is that the organisation can handle an incident fast and error-free, reducing the risks and impact on the data subjects and the financial or reputation loss for the organisation.

There is no strict legal rule of what should be included in an IRP. However, as a matter of industry-relevant best practices, it is highly recommended for the IRP to cover the following:

• Contact information about the responsible person or the incident response team (IRT) tasked with addressing and establishing the existence of a breach and assessing risks
• The roles and responsibilities of the IRT
• Investigation strategies
• How a breach should be escalated in the organisation
• Information on how the risks to individuals as a result of a breach should then be assessed (likelihood of no risk, risk, or high risk)
• How the organisation should act to contain and recover a breach
• How a breach is documented

So far, this post has not really touched on the core legal requirements concerning data breaches. The core requirement from the regulations is that you, as a controller, should notify your supervisory authority (the commissioner for the UK people) and the data subjects; and as a processor, to notify your controller.

Firstly, the supervisory authority. They have to be notified within 72 hours after having become aware of a breach, or otherwise you should explain the delay. However, you aren’t required to notify if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If you are the processor, you should notify the controller without undue delay, or even sooner if the data processing agreement (DPA) stipulates a time frame.

Now, on to the data subjects. The threshold to notify the data subjects is higher than that of the supervisory authority. You must only communicate the breach without undue delay if it is likely to result in a high risk to the rights and freedoms of natural persons.

It does seem like, just like last week, we have to circle back to the assessments of risks again… As usual with the GDPR, you should consider the nature, scope, context, and purposes of processing when assessing risks. The notion of high risk, which is the condition needed for notifying the data subject, can be determined in two different contexts. Either by the impact on a large number of data subjects or by a large amount of damage caused to certain individuals. High risks exist when the breach may lead to physical, material or non-material damage to the individuals whose data have been breached. For example, discrimination, identity theft or fraud, financial loss and damage to reputation. These risks are also likely to exist if a breach involves special category data or data relating to criminal convictions or offences.

What kind of information should you give in a notification? When you notify either the supervisory authority or the data subjects, the content of the notification should at least describe:

1. The nature of the personal data breach; including data subject categories, personal data types, and an approximation of the number of affected individuals and personal data.
2. The likely consequences of the personal data breach.
3. 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.
4. The name and contact details of the data protection officer or other contact points where more information can be obtained.

The data subjects should be informed about all of the above in clear and plain language. In addition to that, they could also be informed about any recommendations about how to mitigate any potential adverse effects, for example, changing passwords.

Here are six examples of common data breaches from the EDPB Guidelines 01/2021 (the examples can of course overlap in parts). Firstly, in a ransomware attack where a malicious code access and encrypts the data for you to pay ransom. Secondly, by a data exfiltration attack where the bad actor exploits vulnerabilities in services over the internet by exfiltrating, copying or abusing the personal data that you hold. Third, by human errors internally in your organisation, either by e.g. intent or accidents. Fourth, by lost or stolen devices or documents. Fifth, mispostal of packages or mail. Finally, social engineering. The guidelines also gives some advice on prior measures and mitigation strategies, so if you are interested in deep-diving into these breach examples, then please follow the link!

I think it’s time for me to talk about some other requirements next time. So the next post will be diving into another principle, namely that of purpose limitation, a cornerstone of the European data protection.