ICO Reprimands ACRO: Compromised CMS Endangers 10,920 People

Published on 16 August 2026

For seven months, from August 2022 to March 2023, an attacker had undetected access to the website and content management system of the UK's ACRO Criminal Records Office – the agency that, among other things, issues police background checks and international child protection certificates. On 12 August 2026, the UK data protection authority ICO (Information Commissioner's Office) formally reprimanded the agency for it. The central lesson for German website operators is an uncomfortable one: the breach did not succeed because of a sophisticated zero-day attack, but because no one was clearly responsible for applying critical updates – and because existing alerts were simply ignored.

What happened?

The affected system was the ACRO customer portal, a web application based on the CMS Kentico (a system for managing website content). According to the ICO reprimand, dated 7 August 2026, in the largest of the incidents – referred to by the ICO as "Group A" – an attacker maintained unauthorised access to this website and CMS environment between 5 August 2022 and 14 March 2023.

On 15 and 16 February 2023, data was staged for possible exfiltration – that is, unauthorised removal from the network. This data came from cases relating to background checks, subject access requests and international child protection certificates. Whether the data actually left the network could no longer be determined by ACRO after the fact – because the log data had not been retained for a sufficient period. And here lies one of the most painful lessons: without usable logs, in a serious incident it remains unclear what was stolen.

Up to 10,920 people were potentially affected. The data comprised identity, financial, biometric and criminal data as well as special categories of personal data – in other words, highly sensitive information. As a precaution, ACRO notified a total of 84,048 people in April 2023.

The ICO found breaches of several provisions of the UK GDPR, in particular Art. 32 – the obligation to implement appropriate technical and organisational security measures.

The technical background – explained clearly

Important context: this is not a confirmed new Kentico exploit. The forensic investigation report was unable to identify the specific vulnerability that was exploited. The ICO merely considers it "highly likely" that the initial access occurred via an unpatched Kentico vulnerability.

ACRO ran the application on Kentico CMS 12.0.0 from September 2019 to March 2023. Throughout this entire period, not a single one of the cumulative security hotfixes released by the vendor was applied. The system therefore ran for years on an outdated patch level.

As a publicly documented reference matching the version line in use, the material cites CVE-2019-10068. This vulnerability affects Kentico 12.0.x prior to version 12.0.15: flawed validation of security headers in the so-called staging service can, under the right configuration, enable unauthenticated remote code execution (RCE) via deserialisation – in simple terms: an attacker can execute their own malicious code on the server without logging in. This CVE is listed in the CISA catalogue of known, actively exploited vulnerabilities and was fixed in version 12.0.15. Note: the ICO does not mention this CVE and was unable to determine which Kentico vulnerability was actually abused at ACRO. A mere version match does not prove an attack.

The technology alone was not the problem

The incident also lasted so long because several organisational controls were missing:

• Unclear responsibility: One service provider patched operating systems and servers, the web development provider was supposed to apply Kentico patches – but no one was demonstrably responsible for even identifying which CMS patches were needed.
• No documented patch policy: No CMS patch policy was produced.
• Ignored alerts: The security software Trend Micro repeatedly detected and quarantined attacker tools. On 23 February 2023, it blocked four attempts to install the well-known password-harvesting tool Mimikatz. According to the ICO, these warnings were not investigated or acted upon.

"ACRO did not clearly define who was responsible for monitoring for required security patches. … ACRO itself did not monitor for required security patches, meaning that there was an absence of oversight for this important security control." – ICO reprimand against ACRO

One bright spot: the network segmentation – that is, dividing the network into separate zones – demonstrably prevented the attacker from moving laterally into core police systems. It limited the damage, but did not eliminate the risk.

Who is affected?

Directly affected is ACRO in the United Kingdom. For German companies, however, the lesson is immediately relevant if you operate a publicly accessible CMS containing personal data. The risk is particularly elevated when:

• a customer portal, forms or upload functions process personal data,
• an unsupported CMS is in use (Kentico 12.x is now end-of-support),
• neither robust patch responsibility nor functioning log and alert handling can be demonstrated,
• hosting is fully outsourced but it is not contractually clearly defined who identifies and applies security updates.

The risk is not high simply because a website is publicly visible. What matters is the specific data held, the attack surface, the patch level, the access rights, the segmentation and the responsiveness.

How to check whether you are affected

1. Create an inventory: Record all publicly accessible websites, subdomains, customer portals, forms, upload functions as well as their CMS, plug-ins, web servers and your hosting and development partners. Assign each component a technically responsible owner – it was precisely this responsibility that was the core failing at ACRO.
2. Have the CMS version confirmed: Check the version exclusively via authorised internal access or the deployment/support documentation – not through unauthorised testing. For Kentico 12, the vendor documentation describes the "System" application and the "General" tab as the place for system and environment information. Have the version and hotfix level confirmed in writing by administration, development or hosting.
3. Compare against the lifecycle: Map the confirmed status against the vendor lifecycle and the security advisories. Every Kentico 12.x installation is unsupported in 2026 and should be treated as a migration risk. For CVE-2019-10068: 12.0.x prior to 12.0.15 is affected.
4. Review the patch history: Is there a complete patch history, risk decision, test record, approval and rollback capability for the CMS, operating system, web server and third-party components? If these records are missing, that is a governance and security risk – even if a service provider installs the updates.
5. Analyse logs: Search web server, WAF, CMS, authentication, antivirus/EDR and SIEM logs for unusual admin logins, new or modified files, unusual data transfers and unhandled alerts. For instances suspected of being compromised, Kentico cites, among other things, unknown files, antivirus detections and suspicious IIS log activity such as SyncServer.asmx as points to check. Preserve evidence before any clean-up.
6. Create a data map: Determine which personal data is processed via the website (form, upload, payment, support data) and where it resides. This data and risk map is the basis of any GDPR assessment.

What you must do now

1. In the event of concrete signs of attack: activate incident response. Assign responsibilities, secure evidence and logs and reduce the external attack surface in a controlled manner. No hasty clean-up that destroys forensic traces – because of missing logs, ACRO was later unable to clarify whether data had been exfiltrated.
2. Migrate unsupported CMS versions. For Kentico 12.x, the vendor explicitly recommends upgrading. Retroactively applying a historical hotfix does not eliminate the end-of-support risk.

   "The only solution to secure your website is to upgrade to the latest supported version and apply the latest hotfix." – Kentico

3. Document patch management. Establish a process covering inventory, vendor alerts, risk assessment, testing in staging, approval, rollout, verification and deadlines. Define a RACI matrix that clearly separates who identifies, assesses, applies, verifies and escalates updates – even across service provider boundaries.
4. Actively handle alerts. Centralise web, CMS, server, authentication and endpoint logs, define triage and escalation deadlines and test the on-call path regularly. The ICO notes that a timely investigation of the Trend Micro warnings would probably have prevented further malicious activity.
5. Harden the portal and limit damage. Secure administrative access with MFA (multi-factor authentication) and minimal privileges, separate admin and production accounts, maintain tested backups and segment the website zone from core systems. At ACRO it was precisely the segmentation that reduced the potential damage.
6. Prepare data protection incident response. Designate controllers, processors and contact persons at the supervisory authority and keep a 72-hour decision matrix along with draft notifications ready.

Context and GDPR relevance

The ACRO decision is based on the UK GDPR and is not a direct German legal ruling. However, Art. 32 GDPR requires equally risk-appropriate technical and organisational measures in Germany – including the ongoing confidentiality, integrity, availability and resilience of the systems (Art. 32(1)(b)) and a process for regularly reviewing their effectiveness (point (d)). It is precisely the points criticised in the ACRO case – missing responsibilities, unpatched components, missing risk documentation, unhandled alerts – that are therefore immediate warning signs for German operators too.

If a web incident leads to a personal data breach, the competent supervisory authority must be informed pursuant to Art. 33 GDPR without undue delay and, where feasible, within 72 hours of becoming aware, where there is a likely risk. Where the risk is high, the data subjects must generally also be notified under Art. 34 GDPR. Every breach must be documented. For breaches of Art. 32, Art. 83(4) GDPR provides for a maximum of up to EUR 10 million or up to 2% of global annual turnover – whichever is higher. This is not an automatic fine amount; sanctions always depend on the individual case.

The fact that supervisory authorities react firmly to website incidents is shown by the comparable case of Ticketmaster UK: on 13 November 2020, the ICO imposed a fine of GBP 1.25 million following a web attack via a third-party chatbot component – with 9.4 million people in the EEA notified as potentially affected. The parallel lies in the third-party and website risks as well as in the inadequate response to warning signs.

How serious the situation is in Germany is underlined by the BSI 2025 status report: the exploitation of vulnerabilities in web attack surfaces rose by 38% compared with the previous year – adjusted for one-off effects – and 80% of the ransomware attacks reported hit small and medium-sized enterprises. The BSI sums up the lesson:

"This is why patches are one of the most effective ways to prevent attacks from the internet." – Federal Office for Information Security (BSI)

Conclusion

The ACRO case is not a story about a brilliant hacker, but about missing fundamentals: no one was clearly responsible for patches, the CMS ran unpatched for years, logs were missing and alerts were ignored. Every one of these points is avoidable – and every single one of them could just as easily apply to German SMEs.

"Organisations must ensure there is clear accountability for identifying, assessing and applying security updates. They must also have effective monitoring in place so that warning signs of cyber-attacks are identified, investigated and acted upon promptly." – Jonathan Balmforth, Group Manager – Civil and Cyber Investigations, ICO

So check now: who at your organisation is demonstrably responsible for CMS patches? Is your system running on a still-supported version? And would you even notice and act on an alert from your security software? Anyone who can answer these three questions clearly has already avoided the most important mistakes from the ACRO case.