When the UK's Information Commissioner's Office reprimanded ACRO Criminal Records Office for a 2023 data breach affecting over 10,000 individuals, the root cause wasn't sophisticated malware or a zero-day exploit. It was something far more mundane: patch management failures and ignored security alerts.
These myths persist because they let organizations shift accountability rather than confront uncomfortable truths about their security posture. If your team believes any of the following, you're vulnerable to the same failures that exposed names, dates of birth, National Insurance numbers, passport details, biometric data, and criminal offense records in the ACRO incident.
Myth 1: "Our MSP handles patches, so we're covered"
Reality: Your managed service provider handles what you've contractually defined, nothing more.
In the ACRO breach, the MSP applied operating system patches but not patches for the Kentico content management system. The web development supplier could apply CMS patches when directed but wasn't responsible for identifying when patches were required. ACRO itself didn't monitor for required security patches, creating a coverage gap that attackers exploited for seven months.
You need a patch management responsibility matrix that maps every system component to a specific owner. Document who identifies vulnerabilities, who assesses severity, who applies updates, and who verifies successful deployment. If you can't name the person responsible for patching your CMS, your customer portal, or your third-party integrations, you have the same gap ACRO did.
Myth 2: "Installing security tools equals having security monitoring"
Reality: Tools generate alerts. Humans must review, investigate, and act on them.
ACRO had Trend Micro solutions installed to detect and quarantine malware. The system generated alerts. Those alerts went unreviewed and unacted upon. According to the ICO, "Had the alerts been investigated by ACRO at the time, and an appropriate response conducted, it is likely that further malicious activity could have been prevented."
Your security monitoring process must answer three questions: Who reviews alerts daily? What's the escalation path for confirmed threats? How do you verify that critical alerts trigger investigation within defined timeframes? If your security dashboard shows alerts from last week that no one's touched, you're not monitoring, you're just logging.
Myth 3: "We'll know when we've been breached"
Reality: Poor record-keeping can leave you uncertain whether data was exfiltrated.
The ICO noted that ACRO's poor record keeping meant "it remains unclear whether they ever exfiltrated the data on 10,920 victims." The attacker had unauthorized access between August 2022 and March 2023, but the organization couldn't definitively determine what left the network.
Your incident response structure must include logging sufficient to reconstruct attacker activity. This means centralized log collection with adequate retention periods, baseline traffic patterns to identify anomalies, and documented procedures for forensic analysis. If you discovered a breach tomorrow, could you tell regulators and affected individuals exactly what data was accessed?
Myth 4: "Security is IT's problem"
Reality: Effective security requires clear governance across technical and business functions.
The ACRO breach resulted from accountability gaps, not just technical failures. The MSP, the web development supplier, and ACRO each had partial responsibility for security, but no one had complete oversight of the attack surface.
ICO group manager Jonathan Balmforth stated: "Having the right policies, responsibilities and oversight arrangements in place is just as important as having the right technology." Your governance structure must define who owns security decisions for each system, who has authority to halt operations when vulnerabilities are discovered, and who reports security metrics to executive leadership.
Myth 5: "Network segmentation means a breach won't hurt us"
Reality: Segmentation reduces blast radius but doesn't excuse prevention failures.
The ICO acknowledged that ACRO had network segmentation in place, which limited the attack's scope. This likely influenced the decision to issue a reprimand rather than a financial penalty. But segmentation is a containment control, not a preventive one.
Your defense-in-depth strategy needs both. Segmentation protects you when preventive controls fail, but you still need patch management, security monitoring, access controls, and vulnerability scanning working correctly. Don't let one layer of defense excuse failures in others.
What to do instead
Start with the ICO's guidance, which applies regardless of your jurisdiction:
Define patch management accountability. Create a single document that lists every system component, the party responsible for identifying required patches, the party responsible for applying them, and the maximum time between patch release and deployment based on severity level. Review this quarterly as your technology stack changes.
Implement active alert monitoring. Assign specific individuals to review security alerts daily. Document what constitutes a critical alert requiring immediate escalation versus routine events. Track mean time to investigate and mean time to remediate. If alerts pile up unreviewed, you need either more staff or better alert tuning.
Test your incident response structure. Run a tabletop exercise where you discover unauthorized access to a system with poor logging. Can your team determine what data was accessed? Who has authority to engage forensic specialists? Who communicates with regulators? Document the gaps you find.
Establish security governance rituals. Your risk committee should review a cybersecurity risk register quarterly that includes patch compliance rates, mean time to patch critical vulnerabilities, and security alert response metrics. Executive leadership needs visibility into these operational realities, not just strategic briefings.
The ACRO breach exposed over 10,000 individuals' sensitive data because the organization believed it had security when it only had security products. Your patch management and monitoring processes are only as strong as the accountability structures supporting them. If you can't name who's responsible for each component, you're one unpatched CMS away from your own reprimand.
