ICO reprimand for cyber security failings: what Article 32 actually requires
In short: The ICO’s reprimand for cyber security failings, issued to ACRO Criminal Records Office on 7 August 2026, turns on named ownership of patch management and monitoring of security alerts under UK GDPR Article 32. A hacker held access to ACRO’s website for seven months, exposing sensitive data for up to 10,920 people. The ICO reprimanded rather than fined because ACRO’s network segmentation and remediation counted in its favour.
The Information Commissioner reprimanded ACRO Criminal Records Office on 7 August 2026 because ACRO could not show who inside the organisation was responsible for keeping its systems patched. A hacker had held access to ACRO’s website and content management system between August 2022 and March 2023, exposing criminal-records data, including biometric and special category information, for up to 10,920 people. ACRO had bought patch management from third-party providers. What it could not evidence was management ownership. Any UK data controller running a public-facing system that processes sensitive personal data has to be able to answer that question, and the ICO’s reprimand shows what happens when it cannot.
What the ICO’s reprimand for cyber security failings illustrates about UK GDPR Article 32 requirements
UK data controllers and processors must implement technical and organisational measures appropriate to the risk under UK GDPR Article 32, headed “security of processing”. What counts as appropriate depends on the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing. Article 32(1) names four measures: pseudonymisation and encryption; the ability to maintain ongoing confidentiality, integrity, availability and resilience of processing systems; the ability to restore access after an incident; and a process for regularly testing and evaluating whether the measures work. Article 32(2) requires the data controller to assess the risk of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
The ICO found that ACRO had engaged third-party providers for security services, including patch management, but had not established clear ownership for identifying and monitoring critical updates to its content management system, and had not adequately investigated the security alerts that would have caught the intrusion sooner. The Information Commissioner reprimanded ACRO for infringing Article 32(1), Article 32(1)(b) and Article 32(1)(d), using the Article 58(2)(b) corrective power rather than the fines available under Article 83. The ICO reprimand for cyber security failings turned on that ownership gap, not on the sophistication of the attack. AI-driven threats raise the same accountability question at board level, examined further in a related piece on the DSIT open letter on AI cyber threats and in a further piece on the Five Eyes statement on AI cyber risk.
Why outsourcing did not answer the duty
A data controller that outsources a security function keeps the Article 32 duty. Where a data controller engages a third-party provider for patch management or monitoring, its Article 28 processor arrangements have to allocate, and let the data controller demonstrate, who identifies a needed update, who applies it, and who investigates an alert that a system has not been updated. A services contract listing patch management as a deliverable did not settle the point on the ACRO facts. The ICO looked at what happened operationally, not at the allocation on paper.
Article 32(1)(b) and Article 32(1)(d) are the two limbs the ICO relied on, and both depend on a person. A data controller maintains ongoing resilience, and regularly tests and evaluates its security measures, only if somebody is accountable for acting on what the monitoring shows. ACRO had the monitoring. Nobody owned the response.
The mitigating factors matter as much as the finding. ACRO’s network segmentation kept the hacker inside the compromised website environment and away from its core systems. The ICO also weighed ACRO’s remedial programme, including decommissioning the affected infrastructure and improving threat visibility, in favour of a reprimand rather than a fine. Article 32(1) sets no fixed technical standard: it asks whether the measures were appropriate to the risk, given the state of the art and the cost of implementation. A data controller that can evidence proportionate technical controls, even where a process gap contributed to an incident, stands in a materially different position from one that cannot.
Cyber security obligations for data controllers and their suppliers
The duty applies to any UK data controller running a public-facing website, portal or content management system that processes sensitive or special category data. Public bodies and regulated firms handling identity, criminal-records or safeguarding information are the most exposed, because the data at stake is the data the ICO treats most seriously. Their third-party providers for patch management, hosting and security monitoring carry whatever the Article 28 arrangements give them, and no more.
What the ICO is asking for is cheap relative to the risk, and it needs no new technology. A data controller names who owns patch identification and application for each system, ensures security alerts are actively monitored and escalated rather than logged and left, and keeps evidence of both. That prompts two checks: whether the organisation’s information security policy names an owner for each system’s patch cycle, and whether its Article 28 processor agreements make monitoring and escalation explicit rather than assumed. Where an organisation is already dealing with ICO scrutiny following a security incident, our investigations and enforcement support page sets out how that process typically runs.
The ICO’s enforcement pattern for security and access failures escalates: an assessment, then a reprimand, then an enforcement notice for organisations that do not act on the first two. A reprimand carries no financial penalty. It is a public, named finding, and a second finding on the same failure mode starts from a materially worse position than a first.
Viewpoint
The gap the ICO found at ACRO is a common one. An organisation can produce a security policy and a managed-services contract, and still be unable to say, system by system, who is accountable for acting on a patching alert once it arrives. The contract allocates a service. It does not, on its own, allocate the decision.
The ICO’s security guidance has said for some time that accountability and evidenced ownership matter as much as the technical control. In ACRO the ICO applied that to a live incident rather than stating it in guidance alone, which is what makes this reprimand worth reading for data controllers who have outsourced the same function.
For advice on Article 32 accountability and patch management governance, or on reviewing Article 28 processor arrangements after a security incident, contact Rob Bratby at Bratby Law.
