Sensitive data does not only leak through hackers.
It can leak when a team uploads the wrong file.
That is what makes the Post Office data breach so useful to examine from a workflow point of view. The failure was not complex to understand. An unredacted legal settlement document was mistakenly published online. Names, home addresses and operator status were exposed.
The people affected were not ordinary website users. They were former Post Office operators linked to the Horizon litigation. Many had already been through years of harm, stress, financial damage, criminal proceedings, public stigma, and delayed compensation.
On 3 December 2025, The Guardian reported that the Information Commissioner’s Office had reprimanded the Post Office over the breach. The report said the unredacted document exposed personal details of 502 of the 555 people involved in the successful litigation led by Sir Alan Bates.
The ICO reportedly called the breach “entirely preventable” and said the Post Office had failed to put appropriate technical and organisational measures in place. The weaknesses included a lack of documented policies, no proper quality assurance for publishing documents online, and insufficient staff training on information sensitivity and publishing practices.
This is not only a privacy story.
It is a document workflow story.
If your team publishes reports, consultation documents, settlement records, public submissions, research outputs, evidence packs, client documents, or AI-generated summaries, the lesson is direct. A final publishing step is not enough. You need a controlled route from source document to redaction, review, sign-off and publication. If you need help checking that route, start with Data Use, Reporting & Communication Systems, Traceable Evidence Workflow Support, or Data Collection & Intake Systems.
Who this guide is for
This guide is for: Teams publishing reports, consultation documents, public spreadsheets, research outputs, evidence packs, AI summaries and sensitive documents.
Key takeaways
- Sensitive data can leak through ordinary publishing mistakes, not only cyberattacks.
- Redaction needs version control, second-person review and live-page checks.
- Publishing QA should check risk, not only spelling, formatting and links.
- Sensitive document workflows need clear classification, sign-off and incident response routes.
The current situation
The Post Office was reprimanded by the ICO rather than fined.
According to The Guardian, the ICO had initially considered a fine of up to £1.09 million, but decided the breach did not meet the threshold for an “egregious” public-sector fine under its approach to fining public-sector bodies.
That decision was criticised by the Open Rights Group, which argued that a reprimand was too weak given the harm already experienced by the people affected.
The breach itself took place in June 2024. At the time, The Guardian reported that the Post Office had accidentally published names and addresses of people involved in the Horizon litigation on its corporate website.
The document was removed, the Post Office apologised, and the matter was referred to the ICO.
The December 2025 reprimand matters because it gives the incident a clearer systems lesson. The issue was not only that one person made a mistake. The issue was that the organisation did not have enough workflow control around online document publishing.
For teams handling sensitive information, that distinction matters.
A mistake happens at a moment in time. A workflow failure explains why the mistake was possible.
What happened
The Post Office accidentally published an unredacted legal settlement document on its website.
The document reportedly included names, home addresses and operator status for 502 of the 555 people involved in the successful litigation action against the Post Office led by Sir Alan Bates.
That litigation was part of the wider Horizon scandal, where sub-postmasters and operators were wrongly pursued after faulty Horizon IT data made it appear that money was missing from branches.
The data breach therefore landed on people who had already been harmed by an information system.
That is the cruel part of the incident.
First, faulty system evidence contributed to wrongful accusations and prosecutions. Then, years later, a document publishing failure exposed personal details of people linked to the litigation.
Different failure. Same underlying pattern.
Information was treated without enough care.
The main point
The Post Office data breach shows that document publishing needs a QA workflow.
Redaction is not only a legal or privacy step. It is a workflow step.
Online publishing is not only a communications task. It is a controlled release process.
A sensitive document should not move from working file to public website through informal judgement, email attachments, unclear filenames or last-minute checks. There should be a defined route.
That route should answer:
Which version is approved for publication?
Has personal data been removed?
Who checked the redaction?
Who checked the metadata?
Who confirmed the file is the public version?
Who approved upload?
Who checked the live page?
What happens if the wrong document is published?
Who owns notification and correction?
If those questions are not answered before publication, the organisation is relying on memory and habit.
That is not enough when the document contains personal data.
This is why source traceability in evidence-heavy reports matters beyond research and reporting. It is also part of document control. A team should be able to trace which file was used, which version was approved, who reviewed it, and where it was published.
Where the workflow failed
1. The legal settlement document entered the publishing route without enough control
The starting point was a legal settlement document.
That kind of document carries obvious sensitivity. It may contain names, addresses, legal status, compensation details, settlement terms, case references, signatures, or other personal information.
A document like that should not be treated like ordinary website content.
Before it enters a public publishing route, it should be classified.
At minimum, the workflow should identify:
document type
sensitivity level
personal data fields
redaction requirement
owner
reviewer
publication purpose
approved public version
publication location
sign-off status
Without that structure, the publishing team may only see a file to upload. They may not see the risk inside the file.
This is why a source register for an evidence-heavy report is useful. It gives a team a controlled record of source material, ownership, status and use. The same logic can apply to sensitive documents moving towards publication.
2. Redaction was not controlled through a clear review process
Redaction is not only blacking out text.
It is a decision process.
The team needs to know what must be removed, what can remain, what legal basis applies, who has authority to decide, and how the redacted version is checked.
A weak redaction process can fail in several ways:
the wrong file is redacted
the redaction is incomplete
hidden metadata remains
an old version is uploaded
a working version is mistaken for the public version
no one checks the final file after export
the live version is not reviewed after upload
That last point matters.
A document can be correct in the working folder but wrong on the website. The publishing process has to check the live output, not only the file before upload.
For evidence and reporting teams, this is similar to checking whether a report table still matches the spreadsheet, whether a quote still links to the correct source, or whether a public submission summary still reflects the original comment.
A source-linked evidence table helps with that kind of checking because it connects final claims and outputs back to the underlying material.
3. Version control was not strong enough
The simplest explanation for this type of breach is often version confusion.
There may be an internal version, a legal version, a redacted version, a reviewed version, a signed-off version, and a public version.
If those versions are not named, stored and approved clearly, the risk of uploading the wrong file increases.
Version control should not depend only on filenames like:
final
final final
redacted
approved
upload version
latest
clean copy
Those names are not enough when sensitive personal data is involved.
A safer workflow uses structured file naming, folder separation, approval status and final publication checks.
For example:
Internal working file
Legal review file
Redacted review file
Approved public file
Published file record
The final public file should be stored separately from working versions. It should have a clear owner and a sign-off record.
This is not complicated software. It is disciplined workflow design.
4. Publishing quality assurance was missing or too weak
According to The Guardian’s report, the ICO highlighted the lack of documented policies or quality assurance for publishing documents online.
That is the clearest workflow lesson.
Publishing QA should not only check spelling, formatting and broken links. It should check risk.
For sensitive documents, the publishing checklist should include:
correct document version
personal data removed
redactions checked
metadata checked
filename checked
access permissions checked
legal or privacy sign-off recorded
publication page checked
live file opened after upload
rollback process known
incident contact identified
A publishing workflow that skips those checks may work most of the time. But when it fails, the harm can be serious.
The Source Traceability Risk Checker is useful for teams that need to test whether they can trace an output back to its source and review status before it is used or published.
5. Staff training did not match the sensitivity of the work
The ICO reportedly found insufficient staff training and no specific guidance on information sensitivity or publishing practices.
That is not a minor point.
People cannot follow a process they have not been given.
If a communications, publishing, admin or project team handles sensitive files, they need practical guidance. Not a long policy no one reads. Practical guidance.
They need to know:
what counts as personal data
what counts as sensitive material
which documents need extra review
who approves publication
how to identify public and non-public versions
how to check redactions
how to escalate uncertainty
what to do if the wrong file is published
Training should be tied to the actual workflow, not only the legal rule.
6. The impact fell on people who had already been harmed
This is what makes the breach more serious.
The affected people were linked to the Horizon litigation. Many had already been through a long process of wrongful accusation, financial damage, legal pressure and public exposure.
A data breach in that context is not abstract.
It can create fear, anger, embarrassment, safety concerns, renewed media attention and further loss of trust.
A sensitive workflow should take that context into account. The same data field can carry different risk depending on the person and the situation.
A name and address in an ordinary mailing list is one kind of risk. A name and address linked to litigation, criminal accusations or public scandal is another.
That is why sensitive document handling needs judgement, not only process.
What should have happened
No publishing process can remove every possible human mistake. But a stronger workflow can reduce the chance that the wrong document reaches the public website.
The document should have been classified before publication
The document should have been treated as sensitive before it entered the publishing route.
That classification should have triggered extra controls.
A basic classification process would ask:
Does the document contain personal data?
Does it contain addresses, contact details or legal status?
Does it identify vulnerable or previously harmed people?
Is it linked to litigation, complaints, compensation or disciplinary matters?
Does it need legal or privacy review?
Is a redacted public version required?
Who signs off the final version?
If the document is sensitive, it should not follow the same route as ordinary website content.
A redaction checklist should have been used
A redaction checklist should cover both visible text and hidden risk.
That includes:
names
addresses
contact details
signatures
reference numbers
case status
document metadata
comments
tracked changes
embedded files
file properties
previous versions
The checklist should be completed by one person and reviewed by another.
For high-risk documents, a second-person check is not excessive. It is basic risk control.
The public version should have been separated from working versions
The file approved for upload should have been stored in a controlled public-release folder.
Working files should not sit beside publishable files without clear status labels.
The workflow should make it difficult to upload the wrong file.
This can be done with simple controls:
separate folders for internal and public documents
fixed naming rules
protected final files
approval status fields
publication log
uploader and reviewer roles
final live-page check
A practical data use, reporting and communication system can include these kinds of controls when teams turn source material into public-facing documents, dashboards, microsites, reports or briefing outputs.
The live upload should have been checked
The workflow should not end when the file is uploaded.
Someone should open the live document from the public website and check that the correct file is visible.
That final check should be recorded.
It sounds simple. But many avoidable publishing errors happen because teams check the file before upload and never check the live version after upload.
For sensitive material, the live check is part of the control environment.
There should have been a prepared incident route
If the wrong file is published, the team needs to act quickly.
The incident route should cover:
removing the file
preserving evidence of what happened
identifying affected people
notifying internal owners
notifying the regulator if required
notifying affected people where needed
preparing a public statement
recording decisions
reviewing the workflow
changing the process so it does not repeat
The ICO’s UK GDPR data breach reporting guidance says organisations should give accurate breach information, report where required, assess risk to people, notify affected people where risk is high, and reflect on lessons learned after a breach.
That guidance is useful because it shows the response needs structure. It is not enough to apologise and remove the document.
What this shows about weak document workflows
The Post Office breach shows that document failures often look simple from the outside.
The wrong file was uploaded.
But the underlying questions are more serious.
Why was the unredacted version available for upload? Why was there not a clear public version? Why did the workflow not force redaction review? Why was there no strong publishing QA? Why was staff training not specific enough? Why were affected people exposed again after the Horizon scandal?
That is the difference between a mistake and a workflow failure.
A mistake explains what happened. A workflow failure explains why it was allowed to happen.
This applies to many teams outside the Post Office.
A public-sector team can publish the wrong consultation spreadsheet. A research team can share a transcript with identifying details still inside. A donor-funded programme can circulate a case study with names that should have been removed. An HR team can attach the wrong file to an email. A service business can upload a client document into a public folder. An AI assistant can be given access to documents that were never approved for wider use.
The issue is not only the document. It is the route the document follows.
How a stronger workflow could have reduced the risk
A stronger workflow would not guarantee that no document mistake ever happens.
But it could reduce the chance that an unredacted settlement document is published online.
A stronger workflow would include:
document classification
source and owner fields
sensitivity flags
version control
redaction checklists
second-person review
public-release folders
sign-off records
publishing QA
live-page checks
incident response steps
staff guidance tied to the real workflow
The purpose is not to slow every publication down. The purpose is to identify documents that need extra care.
Not every document needs legal review. Not every web update needs a second-person check. Not every file is high risk.
But when a document contains personal data linked to litigation, compensation, criminal accusations or public harm, the workflow must change.
That is where many organisations fail. They treat sensitive documents as if they are ordinary content.
What this means for research, policy, donor reporting and evidence work
The Post Office data breach is about a legal settlement document, but the lesson applies across evidence-heavy work.
A policy team may publish a submissions table with names, email addresses or identifying comments still visible.
A research team may circulate interview excerpts without removing participant identifiers.
A donor-funded programme may include a case story that exposes a beneficiary.
A public consultation team may upload the wrong response matrix.
A report writer may paste a quote into a public report without checking consent or attribution rules.
A team building an AI knowledge base may upload working files that include confidential notes, personal data or internal review comments.
In each case, the problem is not only privacy. It is workflow design.
The team needs a controlled route from source material to public output.
That route should include source tracking, sensitivity flags, review notes, allowed-use rules, redaction checks and final sign-off.
This is why how to prepare documents for AI retrieval matters before a team uploads material into an AI system. The same preparation logic applies before a team publishes documents, shares evidence or builds a searchable internal library.
If the source material is messy, AI can give weak or risky answers because the tool is working from poorly controlled inputs.
Where my work fits
My work helps teams move from messy information to structured systems, faster analysis, clearer reports and better decisions.
In a document publishing or evidence workflow, that can include:
source registers
document inventories
file naming rules
folder structures
review status fields
sensitivity flags
redaction checklists
public-release workflows
issue logs
source-linked evidence tables
QA checklists
handover notes
AI-ready document preparation
The goal is not to replace privacy, legal, cybersecurity or communications teams.
The goal is to build the working structure around the information so the right people can review, check, publish and respond with less risk.
My Local Government White Paper evidence workflow case study shows how public submissions, claims coding, synthesis, drafting support and review comments can stay connected instead of being split across folders, notes, tracked changes and one-off summaries.
The UNICEF Zambia child poverty evidence workflow shows how narrative case material can be structured into a spreadsheet-first evidence workflow with quote-per-claim checks.
The UNICEF Palestine situation analysis case study shows how scattered qualitative material can be rebuilt into a retrieval, recommendation and drafting workflow under deadline pressure.
Different sectors. Same principle.
The final document is only as safe as the workflow behind it.
FAQ
What was the Post Office data breach?
The Post Office data breach involved the mistaken online publication of an unredacted legal settlement document linked to the Horizon litigation.
The document reportedly exposed names, home addresses and operator status for 502 of the 555 people involved in the successful litigation led by Sir Alan Bates.
Was the Post Office fined by the ICO?
No. The Post Office was reprimanded by the ICO rather than fined.
The Guardian reported that the ICO had initially considered a fine of up to £1.09 million, but decided the breach did not meet the threshold for an egregious public-sector fine under its approach to public-sector penalties.
Why did the ICO reprimand the Post Office?
The ICO reportedly found that the Post Office failed to put appropriate technical and organisational measures in place to protect personal information.
The weaknesses included missing documented policies, weak or missing quality assurance for publishing documents online, and insufficient staff training on information sensitivity and publishing practices.
What personal data was exposed?
Reporting said the exposed information included names, home addresses and operator status of people involved in the Horizon litigation.
That made the breach especially sensitive because the people affected had already experienced harm linked to the Horizon scandal.
Why does this breach matter?
It matters because it shows that sensitive data can be exposed through ordinary publishing mistakes, not only through cyberattacks.
A wrong file upload, weak redaction process, poor version control or missing final review can create a serious data breach.
What is a document publishing QA workflow?
A document publishing QA workflow is the controlled process used to move a document from working file to public release.
It should include document classification, redaction checks, version control, review status, sign-off, metadata checks, upload checks and a live-page review after publication.
Why is redaction not enough by itself?
Redaction is only one part of the process.
The team also needs to make sure the correct version is redacted, hidden metadata is checked, working versions are separated from public versions, the file is approved for release, and the live website shows the correct document.
What is the workflow lesson from the Post Office breach?
The lesson is that a document can be technically available for publication while still being unsafe to publish.
Sensitive documents need source tracking, version control, redaction review, publishing QA, sign-off and incident response steps before they go live.
How does this relate to evidence-heavy reports?
Evidence-heavy reports often contain quotes, submissions, interview excerpts, case studies, personal details, internal comments and source references.
If the workflow is weak, sensitive material can move from working files into public outputs without proper review.
How does this relate to AI knowledge bases?
AI knowledge bases often start with document uploads.
If working files, unredacted documents or sensitive source material are uploaded without review, the AI system may expose, summarise or retrieve material that should not be used.
That is why teams should prepare documents properly and run an AI knowledge base QA process before use.
How can organisations avoid this type of breach?
Organisations can reduce the risk by using document classification, sensitivity flags, file naming rules, redaction checklists, second-person review, public-release folders, approval records, publishing QA, live-page checks and breach response workflows.
The aim is to make the wrong upload harder to do and easier to catch.
Who can help audit a document publishing or evidence workflow?
I help teams audit and rebuild workflows that move from raw documents to reports, public outputs, AI knowledge bases, evidence tables, public submissions analysis and decision support.
If your team needs to check whether its current process can survive review, correction, breach response or public scrutiny, contact me here.
A useful next step
If your team publishes reports, consultation documents, public spreadsheets, settlement records, research outputs, donor evidence, case studies, AI summaries or internal documents, ask three questions:
Can we identify which version is approved for publication?
Can we prove that sensitive information was checked before release?
Would we know exactly what to do if the wrong file was published?
If the answer is no, the issue is not only publishing. It is workflow design.
Use the Source Traceability Risk Checker to test where the review trail may break. Use the Search and Review Time Savings Calculator to estimate the hidden cost of searching, checking and reconstructing source material after the fact.
A weak document workflow can become a public data breach, a trust problem, a legal risk or an expensive correction exercise. If your team needs to check whether its document, evidence, AI, reporting or publishing workflow is safe enough, get in touch. I can help audit the current process, identify the main risk points and build a clearer route from source material to controlled publication.
Sources used in this guide
These sources were used to ground the facts of the case. The workflow analysis is my own.
Used for factual background and source context.
Read sourceUsed for factual background and source context.
Read sourceUsed for factual background and source context.
Read sourceData Collection & Intake Systems
Collect useful, traceable data from the start through forms, fieldwork tools, public submission portals, partner reporting systems, calculators, and intake workflows.