The critical CMS update remained undone because responsibility for applying it was unclear. The UK Information Commissioner’s Office found that weak ownership, ineffective patch management and inadequate investigation of security alerts at ACRO allowed an actively exploited flaw to remain exposed.
That finding changes how the failure should be understood. Looking for the engineer who missed an update may produce a name, but it does not explain why a critical task could sit between teams without a clear owner, deadline or escalation path.
The patching failure started with unclear ownership
A security bulletin can identify an affected product, describe the risk and recommend an update. None of that determines who inside an organisation must act.
That decision belongs to governance. Someone must know which systems run the vulnerable software, who operates each instance, who can approve downtime, who applies the patch and who verifies the result. If those duties sit across security, infrastructure, application support and an external supplier, the handoffs need to be explicit.
The ICO’s findings at ACRO point to a breakdown in that chain. Responsibility for critical CMS updates was unclear, and patch management was ineffective. Those two weaknesses reinforce each other: a patch process cannot work reliably when nobody has unambiguous authority to move it forward.
This is why a spreadsheet containing patch dates offers limited reassurance on its own. A useful control must also show the accountable owner, the affected asset, the risk rating, the required completion date, any approved exception and evidence that remediation succeeded.
Without those fields, “assigned” can mean little more than “someone received an email.”
Security alerts need a decision path
The ICO also found that security alerts were not investigated adequately. That matters because patching and monitoring form a connected control loop.
A vulnerable system may generate signs of scanning, exploitation attempts or unusual activity before a patch is applied. Those alerts should change the urgency of the response. A routine maintenance item can become an incident requiring containment, evidence preservation and senior attention.
The process therefore needs more than an alert destination. It needs a named person who reviews the signal, a defined threshold for escalation and a record of the decision taken. Closing an alert without documenting what was checked leaves the organisation unable to distinguish a false positive from a missed warning.
Teams should also test the awkward cases. What happens when an alert arrives outside working hours? Who acts if the CMS belongs to communications but runs on infrastructure managed by IT? Can a supplier patch immediately, or does the contract require approval first?
These details tend to look administrative until a live exploit compresses the available time. Then every unclear handoff becomes part of the attack surface.
Segmentation reduced the potential damage
One control did help at ACRO. According to the ICO’s findings, network segmentation limited the attacker’s movement.
That is an important result, but it should be interpreted carefully. Segmentation can restrict which systems an attacker reaches after gaining access. It does not repair the exposed CMS, establish who owns updates or prove that security alerts were handled correctly.
The distinction matters when reviewing a security programme. Preventive controls reduce the chance of entry. Detective controls identify suspicious activity. Containment controls limit what happens next. A strong result in one category does not cancel a failure in another.
The ACRO case therefore provides evidence for layered defence while also showing its limits. Segmentation reduced the scope available to the attacker, buying the organisation protection that its patching process had failed to provide. Relying on that outcome would be a mistake. The next vulnerable system may sit in a different segment or hold data valuable enough that lateral movement is unnecessary.
This resembles the authority problem examined in Priya’s Plugin Risk. The Deploy Window Is Closing.: boundaries matter most when they are defined before the deadline becomes an emergency.
Make one person answerable for the update
The practical response is to assign accountability at the system level, before the next critical advisory arrives.
Each internet-facing service should have one named role responsible for confirming whether it is affected and driving remediation to completion. That person does not need to perform every technical step. They do need the authority to coordinate teams, escalate delays and produce evidence that the risk was addressed.
Organisations should test this arrangement with a short exercise. Select one critical CMS advisory and ask for the affected asset list, accountable owner, patch deadline, exception route, alert history and verification evidence. If any answer depends on finding the right person informally, the process remains fragile.
Supplier agreements deserve the same scrutiny. Contracts should state who monitors advisories, who approves emergency changes, how quickly critical updates must be applied and what proof the supplier provides afterward. “Managed service” is not a useful allocation of responsibility unless the underlying duties are written down.
The final check is simple: choose an internet-facing CMS and ask one person, by name or defined role, to show its current version, outstanding critical fixes and latest security-alert review. If the answer still requires a search for the owner, the governance failure is already visible.
Comments
No comments yet.