UK GDPR Article 32: Website Security the ICO Expects

UK GDPR Article 32 sets the security obligation that every UK controller and processor of personal data must meet. The text reads almost identically to EU GDPR Article 32 but the UK enforcement perimeter is shaped by ICO guidance and by reference to NCSC technical advice. This guide covers what Article 32 actually requires of a UK SME website, where the ICO has drawn the line in its enforcement record and the practical patch and encryption baselines a typical SME should target.

For a technical scan against the ICO's actual baseline, run a free check at /uk/en/scan.

What Article 32 says

Article 32 of UK GDPR requires a controller and processor to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." It lists four examples of what may be appropriate:

The pseudonymisation and encryption of personal data. The ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services. The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures.

These are examples, not a checklist. Article 32(2) says appropriateness must take into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing and the risk of varying likelihood and severity for the rights and freedoms of natural persons.

In practice the ICO has translated this into a layered expectation that increases with the sensitivity of the data being processed.

The five Article 32 layers the ICO actually checks

Reading the ICO's published reprimands and monetary penalty notices reveals which Article 32 layers it examines first. The pattern is consistent across published cases.

<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">Layer</th> <th className="border border-slate-300 px-3 py-2 font-semibold">What "appropriate" looks like for an SME</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Article 32 reference</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Encryption in transit</td> <td className="border border-slate-300 px-3 py-2">HTTPS on every page that handles personal data. Valid certificate. Modern TLS.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(a)</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Encryption at rest</td> <td className="border border-slate-300 px-3 py-2">Database-level encryption for special-category or financial data. Optional for low-risk SME data.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(a)</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Access controls and authentication</td> <td className="border border-slate-300 px-3 py-2">Unique accounts per user, least privilege, MFA on admin access, prompt deprovisioning on departure.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(b)</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Patching and update discipline</td> <td className="border border-slate-300 px-3 py-2">Critical patches within 14 days. Shorter for actively exploited CVEs. Documented inventory of software in use.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(b)</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Backup and restore</td> <td className="border border-slate-300 px-3 py-2">Off-site or off-line copy. Tested restore procedure. Documented RPO and RTO appropriate to the data.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(c)</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Regular testing</td> <td className="border border-slate-300 px-3 py-2">Annual review of technical controls. Vulnerability scans. Penetration test for higher-risk processing.</td> <td className="border border-slate-300 px-3 py-2">Art 32(1)(d)</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Staff training and organisational measures</td> <td className="border border-slate-300 px-3 py-2">Annual refresher. Phishing-simulation evidence. Documented incident-response plan.</td> <td className="border border-slate-300 px-3 py-2">Art 32 (organisational measures)</td> </tr> </tbody> </table> </div>

The ICO has been explicit in published decisions that organisations cannot defend an Article 32 finding by pointing only to technical measures. The British Airways monetary penalty notice (£20 million, 2020) examined both technical (network segmentation, log monitoring) and organisational (staff awareness, response procedures) failings.

NCSC guidance: the de facto SME baseline

The ICO's security guidance does not set fixed numerical thresholds for SMEs. Instead it references National Cyber Security Centre (NCSC) publications. The NCSC Small Business Guide is treated as the operational baseline for SMEs in ICO enforcement reasoning.

The Small Business Guide's five core actions form a practical Article 32 baseline:

Back up data, including the ability to restore from backups. Protect against malware (anti-malware on endpoints, application allow-lists where practical, careful download policies). Keep devices and software up to date (the source of the 14-day patch window). Use passwords to protect your data (unique, strong passwords plus MFA on admin access). Avoid phishing attacks (staff training plus technical filtering).

Cyber Essentials, the NCSC-backed certification scheme, formalises these into auditable controls. Cyber Essentials certification is not a legal requirement under Article 32, but ICO enforcement decisions have repeatedly noted its absence as relevant where the failing relates to controls the scheme would have addressed.

The patch window: where SMEs most often fall short

The most consistent Article 32 finding in ICO reprimands against SMEs is patch latency. A WordPress plugin, a CMS core version, an operating system or a server-side library left unpatched after a CVE is published is the single most common technical failing.

<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">CVE severity</th> <th className="border border-slate-300 px-3 py-2 font-semibold">NCSC patch window</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Aggravation if exploited in the wild</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Critical (CVSS 9.0+)</td> <td className="border border-slate-300 px-3 py-2">14 days from fix availability</td> <td className="border border-slate-300 px-3 py-2">Shorter (days, sometimes hours)</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">High (CVSS 7.0-8.9)</td> <td className="border border-slate-300 px-3 py-2">14-30 days</td> <td className="border border-slate-300 px-3 py-2">Treated as critical if exploited</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Medium (CVSS 4.0-6.9)</td> <td className="border border-slate-300 px-3 py-2">Within next planned release</td> <td className="border border-slate-300 px-3 py-2">Depends on exposure</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Low (CVSS &lt, 4.0)</td> <td className="border border-slate-300 px-3 py-2">Risk-based</td> <td className="border border-slate-300 px-3 py-2">Rarely fatal in isolation</td> </tr> </tbody> </table> </div>

For UK businesses on managed platforms (Shopify, Wix, Squarespace), patching is largely the platform's responsibility. For self-hosted WordPress, Drupal, Magento or custom stacks, the controller carries the duty. See the WordPress plugin verification guide for how to check whether a vulnerability claim is genuine before deciding to patch.

What "appropriate" looks like by data category

Article 32 scales with risk. The ICO's enforcement reasoning treats different data categories with materially different expectations.

<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">Data category</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Typical SME expectations</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Marketing list (name, email)</td> <td className="border border-slate-300 px-3 py-2">HTTPS, unique admin accounts, MFA on email-platform admin, regular backups.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">E-commerce orders (name, address, contact)</td> <td className="border border-slate-300 px-3 py-2">Above plus payment processor handles card data under PCI DSS. No card numbers stored locally.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Account holders with passwords</td> <td className="border border-slate-300 px-3 py-2">Above plus password hashing with modern algorithm (bcrypt, Argon2), brute-force protection.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Special category data (health, biometric, religious, political)</td> <td className="border border-slate-300 px-3 py-2">Above plus encryption at rest, audit logging of access, formal access-control review, annual penetration test.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Children's data</td> <td className="border border-slate-300 px-3 py-2">Above plus alignment with the ICO Age Appropriate Design Code.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Criminal-conviction data</td> <td className="border border-slate-300 px-3 py-2">Stricter access controls. DPA 2018 Schedule 1 condition required. Formal appropriate-policy document.</td> </tr> </tbody> </table> </div>

What Article 32 does not require

A common SME misconception is that Article 32 demands enterprise-grade security regardless of data risk. The ICO has been explicit that this is wrong. Article 32 is risk-proportionate.

A small marketing-list controller does not need a 24/7 SOC, an ISO 27001 certificate or a dedicated CISO. It does need the basic NCSC five and a documented response plan. A larger controller processing special category data at scale faces materially higher expectations.

The reverse is also true. A ten-person business cannot defend a major breach by pointing only to its size. The ICO has issued penalties against SMEs where the underlying failing was elementary (no MFA on admin accounts, decade-old unpatched plugins, default passwords).

Documenting Article 32 compliance

The accountability principle under UK GDPR Article 5(2) requires controllers to be able to demonstrate compliance. For Article 32, this means a documented record that can be produced if the ICO requests it.

A typical SME Article 32 record covers an inventory of systems and software in use with version numbers, the access-control policy and how it is enforced, the patching and update policy with target windows, the backup and restore arrangement with last-tested date, the incident-response plan with named owner and an annual review log showing the date and outcome of the last review.

The document does not need to be lengthy. The ICO has been more critical of substantively absent records than of brief ones.

What happens when Article 32 fails

If a personal-data breach occurs and an Article 32 failing is part of the cause, two consequences follow. The breach itself triggers the Article 33 notification clock (72 hours from awareness to notify the ICO, where risk to individuals is likely). The Article 32 failing becomes part of the ICO's investigation and may lead to a separate finding.

Co-operation, prompt remediation and a credible Article 32 record significantly affect outcome. See the ICO investigation process for the four-stage procedure and what the ICO actually checks on your website for the specific technical checks that often follow a breach notification.

For the broader compliance position, see GDPR compliance for UK businesses and UK GDPR fines under the ICO.

---

This is technical analysis, not legal advice. For Article 32 questions related to special category data, regulated sectors or live or recent breaches, take advice from a data-protection specialist before acting.