ICO Enforcement Patterns Against UK Tech Functions: Six Practical Lessons

Every major ICO fine since early 2025 has been a security-failure case under Article 32, not a privacy-policy case. Capita, Advanced Computer Software, 23andMe, and LastPass — the pattern across all four is specific enough to extract direct, technical lessons, not just a general reminder to take security seriously.

Average ICO fine values have risen sharply — from around £380,000 in 2024 to just under £3 million in 2025, and already averaging over £3 million so far in 2026. Fewer penalties, but materially larger ones, concentrated specifically on security failings rather than the marketing and cookie-consent breaches that used to dominate ICO enforcement. This is a reading of the six specific, technical lessons the recent cases actually teach.

Who this is for

• The CTO or CISO at a UK organisation benchmarking security controls against what the ICO has actually penalised, not a generic best-practice list.
• The board reviewing whether the technology function’s incident response would hold up against the specific standard recent ICO decisions have set.

Lesson one: MFA absence is now a de facto baseline failure

The ICO hasn’t issued a prescriptive technical standard mandating multi-factor authentication, but its enforcement record now treats MFA on internet-facing and remote access systems as an Article 32 baseline regardless. Advanced Computer Software’s £3.07 million fine specifically cited a customer account without MFA as a core failing; 23andMe’s £2.31 million fine cited failure to mandate MFA on accounts holding genetic data. An organisation without MFA enforced on every internet-facing and remote-access system is, on current enforcement precedent, already exposed on this point alone.

Lesson two: fast notification is not, by itself, a mitigating factor

Capita notified the ICO within 14 hours of its breach — well inside the 72-hour deadline — and the ICO explicitly found this was not a mitigating factor in the final £14 million penalty. LastPass’s “good” cooperation was similarly found not to go “beyond what is reasonably to be expected.” The lesson is specific: the ICO is assessing sustained, genuine diligence throughout an incident, not crediting a single fast administrative step. A breach response plan optimised around hitting the notification deadline, without equivalent investment in the technical containment that actually limits harm, is solving for the wrong metric.

Lesson three: processors are no longer shielded by the controller relationship

Advanced’s fine was the ICO’s first major enforcement action against a data processor rather than a controller — a genuine precedent shift. For years, processors operated with limited direct exposure to ICO action; that era is over. Any organisation processing data on behalf of others — cloud providers, SaaS platforms, outsourced service providers — should now assume its own technical controls will be assessed directly, regardless of what the controller contract says about where responsibility sits.

Lesson four: fine calculations use group revenue, not the UK entity’s turnover

LastPass was owned by an investment holding company, and the ICO based its fine on the holding company’s global revenue, not LastPass’s own turnover — resulting in a penalty representing roughly 8.5% of LastPass’s own revenue specifically. An organisation assessing its own maximum exposure under UK GDPR needs to model against group-level turnover if it sits inside a larger corporate structure, not the standalone UK entity’s figures — the ICO has shown it will look through the corporate structure to the parent’s balance sheet.

Lesson five: known, unremediated vulnerabilities are a specific aggravating factor

Capita’s vulnerabilities had been flagged internally on at least three separate occasions before the attack and were not remedied — the ICO treated this specifically as an aggravating factor, distinct from the underlying technical gap itself. A vulnerability management process that identifies risks but doesn’t have a forcing function to actually close them creates a documented record that becomes evidence against the organisation, not evidence of diligence — a known, tracked, unremediated finding is a worse position under scrutiny than a genuinely undiscovered one.

Lesson six: privilege architecture is a specific, named control the ICO checks for

The ICO’s Capita findings specifically identified the absence of a tiering model for administrative accounts as a distinct failing — this allowed attackers to escalate privileges and move laterally across multiple domains once inside. This isn’t a general “access control was weak” finding; it’s a specific architectural gap the ICO named directly. A technology function’s privileged access management should be reviewed specifically against this standard — genuine administrative account tiering, not just role-based access control applied uniformly regardless of privilege level.

What this means going into 2026

The Data (Use and Access) Act 2025, in force from February 2026, raised PECR fine ceilings to the same £17.5 million or 4% of global turnover level as UK GDPR, and gave the ICO binding assessment notices and compulsory interview powers that materially strengthen its fact-finding ability before a penalty is even issued. A new structured settlement framework offers discounts of up to 40% for early resolution — mirroring the FCA and Ofcom approach — which makes early, genuine engagement with an ICO investigation a more clearly rewarded strategy than contesting it.

What a defensible posture demonstrates

1. MFA enforced on every internet-facing and remote-access system, treated as a non-negotiable baseline.
2. Incident response measured on sustained technical containment quality, not just notification speed.
3. Processor-side technical controls assessed and evidenced independently of the controller contract’s liability allocation.
4. Maximum fine exposure modelled against group-level turnover where the organisation sits inside a larger corporate structure.
5. A vulnerability management process with a genuine forcing function to close identified findings, not just track them.
6. Administrative account tiering specifically reviewed and evidenced, not assumed to be covered by general access control.

How we engage with this

We read security postures against the specific patterns recent ICO enforcement has actually penalised — not a generic controls checklist — as a Technology Control Review. The output is a written assessment identifying where the organisation’s controls would or wouldn’t hold up against current enforcement precedent.

We don’t run penetration tests. We don’t handle ICO investigations. We don’t sell security software. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your security controls haven’t been checked against the specific ICO findings from the last eighteen months, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.