The gap between two suppliers is where breaches live

On 12 August the Information Commissioner’s Office (ICO) published a reprimand, dated 7 August, against ACRO Criminal Records Office, the national police unit that issues police certificates on behalf of 43 forces. According to the reprimand, an attacker held access to ACRO’s customer portal and its content management system (CMS) from 5 August 2022 to 14 March 2023, and on 15 and 16 February 2023 staged the personal data of up to 10,920 people for exfiltration. ACRO had kept too few logs to say whether the data left.

The data included bank account details, National Insurance numbers, passport and driving license numbers, biometric data and criminal offense information, the ICO says. ACRO wrote to 84,048 people on a precautionary basis in April 2023. It got a reprimand rather than a fine, partly because network segmentation kept the intruder out of core policing systems and partly because it has since moved to Salesforce Experience Cloud and put in a security information and event management (SIEM) service.

Channel leaders should read it for what the ICO found when it asked who was supposed to patch the website. ACRO’s managed service provider (MSP), whose name is redacted, was contracted to patch the operating system and maintain the servers. The reprimand says its role stopped at the infrastructure. A separate web development supplier was responsible for applying Kentico CMS patches and hotfixes, under a February 2020 email exchange with ACRO that said nothing about looking for them. Nobody, the ICO found, was monitoring for patches at all. The website ran Kentico version 12.0.0 from September 2019 to March 2023 and not one of the cumulative security hotfixes released in that time was applied.

That is the whole story, and I expect it to be the story of most breaches this decade. Breaches live in the gap between two suppliers’ contracts, and the ICO has now written that gap down in a published finding.

Two contracts, one hole

The ICO’s wording is precise: “The ambiguity around who was accountable for identifying necessary Kentico CMS patches created a gap where patches and hotfixes were missed which ultimately left ACRO’s website vulnerable.” The MSP patched what it was paid to patch. The developer agreed to apply patches it was never asked to find. ACRO could not produce a documented patching policy when the ICO asked for one. Each party can point to a document that says it did its job. The regulator’s finding is that the job did not get done.

Note who the reprimand is addressed to: ACRO, the customer, rather than either supplier. Under Article 32 of the UK General Data Protection Regulation the duty to secure processing sits with the controller or processor; suppliers are how it is discharged. An MSP might read that as comfort. It should not. A scope line kept the MSP out of the reprimand and did nothing for the customer, whose name is now attached to a public account of how its suppliers’ boundaries lined up to leave a police website unpatched for three and a half years.

The alerts nobody read

The second finding is worse, because the technology worked. Trend Micro antivirus behind the website detected and quarantined attacker tools several times during the intrusion. On 23 February 2023 it stopped four attempts to install Mimikatz, a well-known credential-harvesting tool. The February 2023 report, whose title is redacted, produced by a supplier the ICO says ACRO had asked to reboot the affected server, makes no mention of the quarantined files. ACRO told the ICO it could not establish which roles had been responsible for reviewing security alerts at the time.

The reprimand’s finding is blunt: “Despite Trend Micro successfully detecting and quarantining threat actor tools on multiple occasions, these alerts were not investigated or acted upon by any involved party.” Any involved party. The attacker kept access for nearly three more weeks, and the ICO says an investigation at the time would likely have prevented further malicious activity.

ACRO had not taken up the SIEM service its hosting supplier offered, the reprimand notes, and that report had a section for flagging security issues. A section in a report is an opportunity to speak up, which is a different thing from a process or a named owner.

The contract the regulator reads

Jonathan Balmforth, group manager for civil and cyber investigations at the ICO, said: “Organisations must ensure there is clear accountability for identifying, assessing and applying security updates.” The ICO’s advice to other organizations, published with the reprimand, is to define who is responsible for identifying, assessing and implementing updates across every system and every supplier, and to make sure alerts are monitored, investigated and escalated.

The implication for an MSP is plain. When a customer is breached, the ICO’s questions start with the contract rather than the firewall: who was responsible for this layer, where is that written down and who was reading the alerts. The ACRO investigation turned on an email exchange from February 2020 and on what a supplier’s report left out. Assume the regulator will read your contract as closely as your logs, and read the contract first.

So here is the test. For every customer you serve, can you say who owns patching for the operating system, the middleware, the CMS or business application and its plugins, and who reads the alerts each of those layers produces? Where the answer is “the customer” or “their other supplier”, is that written down, and has the customer seen the gap between the two? An MSP that cannot answer carries the same risk as one that patches everything, with less control over it.

The ACRO reprimand carries no fine. It is still the most useful thing the ICO has published for the channel in 2026, because it shows where the regulator looks. The regulator will not ask what your tools saw. It will ask who was supposed to look.