When the Criminal Records Office (ACRO) discovered unauthorized access to its Kentico CMS between August 2022 and March 2023, exposing sensitive data on over 10,000 individuals, the ICO's reprimand didn't focus on sophisticated attack vectors. Instead, it highlighted something far more mundane: nobody was clearly responsible for applying CMS patches.
You're facing a similar decision right now, even if you don't realize it. Your organization uses multiple systems. Some are managed by your MSP. Others fall to specialized vendors. Still others sit in-house. The question isn't whether you need patch management, it's who specifically owns it for each system in your environment.
The Decision You're Actually Making
You're choosing between three accountability models for security updates:
- Centralized ownership, one team identifies, assesses, and applies all patches across all systems.
- Distributed responsibility, different teams own different systems, with coordination protocols.
- Vendor-managed patching, external parties handle updates under contract.
The wrong choice doesn't just create gaps. It creates the illusion of coverage while leaving critical systems unmonitored. ACRO's MSP patched the OS. The web development supplier could apply CMS patches but wasn't responsible for identifying when patches were needed. ACRO itself didn't monitor for required updates. Three parties, zero accountability.
Key Factors That Determine Your Path
Before you assign responsibility, assess these four factors:
System complexity and interdependencies. If your CMS integrates with authentication systems, databases, and third-party APIs, patching requires coordination. A single team needs visibility across the stack to assess impact and sequence updates properly.
Contractual clarity with vendors. Review your MSP and vendor agreements. Does "managed services" include patch identification, or just application? The distinction matters. ACRO's arrangement split identification from implementation, creating a structural gap.
Internal technical capability. Can your team assess patch criticality, test updates in non-production environments, and roll back failed deployments? If not, vendor-managed patching may be necessary, but only with explicit contractual requirements for monitoring and escalation.
Regulatory requirements under Article 32 GDPR. Technical and Organisational Measures must be appropriate to the risk. Processing special category data demands documented accountability for security controls. Ambiguity fails the "appropriate measures" test.
Path A: Centralized Ownership
Choose centralized ownership when:
- You process high-risk data categories (special category, criminal offense, children's data).
- Your systems are tightly integrated.
- You have in-house technical capability.
- You need audit-ready documentation of security decisions.
Implementation requirements:
Designate a specific team (typically InfoSec or IT Operations) as the single point of accountability. They maintain a complete asset inventory, subscribe to vendor security advisories for every system, assess each patch against your risk register, and document decisions to apply, defer, or reject updates.
This team doesn't necessarily apply every patch themselves. They can delegate implementation to specialists. But they own the monitoring and decision-making.
What this solves: The ACRO scenario becomes impossible. One team knows every system exists, monitors for patches, and escalates when vendors don't provide timely updates.
Trade-off: Requires dedicated resources. For a mid-sized organization processing sensitive data, expect 1-2 FTE minimum to maintain effective patch management across 50+ systems.
Path B: Distributed Responsibility with Coordination Protocols
Choose distributed responsibility when:
- You have distinct business units with separate technical teams.
- Systems are loosely coupled.
- You process primarily standard personal data.
- You need flexibility for specialized systems.
Implementation requirements:
Create a RACI matrix that maps every system to a responsible owner. Each owner monitors their assigned systems and applies patches according to a documented timeline (typically: critical patches within 72 hours, high-priority within 30 days, routine within 90 days).
Establish a coordination layer, a security council or change advisory board that meets weekly. Owners report patch status, flag dependencies, and coordinate maintenance windows.
What this solves: Distributed ownership can work if you eliminate ambiguity. Every system has exactly one owner. That owner knows they're accountable.
Trade-off: Coordination overhead. You need governance processes to prevent gaps at system boundaries. Monthly audits should verify that every system in your CMDB has an active owner who's monitoring for patches.
Path C: Vendor-Managed with Contractual Guarantees
Choose vendor-managed patching when:
- You lack in-house expertise for specialized systems.
- Your vendor has better visibility into their own product's vulnerabilities.
- You're willing to pay for managed security services.
Critical contractual requirements:
Your agreement must specify:
- Vendor will monitor for security updates and notify you within 24 hours of vendor release.
- Vendor will assess applicability to your configuration.
- Vendor will apply patches within your defined timeline or provide written justification for delay.
- Vendor will provide monthly attestation of patch compliance.
- You retain the right to audit patch management processes.
What this solves: Transfers technical burden to specialists who know their own products.
Trade-off: You're dependent on vendor performance. The ICO noted ACRO's web development supplier could apply CMS patches but wasn't responsible for identifying when patches were needed. That contractual gap created the vulnerability. Your SLA must close it.
Active Monitoring Isn't Optional
Regardless of which path you choose, you need security monitoring with defined escalation. ACRO had Trend Micro alerts that went unreviewed. The ICO stated explicitly: "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."
Assign a specific person to review security alerts daily. Not a team. Not a shared mailbox. A named individual who's accountable for investigating warnings and escalating anomalies within defined timeframes (typically 4 hours for critical alerts, 24 hours for high-priority).
Summary Matrix
| Factor | Centralized | Distributed | Vendor-Managed |
|---|---|---|---|
| Best for data risk | Special category, criminal offense data | Standard personal data | Depends on contract strength |
| Resource requirement | 1-2 dedicated FTE | 0.25 FTE per system owner + coordination overhead | Vendor cost + oversight |
| Audit readiness | High (single documentation source) | Medium (requires aggregation) | Depends on vendor reporting |
| Gap risk | Low (if resourced properly) | Medium (coordination failures) | High (if contract is ambiguous) |
| Speed to patch | Fast (direct control) | Variable (depends on owner availability) | Variable (depends on vendor SLA) |
The ICO's guidance is clear: "Organizations must ensure there is clear accountability for identifying, assessing and applying security updates." Clear means documented. Accountability means a specific person or team, not a general function. Choose your model, document the assignment, and verify monthly that every system has an active owner who's monitoring for patches. That's how you avoid becoming the next reprimand case study.
