The ACRO case has demonstrated the role of ownership and accountability in patch management. How should CISOs and compliance leaders respond?
In August, the Information Commissioner’s Office (ICO) reprimanded ACRO Criminal Records Office (ACRO) after a run of attacks between July 2021 and June 2023 led to the exposure of 10,000 people’s sensitive details.
While ACRO escaped a fine, the ICO highlighted “basic cyber security failings”, including leaving a critical system unpatched for nearly four years because the organisation didn’t know who was responsible for updating it. This allowed the hackers to gain unauthorised access to the national policing unit’s website and content management system.
ACRO “did not ensure clear responsibility for identifying and monitoring critical CMS security updates, failed to maintain an effective patch management process, and did not adequately investigate security alerts that could have identified the hacker’s activity earlier”, according to the ICO.
Threat Debt
The ACRO case shows the risk of known weaknesses remaining unresolved, resulting in mounting “threat debt”, according to Andrew Woodford, CTO at Titania. “There was no plan in place to patch the website’s content management system, and nobody was monitoring it,” he points out.
Yet ACRO is not the only organisation slow to patch its systems. According to the 2026 Verizon Data Breach Investigations report, the median time to fully patch has risen to 43 days — up from 32 the previous year. Organisations fully remediated just 26% of the US Cybersecurity and Infrastructure Security Agency’s (CISA’s) known-exploited vulnerabilities, down from 38% the year before.
Somewhere in your estate there is a vulnerability “probably older than your CISO’s tenure”, says Ivan Milenkovic, vice president risk technology at Qualys. “Several people have probably seen it, and each had a good reason to leave it.”
He describes how easily a fix can stall because it sits between two teams or suppliers. “Each assumes the other has it in hand,” says Milenkovic.
Alternatively, the system owner might be nervous about downtime, and no one is prepared to overrule them to ensure the patch is deployed. “Sometimes, the asset isn’t in the inventory, so it never appears in a scan at all,” suggests Milenkovic. “Or you might find the server runs a legacy application whose author left years ago, and nobody wants to be the person who breaks the application now.”
Mounting Patches
While these issues can see patches delayed, remediation is even more crucial at a time when security vulnerabilities are mounting, at least partly due to increasing use of AI in bug hunting.
Titania’s Woodford acknowledges “a massive increase” in the number of published vulnerabilities, but he says this “doesn’t necessarily mean more risk”.
“Exploitability is a property of the deployed system, not the source code, so a high severity score doesn’t necessarily mean high risk in your environment,” Woodford explains.
In order to figure out what to tackle first, he advises asking a simple question: “What can get where? A critical flaw on an isolated system may matter less than a medium one on a router with a path to sensitive data.”
Vulnerabilities should be ranked using three questions, says Milenkovic: “Is the issue being exploited in the wild? Can an attacker reach it? What does the business lose if that asset does get attacked?”
In ACRO’s case, answering these questions would have shown how important the fixes were. Milenkovic points out that ACRO’s portal was running a version with multiple known, publicly documented vulnerabilities. “The server faced the public internet. The data exposed was valuable, including National Insurance numbers, passport and driving licence details, bank information, biometric data, and criminal offence information.”
Delaying a Patch
The general advice is to patch as quickly as possible, but there are sometimes legitimate reasons to delay remediation.
This could happen in environments where uptime and stability are critical, says Kelvin Lim, head of security engineering APAC at Black Duck. “If remediation needs to be delayed, organisations should implement compensating controls, increase monitoring, and formally track the risk.”
If a vulnerability cannot be fixed, someone needs to formally own that decision, Lim tells IO. “Documenting accepted risk creates accountability, captures the business rationale, and ensures the decision is reviewed over time. If it is not documented, it will be difficult to demonstrate that the risk was ever evaluated in the first place.”
In addition, it’s important that senior leaders are provided visibility of overdue critical vulnerabilities.
Leaders need to see what’s overdue, who owns it and why it’s stuck, because “only they can make the trade-offs that unblock it”, according to Titania’s Woodford.
Boards should be able to see a list that shows critical vulnerabilities past their deadline on internet-facing or high-value systems, each with its age, its owner, and the reason it’s still open, adds Qualys’ Milenkovic.
At the same time, the CISO should not be accepting business risk on behalf of the business, says Milenkovic. “The signature belongs to the person whose budget, customers or licence absorbs the loss if it goes wrong.”
Monitoring and Patching
According to the ICO, ACRO’s failings centred around monitoring and patching. The two areas should not operate in separate silos, says Black Duck’s Lim. “Monitoring helps identify vulnerabilities, detect exploitation attempts, validate remediation efforts, and provide coverage when a fix cannot be applied immediately. Together they form a continuous cycle of identifying, reducing, and managing risk.”
ISO 27001:2022 Annex A Control 8.8 focuses on managing technical vulnerabilities by identifying risks, maintaining an asset inventory, assessing threats, and implementing mitigation measures to protect an organisation’s infrastructure. It emphasises proactive vulnerability management to strengthen information security.
Good vulnerability management is not about “patching everything immediately”, says Lim. He advocates clear ownership, risk-based prioritisation, defined remediation timelines, executive visibility, continuous monitoring, and disciplined exception management. “Mature organisations focus on reducing business risk, not closing the most tickets.”
A mature vulnerability programme produces “no heroics and very few surprises”, according to Qualys’ Milenkovic. “The board reports are short, and engineers aren’t pulling all-nighters on emergency patches, because the dangerous work was scheduled weeks ago. When a regulator asks a question, the answer comes from a system in minutes.”
In its reprimand to ACRO, the ICO said having the right policies, responsibilities and oversight arrangements in place is just as important as having the right technology.
With this in mind, CISOs and compliance leaders should treat vulnerability management as a “governance issue as much as a technical one”, says Lim. “Their role is to create accountability, ensure prioritisation aligns with business risk, provide executive visibility, and make sure risk decisions are documented and reviewed.”
Expand Your Knowledge
Blog: AI Is Supercharging Vulnerability Exploitation: What Happens Next?
Podcast: Phishing for Trouble S2 E8: What the Regulators Want
