CC instead of BCC: the smallest mistake with the largest consequence

A London charity sent an email to participants in a health support programme. The addresses went into the CC field rather than BCC. Two hundred and sixty-four recipients received the message, and with it the address list of everyone else on it. One hundred and sixty-six of those people were identifiable or potentially identifiable.

The programme supported people living with HIV. The address list, on its own, disclosed each participant’s health status to every other recipient.

The UK regulator fined the organisation GBP 7,500 in April 2024. That figure deserves a second look, because the penalty initially recommended was GBP 300,000, reduced under the regulator’s approach to public sector and charitable bodies. A commercial firm making the identical error is looking at the first number.

This has happened three times

The reason to write about a GBP 7,500 penalty is what surrounds it.

The same regulator fined another organisation working with people living with HIV GBP 10,000 in October 2021 for the same failure. It issued a reprimand to a health board in March 2023, again for the same failure. Alongside the 2024 penalty, the Information Commissioner made a public statement calling for urgent improvement across organisations serving this group.

Three organisations, three years, one error. At that point the useful conclusion is structural. If capable, well-intentioned organisations repeat an error this consistently, the error is being produced by the design of the task rather than by the character of the people performing it.

Why this specific mistake keeps happening

Four properties of the CC field combine to make it unusually dangerous, and none of them is about competence.

The fields are adjacent and look identical. CC and BCC sit next to each other, take the same input, and render the same way while you are typing. Nothing about the composing experience distinguishes the safe field from the unsafe one.

The error is invisible before sending and obvious after. A draft with 264 addresses in CC looks exactly like a draft with 264 addresses in BCC to the person writing it. The difference appears in the recipients’ inboxes, at which point it cannot be undone.

The person sending is usually not the person who owns the risk. Bulk participant emails are often sent by programme staff, coordinators, or administrators, doing an ordinary task under time pressure. The data protection consequence sits with someone else entirely.

There is no confirmation step. High-consequence actions in most systems have one. Sending a message to hundreds of people whose membership of a list is itself sensitive does not.

The part that makes it severe

Under the GDPR, data revealing health status is a special category, and processing it carries a higher bar and higher penalties. The important subtlety in this case is that no health data was written in the message.

What was disclosed was a list of email addresses. It became health data through inference: these people are on this programme, and this programme is for people with this condition. The sensitive fact was created by the combination of the list and its context, not by anything anyone typed.

This generalises well beyond health. A recipient list can disclose that people are in a redundancy consultation, in a grievance process, in arrears, in a bankruptcy proceeding, or clients of a particular adviser. In each case the addresses are ordinary and the membership is not.

What happens in the hour after

Worth walking through, because the response burden is the part that never appears in the penalty figure.

The send cannot be recalled in any way that helps, since the addresses are already in every recipient’s inbox. The organisation has to assess whether the breach is likely to result in a risk to the individuals, and for special category data through inference the answer is almost always yes.

That triggers a notification to the supervisory authority within 72 hours. Where the risk is high, it also triggers notification to every affected individual, which means contacting each person to tell them their health status was disclosed to 263 others. Each of those contacts is itself a difficult communication, and some recipients will have already seen the list and drawn their own conclusions.

Then there is the standing exposure. Individuals affected by a breach of this kind may bring claims for distress, and the population is large and identifiable by construction.

Set against that sequence, a confirmation dialog above twenty recipients is inexpensive.

A decision rule you can apply this week

The workable version of this control is a rule about categories rather than a reminder to be careful.

If the recipient list is	Then
People who know each other and expect to be visible to each other	CC is appropriate. A project team, a committee, a working group.
People who share a characteristic they did not choose to disclose to each other	BCC, or better, individual sends from a system built for it.
More than roughly twenty external addresses	Use a mailing tool. Bulk sends from a mail client have no safeguards.
Unclear which of the above applies	Treat it as the second row. The cost of an unnecessary BCC is nothing.

The second row is the test that matters, and it is worth phrasing it as a question people can hold: would any recipient be uncomfortable if the others knew they were on this list. If the answer is yes for even one person, the list is sensitive.

What to change, in order of effect

1. Move bulk sends out of the mail client. A tool that sends individually removes the failure mode entirely rather than mitigating it. This is the only change on this list that eliminates the risk.
2. Add a confirmation step for large recipient counts. Where bulk sending from a client is unavoidable, an interruption above a threshold catches the error at the only moment it is still catchable.
3. Name the categories in your policy. “Be careful with BCC” is not a control. A list of the categories that always require individual sends is.
4. Brief the people who actually send. The training usually reaches the data protection function and the managers. The person sending the participant email is often neither.

Where a pre-send check fits

This is the failure mode a pre-send control is best suited to, because everything needed to catch it is present in the draft before it goes: the number of recipients, the fact that they are external to each other, and the field they were placed in.

Our pre-send check evaluates the recipient list alongside the content, and the recipient side of that check is what applies here. The intervention is a question at the moment of sending, which is the last point at which the answer still matters.

It will not tell you that a list is sensitive if nothing in the message says so, and that limit is worth stating. The category judgement in the table above is yours to make once, in policy. What a check does is stop the mechanical error from executing it wrongly.

The takeaway

Find every recurring bulk email your organisation sends from a mail client, and move the ones with sensitive membership to a tool that sends individually. That single change closes the route that produced three enforcement actions in three years. For the wider pattern of confidential information leaving in ordinary messages, see our piece on the four routes it takes.