When Britain's ACRO Criminal Records Office discovered it had been breached three times over nearly two years, investigators uncovered something more troubling than the attacks themselves: nobody knew whose job it was to stop them.
The Information Commissioner's Office reprimand published this week reveals a pattern you may recognize in your own organization. Trend Micro quarantined four separate attempts to install Mimikatz credential-harvesting tools. All went unheeded. The Kentico CMS hadn't been patched since September 2019, despite multiple known vulnerabilities. Nobody applied the fixes because ACRO, its managed service provider, and its web development supplier all assumed someone else was responsible.
This wasn't a sophisticated zero-day exploit. This was organizational failure dressed up as a technical problem.
Why These Mistakes Keep Happening
The accountability gap isn't new, but it's getting worse. As your security stack grows, you add managed service providers, specialized vendors, and cloud platforms. Each handoff creates ambiguity about who owns what. You're running ISO/IEC 27001 controls for information security management, but if nobody knows who's responsible for A.12.6.1 (management of technical vulnerabilities), the control exists only on paper.
The problem compounds when you treat security as a technical function rather than an organizational one. Your CISO can't patch every system personally. Your SOC can't investigate every alert. Clear accountability means documented processes that specify who reviews what, when they escalate, and what happens when they don't.
Mistake 1: Assuming Vendors Own Patch Management
ACRO's Kentico system went unpatched for nearly four years. The vendor shipped fixes. Nobody applied them.
Why it happens: You sign a managed services agreement and assume "managed" means "patched." The vendor assumes you're handling application-layer updates because they only manage infrastructure. Your internal team thinks the vendor handles everything.
Real consequence: Between July 2021 and June 2023, attackers exploited publicly documented vulnerabilities. One group maintained persistent access for seven months, staging data on just under 11,000 people for exfiltration in February 2023.
The fix: Document patch ownership in your vendor contracts using RACI matrices (Responsible, Accountable, Consulted, Informed). For every system component, specify who applies patches, who verifies deployment, and who escalates when patches aren't applied within your defined SLA. NIST Cybersecurity Framework (CSF) 2.0 function PR.IP-12 calls for vulnerability management plans. Make yours specific enough that a new hire could execute it without asking questions.
Mistake 2: Treating Security Alerts as Optional Reading
ACRO's Trend Micro solution flagged malicious activity throughout the attack period. Nobody reviewed the alerts. When the ICO asked about the business process for handling security alerts, ACRO couldn't identify one.
Why it happens: Your SIEM generates thousands of alerts daily. You don't have staff to review them all, so you rely on automated rules and thresholds. Low-priority alerts pile up. Critical alerts get buried in noise. Eventually, your team stops checking the queue because it feels futile.
Real consequence: The ICO concluded that if ACRO had acted on the alerts, further malicious activity could have been prevented. Attackers had seven months of persistent access while detection tools screamed into the void.
The fix: Define alert triage as a mandatory operational process, not an optional task. Assign specific roles to review alerts within defined timeframes. If you're following NIST SP 800-53, control SI-4 (System Monitoring) requires you to review and analyze system monitoring information. Build escalation triggers: if an alert sits unreviewed for 24 hours, it escalates automatically. If you can't staff alert review adequately, reduce alert volume by tuning your rules rather than ignoring the queue.
Mistake 3: Leaving Role Definitions Vague During Vendor Transitions
ACRO involved a managed service provider and a web development supplier. When investigators asked who was responsible for security monitoring, nobody could answer.
Why it happens: You migrate to a new platform or onboard a new vendor. During transition, everyone's focused on functionality. Security responsibilities get documented in scattered emails and meeting notes, never consolidated into a single source of truth. Six months later, when an incident occurs, you discover the gaps.
Real consequence: ACRO couldn't establish what business process existed for assessing security alerts. The organization told regulators it didn't know which roles were responsible for reviewing and escalating threats. That's not a technical failure. That's a governance breakdown.
The fix: Build a security responsibility matrix before you sign the vendor contract. Map every ISO/IEC 27001 Annex A control to an internal role or vendor role. For shared responsibilities, document the handoff points. If your vendor monitors infrastructure but you handle application logs, specify which log sources each party reviews and how you coordinate during investigations. Update your Statement of Applicability to reflect vendor-shared controls, and audit vendor compliance annually.
Mistake 4: Assuming Segmentation Means You're Safe
The ICO noted that network segmentation prevented attackers from reaching ACRO's core policing systems. ACRO treated this as evidence the breach wasn't severe. The regulator cited it as a mitigating factor when deciding not to impose financial penalties.
Why it happens: You implement segmentation, see it block lateral movement during tests, and assume it's sufficient defense-in-depth. You deprioritize monitoring on segmented systems because "they can't reach the crown jewels anyway."
Real consequence: Attackers still compromised sensitive data on just under 11,000 people, including victims of domestic violence. ACRO notified more than 84,000 people on a precautionary basis. Segmentation limited the blast radius but didn't prevent the breach. You still face regulatory action, reputational damage, and operational disruption.
The fix: Treat segmentation as containment, not prevention. Every segment still needs patch management, alert monitoring, and access controls. If you're mapping to NIST Cybersecurity Framework (CSF) 2.0, PR.AC-5 addresses network integrity protection through segmentation. That control assumes you're also implementing PR.IP-12 (vulnerability management) on every segment. Don't let segmentation create security blind spots where you assume "it's isolated, so it's fine."
Mistake 5: Failing to Retain Sufficient Logs for Investigation
When ACRO's forensic investigators tried to determine if data was exfiltrated, they couldn't confirm it. The organization hadn't retained adequate logs.
Why it happens: Logs consume storage. You set retention policies based on cost rather than investigation needs. You keep 30 days because that's the vendor default, not because you've calculated how long an investigation takes.
Real consequence: ACRO found evidence that attackers staged data for exfiltration in February 2023 but couldn't prove whether exfiltration occurred. That uncertainty forced the organization to notify more than 84,000 people on a precautionary basis, far more than the 11,000 whose data was confirmed staged.
The fix: Set log retention based on your mean time to detect (MTTD) plus investigation time. If it takes you 60 days to detect an incident and another 30 days to investigate, 30-day retention guarantees you'll miss evidence. NIST SP 800-53 control AU-11 requires you to retain audit records for incident response and analysis. Under the General Data Protection Regulation, if you can't determine the scope of a breach, you must assume worst-case when notifying affected individuals. Longer retention reduces notification scope and regulatory exposure.
Prevention Checklist
Before your next vendor review or security audit, verify:
- Patch ownership is documented in RACI format for every system component, with named roles (not just "IT team")
- Alert review is a scheduled operational task with defined SLAs and automatic escalation for missed reviews
- Vendor security responsibilities are mapped to specific controls in your Statement of Applicability or control framework
- Every network segment has monitoring, patching, and access controls documented in your asset inventory
- Log retention policies reflect your MTTD plus investigation time, not vendor defaults or storage cost optimization
- Security handoffs between internal teams and vendors are tested quarterly with tabletop exercises that identify role confusion
- Your incident response plan names specific individuals (with backups) responsible for each phase of response, not generic role titles
The ACRO breaches didn't require advanced persistent threats or nation-state resources. They required patience. Attackers waited while alerts piled up unread and patches went unapplied. Your controls only work if someone's accountable for operating them. Make that someone's name visible in your documentation, and you'll close the gap before regulators force you to.
