To help you assess the severity of a breach we have selected examples taken from various breaches reported to the ICO. These also include helpful advice about next steps to take or things to think about.
Paperwork was sent to children’s birth parents without redacting the adoptive parents’ names and address. When the data controller discovered the breach, they did not inform the adoptive parents, who later contacted the controller to advise that the birth parents had been to their address and had to be removed by the police. The adoptive parents and the children had to relocate.
The controller should have notified the adoptive parents as soon as they discovered the breach, as this incident presents a high risk to their safety. The controller was aware that this address should have remained confidential. The main reason for notifying a data subject is so they can take steps to minimise the risks to themselves. For example, if the controller had notified the adoptive parents, they could have moved into alternative accommodation sooner or put additional safeguarding measures in place. This incident would also need to be reported to the ICO as the threshold for reporting is lower than notifying the people affected by the breach. The controller should also investigate the causes of this incident to ensure they understand how and why it occurred and put in place steps to prevent a similar incident occurring in the future.
A debt insolvency agent emailed a new client’s file in error to a colleague in a different department. The file contained a list of the client’s outstanding debts, their contact details, basic financial history, information about their mental health and reasons for seeking support with their financial situation. The organisation considers the client to be vulnerable due to their mental state. The colleague who received the file immediately deleted the email and informed the sender of their error.
Both the sender and the recipient work for the same organisation in similar roles, although they are in different departments. Both are bound by the same data security measures, and both individuals have completed training on working with vulnerable people. The recipient followed correct procedure in deleting the email and informing the sender. It is very unlikely that there would be any risk of harm or detriment to the data subject, despite special category personal data being involved. As such, there is no legal obligation to report the breach to the ICO or to inform the affected data subject. The organisation should document the breach internally and provide guidance to staff about checking contact details when sending emails, to minimise the risk to their data subjects. If the email had been sent to a member of the public, the risk to the data subject would have been higher.
An employee could not find his briefcase, which contained his laptop and paper files. The employee told his manager that he believed the laptop was encrypted and the paper files were redacted. The manager reported the incident to the IT department, who remotely wiped the laptop. The data controller did not report the breach to the ICO as they believed there was little or no risk to data subjects.
The IT department later discovered the employee was working on an old laptop, which was not encrypted or password protected. The employee also confirmed that the paper files were for an upcoming criminal trial and the personal data, which related to criminal convictions and health information, had not been redacted. The controller then reported the breach to the ICO and informed the data subjects.
If the laptop had been encrypted and the paper files redacted, this incident would be unlikely to affect the rights and freedoms of the individuals concerned. The IT department had also wiped the laptop, which reduced the risk of detriment. Therefore, at this stage, it was reasonable to assess a risk was unlikely to occur given the security measures in place.
However, when the controller discovered this was not the case, they made the right decision to notify the individuals concerned and the ICO. This is because the paper files were unredacted and not secured and there was a period of time that somebody could have accessed sensitive data. There was no way for the controller to know what had happened to the data and how it would be used, therefore they cannot be certain that it was unlikely a risk to the data subjects would occur. Their internal breach log should reflect this new information and should document the developing situation, including the way the breach changed from not reportable to reportable. The controller would then able to explain any delay in reporting the breach to the ICO within the required 72 hours.
A courier collected a number of medication deliveries from a pharmacy in Scotland. The courier delivered one set of medication to the wrong patient (Patient A) on their rounds. Patient A called the pharmacy to complain. The pharmacist realised the prescription was actually for a different patient with a similar name (Patient B). They contacted the courier who called back to Patient A, collected the unopened items and redelivered to Patient B. At this point, the courier told Patient B about the error. Patient B then complained to the pharmacist, as they felt their medical information and address had been shared inappropriately with Patient A. The pharmacy decided that although any risk was unlikely, they would report the breach to the ICO just in case Patient B subsequently complained to the ICO about the way their personal data had been handled.
The pharmacist made the right assessment that a risk to Patient B was unlikely to occur. This was because of the initial actions of Patient A, the pharmacy and the courier to correct the error. Assuming the pharmacy documented the details of the breach - including the rationale for their decision, an investigation into the cause and that safeguards were put in place to prevent a reoccurrence - there was no other action for them to take from the ICO’s viewpoint.
The threshold for informing data subjects is higher than for informing the ICO. Whilst it is understandable that controllers want to be transparent, when individuals are told about breaches which are either minor or unlikely to cause risk or harm, controllers can actually cause unnecessary worry. Data subjects may even get tired of hearing about breaches and miss when a controller genuinely needs individuals to take action to protect themselves.
The trigger to report to the ICO was driven by Patient B’s complaint threat. The pharmacist should have had confidence in their decision making and taken accountability for it. If, having received a complaint from the data subject, the ICO wanted to know why the pharmacy had not reported the breach, their rationale should be recorded on the internal breach log.
Had the pharmacy been located in England, it would have reported the incident via the Data Security and Protection Incident Reporting tool, regardless of the threshold for reporting to the ICO.
A law firm employee received an email and clicked on a link to download a document. They were then prompted to enter their login credentials into what they believed was a legitimate website. It later came to the employee’s attention that they were no longer receiving emails so they reported this to their IT department.
Upon further investigation, the data controller discovered that the email account had been compromised when the employee entered their login credentials. They also discovered that a forwarding rule had been diverting the employee’s emails to a third party. During this time, the third party had responded to several client emails using a spoofed email account, advising them of a change of bank details. This resulted in two clients making significant payments to the third party rather than the data controller.
In addition to the above, it was also discovered that the affected email account contained scanned copies of client ID documents. The data controller decided to report the breach to the ICO and notified the affected clients about the breach.
This data controller has experienced a phishing attack. As the affected email account contains personal data, this becomes a personal data breach, as the data controller can no longer maintain the confidentiality of the personal data held within the email account.
In this case, the data controller has correctly determined the breach to be reportable, as they cannot say the risk to the affected clients’ rights and freedoms is unlikely.
The data controller has also told the affected clients about the breach, as they have identified a high risk to their clients’ rights and freedoms. This is due in part to the financial detriment that two clients have experienced as a result. They are aware that other clients have also received an email requesting payment, making it highly likely that further financial detriment will be caused. There is also a high risk of identity theft or fraud to clients, as scanned copies of ID documents were held within the affected email account.