Natural Resources Wales
Nobody attacked anything. The spreadsheet was uploaded to the website.
What happened?
Natural Resources Wales disclosed a personal data breach caused by human error. A spreadsheet containing diversity monitoring information for former and current employees was inadvertently published on its own website.
There was no intrusion. The file was uploaded to a public page by somebody who did not know what was inside it. The affected population covers people who worked for the organisation between April 2013 and March 2018.
What data was actually inside?
Ethnicity, disability status, religion, sexual orientation and caring responsibilities.
Every item on that list is special category data under UK GDPR, which is the most strictly protected class there is. Sexual orientation and religion in particular are data people disclose to an employer on the explicit understanding that the disclosure is confidential, aggregated and used only for monitoring. This was the raw spreadsheet rather than the aggregate.
Who gets hurt and how?
Employees and former employees across a five-year window, some of whom left a decade ago and have no ongoing relationship with the organisation.
Diversity monitoring depends entirely on a confidentiality promise. People disclose a disability, a religion or a sexual orientation to help an employer measure its own fairness, and the exchange only works because the individual response is never visible. Publishing the spreadsheet breaks that bargain for everyone who answered honestly, and it is the reason the next monitoring exercise will produce worse data.
The exposure is also permanent in the way a leaked identifier is not. These attributes describe a person and cannot be reissued or revoked.
What did they think they were doing right?
Collecting diversity monitoring data is good practice and in parts of the UK public sector a statutory duty. Publishing data openly is also correct for an environmental body that is expected to be transparent about its work.
The two practices collided. An organisation with a culture of publishing, holding a file whose contents nobody had examined, produced exactly this outcome. Nothing in the upload process asked what was inside the spreadsheet.
What did they not know about their own data?
What was in the file. This is the clearest example in this series of the content question, because there is no attacker to blame and no vulnerability to patch.
Somebody had a spreadsheet. The filename and the folder gave no indication that column headers included sexual orientation and religion. It went to a public page because nothing between the desktop and the website inspected the contents.
An organisation that scans what it publishes before publishing it does not have this incident. The check is cheap, it runs in seconds on a single file, and it is the one control that would have caught this specific failure.
If your environment was compromised today, could you say within 24 hours exactly what sensitive data was accessed?
Not sure where to start? How to find sensitive data across your estate
What does attribution look like the morning after?
There is no attacker. This is a self-inflicted exposure, and the honest categorisation is human error compounded by a process gap.
Accidental publication is more common than the breach headlines suggest and tends to be underreported, because there is no ransom note to force the disclosure. It surfaces when somebody notices, which may be long after the upload.
What would have changed the outcome?
Inspecting files before they go to a public endpoint. Not reviewing them by eye, which is what failed, but inspecting the contents automatically for the categories that must never be published.
Second, not keeping the raw monitoring responses at all. Diversity monitoring produces statistics. Once the aggregate exists, the individual responses have served their purpose, and a spreadsheet of named individual answers sitting on a shared drive five years later is a liability with no remaining function.
Gyazo found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.
Want to understand the process first? Read our guide to sensitive data discovery .