What does the UK ICO reprimand of ACRO Criminal Records Office reveal about supply-chain patch management in 2026?

13 August 2026 7 min read 1503 words

The UK ICO reprimanded ACRO Criminal Records Office on 12 August 2026 for three intrusions (9 July 2021 – 22 June 2023) exploiting Kentico CMS v12.0.0, unpatched since September 2019 despite published hotfixes. ICO found no documented accountability for CMS patching across ACRO, its MSP, and its web vendor; Trend Micro's four quarantined Mimikatz attempts (23 Feb 2023) were never triaged. Network segmentation stopped lateral movement into the Police National Computer — the factor that avoided a fine. ACRO notified 84,048 people and migrated to Salesforce Experience Cloud with a SIEM.

Key facts

Three intrusions between July 2021 and June 2023 all exploited the ACRO customer portal (www.acro.police.uk), a web application built on Kentico CMS v12.0.0 — the same version since September 2019, despite cumulative security hotfixes released by Kentico between 2019 and July 2023.
No documented accountability for CMS patching. ACRO's Managed Service Provider (MSP) handled Operating System and server maintenance but explicitly excluded Kentico CMS patching; the web development vendor was responsible for applying CMS patches under the support agreement but was not contractually required to monitor for them. The result was a governance gap, not a technical mystery.
Trend Micro quarantined four Mimikatz installer attempts on 23 February 2023 — credential-harvesting tooling that, in any healthy SOC, would have triggered immediate host isolation. The forensic investigation found that no party (ACRO, MSP, or web vendor) reviewed the alerts. ACRO itself could not establish which roles previously held responsibility for monitoring them.
Group A maintained persistent access from 5 August 2022 to 14 March 2023 (≈7 months). Between 15–16 February 2023, the threat actor staged personal data of just under 11,000 people (Police Certificate Applications, Subject Access Requests, Record Deletion Requests) for exfiltration. ICO found that insufficient log retention prevented ACRO from confirming whether data was actually exfiltrated.
Network segmentation prevented lateral movement from the compromised web environment into the Police National Computer (the core policing system). ICO cited this as the key mitigating factor; the reprimand carries no financial penalty.
Medusa RaaS publicly claimed responsibility, but no stolen data was published on the group's leak site — whether this reflects a quiet extortion payment or a fabricated claim remains unconfirmed.
ACRO notified 84,048 people on a precautionary basis in April 2023 and received more than 40 formal complaints. Remediation: decommissioned compromised infrastructure, migrated to Salesforce Experience Cloud (where patching is a platform responsibility), implemented a SIEM, and introduced documented patching governance.

What this means for a B2B or production company

Area	What we know from ACRO	What it means for a B2B / production firm	Recommended action (30 / 90 days)
CMS / public web exposure	Kentico v12.0.0, unpatched from Sept 2019 to Mar 2023	Public-facing CMS is part of your attack surface; default vendor version ≠ secure version	30d: inventory all public web apps + underlying CMS/framework versions; 90d: assign a named owner per asset for patch monitoring
Supply-chain responsibility	Patching responsibility split between ACRO, MSP (OS only), and web vendor (CMS application only)	When three parties touch one stack, someone must own the patch-monitoring loop end-to-end	30d: map RACI per critical asset (who detects, who applies, who verifies); 90d: contractually bind the detection obligation
Antivirus alert triage	Trend Micro quarantined Mimikatz 4× on 23 Feb 2023 — no review	Quarantine is not detection; an un-triaged quarantine is a future breach	30d: define SLA for high-severity AV alerts with named owner; 90d: integrate AV + EDR into SIEM with automated triage playbooks
Network segmentation	Segmentation prevented lateral movement to Police National Computer	The single control that earned ACRO the absence of a fine	30d: review east-west segmentation between web tier and OT / core systems; 90d: test with tabletop + passive validation (CHORS P0/P1)
Log retention	Insufficient retention prevented confirmation of exfiltration	You cannot prove what you cannot log; you also cannot disprove a breach	30d: confirm retention meets legal minimum (NIS2 Art. 21(2)(f), UK GDPR Art. 5(2)); 90d: extend to 12 months hot + 5 years cold
Third-party RaaS claims	Medusa claimed responsibility, no leak	Claims are noise; treat the technical intrusion as the source of truth	30d: include dark-web leak monitoring in threat intel cycle; 90d: rehearse external-claim response (comms, regulator, customers)
Remediation architecture	Migrated to Salesforce Experience Cloud (PaaS)	Moving to managed PaaS shifts patching responsibility to the vendor — still verify	30d: re-baseline the threat model after any platform migration; 90d: confirm vendor SOC2/ISO reports + shared-responsibility matrix

Perspective from Marcin Białczyk — operational notes

From an operator's perspective, the most uncomfortable detail in the ICO reprimand is not the unpatched Kentico. It is paragraph 37 of the regulator's reasoning: "ACRO could not demonstrate clear accountability for identifying required security patches and hotfixes for Kentico CMS." That sentence is the real root cause. The technical control (a CMS hotfix) had been published many times; what was missing was the governance — a named role, a documented process, and an obligation to monitor. Most organisations I work with have the same gap, usually surfaced during the first P1 Authorized Vulnerability Assessment: every patch exists somewhere, but nobody can answer "who is responsible for telling us a new patch exists tomorrow?"

The second lesson is the Trend Micro Mimikatz alert loop. Quarantining malware is necessary but not sufficient. The forensic report shows the alerts existed in the console and were never reviewed; the host that ACRO itself required to be rebooted after the quarantine never was. This is exactly the failure mode a SOC (or in CHORS terminology, the NIS2/KSC Continuous Readiness engagement) is meant to catch — but a SOC only helps if someone owns the alert queue and the queue is small enough to be acted on. In most SMEs I see, alert ownership is implicit, and after an incident it becomes explicit in the regulator's report.

The third lesson is that network segmentation saved the policing core system. ACRO's web environment was compromised for nearly two years, but the Police National Computer stayed clean. That is not luck — that is an architecture decision someone made earlier and an operator's report later called out as the decisive mitigating factor. For manufacturing and OT-adjacent B2B firms, this is the most replicable lesson: the segmentation between web tier and OT/core systems is the single control that turns a public breach into a contained one. The CHORS methodology treats segmentation as a measurable artefact, validated passively during P0 and actively during P1, not as a checkbox on a network diagram.

— case study from CHORS engagements where unpatched CMS / un-triaged antivirus alerts / missing patch-monitoring RACI were identified during P1 assessments and the operational impact on the client's incident-readiness posture.

Frequently asked questions

Q1. Was ACRO fined?

No. The ICO issued a reprimand under Article 58(2)(b) UK GDPR, which carries no financial penalty. ICO cited network segmentation and ACRO's post-incident remediation (decommissioning, SIEM, Salesforce Experience Cloud migration) as mitigating factors. The reprimand is published and forms part of ACRO's regulatory record.

Q2. Was data actually exfiltrated?

The ICO found that ACRO's insufficient log retention meant the office could not confirm whether data was exfiltrated. The threat actor staged ≈11,000 records (Police Certificate Applications, Subject Access Requests, Record Deletion Requests) in February 2023; ACRO notified 84,048 people on a precautionary basis in April 2023. Medusa RaaS claimed responsibility but published no data on its leak site.

Q3. Why was Kentico CMS left unpatched for so long?

ICO's findings: ACRO's MSP patched the operating system but explicitly excluded the CMS layer. The web development vendor applied CMS patches under support but was not contractually obligated to monitor for new ones. ACRO itself had no documented patching policy covering the CMS. The result was a governance gap — who should monitor for new Kentico hotfixes was never answered.

Q4. Does this case apply to NIS2/KSC entities in the EU?

The ACRO case is UK GDPR, but the operational pattern — supply-chain patching responsibility, un-triaged AV alerts, segmentation as a mitigating factor, log-retention proving/disproving exfiltration — maps directly onto NIS2 Article 21(2) risk-management measures (in particular (d) supply-chain security and (f) baseline practices) and to KSC obligations for entities of significant importance. Interpretation of EU law requires consultation with a law firm; CHORS provides technical readiness assessment, not legal opinion.

How CHORS.NET helps

CHORS.NET supports the technical-operational side: passive exposure assessment, configuration verification, evidence packs and NIS2/KSC readiness support. See: Services, About CHORS.NET and Contact.

Boundaries and assumptions

CHORS.NET is not a 24/7 SOC and does not guarantee detection of every incident.
CHORS.NET does not certify NIS2 / KSC compliance and does not issue independent legal opinion.
The Medusa RaaS attribution is the group's claim, not a confirmed attribution by the ICO.
All findings above reflect the ICO reprimand (dated 7 August 2026, published 12 August 2026) and the therecord.media article by Alexander Martin on 12 August 2026; any subsequent ACRO statement supersedes these.
For interpretation of UK GDPR, EU NIS2, or Polish KSC, CHORS works with cooperating law firms; this article is informational and technical, not legal advice.

Last updated: 2026-08-12 Pipeline: chors-incidents-to-blog v1.1 → qa-blog-draft v1.1 (draft, pre-QA) Language scope: EN-only (per incident record LanguageScope=EN)

Precyzyjna wiedza
o ciemnych systemach.