Everyone Was Responsible. So No One Responded. — The ACRO Cyberattack
ACRO had patches available, security alerts firing, and several providers in the picture. The documented failure was not only technical: responsibility for monitoring, patching, and escalation was unclear.
Incident overview
The UK Information Commissioner’s Office reprimanded ACRO after three forensic incident groupings involving its public-facing website. The ICO found ineffective patch management, unclear accountability for critical CMS updates, and security alerts that were not adequately reviewed or escalated.
Why it works
When responsibility is spread across internal teams and outside providers, every participant can assume someone else owns the response. That ambiguity can turn available patches and active alerts into background information instead of action.
Protective actions
- Assign one named owner to every critical alert, patch stream, and escalation path.
- Name a backup owner and define what happens when the primary owner is unavailable.
- Require closed-loop verification: record who reviewed the alert, what they decided, and when it was resolved.
- Test vendor and internal-team responsibilities together instead of relying on assumptions in separate contracts or procedures.
- Audit whether critical alerts are reaching a person with both the authority and time to act.
Video companion
Watch the breakdown
The documented incident
The Information Commissioner’s Office (ICO) reprimanded the UK’s ACRO Criminal Records Office after investigating compromises involving ACRO’s public-facing website and its Kentico content-management system. The regulator grouped the forensic evidence into three distinct sets of activity spanning July 2021 to June 2023. Those groupings do not prove that three separate attackers were involved.
The ICO found that ACRO used Kentico 12.0.0 from September 2019 until March 2023 without applying the cumulative hotfixes released during that period. The forensic evidence could not identify the exact vulnerability used, but the ICO considered it highly likely that an unpatched Kentico vulnerability enabled the initial access.
The failures were organizational as well as technical
ACRO had internal teams and third-party providers in the security process, but the ICO found that accountability for identifying and applying critical CMS updates was unclear. It also found that Trend Micro security tools detected and quarantined several attacker tools, while the resulting alerts were not adequately reviewed or acted upon. ACRO could not establish which roles owned the review and escalation of those alerts.
That distinction matters. This was not simply a case of a patch being missed or an alerting product failing. The patching information and alerts existed; the operating process did not reliably convert them into owned action.
What is known about the data
The investigation identified up to 10,920 people whose data may have been affected. The potentially affected information included identifiers, financial information, national identification documents, criminal-offence information, domestic-violence information, special-category data, biometric data, and race or ethnic-origin data.
Attackers staged data in February 2023, but insufficient logging meant the investigation could not definitively establish whether that data was exfiltrated. “Potentially affected” is therefore more accurate than saying that all of those records were confirmed stolen.
What worked
The incident was serious, but the controls did not all fail. Network segmentation prevented movement from the website environment into ACRO’s core systems. ACRO later decommissioned the affected infrastructure, moved the public site to Salesforce Experience Cloud, introduced a security information and event management system, and strengthened monitoring, hardening, and segmentation.
Fact, interpretation, and uncertainty
The ICO’s findings support the claims about unpatched software, unclear responsibility, uninvestigated alerts, potentially affected data, and the remediation. The psychology framing below is Connor’s interpretation of the organizational pattern. It is not a diagnosis of ACRO employees or providers, and the public evidence does not establish any individual person’s motives.
The smoke-alarm analogy
Imagine a smoke alarm sounding in an office. The boss assumes the building manager will handle it. The building manager assumes the facilities team is on it. Facilities assumes the alarm company is monitoring it. The alarm company assumes someone inside has already checked.
The analogy exaggerates the physical consequences, but it captures the coordination problem: a warning can be visible to many people and still belong to no one.
Diffusion of responsibility
Diffusion of responsibility describes how each person can feel less personally obligated to act when responsibility appears to be shared across a group. It is one mechanism associated with the bystander effect.
Applied carefully, it offers a useful lens for the ACRO findings. If an internal team thinks a provider is monitoring updates, the provider thinks an implementer owns the CMS, and several people receive the same alert, the shared visibility can create reassurance without ownership.
What the 1968 study can and cannot show
In Darley and Latané’s 1968 experiment, participants believed they heard another participant having a seizure. When they believed they alone knew about the emergency, 85% reported it before the recording ended. When they believed four other bystanders also knew, 31% reported it before the recording ended.
The study did not examine cybersecurity operations, software patching, or ACRO. It supports the general mechanism, not a causal claim about this incident.
Give the alert an owner
The practical rule is more specific than “install your updates.” Every critical alert, patch stream, and escalation path needs a named owner, a backup, a response window, and a way to verify closure.
A security alert without an owner is just a notification.
Full spoken transcript
This organization had security patches available, security alerts firing, and multiple security providers, but they were still breached because somehow it wasn't clear whose responsibility it was to act on any of it.
The UK's ACRO Criminal Records Office, or ACRO for short, was just reprimanded for several security failings involving its public website. And as I mentioned earlier, these intrusions weren't the result of hackers doing anything particularly clever or sophisticated. The organization was running software with known vulnerabilities and it hadn't applied some patches in years.
ACRO had its own internal teams and third-party security providers, but almost amazingly, it wasn't clear whose job it was to actually monitor for security updates and make sure they get installed. And if you thought it couldn’t get any worse, the security software was actively generating alerts during the attacks. It’s just no one was investigating them. It’s like a smoke alarm is going off in a building. The boss isn’t going to do anything about it because they’re the boss. The building manager assumes the facility staff is looking into it. They assume the alarm company is monitoring it. And the alarm company assumes someone in the building must have checked on it because they’re inside the building where the alarm is going off. And then the building burns down. This analogy is a bit of an exaggeration, but it’s really not that far off from what actually happened. Attackers don’t need to hit a 120-mile-an-hour fastball trick shot winner. They can just keep the ball in play and wait for you to make an unforced error. Either way, they still get the point. Situations like this sound a bit like the bystander effect, but the part I want to focus on is something called diffusion of responsibility. This basically means that when it’s several people’s responsibility to do something, each individual person can feel less pressure to be responsible. If it’s five different people’s responsibility to make sure the security alerts get investigated, at the end of the day, is it really that surprising when it doesn’t get done? There was a famous 1968 study where people thought they heard someone having a seizure. If they believed they were the only person that heard it, 85% reported the emergency before the recording ended. But if they believed four other people had also heard it, the response rate tanked all the way down to 31%. Obviously, reacting to a real-life emergency is different than managing cybersecurity alerts and patches, but the same idea is there. If one team thinks five other teams are also responsible for something, it suddenly becomes much more likely that no one will do it. And the consequences of inaction can be potentially very serious. So the practical takeaway here isn’t just install all your updates, even though you should definitely do that. The lesson here is that responsibilities need an actual owner. A security alert without an owner is just a notification that you're being hacked and you're not doing anything about it. So as always, stay mindful, stay resilient, make sure it's clear who owns what problem, and follow for more cyberpsychology breakdowns.
Script or transcript notes
The exact final spoken transcript is preserved below as Connor supplied it.
Sources
- Reprimand of ACRO Criminal Records Office (opens in a new tab)
Information Commissioner’s Office · August 7, 2026
Supports: Primary source for the incident chronology, patch-management and alert- handling findings, categories of potentially affected data, uncertainty about exfiltration, and remediation.
- Three intrusions at UK criminal records office went undetected for two years (opens in a new tab)
The Record · August 12, 2026
Supports: Independent reporting on the ICO reprimand and the duration and context of the incident activity.
- Bystander intervention in emergencies: Diffusion of responsibility (opens in a new tab)
Journal of Personality and Social Psychology
Supports: Primary study supporting the 85% versus 31% seizure-reporting comparison. The study did not examine cybersecurity teams or the ACRO incident.
Related cases
Video breakdownThe Door Was Never Locked
Anthropic’s Claude models reached real systems during controlled cybersecurity evaluations because an intended simulation retained live internet access. The lesson is not simply that the models crossed a line. It is that the environment did not technically enforce the line.