GDPR Article 32 Security of Processing Guide

Article 32 of the GDPR never lists a control you can tick off, so most organisations cannot show a regulator why their security is "appropriate to the risk". The article sets a test, not a standard: weigh the state of the art, cost, the nature, scope, context and purposes of the processing, and the risk to people, then choose and evidence measures that fit. This guide works through that test clause by clause, shows how to run the risk assessment the article expects, and sets out the evidence pack that turns a judgement into something you can defend. It is written for security leads, DPOs and assurance teams who already know the GDPR basics and need to apply Article 32 to real systems. For the wider GDPR picture, see the GDPR Compliance Guide for Security Teams.

Key takeaways

The duty is risk based and shared. Article 32(1) applies to controllers and processors alike, and both must pick measures that give a level of security appropriate to the risk.
Risk means harm to people, not to the business. Article 32(2) and recital 75 point the assessment at destruction, loss, alteration, disclosure and access, and at the physical, material and non-material damage that follows for individuals.
The four named measures are a floor for thinking, not a checklist. Pseudonymisation and encryption, ongoing CIA and resilience, timely restoration, and regular testing must each be considered and either applied or reasoned away in writing.
Cost and state of the art can shape measures but never excuse gaps. The ICO says costs do not justify inadequate measures; they help choose between adequate options.
Evidence is the deliverable. A recorded risk assessment, a mapping from risk to measure, and dated test results are what show compliance, and failure can draw fines under Article 83(4) of up to EUR 10 million or 2% of worldwide turnover.

What Article 32 actually requires

Article 32 has four paragraphs. Each one creates a different obligation, and each needs its own evidence.

Paragraph	What it says	What it means in practice	Evidence to keep
32(1)	Controller and processor implement technical and organisational measures for a level of security appropriate to the risk, taking account of state of the art, costs, nature, scope, context and purposes, and the likelihood and severity of risk to rights and freedoms. Points (a) to (d) list measures "as appropriate".	A documented selection process per processing activity or system, not one blanket control set.	Risk assessment, control baseline, rationale for each named measure.
32(2)	In assessing the appropriate level, account is taken in particular of risks from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.	Threat scenarios must cover accidents and availability, not only attackers and confidentiality.	Scenario list covering all three breach types.
32(3)	Adherence to an approved code of conduct (Article 40) or approved certification mechanism (Article 42) may be used as an element to demonstrate compliance.	Helps, but is one element. A general security certificate is not an approved GDPR mechanism.	Scheme approval reference, scope statement.
32(4)	Controller and processor take steps so that any natural person acting under their authority with access to personal data processes it only on instructions from the controller, unless law requires otherwise.	Least privilege, training, confidentiality terms and monitoring of staff and contractor access.	Access reviews, training records, confidentiality clauses, access logs.

Article 32 sits alongside Article 25 (data protection by design and default), Article 35 (DPIA for likely high risk processing) and Article 28 (processor terms, which must oblige the processor to take all measures required by Article 32). See the GDPR Article 28 Processor Guide for how that flows into contracts.

Running the Article 32 risk assessment

Recital 83 asks controllers and processors to "evaluate the risks inherent in the processing" and to implement measures to mitigate them. The ICO's guidance says to start with an information risk assessment and to consider how sensitive the data is and the harm a compromise could cause. A workable method has five steps.

Scope the processing: take each activity from your record of processing (Article 30) and list the systems, data categories, data subjects, volumes, locations, processors and access paths, including service accounts and integrations.
Rate impact on individuals: use the recital 75 harms: discrimination, identity theft or fraud, financial loss, reputational damage, loss of professional secrecy, unauthorised reversal of pseudonymisation, and loss of control. Raise the rating for special category or criminal offence data, children and other vulnerable people, profiling, and large scale processing.
Rate likelihood per scenario: for confidentiality, integrity and availability separately, consider exposure (internet facing or internal), who has access, third party paths, and known threat activity in your sector.
Select measures: map each scenario rated medium or above to controls, and record how each of points (a) to (d) has been considered. Where a named measure is not used, say why (for example, encryption at field level rejected because the dataset holds no direct identifiers and is already pseudonymised).
Record residual risk and owner: accept, reduce or escalate. A residual high risk to individuals that you cannot reduce is a trigger for a DPIA and, under Article 36, prior consultation with the supervisory authority.

ENISA's Handbook on Security of Personal Data Processing (2018) applies a similar approach for SMEs and is a useful worked reference. For the DPIA itself, see the DPIA Guide; Article 32 risk assessment and DPIA should share one scale so that results do not contradict each other.

Weighing state of the art and cost

State of the art: what is established and widely available today, not what is newest. Measures in common sector use become the reference point a regulator compares you against, and that bar moves over time, so review it at least yearly.
Cost: the ICO states that cost does not justify inadequate measures. Use cost to choose between options that each reduce the risk enough, and record the comparison.
Size: a small organisation can meet Article 32 with simpler measures if its risk is lower, but special category data or large volumes raise the bar regardless of headcount.

The four named measures, applied

The list in Article 32(1) is introduced with "inter alia, as appropriate", so it is neither exhaustive nor mandatory in every case. In practice a regulator will expect each to be considered for every processing activity.

Measure	Questions to answer	Typical decisions	Weak answers regulators see
(a) Pseudonymisation and encryption	Where is the data at rest and in transit? Who holds the keys? Can analytics or test work run on pseudonymised data?	Encrypt storage and backups, keys in a managed KMS or HSM with separate administration; pseudonymise for analytics and non-production.	Disk encryption only, with keys held by the same administrators as the data; production copies in test.
(b) Ongoing confidentiality, integrity, availability and resilience	Who and what can access the data, and how is that reviewed? How is integrity checked? What happens under load or attack?	MFA, least privilege, privileged access controls, segmentation, patching targets, logging of access to personal data.	Point in time hardening with no ongoing review of access or patch status.
(c) Timely restoration after an incident	What restore time is acceptable for the people affected? Has it been proven?	Recovery objectives per system set by impact on individuals; isolated or immutable backups; tested restores.	Backups exist but no restore has been timed; backup credentials share the main identity domain.
(d) Regular testing, assessment and evaluation	How is effectiveness measured, how often, and what happens to findings?	Vulnerability scanning, penetration testing, control self-assessment, tabletop exercises, internal audit with tracked remediation.	Test reports with no record of action or of reasons for not acting.

The ICO notes that the GDPR does not define "timely" restoration and gives the 3-2-1 backup approach as an example. See the Backup Security and Immutable Backup Guide, the Pseudonymisation Techniques Guide and the Penetration Testing Guide for the controls behind each row.

Organisational measures and Article 32(4)

The ICO is clear that information security covers physical and organisational measures as well as cyber security. Organisational measures that carry most weight in enforcement are:

Accountability: a named owner for day to day security with the authority and resources to act, plus an information security policy. The ICO says a formal policy document is not always required but helps demonstrate compliance.
Staff training: initial and refresher training on data protection duties, phishing, verifying callers and acceptable use.
Instructions only: Article 32(4) requires that people under your authority process personal data only on instructions. Pair role based access with confidentiality terms and monitoring of bulk export, unusual queries and access outside a person's role.
Third party access: processors must give sufficient guarantees, and the controller stays responsible for what they do. The contract must oblige the processor to meet Article 32 and allow audits.

Where identity fits

Article 32(4) is written about natural persons, but the same instruction principle should apply to the non-human identities that touch personal data: ETL jobs, integration accounts, API keys and AI agents. These often hold the broadest standing access and are rarely in an access review. Give each an owner, scope it to the datasets its purpose needs, prefer short lived credentials, and log its reads. See the Privacy in Security Logging and Monitoring Guide for logging access without creating a new privacy problem.

Building the Article 32 evidence pack

Under Article 5(2) and Article 24 the controller must be able to demonstrate compliance. For Article 32 that means an evidence pack per system or processing activity that a supervisory authority could read cold.

Evidence item	Contents	Refresh
Risk assessment	Scope, scenarios by breach type, impact and likelihood ratings, residual risk and owner	Yearly and on significant change
Measure rationale	How points (a) to (d) were considered, state of the art and cost reasoning	With the risk assessment
Control baseline	Configured controls with reference to the framework you use	On change
Test results	Scan and penetration test reports, restore tests, tabletop outputs, with dated remediation	Per test cycle
Access evidence	Access review sign off, privileged account list, service account owners	Quarterly for high risk data
Processor assurance	Due diligence, Article 28 terms, audit or report results	Yearly per processor
Incident learning	Breach register entries and the control changes they caused	After each incident

The breach register is required separately by Article 33(5), which obliges the controller to document every personal data breach. Linking each entry to the Article 32 assessment it tested is one of the strongest signals of a working programme. The Privacy Incident Assessment Template gives a structure for those entries.

Framework mapping

Article 32 does not mandate any framework, and the ICO notes that meeting a sector standard such as PCI DSS is not automatically compliance with the security principle. A mapped control framework does make the evidence pack faster to build.

Article 32 element	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
Risk assessment (32(1), 32(2))	RA-3 Risk Assessment	Clause 6.1.2 risk assessment; 5.34 Privacy and protection of PII
(a) Encryption	SC-8 Transmission Confidentiality and Integrity; SC-28 Protection of Information at Rest	8.24 Use of cryptography
(a) Pseudonymisation	SI-12 Information Management and Retention (supporting)	8.11 Data masking
(b) Access and least privilege	AC-6 Least Privilege; AU-2 Event Logging	5.15 Access control; 8.2 Privileged access rights
(c) Restoration	CP-9 System Backup; CP-10 System Recovery and Reconstitution	8.13 Information backup; 5.30 ICT readiness for business continuity
(d) Testing	CA-2 Control Assessments; CA-8 Penetration Testing	5.35 Independent review of information security; 8.8 Management of technical vulnerabilities
32(4) Instructions only	AC-6 Least Privilege	6.3 Awareness, education and training; 6.6 Confidentiality agreements

For a UK baseline, the ICO describes Cyber Essentials as a good starting point that may need to be exceeded. See the Cyber Essentials Guide.

Implementing Article 32: a phased approach

Inventory (weeks 1 to 4): link every processing activity in the record of processing to systems, processors and identities. Rank by data sensitivity and volume.
Assess the top tier (weeks 4 to 10): run the five step assessment on special category, financial and large scale activities first. Agree one impact scale with the DPO.
Close gaps: prioritise missing encryption key separation, untested restores and unreviewed privileged and service accounts first, as each maps directly to a named Article 32 measure. Pilot changes on one system and keep a rollback plan for access changes that could stop a business process.
Prove it: schedule restore tests and penetration tests, and record outcomes and remediation dates.
Extend and repeat: cover the remaining activities, then re-run the assessment yearly and on major change such as a new processor, an AI use case or a migration.

Detection and measurement

Assessment coverage: percentage of processing activities with a current Article 32 risk assessment, target 100% for high risk activities.
Encryption coverage: share of personal data stores and backups encrypted with keys under separate administration.
Restore proof: percentage of high impact systems with a timed restore test in the last 12 months, and actual against target restore time.
Finding closure: median days to remediate high severity test findings on systems holding personal data.
Access hygiene: percentage of human and non-human identities with access to personal data reviewed in the last quarter.
Breach feedback: share of breach register entries that produced a recorded control change.

Common failure patterns

Generic control lists: one corporate policy applied to every system with no link to the risk of each processing activity, so the "appropriate" judgement cannot be shown.
Confidentiality only: scenarios ignore integrity and availability, so ransomware recovery and data corruption are untested, despite Article 32(1)(c).
Testing without action: penetration test findings sit open for months with no recorded reason, which the ICO explicitly expects you to document.
Keys beside the data: encryption is on, but the same administrators or service accounts hold keys and data, so a single compromise defeats it.
Forgotten non-human access: integration and service accounts with broad read rights to customer data, outside access reviews and without an owner.
Relying on a certificate: treating a general security certification as proof under Article 32(3), when only approved codes and GDPR certification mechanisms count, and only as one element.

For how supervisory authorities have applied Article 32 in decisions, see the GDPR Enforcement Decisions on Security Failures Guide.

Practitioner checklist

Link every processing activity in the Article 30 record to its systems, processors and identities.
Run a documented Article 32 risk assessment using recital 75 harms and all three breach types.
Record, for each activity, how points (a) to (d) were considered and why any was not applied.
Separate encryption key administration from data administration.
Set restore objectives by impact on individuals and time a restore at least yearly.
Track every test finding to closure or a recorded reason for not acting.
Review human and non-human access to personal data at least quarterly for high risk data.
Confirm processor contracts require Article 32 measures and allow audits.
Re-run assessments on major change and at least yearly, and feed breach register lessons back in.

Standards and references

This guide summarises GDPR Article 32 and related guidance as of November 2026 and is not legal advice. Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · GDPR Article 28 Processor Guide · DPIA Guide · UK GDPR and Data Protection Act 2018 Guide

GDPR Article 32 Security of Processing Guide: Appropriate Measures in Practice