Personal data breach examples

What happened?

A data controller sent paperwork to a child’s birth parents without redacting the adoptive parents’ names and address. After discovering the breach, the data controller did not inform the adoptive parents.

Why was this a problem?

The breach presented a high risk to the adoptive parents’ safety. The birth parents visited the adoptive parents’ address and had to be removed by the police, and the adoptive parents and their children had to relocate.

What should have happened?

The controller should have notified the adoptive parents as soon as the breach was discovered. This would have allowed the adoptive parents to take steps to minimise the risk, for example by moving into alternative accommodation or putting additional safeguarding measures in place.

The incident also needed to be reported to the ICO, as there was likely to be a risk to individuals.

The controller should also investigate why the incident occurred and take steps to prevent a similar incident occurring in the future.

What happened?

A debt insolvency agent emailed a vulnerable new client’s file in error to a colleague in a different department. The colleague who received the file immediately deleted the email and informed the sender of the error.

Why was this a problem?

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 client was vulnerable due to their mental state.

What did the data controller do?

The sender and recipient work for the same organisation in similar roles, but in different departments. Both work to the same data security measures and have completed training on working with vulnerable people.

The recipient correctly deleted the email and informed the sender. As a result, 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. Therefore, there is no legal obligation to report the breach to the ICO or inform the affected data subject.

The organisation documented the breach internally and provided 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.

What happened?

An employee lost his briefcase, containing work on an unencrypted laptop and unredacted paper files relating to a sensitive court case – including information on criminal convictions and health information.

Initially, 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.

At that point, the data controller did not report the breach to the ICO as they believed there was little or no risk to data subjects, though they did record the incident on their breach log.

After being informed by the IT department that the laptop was unencrypted, and after the employee discovered the paper files had not been redacted, the controller reported the breach to the ICO and informed the data subjects.

Why was this a problem?

The paper files were unredacted and not secured, so somebody could have accessed sensitive data. As the laptop was unencrypted, there was no way for the controller to know whether the data had been accessed. Therefore, they could not be certain that a risk to the data subjects would not occur.

What did the data controller do?

They updated the internal breach log to reflect the new information and documented the developing situation, including the way the breach changed from being not reportable to reportable. On discovering the possibility of a risk to data subjects, the controller correctly reported the breach to the ICO and informed the data subjects.

The controller was then able to use their internal breach log to explain the delay in reporting the breach to the ICO, outside the required 72 hours.

What happened?

A courier, delivering medication for a Scottish pharmacy, delivered one set of medication to the wrong patient (Patient A).

Patient A called the pharmacy to complain. The pharmacist then realised the prescription was for a different patient with a similar name (Patient B). After contacting the courier, the unopened medication was collected and delivered to Patient B.

Why was this a problem?

Patient A and Patient B both complained to the pharmacist. Patient B felt their medical information and address had been shared inappropriately with Patient A.

What did the data controller do?

The pharmacist decided that any risk to Patient B was unlikely, due to the actions of Patient A, the pharmacy and the courier. However, they decided to report the breach to the ICO in case Patient B subsequently complained to the ICO about how their personal data had been handled.

Did the data controller need to report the breach?

As the pharmacy had concluded it was unlikely there was a risk to Patient B, the breach did not need to be reported to the ICO.

There would be no further action for the pharmacy to take, assuming they had documented the details of the breach, their decision not to report and any safeguards put in place to prevent a recurrence. The threshold for informing data subjects is higher than for informing the ICO. Therefore, the pharmacy didn’t need to tell data subjects about the breach either. Informing individuals about minor breaches that are unlikely to cause risk or harm can cause unnecessary worry to data subjects and can also result in data subjects becoming fatigued if informed of numerous breaches.

The pharmacist should have had confidence in their decision making and taken responsibility for it. If, having received a complaint from the data subject, the ICO wanted to know why the pharmacy had not reported the breach, they would be able to refer to the rationale recorded on the internal breach log.

Note that if the pharmacy had been 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.

What happened?

A law firm employee failed to recognise a phishing attack. They received an email, clicked a link to download a document, then inadvertently entered login credentials into what they believed was a legitimate website.

A while later, the employee contacted the company’s IT department as they noticed they were no longer receiving emails.

Why was this a problem?

The data controller discovered the employee’s email account had been compromised when they entered their login details. A forwarding rule had also been set up, diverting the employee’s emails to a third party.

Additionally, the third party had responded to several emails using a spoofed email account, advising the recipients of a change in bank details. This resulted in two clients making significant payments to the third party.

The controller also discovered that the compromised email account contained scanned copies of client ID documents.

What did the data controller do?

The controller reported the breach to the ICO and notified affected clients about the breach.

The controller identified a high risk to affected clients’ rights and freedoms, partly due to the financial detriment that two clients experienced after making payments to the third party. It is also likely that other clients will have received emails asking for payments.

Also, the controller identified that there was a high risk of identity theft or fraud, due to scanned copies of ID documents being held on the compromised account.