On 7 August 2026, the Information Commissioner’s Office (ICO) reprimanded ACRO Criminal Records Office for failures in data security. Its investigation, published on 12 August, describes three intrusions into the organisation’s public customer portal and Kentico CMS between July 2021 and June 2023. The most serious intrusion left persistent access in place for about seven months.
This was more than a website outage. ACRO handles Police Certificate, International Child Protection Certificate and subject access applications, involving information that can concern domestic-abuse victims and other people at particular risk. Data relating to up to 10,920 people may have been staged for exfiltration, but the investigation could not conclusively establish that the data left the systems.
Three intrusions on one exposed surface
The forensic investigation commissioned by ACRO grouped the traces into three sets, called Group A, Group B and Group C in the ICO case. Evidence of malicious activity ran from 9 July 2021 to 22 June 2023. That final date marks the decommissioning of the compromised infrastructure; it does not prove that the attacker was still present on that day.
Group A is the best-documented episode. From 5 August 2022 to 14 March 2023, an attacker retained access to ACRO’s website and Kentico CMS. A separate intrusion, uncovered while investigating SQL injection, exposed 15 sets of credentials, mostly belonging to ACRO staff. The available sources do not establish whether the three episodes involved one actor or several, nor who was behind them.
An unowned patch is an open risk
ACRO had been running Kentico version 12.0.0 since September 2019. Security patches and hotfixes were released during that period, but they were not applied. The ICO found that neither ACRO nor its providers had a sufficiently clear responsibility for identifying, tracking and deploying those critical updates.
The problem was therefore not just old software. ACRO had no documented policy covering Kentico patching and could not show how vulnerabilities were identified or prioritised. When a critical task is split between an organisation, a managed service provider and a web development supplier without an explicit owner, the fix can remain in a blind spot for years.
Antivirus alerts without an escalation process
Trend Micro generated several alerts during the attack period. Four detections involved attempts to install Mimikatz, a tool used to recover credentials. The antivirus quarantined those detections, but they did not lead to a documented investigation or an identifiable escalation.
ACRO told the ICO that it could not establish what process existed at the time for assessing or handling security alerts, or which roles were meant to review and escalate them. An alert is therefore not a complete control: it shortens response time only when someone owns it, the signal is retained and the decision is recorded.
Sensitive data staged, but exfiltration cannot be confirmed
Investigators found that information was gathered on 15 and 16 February 2023 for possible exfiltration. The material could include names, dates of birth, addresses, National Insurance numbers, passport and driving-licence details, bank-account information, biometric data, and criminal-offence and special-category information.
The information was connected to Police Certificate, International Child Protection Certificate and subject access applications. The retained logs were not complete enough to show whether the staged files were actually copied out of the environment. ACRO notified more than 84,000 people as a precaution, while the later analysis reduced the maximum number of people whose data may have been staged to 10,920.
That uncertainty is already a concrete consequence. The 35 formal complaints reported in the case described personal distress and fears of identity theft or financial loss. People connected to domestic violence were among those who raised concerns. When an organisation cannot reconstruct a data path, it cannot give affected people a precise answer about what happened to them.
What affected people can do
If you used the ACRO portal during the at-risk period, be wary of messages that reuse the language of a Police Certificate, subject access request or international procedure. Open the official website by typing the address yourself and verify any request through a known contact. Never share a code, password or identity document in response to an unexpected message.
The password risk depends largely on reuse. Change an identical secret on every email, work or financial service, starting with the accounts that can recover access to others. Enable multi-factor authentication where available and keep a record of the accounts handled, without copying the secrets into a spreadsheet or email.
What organisations should check
The ACRO lesson is about accountability as much as technology. For every exposed CMS and supplier, an organisation should be able to answer four questions: who receives security notices, who sets the priority, who deploys the fix and what evidence confirms completion? That answer must remain valid when a supplier changes teams or contracts.
Alerts need the same path. An owner, review deadline, escalation process and retained logs make it possible to distinguish a false positive from the start of an intrusion. Network segmentation stopped the attacker from reaching ACRO’s core systems and limited the harm, but it did not replace patching, monitoring or adequate logging.
Since the incident, ACRO has decommissioned the compromised infrastructure, migrated its services, strengthened segmentation and introduced security monitoring with better threat visibility. Those measures address part of the risk; they cannot recreate events that insufficient logs failed to record.
The Soclyde connection
Soclyde does not protect the ACRO portal, replace a patched CMS or establish what happened in a third party’s logs. Its role is in access management around this kind of service: generate a unique secret for every account, keep it in an encrypted vault and quickly identify which access needs to be rotated when an organisation or supplier is affected.
That separation reduces the risk of reuse turning one exposed credential into a wider incident, and avoids scattering secrets across shared files. It complements patching, monitoring, segmentation and log retention; it does not replace them.
Takeaway
The ACRO case shows how three intrusions can span nearly two years when patches have no owner, alerts have no follow-up and logs can no longer settle whether data was exfiltrated. The information at stake was particularly sensitive, and the uncertainty itself placed an additional burden on vulnerable people.
For users, remove password reuse, verify messages through the official channel and prioritise accounts that recover other access. To structure that work, read our secure password generator guide or contact Soclyde.
