The headlines this week called it an email blunder. The Register reached for "email stuff-up." It was not a stuff-up, and getting that wrong matters, because the lessons you draw from a slip are not the lessons you draw from what actually happened.
What actually happened at NHS Forth Valley is that a member of staff took a spreadsheet of maternity patients' data out of the maternity system and sent it to their own personal email account. Reportedly "for analytical purposes." That is not someone fat-fingering the CC field. That is data walking out of the building in someone's pocket — and it changes what the rest of us should take from it.
What we know
Around 150 women who used maternity services at Forth Valley Royal Hospital are affected. Per the board's own statements, relayed by the Falkirk Herald and SC Media, the spreadsheet held full names, dates of birth, NHS numbers, postcodes, details of their maternity care, and — for some — the number of children they have. For a maternity dataset, that is about as sensitive as personal data gets.
The person responsible was, in the board's words, a fully qualified NHS employee, not a junior, and not clinical. The matter has been reported to Police Scotland and the Information Commissioner's Office, which said it has "received a report from NHS Forth Valley and are making enquiries." Affected women were contacted directly.
Then come the three sentences that always follow a breach like this, and that deserve more scepticism than they usually get. The board says the majority of the data is "unidentifiable." It says there is "no evidence that the information has been shared any wider." And it says the staff member "has advised that they have now deleted the data."
Read those again as a security person, not a press officer. "The majority is unidentifiable" means some of it plainly is not. "No evidence it was shared wider" is not the same as evidence it was not — it is the absence of a capability to know. And "the staff member has advised they deleted it" is one person's word about a file that was, by then, sitting in a personal mailbox the organisation cannot see, search, or wipe. NHS Forth Valley has itself conceded it cannot say with certainty that no copies remain. That is the honest position, and it is the whole problem in a sentence: once the data left, they were reduced to hoping.
Why "misdirected email" is the wrong label
There are two completely different failures that both end with "patient data went somewhere it shouldn't via email," and they need different fixes.
The first is the genuine accident: you send a group email and put the addresses in CC instead of BCC, and now every recipient can see every other recipient. That is careless, it is common, and the ICO says BCC misuse is one of the top breach types reported to it every year — close to a thousand incidents since 2019. NHS Scotland has done exactly this before, which I will come to.
The second is what happened here: a person with legitimate access to a system deliberately extracted a bulk dataset and moved it to a place outside the organisation's control. The intent may have been entirely benign — "I wanted to do some analysis at home" is a very human thing to say — but the mechanism is data exfiltration, not misdirection. The ICO even categorises these separately: "data emailed to the incorrect recipient" is one incident type; "unauthorised access or disclosure" is another.
The distinction is not pedantry, and it carries legal weight. Moving personal data to a personal account without the controller's authorisation is the sort of act section 170 of the Data Protection Act 2018 exists for — it is a criminal offence to knowingly or recklessly obtain, disclose, or retain personal data without the data controller's consent. Whether the ICO or Police Scotland take that road here is unknown, and I would not pre-judge it. But it tells you the category: this is an insider-handling failure, and insider-handling failures are stopped by controls, not by another line in a policy nobody reads until after.
Not the first time — and let us be fair about why
Peter's readers will already be thinking it, so let me say it plainly: this is not an isolated slip for NHS Scotland. The pattern is real.
NHS Highland was reprimanded by the ICO after staff used CC instead of BCC on an email to people who used HIV services, exposing 37 identities to one another. NHS Lanarkshire was reprimanded after 26 staff shared patient data more than 500 times through a WhatsApp group between 2020 and 2022. NHS Dumfries and Galloway suffered a ransomware attack in 2024 in which the INC Ransom group published over three terabytes of stolen data. And an FOI investigation by The Ferret found at least 1,395 patient-data breaches across NHS Scotland boards in the two years to 2020 — a figure the reporters noted was probably an undercount.
So the pattern stands. But I want to be fair about what it is and is not, because the cheap version of this article writes itself and it would be wrong.
It is not evidence that NHS Scotland is uniquely careless. Human error is the single leading cause of data breaches reported to the ICO across every sector — health reports more because health holds more, processes more, and is watched more closely. The NHS runs at a scale, and under a staffing and funding pressure, that almost no private business will ever face. And the ICO itself now deliberately softens penalties on public bodies, favouring reprimands over fines, precisely so it does not pull money out of services that are already stretched.
None of that excuses the missing guardrail. But it reframes the fault. The problem is not that the NHS is full of reckless people. The problem is that a well-meaning analyst was able to move 150 maternity records to a personal inbox without anything stopping them or even flagging it. That is not a moral failure. It is a controls failure, and controls failures are the ones we can actually fix.
The lesson: the rule was there, the guardrail was not
I would bet a good deal that NHS Forth Valley already had a policy saying "do not email patient data to personal accounts." Almost every organisation does. The data still left.
That is the lesson, and it generalises to every business, not just hospitals. A policy is a statement of intent. It stops the people who were never going to do it anyway. It does nothing about the tired, rushed, well-intentioned employee who just wants to get some work done tonight and takes the path of least resistance — because the safe path was slower, or did not exist. The question a board should ask after this is not "did we have a rule?" You did. It is "what technical control was supposed to catch a bulk export of sensitive records leaving for a personal mailbox — and why didn't it?"
What to actually do about it
The NCSC's guidance on reducing data exfiltration frames this well as three moves: prevent, monitor, audit. It is written about malicious insiders, but the same controls catch the far more common well-meaning one. In rough order of value:
- Ask why one person could export the whole dataset at all. This is the least-privilege question, and it is the most important. A non-clinical analyst almost certainly did not need live access to 150 complete maternity records to do their job. Restrict who can run bulk exports, and log it loudly when they do. Most data that leaves should never have been reachable in bulk in the first place.
- Give people a safe path so they stop improvising an unsafe one. The employee wanted data "for analysis." Fine — then hand them a de-identified or pseudonymised extract inside a sanctioned analytics environment, not a raw pull from the clinical system. Data minimisation is a legal principle under UK GDPR and it is also the most practical control you have: if the analysis only ever sees data with the names stripped out, the personal inbox copy is worthless.
- Control the exfiltration channels. The NCSC names email to personal addresses and web upload tools as priority channels to manage. For most businesses that means data-loss-prevention with content inspection on outbound mail, and — cheaper and blunter — blocking or alerting on traffic to consumer webmail (Gmail, Outlook.com, and the rest) and on large attachments going to external domains. You do not need a six-figure platform to notice a spreadsheet of 150 records leaving for a personal account.
- Monitor and audit so you find out in hours, not from a journalist. The worst part of this story is not that data left; it is the implied gap between it leaving and anyone noticing. You want an alert when a bulk export happens, and an audit trail you can actually query. Detection is what turns a catastrophe into an incident.
- Fix the cheap misdirected-email failure too, while you are here. For the other, accidental, version — teach and enforce BCC discipline, and use proper bulk-email or mail-merge tooling for anything going to more than a handful of recipients. The ICO has specific guidance on this, and it costs nothing.
- Rehearse the response. UK GDPR gives you 72 hours to report a notifiable breach to the ICO. That clock starts when you become aware, not when you are ready. If you would be scrambling to work out who does what, you are not ready — and this is exactly the drill to run before you need it.
Underpinning all of it is the thing the ICO keeps asking for and most places skip: training paired with a genuine near-miss culture, where a member of staff who realises they have done something daft feels able to say so immediately rather than quietly hoping it goes away. That culture is worth more than another policy PDF.
The uncomfortable part
Strip it back and this is a small, ordinary failure with a very sharp edge. One person, one spreadsheet, one personal email account, and 150 women now relying on a stranger's assurance that the file has been deleted and nothing was seen.
Every reassurance NHS Forth Valley has offered — most of it is unidentifiable, no evidence it went further, we are told it is deleted — is a sentence you can only ever say from a position of not really knowing. That is what losing control of data sounds like. The entire point of the controls above is that you never have to say any of them, because the data never left in a form that could hurt anyone, and you would have known within the hour if it tried.
You cannot un-send an email to a personal account. You can only build the systems that make sure the email was never worth sending. That is the work, and it is a great deal cheaper than the letter to 150 patients.