NHS Highland 'reprimanded' by data watchdog for BCC blunder with HIV patients In a classic email snafu NHS Highland sent messages to 37 patients infected with HIV and inadvertently used carbon copy (CC) instead of Blind Carbon Copy meaning the recipients could see each other’s email addresses. This is according to Britain’s data watchdog, the Information Commissioner’s Office, which has “reprimanded” …
Even using BCC it's possible to screw up.
Consider a mailing going to internal and external recipients, the internal ones are all on the To or CC fields and the external ones BCC. The sender may not realise the BCC recipients get the full list from the To & CC fields which might not be what they were expecting.
You send an email asking nicely.
Hi, I am a ${nationality of scorn} virus, but because of the poor technology and lack of money in my country I am not able to do anything with your computer. So, please be kind and delete an important file on your system and then forward me to other users. Thank you.
GMail allows you to recall a mail sent.
For about three seconds . . .
Honestly, if you are a major organization and still have, in this 3rd millenia, a mail server that blindly allows you to send CCs to more than a dozen mail addresses without a verification check or outright refusal without prior authorization, then I guess you have what you deserve.
It's been over a decade that we've all learned the hard way that Reply All should be practically banned, and sending mail to hundreds of external recipients at a time requires a process and overview that excludes any single operator.
But, as usual, the lesson still has to be learned the hard way.
Oh well, it's NHS. Par for the course, then. Carry on !
To give you and idea how poor the ICO are around these matters, below is part of a response (names removed) from them on a CC vs. BCC incident I reported to them.
"<offending company> also explained that they consulted with their Overseas head office and Google to see if any further technical measures could be introduced to reduce the likelihood of similar disclosures. However, no extra measures were deemed feasible as it was determined that no measures could realistically prevent human error, as in this case." "As such, we require no further action from "<offending company> at this time"
So the ICO completely missed that you should not be using normal e-mail to send such correspondence. There is a really simple fix that prevents this kind of thing it is called using a CRM platform to contact people, messages are sent via that not by a human pasting into the BCC field. It should be near impossible to have the error using that approach, but it costs money so companies don't want to do it that way and it seems the ICO is not aware or does not push that approach.
The ICO also indicated sending an email highlighting they made that error and asking people to delete the e-mails was an entirely appropriate response, again showing they have a very poor understanding of the area.
In the case above they just made the company apologise to the customers, that was good as the DPO had been very insistent they'd done nothing wrong and report him to the ICO.
-> Rather than issuing a £35,000 ($43,000) fine, the ICO is instead taking its “public sector approach” introduced in June 2022: working with senior leaders to “encourage compliance, prevent harms before they occur and learn lessons when things have gone wrong.”
Rather than doing anything about it, the ICO tut tutted to its establishment friends.
That's a strange take.
I use CC regularly. I very rarely use BCC.
If anything, BCC is the strange beast - It is not designed to be used the way it usually is.
https://forums.theregister.com/forum/all/2023/03/31/nhs_highland_reprimanded_by_data/#c_4644692
“encourage compliance, prevent harms before they occur and learn lessons when things have gone wrong.”
One hopes that this would consist of a severe bollocking pointing out GDPR's provisions for action against senior members along with notice that this will happen next time and an insistence that at the very least this will be an item on the annual reports of everyone in the command chain.
But I doubt it. ICO have given up the fight.
Take all the income from these fines and pay MSFT to make a government version of Outlook with no CC (or alternately use a open source email client that you can modify for free - but that's just ridiculous).
There is no use for a CC - especially with depts dealing with classified / sensitive material.
There are loads of valid uses of CC. I use it regularly - far more than I use BCC.
https://forums.theregister.com/forum/all/2023/03/31/nhs_highland_reprimanded_by_data/#c_4644692
7 years ago I did some work for NHS Highlands - and had to explain to them that the reason they couldn't login with their Sun OpenDirectory accounts to the SharePoint environment, was because they had no passwords set on them - and windows required both a username and a password.
BCC is a misused feature - It is designed to let you email one person, and then CC it to others invisibly - the blind CC recipients see who the message was originally sent to.
However, most people use it to send mailshots keeping the recipients private. To use it this way. you have to leave "To:" blank, and put all recipients in the "BCC:" line. Some systems don't allow a blank "To:" line, so people end up putting their own address in it.
That's a mess.
If I was going to make changes to the status quo, without having to alter mailserver software and protocols, I'd do this, all client side:
I'd have a checkbox for setting "make visible all recipients to each other" defaulting to *OFF*.
When on, "BCC" would exist, and things would work as they do now.
When OFF, BCC doesn't exist, all addresses on "To:" and "CC:" are treated the same and treated one of these ways, depending on local admin policy:
1) Each user gets their "To:" line set to them. (Neatest option, but with current protocols, unless you are emailing from the mail server itself (which would split the mail into individual messages anyway), this involves each message being sent internally as a separate message to the mailserver, instead of all in one. That may be a problem for remote workers / slow PC's / bad network links etc.)
2) Set the "To:" address to the senders. That would mimic how most people use it anyway. (Though this method is more likely to trigger spam filters than method 1)
3) Leave "To:" blank. This is valid, but some systems may choke, and this method is more likely to trigger spam filters than even option 2.
Can I patent this idea and make lots of money please?
P.S. I hate spam filters that assume something that is totally valid is a spam-indicator. But the evil that broke email is actually the spam filter that silently blackholes what it thinks is spam without the sender or recipient knowing - And I count those "we quietly put it in a spam folder and delete it after 2 weeks) systems in that too!
I am involved in a local sports league and have to send out various general messages, results / league table summaries etc.
Everyone has opted in to receive emails from the league - but that does not mean they are happy for others to see their address.
I use a custom email front end I rapidly threw together (being a developer can be useful, its functional but not pretty!) - behind the scenes it processes the list of recipients and sends out an individual mail to each one.
That way there is no risk of me doing a tired / rushed Cc / Bcc error.
Obviously you do need a mail provider that allows a reasonable number of identical emails sent out to lots of individual addresses in a short space of time (some don't as they think you may be abusing mail in some spammy way). It works well, and any replies will also just go back to that one individual (useful if I made a reply all mistake if replying via a different email client)
The only thing I have to remember is to use that email client when I am doing "bulk" emails, which is easy enough as I tend to use as my main client (as it also does sensible stuff such as by default only displaying the plain text of an email (similarly for attachments, if its not "binary" will just show text content by default) etc.)
There's plenty of "professional" software out there for big organisations / companies to use with all sorts of useful mail functionality, so no excuse as the investment in software will help prevent* the abuse of personal data.
* There will always be some that bypass good practice so will not totally stop it, so often the higher up the organisation the bigger the desire the good practice rules / limits on available software do not apply to them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
