Outsourcing patching did not outsource the duty: what the ICO’s ACRO reprimand means for supplier clauses

The ICO reprimand of the ACRO Criminal Records Office is dated 7 August 2026 and was published on 12 August 2026. It follows an incident in which hackers accessed ACRO’s website and content management system between August 2022 and March 2023, with up to 10,920 people potentially affected.

The ICO reprimanded ACRO under Article 32(1), (1)(b) and (1)(d) UK GDPR. The ICO has stated that ACRO used third-party providers for security services, including patch management, but did not set clear accountability across those suppliers. The finding is not that outsourcing is improper. It is that outsourcing without defined responsibility across the supply chain left the security arrangements unclear.

The practical reading for any controller using vendors is that the Article 32 security duty stays with the controller. A supplier can carry out patching, monitoring or hosting, but the regulator looks at whether the controller set up clear responsibility for those functions, not only at who held the keyboard.

That is a drafting point as much as a compliance point. Where several suppliers each handle a layer of security, a contract that says only that the supplier will use appropriate security measures leaves the allocation of tasks to implication. The ACRO reprimand is a reminder of what an unclear allocation can look like to a regulator.

A note on recency. The reprimand is older than 30 days. We include it because it is still the clearest recent ICO statement on supplier accountability, not because it is the newest enforcement notice.

(Case law reference – not recent, included for legal interpretation.) In DSG Retail Ltd v Information Commissioner [2026] EWCA Civ 140, the Court of Appeal (Civil Division), per Warby LJ, on 19 February 2026, allowed the ICO’s appeal and the Upper Tribunal’s decision was reversed.

The court held that the security duty requires a controller to safeguard personal data “against any unauthorised or unlawful processing… whether or not the person carrying out that processing would be able to identify the individual(s)”. Whether data is personal data is judged from the controller’s perspective. The case arose under the Data Protection Act 1998 and the Directive, following a 2017-18 card-system hack, and the court noted that Article 32 UK GDPR imposes the same duty.

For a contract, the relevance is scope. A controller cannot argue that the security duty falls away because an attacker, or a supplier handling the data, could not identify the individuals. Security terms should therefore be drafted by reference to the data the controller holds, not by reference to what the supplier can see.

It is worth being precise about what the Court of Appeal did not decide. DSG Retail concerns the scope of the security duty owed by a controller. It does not decide processor or supplier liability, and it should not be relied on as authority for how responsibility is divided between a controller and its vendors.

That division is therefore a matter for the contract and for the regulator’s view on the facts of each case, as in the ACRO reprimand. The two sources work together: the reprimand shows the ICO’s concern about unclear accountability across suppliers, and DSG Retail shows how wide the controller’s duty runs. Neither tells a controller how a loss will be shared with a supplier. Only the contract does that.

Most supplier contracts set a liability cap by reference to annual fees. That figure is chosen for commercial reasons and bears no relationship to the cost of a security incident, which can involve regulatory action, notification to affected individuals and remediation.

If the controller remains accountable to the regulator while the supplier’s exposure is capped at fees, the gap falls on the controller. A cap that looks acceptable in a low-risk services schedule can look very different once the supplier is responsible for patching a public-facing system that holds personal data.

This is advice on how to approach the negotiation, not a statement of what a court would hold. The practical step is to decide, before signing, which security failures should sit outside the general cap or under a separate, higher cap, and to record that decision in the liability clause.

Five terms address the weakness the ICO identified at ACRO. They are drafting recommendations for controllers who rely on suppliers for security services.

• Specific patch timelines, stated by severity and measured from the date a patch is released, so that patching is a defined obligation and not a general standard of care.
• Alert escalation, setting out who the supplier tells, how fast, and through which channel when it detects suspicious activity.
• A named responsibility matrix, allocating each security function to a named party across every supplier in the chain, so that no function is left between providers.
• Audit rights, allowing the controller to verify patching, access controls and incident records, and to require evidence rather than assurances.
• Breach notification terms and a tested liability cap, with a fixed notification period to the controller, and a cap that reflects the controller’s regulatory exposure and not just the fees paid.