Data breaches: when to notify Regulators and affected individuals

January 2022

European Data Protection Board (EDPB) publishes new case-based guidelines on data breach notifications

As we know, not all personal data breaches need to be reported to Supervisory Authorities, such as the UK’s Information Commissioner’s Office, nor indeed to affected individuals. It all depends on the nature of the incident and risk posed. This can be a tricky decision to make.

What the law says about notifying a data breach

UK GDPR tells us where a breach is unlikely to result in a risk to the rights and freedoms of individuals, it doesn’t need to be reported to the ICO. Furthermore, it tells us we should inform affected individuals only where it is likely to result in a high risk.

Assessing data breach risks

The key then, after establishing an incident involves personal data, is to assess the risk it poses to the people whose details are affected. This can sometimes be complex, and the law gives us a short timescale to make an assessment. As we know, personal data breaches which are likely to represent a risk to individuals need to be reported to the ICO (or other DPA) within 72 hours of becoming aware of the breach.

This leaves many to err on the side of caution; that’s to say they notify for fear of making the wrong decision.

Our Privacy Pulse Survey 2022 provides some interesting insight on the number of breaches organisations are experiencing, the volumes being reported to the ICO, and the numbers communicated to affected individuals.

Case studies to help our risk assessment

Helpfully, the EDPB has published new guidelines which provide some useful example. These are designed to be complementary to the previously published Guidelines on Personal data breach notification.

The types of scenarios covered include:

  • Ransomware
  • Exfiltration of data from websites
  • Data ‘stolen’ by an employee
  • Accidentally sending data to a trusted party
  • Lost or stolen devices and paper documents
  • Errors by postal mail
  • Social engineering

In each case a common scenario is posed, and we are taken through the decision-making process with the following sections:

  • ‘Prior measures and risk assessment’
  • ‘Mitigations and obligations’

It’s stressed the analyses provided relate explicitly to the specific cases under scrutiny. We’re clearly warned if our circumstances differ slightly, the risk posed will also differ.

I have picked out several examples (please note these have been summarised).

Accidental transmission to a trusted party

An insurance agent noticed that – made possible by the faulty settings of an Excel file received by e-mail – he was able to access information related to two dozen customers not belonging to his scope. He is bound by professional secrecy and was the sole recipient of the e-mail. The arrangement between the data controller and the insurance agent obliges the agent to signal a personal data breach without undue delay to the data controller. Therefore, the agent instantly signalled the mistake to the controller, who corrected the file and sent it out again, asking the agent to delete the former message. According to the above-mentioned arrangement the agent has to confirm the deletion in a written statement, which he did. The information gained includes no special categories of personal data, only contact data and data about the insurance itself (insurance type, amount). After analysing the personal data affected by the breach the data controller did not identify any special characteristics on the side of the individuals or the data controller that may affect the level of impact of the breach.

In this case, the combination of a low number of affected individuals, the immediate detection and the measures taken, leads to an assessment of ‘no risk’. In other words no obligation to notify a Supervisory Authority or individuals. The incident should, however, be logged internally.

Stolen device containing unencrypted data

The electronic notebook device of an employee of a service provider company was stolen. The stolen notebook contained names, surnames, sex, addresses and date of births of more than 100,000 customers. Due to the unavailability of the stolen device it was not possible to identify if other categories of personal data were also affected. The access to the notebook’s hard drive was not protected by any password. Personal data could be restored from daily backups available.

This is clearly a case where there’s an obligation to notify the Supervisory Authority and affected individuals. Other examples are given where devices where encrypted, which lead to a differing assessment of the risks posed and notification obligations.

Postal mail error

Two orders for shoes were packed by a retail company. Due to human error two packing bills were mixed up with the result that both products and the relevant packing bills were sent to the wrong person. This means that the two customers got each other’s orders, including the packing bills containing the personal data. After becoming aware of the breach the data controller recalled the orders and sent them to the right recipients. The bills contained the personal data required for a successful delivery (name, address, plus the item purchased and its price).

The EDPB says the controller should provide for a free return of the items and the accompanying bills, and should request the wrong recipients destroy / delete all copies of the bills containing the other person’s personal data.

In this specific set of circumstances, the assessment concludes the risk to be considered low. No special category data or other data is disclosed, which might lead to substantive negative effects on those involved. Therefore no obligation to notify to the Supervisory Authority nor affected individuals. Saying this, communication of the breach cannot be avoided with the individuals involved, as their cooperation is needed to mitigate the risk.

Ransomware attack with proper backup and without exfiltration

The computer systems of a small manufacturing company were exposed to a ransomware attack, and data stored in those systems was encrypted. The data controller used encryption at rest, so all data accessed by the ransomware was stored in encrypted form using a state-of-the-art encryption algorithm. The decryption key was not compromised in the attack, i.e. the attacker could neither access it nor use it indirectly. In consequence, the attacker only had access to encrypted personal data. In particular, neither the email system of the company, nor any client systems used to access it were affected…
…After analysing the logs and the data collected by the detection systems the company has deployed, an internal investigation supported by the external cybersecurity company determined with certainty that the perpetrator only encrypted data, without exfiltrating it.
A backup was readily available, and the data was restored a few hours after the attack took place.

The assessment reached in this scenario is the breach didn’t result in any consequences for the day-to-day operation of the manufacturing company, nor did it have any significant effect on the data subjects. Therefore, no obligation to notify the Supervisory Authority or communicate to individuals. The personal data breach should be internally logged.

There are further ransomware attack examples given, where the circumstances differ and notification would be required.

Our 7 key data breach takeaways

1. Develop a data breach plan and keep it under regular review
2. Assign a suitably knowledgeable data breach team (or have external experts on hand to support when required)
3. Have a methodology for assessing, evaluating and documenting risk (for example using a risk matrix)
4. Maintain a log of all personal data breaches, whether they’re judged notifiable or not
5. Keep a record of any justification for not notifying of a breach
6. Remember, a breach can be notified before all facts are known. A full assessment can run in parallel to notification and subsequent information learnt can be provided to the ICO (or other Supervisory Authority) in phases.
7. Training and awareness focused on data incident identification, expected actions and triage is essential for both controllers and processors.

In summary…

The EDPB case-based guidelines are another helpful tool to support organisations in their handling of data breaches, and factors to consider during the risk assessment process. The ICO also has detailed data breach guidance and has published some useful data breach examples.