PSNI made an FOI spreadsheet a workforce-safety

Summary

On 8 August 2023, a freedom-of-information response published by the Police Service of Northern Ireland contained a source worksheet with workforce information for 9,483 officers and staff. The workbook was online for just under two and a half hours. It did not include home addresses, but it combined identifiers, roles, organisational units and work locations in a security context where aggregation materially increased risk.
The public record does not support a “single spreadsheet mistake” explanation. An HR export remained inside the release entity; checks concentrated on the visible response; information ownership, risk assessment, role-specific training, classification and final-artifact assurance were weak; and several people could review the file without anyone proving that the binary entity contained only the fields authorised for publication.
The Information Commissioner’s Office found negligent infringements of UK GDPR Articles 5(1)(f), 32(1) and 32(2). It calculated a £5.6 million penalty, reduced it to £750,000 under its public-sector approach. The ICO also recorded serious potential harm, widespread fear and loss of control, while stating that it had not seen evidence of physical injury caused by the incident.
Durable accountability is measurable. A public authority should create a new minimal release artifact, inspect hidden content and metadata, require independent approval of the exact binary entity, retain hashes and decision evidence, test recall, support affected people, and distinguish management-reported action completion from independent validation. Transparency and safety become compatible when the release pipeline is designed as a controlled production system.

A public release entity, not a visible table

The PSNI disclosure is easy to compress into a familiar warning: someone sent the wrong spreadsheet. That description is factually thin and managerially dangerous. It treats the visible moment of failure as though it were the whole control system. The more useful question is how a working data product, created from a sensitive human-resources system, remained intact long enough to become a public information product. That path included extraction, transformation, format selection, review, approval, publication and recall. Each stage had an owner or an opportunity for control.

The failure reached the public only because the stages did not collectively prove that the final entity was safe.

The event began with a legitimate transparency function. On 3 August 2023, PSNI received a freedom-of-information request seeking numerical information about officers and staff by rank or grade. The request did not require a list of names, service numbers or individual work locations. A response could have been generated as a small statistical table. Instead, the working method began with a much richer extract from the organisation’s SAP human-resources environment. That extract was used to build a pivot table and a response tab. The richer source remained inside the workbook as the file moved toward publication.

The independently led review reconstructed the sequence in unusual detail. The person preparing the response removed visible worksheets considered unnecessary but did not remove the worksheet containing the source download. Interface dots indicated that additional tabs existed, yet the source content was not detected. Further checks by human-resources and information-handling staff concentrated on the visible response. Communications staff also viewed what appeared on screen. At 14:32 on 8 August, the workbook was published. It remained online for almost two and a half hours before removal.

The copy contained 32 columns. The final ICO notice explains the apparent numerical difference in the public record: one column was unused, so the regulator described 31 information fields. The data covered 9,483 officers and civilian staff. It included combinations such as surname, initials, service or staff number, rank or grade, role, organisational unit, post location, duty information, contract information and gender. Home addresses were not included. That boundary matters both for accuracy and for risk analysis.

The incident should not be exaggerated by adding unsupported data fields; neither should its seriousness be reduced merely because addresses were absent.

Risk arose from combination and context. A field that appears ordinary in isolation can become highly consequential when joined to a named workforce, organisational structure and work location. The file effectively connected identities to the operating map of a police service. It could support unwanted contact, intimidation, pattern analysis or targeting. PSNI stated that the dataset had reached dissident republican hands and used that assessment in its response planning. That statement belongs in the record as an attributed security assessment.

The public evidence reviewed here does not identify every downloader, every redistribution path or the intention of each person who obtained a copy.

This distinction between visible content and file content is the core accountability lesson. A spreadsheet is not only the cells a reviewer sees. It is a container that may include additional worksheets, formulas, comments, named ranges, filters, cached values, links, metadata and historical structure. A review that asks “does the displayed answer look correct?” is different from a review that asks “is this exact binary entity authorised for public release?” PSNI’s process allowed the first question to be asked several times without requiring a defensible answer to the second.

The timeline shows a system, not an isolated click

The immediate chain matters because it allocates control. The FOI request moved from the corporate information function to human resources because HR held the workforce data needed to answer it. A rich SAP output was then used as the basis for aggregation. Creating a pivot table was operationally convenient: it enabled counts to be generated without building a dedicated reporting interface. But convenience imported the sensitivity of the source system into the disclosure workflow. The same workbook became both a private analytical environment and the candidate public response.

That dual use created a predictable hazard. A working file accumulates material that helps its author calculate, reconcile and inspect. A release artifact should contain only material authorised for the recipient. When those purposes occupy the same entity, deletion becomes the security boundary. Every surplus worksheet, field and metadata item must be found and removed. The process is therefore only as strong as the reviewer’s awareness of all embedded content and the software’s ability to make it visible. A clean generation step reverses the burden: it starts empty and adds only approved output.

The evidence also shows why “four eyes” is not a complete control description. Several people can look at one file while sharing the same blind spot. If each reviewer opens the workbook in the same application, lands on the same visible tab and checks the same presentation, the reviews are sequential but not independent. Independence requires a different question, a different method or both. One reviewer might reconcile the answer to the request; another should inspect the package structure, enumerate worksheets, scan metadata and compare the final file against a field-level release specification.

The publication channel further changed the risk. Sending a file to one authenticated recipient is not equivalent to placing it on a public website. Public release removes practical control over copying and redistribution almost immediately. A short exposure window can limit opportunity, but it cannot guarantee retrieval. Removal is necessary containment, not erasure. Therefore the approval threshold should rise with audience size, data sensitivity, security context and irreversibility. The review found no sufficiently mature mechanism that translated those factors into a release decision for this workbook.

The incident response began quickly once the disclosure was recognised. The workbook was removed, internal command structures were activated, workforce communications began and threat-management support expanded. Yet recall could only act on the original publication point. Copies already downloaded were beyond ordinary technical withdrawal. That asymmetry explains why pre-publication prevention deserves more weight than post-publication recovery. A public authority can correct a web page; it cannot reliably recall a personal-data file from every device, message thread or private archive.

The timeline also exposes a classification problem. The data came from a system whose records had obvious workforce and security significance, but the file did not carry a control state that forced exceptional handling throughout its life. The independently led review discussed inconsistent classification, outdated instructions and a lack of automated labelling. Random or uninformative filenames further weakened the visual cues on which staff might otherwise rely. Classification that exists only as policy prose is not a control unless it travels with the entity and changes what users and systems may do.

No single observation excuses individual care, and the final regulator notice described the infringements as clearly negligent. But negligence at organisational scale can be produced by ordinary work conducted inside an unsafe design. An analyst is asked to answer quickly, uses a familiar tool, removes visible working tabs, passes the file to colleagues and receives no machine or procedural warning. If the organisation then calls the outcome human error, it misses the controls that made the error both likely and catastrophic. Accountability is not diluted by examining the system. It becomes more precise.

Why the data became a workforce-safety issue

The affected population was not homogeneous. It included officers and civilian staff in different roles, units, locations and personal circumstances. Their exposure also differed. Some identities were already publicly associated with policing; others were deliberately kept private. Some people lived or worked in circumstances where occupational disclosure created acute concern for them or their families. Staff-association evidence described changed routines, concealment of occupation, anxiety, relocation questions and loss of trust.

Those accounts are important, but they should not be converted into a claim that every affected person experienced the same outcome.

The ICO’s harm analysis provides a disciplined boundary. It identified fear, anxiety and loss of control as common forms of actual damage at differing levels. It also considered severe potential consequences because the data related to a police workforce operating under a known threat. At the same time, the notice stated that the Commissioner had not seen evidence of physical injury resulting from the breach. A credible account holds both facts together: the potential harm was exceptionally serious, documented psychological effects were widespread, and the reviewed record did not establish a resulting physical attack.

Emergency Threat Management Group referrals help show the scale of support demand without serving as a proxy for injury. A government statement recorded 3,954 self-referrals by 30 August 2023. The final ICO notice recorded 4,024 by 18 October and included dated red, amber and green assessment snapshots. Those figures describe people seeking or receiving assessment at particular times. They do not prove that thousands of attacks occurred, and the colour categories should not be treated as permanent labels. They show how a data-governance failure consumed operational security capacity.

The incident extended beyond the individual employee. Families had to consider what occupational information was now public. Managers had to alter identifiers and communications. Threat teams had to assess cases. The service had to investigate distribution while maintaining ordinary policing. Oversight bodies had to test welfare, equality and human-rights consequences. A release-control failure therefore became a continuity problem: resources intended for public safety were redirected toward protecting the organisation’s own workforce and rebuilding confidence in its information handling.

The service-number issue illustrates data devaluation as a response tool. An identifier may not be a secret in the cryptographic sense, but it can connect records or facilitate social engineering. Replacing externally used service numbers with PINs reduced the future value of one exposed field. That is useful mitigation. It does not remove names, ranks, roles or historic locations from copies already circulating. Good remediation separates what can be invalidated, what can be corrected, what must be monitored and what remains permanently outside the organisation’s control.

Support also creates an evidence obligation. Offering up to £500 for personal security measures was a concrete intervention, but oversight still needs aggregate evidence about eligibility, uptake, response time, accessibility and whether assistance matched assessed risk. Trust likewise depends on visible, sustained changes to ownership, training, escalation and assurance—not simply on removing the original file.

The regulator’s finding: security had to match the context

The final ICO monetary penalty notice is the controlling legal record for the data-protection findings. It concluded that PSNI infringed the integrity and confidentiality principle in Article 5(1)(f) and the security obligations in Articles 32(1) and 32(2) of the UK GDPR. The relevant period extended from 25 May 2018 until 14 June 2024 because the regulator assessed not only the publication event but the organisational measures governing this class of processing.

The notice did not characterise the event as intentional. It found the infringements clearly negligent. That distinction prevents an unsupported narrative of deliberate disclosure while preserving the seriousness of the control failure. A controller responsible for a sensitive workforce cannot wait for an incident to discover that routine FOI handling relies on rich HR exports, incomplete instructions and visible-tab checking. Risk assessment, procedure, training and verification must exist before a particular request exposes the weakness.

The regulator’s analysis concentrated on measures appropriate to risk. The personal information belonged to an identifiable police workforce in Northern Ireland. The consequences of unauthorised disclosure could include intimidation or targeting, so ordinary office-file habits were not an adequate baseline. The notice found that PSNI could not demonstrate a suitable assessment of this processing risk and identified deficiencies in procedures and staff training. Security was not satisfied merely because access to the HR system itself was controlled. The relevant processing included what happened after data left that system.

This is an important governance boundary. Organisations often secure the system of record and then treat exported data as the user’s responsibility. Yet an export may be easier to copy, harder to monitor and stripped of the access controls that protected the source. If export is an authorised business function, the organisation remains responsible for the downstream workflow. That means recording the purpose, minimising fields, controlling storage, limiting reuse, applying retention, inspecting release entities and preserving logs sufficient to prove what happened.

The penalty calculation also needs careful presentation. The ICO calculated a £5.6 million amount and then applied its public-sector approach, reducing the imposed monetary penalty to £750,000. Those are alternative stages in one enforcement calculation, not two costs. The reduction reflected the regulator’s policy about how fines affect public bodies and public services. It did not reverse the legal findings or declare the harm minor.

The ICO had provisionally proposed an enforcement notice as well as a fine. By 14 June 2024, PSNI had supplied updated instructions, an audit log, a quality-assurance checklist and a spreadsheet policy. The Commissioner concluded that the relevant hidden-data processing safeguards had been remedied, so there were no grounds to proceed with that proposed notice. The monetary penalty remained. This sequence is useful because it distinguishes stopping a specific unsafe practice from closing an entire reform programme.

A control can be adequate for one identified failure mode while broader governance work remains open. Updated FOI instructions may prevent surplus worksheets from being published. They do not by themselves replace an ageing HR platform, create reliable information-asset ownership, improve every DPIA, strengthen the Data Protection Officer’s senior access, build a data strategy or change organisational culture. The final penalty notice should therefore be read as evidence of a remedied release-path safeguard, not a certificate that all 37 independent-review recommendations were complete.

Responsibility follows practical control

Accountability in this case should not be assigned by visibility alone. The employee who prepared the file was close to the final error, but proximity is not the same as exclusive control. Senior leadership controlled governance design and resources. Human-resources leaders controlled the data product and the methods available to staff. Corporate information leaders controlled the FOI process and publication standard. Assurance functions controlled challenge, monitoring and escalation. Technology owners controlled the export environment and possible guardrails. The Policing Board controlled an external layer of scrutiny.

The ICO controlled statutory investigation and enforcement.

Senior leadership’s responsibility begins with risk appetite. A police service may decide that spreadsheet tools are necessary for flexible work, but that decision requires compensating controls proportional to sensitivity. Leadership should know which processes export whole workforce datasets, which publication channels can receive those files, and whether control owners can demonstrate effective review. The absence of a consolidated view is itself a governance signal. Risk cannot be accepted responsibly if the organisation cannot enumerate the pathway.

Information ownership is the next layer. An Information Asset Owner should be able to state what the dataset is for, who may use it, which fields are especially sensitive, which exports are permitted and how public disclosure must be generated. Ownership is not a name in a register. It is a recurring obligation to review uses, approve controls, resolve exceptions and produce evidence. The independent review’s attention to ownership and data maturity shows that the workbook failure sat inside a wider problem of treating data as a by-product rather than an operational asset.

The FOI function controls a different obligation. It must facilitate lawful transparency, apply exemptions where justified and answer accurately. It should not be asked to become an expert in every source system. Instead, the workflow should make a safe answer the default. A request for counts should produce a counts-only entity. The disclosure team should receive a release candidate with a field specification and provenance, not a working environment whose safety depends on knowing how HR constructed it.

Human resources controlled the extraction and transformation method. That does not mean every HR employee was responsible for system architecture. It means HR management had the capability to replace recurring whole-dataset exports with bounded reports, templates or controlled queries. It could define when a full extract was necessary, where it could be stored, how it would be labelled and how it must be destroyed. It could also require peer review that compares the requested fields with the released fields rather than merely checking the arithmetic.

Technology owners controlled machine-enforceable options. An ageing, heavily customised SAP environment limited some choices, but it did not eliminate the need for safeguards. Exports could be placed into controlled locations, automatically labelled, logged and prevented from reaching public channels without an exception. A secure conversion service could accept approved values and produce a new output. File-analysis tooling could enumerate worksheets and metadata. Where automation was unavailable, the risk should have been visible on a funded change plan, not left as an implicit burden on ordinary staff.

The Data Protection Officer and Senior Information Risk Owner had assurance responsibilities. The review raised questions about direct senior reporting, risk assessment, records of processing and data-protection impact assessment practice. A DPO cannot personally inspect every FOI response. The role should test whether the system identifies high-risk processing, whether control owners provide evidence and whether exceptions reach leadership. The SIRO should connect those findings to resources and risk registers.

Elevating the SIRO role to Deputy Chief Constable level after the incident strengthened the formal position; effectiveness still depends on challenge, information and follow-through.

Training sits across all layers. Generic annual modules can create awareness but rarely build skill in file formats, hidden data, classification or release verification. Role-specific training should use realistic tasks and require demonstration. A person who publishes documents should be able to inspect a workbook’s structure, remove metadata, identify when a safer format is needed and escalate uncertainty. Managers should be able to interpret control evidence. Training completion rates are inputs; tested competence and error trends are outcomes.

External oversight has a separate purpose. The Northern Ireland Policing Board jointly commissioned the independent review and undertook to monitor the response. Its value lies in preventing management’s action list from becoming the sole measure of success. Oversight can ask whether employees experience the controls as usable, whether funding matches the risk, whether completion evidence is independent and whether unresolved items have clear owners and dates. It should also preserve boundaries: public reporting must not disclose new security-sensitive details in the name of accountability.

The deeper governance weaknesses

The independently led review grouped 37 recommendations into five areas: organisational governance and accountability; taking responsibility; foundations; data sharing and use; and culture, skills and talent. That breadth was not decorative. It reflected a conclusion that the disclosure was both a specific process failure and a symptom of institutional weaknesses. Fixing only the missed worksheet would leave the conditions that produced it.

Governance structures matter because data crosses departmental lines. HR owned the source, the information branch owned the request, communications enabled publication, technology supported the tools, and security teams absorbed the consequences. Without a body that sees the whole path, each unit can report local compliance while the handoffs remain unsafe. The later Service Data Board was intended to create that cross-organisational view. Its effectiveness should be assessed through decisions, resolved risks and control evidence, not meeting frequency.

The records-of-processing and DPIA issues are equally practical. A record of processing activities should reveal that workforce data is exported for statistical and disclosure purposes, identify recipients and safeguards, and make ownership visible. A DPIA or equivalent risk assessment should address aggregation, threat context, publication irreversibility and the effect on employees. If those records are incomplete, the organisation loses an early opportunity to redesign the workflow before an incident.

Audit weakness compounds the problem. The review discussed low engagement with audit activity and the danger of reporting actions as complete when the underlying change was not embedded. A traffic-light status can conceal ambiguity. “Green” might mean a policy has been approved, staff have received it, a control has been deployed, testing has passed, exceptions are monitored or an independent reviewer has confirmed effectiveness. Those are different states. Closure criteria should be defined before work begins and supported by artefacts that an outsider can reperform.

The data-protection function’s position is also material. Independence is not achieved by a job title alone. The DPO needs timely access to senior decision-makers, visibility of high-risk processing and freedom to escalate. A reporting chain that filters uncomfortable findings weakens accountability. At the same time, the DPO should not become the owner of every operational risk; business leaders remain responsible for their processing. Good design separates ownership from independent advice and challenge.

The SAP environment represented technical debt with governance consequences. The review described a heavily customised, on-premises system approaching end of life and serving multiple organisational functions. Technical debt does not automatically cause a disclosure, but it narrows safe options, encourages manual extracts and makes change expensive. A replacement business case should therefore value avoided control exposure and staff effort, not only software features. Funding delays must remain visible as accepted residual risks with accountable owners.

Classification weakness shows how policy and tooling interact. Old instructions, inconsistent labels and the absence of automatic classification made sensitivity easier to lose as data moved. A label is useful only if people understand it and systems enforce meaningful consequences. For a workforce extract, those consequences could include restricted storage, disabled external sharing, mandatory expiry and a block on public-web upload. False confidence is a risk: a label that displays a warning but permits unrestricted movement may satisfy a checklist while changing little.

Culture connects these mechanisms. A passive compliance culture asks whether a form was completed. An active assurance culture asks whether the control changes the outcome under ordinary pressure. Staff should be able to report unsafe workarounds without blame, and leaders should treat recurring manual steps as design signals. Learning is not a promise to be more careful. It is a change that can be observed, measured and sustained.

Build the public answer from zero

The strongest technical and procedural lesson is to separate the working data product from the release artifact. For the PSNI request, the authorised output was a small set of aggregated counts. A safer pipeline would execute an approved query or calculation, write only those counts into a new empty document, and reject any field not present in the release specification. The original export would never become a candidate for publication.

Starting from zero changes the failure model. In a subtractive process, safety depends on finding every surplus element. In an additive process, a field must be explicitly selected before it can appear. The output can still be wrong, so it needs reconciliation, but the risk of carrying an entire source worksheet is sharply reduced. The method also creates a clear boundary for testing: compare the final artifact with the allowed schema and fail closed when anything else exists.

Format choice should follow the audience and content. A PDF can reduce casual editing but may retain metadata, attachments or hidden layers. A CSV can eliminate worksheets but may expose every exported column. A web table may be appropriate but can still contain hidden markup or cached data. No format is inherently safe. The control is verified minimisation of the exact final entity, combined with appropriate accessibility and usability.

A release pipeline should preserve provenance without exposing sensitive content. The record can identify the request, source system, approved query or aggregation, field specification, preparer, reviewers, publication destination and retention rule. It can store a cryptographic hash of the approved entity. At publication, the system recomputes the hash and refuses an altered file. This does not prove that the approved entity was substantively correct, but it proves that the entity reviewed is the entity released.

Independent review should be genuinely diverse. One reviewer confirms that the answer satisfies the request and applicable disclosure law. Another verifies the file structure and data-minimisation rule using a separate method. For high-risk releases, a third control may sample the source-to-output calculation or approve the security risk. Roles should be assigned before work starts, and the system should prevent a preparer from self-approving.

Automated checks can improve consistency. A workbook scanner can enumerate tabs, including very hidden states, inspect named ranges, detect personal-data patterns, identify external links and extract document metadata. A policy engine can compare the result with an allowed schema. Yet automation should remain bounded. Pattern matching can miss unusual identifiers and can flag harmless data. The accountable control is the combination of machine inspection, human judgement and a clear escalation path.

Release channels need their own safeguards. A public content system should accept only approved formats from a controlled location, record the uploader and hash, apply a short review delay for sensitive categories and retain the previous version for evidence. It should support an emergency unpublish function that removes the asset and linked caches as far as technically possible. A tested contact tree should notify security, privacy, communications, legal, workforce support and external oversight without waiting for improvised escalation.

Post-release monitoring closes the loop. For a limited period, the organisation can verify that the public page serves the expected hash, scan for unauthorised mirrors where lawful, monitor reports and confirm that the source working file has been deleted or retained according to policy. Monitoring does not promise universal recall. It improves detection and preserves evidence. The release log should show when monitoring ended and who accepted the residual risk.

Exceptions must be controlled rather than banned rhetorically. There will be cases where a spreadsheet is the best accessible format or where complex data must be published. The requester should document why the normal minimal-output route does not work, identify the extra risks and obtain an independent approval. The exception should expire. Recurring exceptions signal that the standard service needs redesign or investment.

Measure remediation, do not count announcements

The public record contains several remediation checkpoints. PSNI reported immediate changes, including a move toward PDF-only release in the first response phase, later instructions covering PDF and CSV, updated FOI procedures, an audit log, a quality-assurance checklist and a spreadsheet policy. The final ICO notice accepted that the relevant hidden-data processing safeguard had been remedied by June 2024. Those steps matter because they directly address the route by which surplus data reached the public.

Broader measures followed. The SIRO role moved to Deputy Chief Constable level. A Service Data Board was created. External-use service numbers were replaced by PINs. Security support was offered to the workforce. The annual report organised response activity into investigation and intelligence, reassurance, review and lessons, and communications. These are credible components of a repair programme, but each requires an outcome measure.

By June 2024, a Chief Constable accountability report said 17 recommendations had been completed. In parliamentary evidence in February 2026, witnesses reported 29 complete, several still in train or dependent on funding, and the independent review team returning to validate progress. Witnesses used approximate language about the total number of actions in that later exchange. The original review’s count of 37 recommendations remains the stable reference. The later evidence should be treated as a dated implementation report, not as the awaited final validation.

For each recommendation, a useful closure record should identify the control objective, accountable executive, operational owner, delivery date, evidence, test method, result, exceptions and residual risk. Policy approval alone should not close an item whose objective is behavioural or technical. Training should be tested. A new board should demonstrate decisions. A new export control should be challenged with representative files. A replacement platform should show that the risky legacy pathway is disabled, not merely less popular.

Independent validation is especially important after a high-profile event. Internal teams face pressure to demonstrate progress, and traffic-light reporting can reward optimistic interpretation. An independent reviewer should sample source evidence, reproduce tests and speak with the people who use the process. Findings should distinguish design effectiveness from operating effectiveness: a control may be well designed but inconsistently used, or widely used but incapable of detecting the relevant risk.

Metrics should include near misses. If scanners detect hidden tabs before publication, that is evidence that the control is working and that unsafe files still reach the gate. If the organisation records only successful releases, it loses information about upstream quality. Useful measures include attempted high-risk exports, blocked releases, exception volume, reviewer disagreement, time to resolution, repeat failure modes and actions overdue. Trends should inform training and system investment.

The workforce should have a route to verify that lessons became practice. Aggregate updates can explain which identifiers were changed, how support was used, what independent testing found and which funding-dependent actions remain. Transparency must respect operational security and personal privacy, but confidentiality should not become a reason to publish only untestable assurances. The best accountability report states both what can be evidenced and what cannot safely be disclosed.

Financial figures must retain their labels

The incident produced several public financial numbers, each answering a different question. Parliamentary evidence in September 2023 discussed a £174 million to £217 million scenario associated with recovery and litigation. It was an early estimate under uncertainty, not a final bill. The 2023–24 annual report recorded £6 million of additional immediate funding and a £610,000 accrual relating to the expected regulatory penalty at that reporting date. The final fine was £750,000.

In December 2025, the Northern Ireland Executive committed £119 million toward data-breach costs and settlement negotiations. An allocation provides capacity to meet obligations; it does not prove the value of final individual settlements or the total lifecycle cost. These amounts should never be added into one headline total. Some overlap, some reflect scenarios, some are accounting treatments and some relate to different time periods.

Better financial accountability uses categories. Direct response costs include investigation, communications, security support and technical change. Regulatory cost includes the imposed fine. Legal exposure includes defence and settlement activity. Long-term transformation includes systems replacement and data-governance capability that may serve purposes beyond this event. Opportunity cost includes staff diverted from other policing work. Each category needs an evidence date and a statement about whether the figure is committed, spent, accrued, estimated or settled.

The public-sector penalty reduction introduces a policy tension. A large fine can consume resources needed for remediation and public service, while a small fine may appear disconnected from the seriousness of the failure. The ICO’s approach resolved that tension through an explicit reduction, not by denying the infringement. Oversight should therefore examine both enforcement and funded repair. A reduced fine increases the importance of evidence that resources actually support affected people and durable controls.

A compact accountability standard

The PSNI record supports a practical standard for any organisation releasing data to the public. First, define the authorised answer. A release specification should identify fields, aggregation, audience, format, legal basis, accessibility needs and expiry. Ambiguity should stop the workflow. “Publish the spreadsheet” is not a specification when the spreadsheet is also a working environment.

Second, map the data path. Record the system of origin, transformations, temporary stores, people and tools involved, and the publication destination. Classify sensitivity at source and carry that classification through exports. If a full dataset leaves the system of record, log why, where it goes and when it will be deleted.

Third, generate a minimal entity. Prefer a service that writes approved output into an empty template. Reject surplus fields, worksheets and embedded entities. Treat PDF, CSV and office formats as containers that require inspection, not safety labels.

Fourth, separate duties. The preparer cannot be the final approver. Legal or FOI review should be distinct from technical package inspection. High-risk publication should require an accountable risk owner. Reviewers should record what they tested, not merely that they “checked the file.”

Fifth, bind approval to bytes. Hash the exact release candidate, store the hash with the decision and verify it at upload. Changes after approval should invalidate approval automatically. The public endpoint can be monitored against the expected hash.

Sixth, test for hidden content and metadata. Enumerate worksheets, ranges, links, comments, revisions, attachments, document properties and other embedded structures relevant to the format. Compare detected fields with the allowed schema. Human reviewers should understand the scanner’s limits.

Seventh, make recall operational. Maintain named contacts, authority to unpublish, cache-removal procedures, evidence preservation and notification criteria. Run exercises. Measure the time from report to containment and the destinations that cannot be recalled.

Eighth, support affected people through a defined service. Explain what data was involved and what was not. Provide channels for individual risk questions, protect sensitive support records, track response times and publish aggregate outcome evidence. Do not use absence of physical injury to minimise psychological harm or loss of control.

Ninth, close actions with tests. Every remediation item needs an owner, evidence and independent acceptance criteria. Separate policy issuance, deployment, adoption and effectiveness. Reopen an item when monitoring finds recurrence. Publish dated progress without presenting management assertion as external validation.

Tenth, retain uncertainty. State what is unknown about dissemination, harm, costs and completion. Update estimates without rewriting the historical record. Attribute security assessments to their source. Precision protects affected people and makes accountability stronger, not weaker.

Transparency needs engineering

Freedom-of-information law did not require PSNI to publish its workforce source data. The request sought statistics. The problem was not that a public authority answered a question; it was that the production process did not reliably separate a statistical answer from the sensitive material used to calculate it. Treating transparency as the cause would produce the wrong remedy: less openness rather than safer disclosure.

The incident instead shows that transparency is a data-engineering and governance function. Public bodies routinely hold information whose release may benefit scrutiny, research and trust. They also hold personal and security-sensitive data. A mature system can serve both duties by minimising output, preserving provenance, inspecting the final artifact and recording accountable decisions. That system needs investment, skilled people and senior ownership just as other operational systems do.

The response record contains real progress and unresolved work. The release-path safeguards accepted by the ICO, the Service Data Board, higher-level information-risk ownership, identifier changes and support measures all address parts of the failure. Later evidence that some actions remained in train or funding-dependent is not proof of inaction; it is a reminder that reform spans different timescales. The essential discipline is to keep those states visible until independent evidence supports closure.

PSNI’s workbook became a workforce-safety event because data escaped the boundaries that gave it meaning and protection. It became an accountability test because responsibility was distributed across people, procedures, systems and oversight. The durable answer is not a promise that no employee will ever miss a tab. It is a release system in which a missed tab cannot silently become a public dataset, and in which every claim of repair can be checked against evidence.

Frozen source register

Police Service of Northern Ireland, Independent Review.
Police Service of Northern Ireland and Northern Ireland Policing Board, Protecting From Within: a review of the PSNI data breach 8th August 2023.
Information Commissioner's Office, Police Service of Northern Ireland enforcement record.
Information Commissioner's Office, PSNI monetary penalty notice.
Information Commissioner's Office, PSNI facing a £750k fine following spreadsheet error.
Information Commissioner's Office, New guidance on disclosing documents to the public.
Northern Ireland Policing Board, Publication of the jointly commissioned independently led review.
Northern Ireland Policing Board, Statement on follow-up action.
Northern Ireland Policing Board, Chief Constable's Accountability Report — June 2024.
Police Service of Northern Ireland, Annual Report and Accounts for the year ended 31 March 2024.
UK Parliament Northern Ireland Affairs Committee, Oral evidence: PSNI data breaches, 5 September 2023.
UK Parliament Northern Ireland Affairs Committee, Oral evidence: staff associations, 12 December 2023.
UK Parliament Northern Ireland Affairs Committee, Oral evidence: Northern Ireland Policing Board, 13 December 2023.
UK Parliament Northern Ireland Affairs Committee, Oral evidence: PSNI leadership, 13 December 2023.
UK Government, Secretary of State's speech — PSNI data breach.
UK Government, Information Security Review 2023 Final Report.
Northern Ireland Department of Justice, Statement: PSNI data breach funding allocation.
UK Parliament Northern Ireland Affairs Committee, Oral evidence, 25 February 2026.