These questions stem from a conversation with a Data Protection Officer (DPO) after the ICO reprimanded the Criminal Records Office. The breach affected over 10,000 people, exposing biometric data and criminal records, and went undetected for seven months. The technical failures weren't complex: unpatched CMS software and ignored security alerts. The root cause was organizational: nobody owned the problem.
If you're working with managed service providers or splitting security responsibilities across multiple vendors, these questions will likely resonate. They're what people ask when trying to determine who's responsible for what.
Q1: We use an MSP for infrastructure. Does that mean they handle all our patching?
No, and this is exactly where ACRO got into trouble.
Their MSP handled operating system patches but not the Kentico CMS patches. Their web development supplier applied CMS patches when told to but didn't monitor when patches were needed. ACRO itself wasn't watching either. The result: a seven-month gap where nobody was minding the store.
You need a written responsibility matrix that covers every system processing personal data. For each one, document:
- Who monitors for available patches
- Who assesses whether a patch is needed
- Who tests the patch
- Who applies it
- Who verifies it worked
- What the SLA is for critical security patches
If the answer to any of these is "I think the MSP does that," you don't have clarity. You have a gap.
Q2: Our security tools generate hundreds of alerts. How are we supposed to review them all?
You're not supposed to review them all equally, but you must have a process ensuring critical alerts get investigated.
ACRO had Trend Micro installed, generating alerts when it detected and quarantined malware. Nobody reviewed them. The ICO noted that if those alerts had been investigated, further malicious activity could have been prevented.
Set up alert triage rules:
- Critical alerts (malware detection, unauthorized access attempts, data exfiltration indicators) go to a specific person or team with a defined response time
- Medium-priority alerts get reviewed daily or weekly depending on risk
- Low-priority alerts can be batched for monthly review
The key is documentation. If a supervisory authority asks "who reviews these alerts and how quickly," you should be able to show them a procedure and logs proving it happens. Article 32 requires appropriate technical and organizational measures, and "we have the tool installed" isn't sufficient if nobody's acting on what it tells you.
Q3: Can we just put in our contract that the processor is responsible for security?
You can put it in the contract, but it doesn't transfer your Article 32 obligation.
You're still the controller. You're still responsible for implementing appropriate technical and organizational measures. If your processor fails to patch a system and that leads to a personal data breach, the supervisory authority will ask what oversight you had in place.
Your processor contract should specify security obligations under Article 28(3), but you also need:
- Regular security reviews (quarterly at minimum for systems processing special category data)
- Documented evidence that patches are being applied according to your agreed schedule
- Incident response procedures that define when the processor must notify you
- Audit rights so you can verify they're doing what they said they'd do
The ICO's advice was explicit: define who is responsible for identifying, assessing, and implementing security updates across all systems. If you can't answer that question for every system in scope, you've got work to do.
Q4: What counts as "effective monitoring" for security alerts?
The ICO didn't define a specific standard, but you can infer one from what went wrong at ACRO.
Effective monitoring means alerts are reviewed, investigated, and escalated so threats are identified before they become major incidents. At minimum:
- Someone with appropriate security knowledge reviews alerts within a defined timeframe
- There's a documented escalation path for alerts that indicate active threats
- You can demonstrate that reviews happened (logs, tickets, sign-offs)
- When an alert indicates malicious activity, there's a response procedure that gets followed
If your security tools are generating alerts that nobody sees for days or weeks, you don't have monitoring. You have expensive log storage.
Q5: We've got multiple suppliers handling different parts of our infrastructure. How do we avoid gaps?
Create an accountability map for every security control.
ACRO's problem was that three parties (the MSP, the web development supplier, and ACRO itself) each thought someone else was handling CMS patch monitoring. The ICO specifically noted "there was an absence of oversight for this important security control."
Your accountability map should cover:
- Patch management (OS, applications, CMS, plugins)
- Security monitoring and alert response
- Vulnerability scanning
- Access control reviews
- Backup verification
- Incident response
For each control, name the party responsible and the party providing oversight. If you're the controller, you're providing oversight even when a processor is responsible for execution. That means you need reporting, you need evidence, and you need to review it.
Q6: How often should we be reviewing our supplier security arrangements?
At least annually for standard systems, quarterly for anything processing special category data or large volumes of personal data.
But you should also review:
- After any significant change to systems or processing activities
- After a security incident (yours or a similar one in your sector)
- When a new vulnerability affects systems in your environment
- When supervisory authority guidance changes expectations
The ICO took into account that ACRO had implemented remedial measures after the breach, including improved security monitoring and better network segmentation. That's good, but it came after 10,920 people had their sensitive data exposed. Your review cycle should catch problems before the ICO does.
Where to go for more
The ICO's reprimand includes specific advice for organizations: define responsibilities for security updates, ensure alerts are actively monitored and acted upon, and get the basics right with patch and vulnerability management. Those aren't revolutionary ideas, but ACRO's breach shows what happens when you assume they're handled.
If you're not certain who owns patch management for every system processing personal data, start there. Build the responsibility matrix. Get written confirmation from your processors. Set up the oversight reporting. The next time someone asks "who's making sure that system is patched," you'll have an answer that satisfies both your CISO and your supervisory authority.
