Cybersecurity Insights for Company Lawyers: Should You Tell Anyone That You Have Been Hacked?

Introduction

In our previous blog, we reminded company lawyers that controllers should notify the competent data protection authority (DPA) without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of the affected individuals (the “data subjects”).

Furthermore, if the personal data breach is likely to result in a high risk to the data subjects’ rights and freedoms, a communication should also be sent to them without undue delay.

So, the answer to the question whether you should tell anyone that you have been hacked will depend on your own assessment of the corresponding risk. In this blog we discuss recent guidance from European DPAs that will help you to assess that risk. 

Personal Data Breach

While it is hacking attacks that most often capture the attention of the media and the boardroom, they are not the only incidents that need to be disclosed. The General Data Protection Regulation (GDPR) talks about “personal data breaches” and defines them as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.”

This means that while not every security incident is a personal data breach (e.g., if only corporate financial information is compromised it would not be a personal data breach), every personal data breach is a security incident. And this means that every personal data breach can be categorized by means of the well-known and widely used “CIA” information security principles, depending on whether the incident affects the data’s Confidentiality, Integrity and/or Availability.

By way of example, the possible effects of a personal data breach can be categorized, according to the GDPR definition mentioned above, as Confidentiality (unauthorized disclosure or access), Integrity (alteration) or Availability (destruction or loss).

Categorizing the incident correctly is important, because it allows you to communicate in a clear and straightforward manner with the DPAs, your internal security team, external forensic experts and other relevant stakeholders about the main characteristics and possible consequences of the breach.

Guidance from European Data Protection Authorities

While there were, prior to the adoption of the GDPR, certain contractual and sector-specific obligations (e.g., for telecommunication providers, “essential” service providers, etc.), the obligation to notify personal data breaches to the Belgian DPA did not exist before it was introduced by the GDPR in May 2018. Therefore, it is not surprising that organizations still have a lot of questions about the notification and communication of such incidents. Fortunately, this is mainly the result of a lack of first-hand experience in handling personal data breaches. However, guidance on this is clearly important.

Acknowledging the need for practice-oriented, case-based guidance on how to handle personal data breaches, and on the factors to consider when assessing the corresponding risks, the European Data Protection Board (EDPB) (the body composed of representatives of all the European DPAs), recently issued draft guidance to complement the guidelines on personal data breaches that were issued in 2017 by its predecessor, the Article 29 Working Party (WP29).

In the document, which was open for feedback until March 2, 2021 and of which a final version will be issued soon, different personal data breach scenarios are described and discussed. For each scenario, the EDPB indicates whether the personal data breach should (i) be documented, (ii) be notified to the competent DPA and/or (iii) be communicated to the affected individuals.

Personal Data Breach Register

Spoiler-alert: the answer to the first question, i.e., “whether a personal data breach should (i) be  documented”, is “yes” for all scenarios. This should not come as a surprise, when you consider the wording of the GDPR: “the controller shall document any personal data breaches.” But it is clear that the EDPB wanted to remind organizations of this obligation by adding a specific “internal register” column and ticking the box for every single scenario.

The register is part of the documentation that a controller should be able to produce when a DPA requests it. Some privacy professionals may claim that having an empty personal data breach register is good news as, in their view, this means that the controller has its information security environment entirely under control.

However, an empty personal data breach register could also be seen as a sign that the birdcage containing the proverbial coalminer’s canary has been left open or, if the canary has not in fact escaped, that it has already crossed paths with a taxidermist.  

Notification Within 72 Hours

If a personal data breach occurs that meets the threshold for notification to the DPA, one of the main jobs of a company lawyer is to decide when the clock for the 72-hour notification window starts ticking.

The WP29 guidelines already clarified that a controller becomes “aware,” and that, therefore, the aforementioned clock starts ticking, when the controller “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.”

The EDPB highlights that when the controller is not able to immediately identify that the incident is likely to result in a risk and must therefore be notified, the notification should not be postponed until the risk and impact surrounding the breach has been fully assessed, “since the full risk assessment can happen in parallel to notification.”

The personal data breach form of the Belgian DPA also incentivizes controllers to notify personal data breaches earlier rather than later, as it starts by providing a choice of 3 options: (a) a new notification, (b) a request to annul a previous notification and (c) the chance to provide additional information related to an earlier notification.

In the case of both (b) and (c), the controller must necessarily have been notified of the incident before all the details were known, and this aligns with the EDPB’s guidance that the controller “should not wait for a detailed forensic examination and (early) mitigation steps before assessing whether or not the data breach is likely to result in a risk and thus should be notified.”

Fire Drills

While it is common good practice to do a personal data breach fire drill once or twice a year, many Belgian organizations still fail to prepare sufficiently for personal data breach situations. A comparison with practices in other countries suggests that personal data breach fire drills will become common practice in Belgium soon.

The EDPB underscores the importance of having plans and procedures in place to handle personal data breach situations, and it even refers to a “Handbook on Handling Personal Data Breach.” It is clear that you should have a playbook with stress-tested procedures, so that you know what to do and whom to call, etc. As mentioned in our previous blog post: the battlefield is not the place to start exchanging business cards…

Personal Data Breach Scenarios

In its draft guidelines, the EDPB provides a number of case studies which are “fictitious” but “based on typical cases from the [DPA’s] collective experience with data breach notifications.” The EDPB provides a clear caveat by stating that “any modification in the circumstances” of the case “may result in different or more significant levels of risk, thus requiring different or additional measures,” but the scenarios and the guidance is sufficiently clear and, thus, helpful for company lawyers.

The case studies are categorized per type of personal data breach:

• Ransomware
• Data exfiltration attacks
• Internal human risk source
• Lost or stolen devices and paper documents
• Mispostal
• Other cases – social engineering

Within each category, different scenarios are used to show the difference in risk and the key points for consideration when the situation, and corresponding risk, changes.

For example, the ransomware category starts with an example of a ransomware attack where there is proper backup and no data exfiltration, but also covers a situation where there is no proper backup but still no data exfiltration, and a situation where there is no proper backup and there is data exfiltration.

The key points to consider for these three scenarios are, i.a., whether or not there was state-of-the-art encryption (implemented by the controller, i.e., it does not refer to the encryption algorithm that the hacker has used), whether there was a proper backup regime that allowed for timely restoration, the type and amount of data that was affected, the number of individuals that was affected, etc.

Clear Guidance

Going through these scenarios is interesting for company lawyers, in particular because the cases are explained in plain language but also refer to technical aspects that would make it easy to start a conversation with the technical teams within your organization.

The EDPB warns, for example, that while the analysis of logs is important in order to assess whether data has been exfiltrated (which would increase the risks of the incident), in case of sophisticated attacks it is not unlikely that the log files will have been edited to remove the trace. Therefore, an absence of logs indicating that there was an exfiltration of data does not necessarily mean that there was no exfiltration of data. And if you cannot be certain, you should act according to the worst-case scenario. So, you might want to ask your Information Security team whether logs are forwarded or replicated to a central log server.

One of the scenarios describes a situation where the backup was also encrypted, and the EDPB considers this to be an issue relating to the design of the backup regime. You should ask yourself whether you know which backup regime your organization uses.

Not being able to quickly restore your systems by means of a backup is not only an operational issue, but can have significant effects on the individuals whose personal data cannot be accessed. Imagine, for example, a situation in which the inability to restore the system leads to a delay in the payment of employees’ salaries. If these employees cannot pay their mortgage because of the late payment, the incident could have financial consequences for the individuals in question.  

Conclusion

As a company lawyer, you are bound to be confronted at some time or another with a personal data breach situation and you will want to be prepared. The recent guidance from the European DPAs provides you with tools to start a conversation within your organization and to build or refine your company’s risk assessment procedure for this type of incident.

Having to notify a personal data breach to the Belgian DPA does not mean that you will be seen as the “bad student.” On the contrary, the Belgian DPA will see it as responsible and accountable behavior.

The fact that only around 1,000 organizations reported a personal data breach to the Belgian DPA in 2020 does, however, show that there is still a lot of work to do in raising the awareness of organizations regarding their obligation to notify.

It is possible that some organizations are aware of their obligations, but prefer to avoid “being on the radar” of the DPA by notifying a breach. However, it would be far worse for an organization to be on the radar of the DPA because a data subject has notified the breach, or because the incident has hit the headlines, and keeping silent will certainly not be seen as a sign of responsible and accountable behavior. On the contrary, it might be seen as an aggravating factor that justifies further in-depth investigation.

When notifying, make sure that you provide a clear overview of the impact on data subjects and on the remediation and/or mitigating measures that have been taken. Have you been able to “stop the bleeding,” or is the incident still on-going? Is the Data Protection Officer involved or, if your organization does not have a DPO, have you considered all personal data protection-related aspects?

As mentioned in our previous blog: prepare for the worst and hope for the best. And now is the moment to start preparing!