EDPB guidelines on personal data breach notifications

Last month, the EDPB published their "Guidelines on Examples regarding Personal Data Breach Notification" (the Guidelines).

These are intended to provide "practice-oriented, case-based" guidance on when it is necessary to notify the relevant supervisory authorities (the SA) under Article 33(1) of the GDPR and/or data subjects under Article 34(1) of the GDPR following a personal data breach.

Whilst the EDPB has provided guidance on personal data breach notifications in the past, the Guidelines focus on practical examples to offer a useful extra layer of reasoning on what events are likely to trigger Articles 33(1) and 34(1), and why.  The Guidelines contain a wide range of examples, setting out each scenario with key variables such as the presence of an IT security system and/or the exfiltration of personal data.  The Guidance takes into account both the preventative measures that could have ensured a different outcome (had they been in place at the time of the incident) and the actions that data controllers could take to mitigate the impact of the incident and ensure compliance with regulatory obligations.

We have set out below some high-level comments on how the Guidelines treat a couple of the scenarios we see most commonly, namely ransomware and social engineering (including business email compromise).

Ransomware

 Ransomware, if effective, will often involve an availability breach – in that personal data will be rendered unavailable as a result of encryption.  It can also potentially result in a confidentiality breach if the threat actor has exfiltrated personal data.  This is often the case as threat actors use the tactic of placing pressure on the data controller by threatening to publish exfiltrated data online should the ransom not be paid.  It follows that the effect on data subjects, and the resulting notification obligations, vary depending on the circumstances of the ransomware incident and the data controller's ability to reconstitute the data.

Existence of backups and no exfiltration

 If a firm suffers a ransomware attack that results in the encryption of data but not the exfiltration of data, there could be an availability breach as the firm is no longer able to access personal data which has been encrypted by the threat actor.  An availability breach of this type can of itself give rise to notification obligations in relation to the SA under Article 33(1) and/or data subjects under Article 34(1).  

If electronic backups are available and the firm is able to use these to ensure an effective and timely restoration of personal data, there may be no requirement to notify either the SA or the data subjects, with only an internal record of the incident being required under Article 33(5), GDPR.  However, a key consideration will be how quickly the data can be restored and whether that restoration will be complete.  The Guidelines state that "the GDPR states that a personal data breach shall be notified without undue delay and, where feasible, not later than after 72 hours. Therefore, it could be determined that exceeding the 72-hour time limit is unadvisable".  This suggests that if data can be restored within 72 hours, notification to the SA under Article 33(1) might be unnecessary, but a lack of availability for longer than this could result in a notification being prudent.  

Where electronic backups are not available, the Guidelines state that the SA is likely to need to be notified, even if data is restored from paper files.  The reasoning is that restoration from paper files takes more time, so the breach of availability of data subsists for longer, and some information (such as meta-data) may not be retrievable.  Therefore, in such cases, there could be both a requirement to keep an internal record of the incident under Article 33(5) and, depending on the nature of the personal data affected, a requirement to notify the SA under Article 33(1).  Whether there is a need to notify data subjects of the incident under Article 34(1) as well will depend on the length of time for which the data is unavailable and the severity of the likely impact of the lack of availability on the data subjects.  The Guidelines contrast an incident at an agricultural company where notification to data subjects "may be necessary" if delays result in financial loss to individuals in contrast to an incident at a hospital where notification to data subjects "is necessary" if it would impact on the treatment of patients.

No backups and evidence of exfiltration

 In situations where there is no backup available and there is evidence that personal data has been exfiltrated, both an availability breach and a confidentiality breach are likely to have occurred, likely leading to greater notification obligations.

Internal documentation of the incident will be required under Article 33(5) as always, and notification to the SA will also most likely be required under Article 33(1).  However, in addition, the data controller may be required to communicate the breach to affected data subjects, especially where the data in question relates not just to basic identity data, but to financial data such as credit card details as well.  The difference is that where only basic identity data is involved, the incident is unlikely to result in a high risk to the individuals, whereas if sensitive financial details are compromised, the individuals should be informed directly because the incident is likely to result in a high risk of them being impacted.  Notifications are needed, not least so that they can take the necessary steps to avoid being impacted to the extent possible.

Social engineering

 The Guidelines also touch on social engineering – situations in which the threat actor communicates with individuals to persuade or trick them into performing an action that allows the attacker access to the systems, rather than using more technical means.  One example of a social engineering incident is sending phishing emails in order to gain access to an email mailbox. 

The scenario set out in the Guidelines involves emails containing expressions relating to payments (e.g. invoice, bank account details, etc) being forwarded to external email addresses and, subsequently, fictious invoices showing the threat actor's bank account details being sent out.  

In this example, it is likely that the threat actor's intention was to commit payment diversion fraud by sending false invoices in the hope that a payment would be made to a fraudulent bank account.  The threat actor's intention does not appear to be to obtain personal data relating to individuals who communicate with the data controller.  However, if there is access to a mailbox, the threat actor ultimately might nevertheless obtain access to personal data belonging to various other individuals, such as employees, that could be used to facilitate other attacks.  As such, the personal data breach could potentially result in significant risk to those individuals, potentially triggering notification requirements, depending on the personal data involved.

Conclusion

 The Guidelines are useful in providing greater clarity on the Article 33 and 34 requirements in various scenarios.  However, personal data breaches vary considerably in circumstance and severity. Indeed, the Guidelines demonstrate the large extent to which situations must be assessed on a case-by-case basis, the degree of variance in outcomes when effective preventative measures are (or are not) in place and the importance of taking the right mitigating actions whilst ensuring compliance with data protection regulations. 

The Guidelines can be found here.