Plymouth Council BCC Blunder Exposes 500 Families, Reported to ICO

Plymouth City Council has confirmed that its Elective Home Education team sent a mass email to around 500 home-schooling families without using the blind carbon copy field, making every recipient's email address visible to everyone else on the list. The council has apologised, asked recipients to delete the message, and reported the matter to the Information Commissioner's Office (ICO).

The incident arrives barely a week after City of York Council disclosed a near-identical mistake that exposed the email addresses of hundreds of disabled residents. Two councils, two weeks, one missing BCC field. For anyone responsible for data protection in a public body, the pattern is the lesson.

What actually happened

The email was meant to inform families about upcoming legislative changes affecting home education. According to the council's statement to local media, "due to human error, a recent email was sent to approximately 500 families without using the BCC function, meaning recipient email addresses were visible." The message contained no information about individual children and was described as a general update.

That detail matters for the severity assessment, but it does not remove the breach. An email address, particularly one tied to a specific and identifiable group such as families who home-educate, is personal data under the UK GDPR. Disclosing 500 of them to each other without consent is an unauthorised disclosure of personal data, which is the textbook definition of a personal data breach under Article 4(12).

Why this is a regulatory matter, not just an embarrassment

Under the UK GDPR and the Data Protection Act 2018, a controller that suffers a personal data breach must assess whether the breach poses a risk to the rights and freedoms of the people affected. The rules break down into a clear decision sequence.

First, the 72-hour rule. Article 33 requires the controller to notify the ICO within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals. The clock starts at awareness, not at the point the organisation finishes its internal investigation. If you cannot complete the assessment in time, you notify on the information you have and supplement it later. Plymouth reported the matter to the ICO, which is the correct first step.

Second, the test for telling the individuals themselves. Article 34 requires notification to affected people only where the breach is likely to result in a high risk to their rights and freedoms. A list of email addresses, with no children's details and no special category data attached, will generally sit below that high-risk threshold, though the sensitivity of the group can push the assessment upward. Plymouth contacted recipients regardless, which is good practice when those people can take protective action.

Third, the documentation duty. Article 33(5) requires controllers to record every breach, including ones they decide not to report, along with the facts, the effects, and the remedial action taken. This internal record is itself something the ICO can ask to see.

How the ICO handled it

An ICO spokesperson confirmed receipt of the report and said the regulator "provided data protection advice and closed the case with no further action." That outcome is typical for a contained, low-to-moderate severity disclosure where the organisation responds promptly, notifies affected people, and commits to preventive measures. Enforcement and fines tend to follow breaches involving sensitive data, large numbers, or a failure to act, rather than a single mailing-list error caught and reported quickly. Organisations can review the regulator's guidance on personal data breaches and use the ICO's self-assessment tool before deciding whether to report.

Plymouth said it asked families to delete the email and to refrain from using any addresses they had received. That request has no legal force over recipients, but it is part of demonstrating that the controller took reasonable mitigation steps, which feeds into the ICO's view of the response.

The compliance steps that prevent this

For any organisation that sends bulk communications to the public, the controls here are unglamorous and effective.

Stop sending bulk personal mailings from a standard mail client. The BCC field exists, but relying on a person to select it correctly every time is a control that fails on a long enough timeline. Use a mail platform that suppresses recipient visibility by design, or a system that sends individually addressed messages.

Build a second pair of eyes into the process. A documented requirement that any mailing above a set recipient threshold is checked by a second member of staff before sending turns a single point of failure into two.

Review the retention and structure of mailing lists so that distribution data is not casually pasted into the To or CC fields. Plymouth said it has promised "extra checks designed to keep future mailing lists out of public view," which is the right direction if it is written into procedure rather than left as good intentions.

Keep the breach log current and rehearse the 72-hour assessment so staff know who decides, who notifies, and what evidence is captured.

The wider point for compliance teams is that the most common breaches reported to the ICO are not the work of ransomware crews or sophisticated intruders. Year after year, the regulator's statistics are dominated by emails sent to the wrong person, attachments containing more than the sender realised, and exactly this kind of missing-BCC disclosure. The fix is process, not technology spend. Sometimes the whole incident comes down to a few hundred recipients and a single unticked box.