Back to the hub

What does GDPR Article 32 require?

Article 32 of the GDPR requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. It names pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration after an incident, and regular testing of those measures.

Applies to: Controllers and processors within the scope of the GDPR, both of whom Article 32(1) obliges directly to secure the personal data they process.

Find out what applies to you

Run the free 2-minute Obligation Scan and get a plain-language list of what your business has to do, and by when.

Run the free 2-minute Obligation Scan

Article 32 is the GDPR's security clause, and it is deliberately not a checklist of controls. It sets a standard, names four measures as examples, and leaves the rest to the risk in front of you. That design frustrates people who want a list, but it is also why the article has aged well.

The standard in Article 32(1)

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

Five inputs feed the judgment: the state of the art, the cost of implementing a measure, and the nature, scope, context and purposes of what you are doing, weighed against the likelihood and severity of harm to people. Cost is explicitly relevant, which is often missed. So is the state of the art, which is why an answer that was appropriate in 2019 may not be appropriate now.

Note also who is bound. Article 32(1) names the controller and the processor. A processor's security duty comes from the Regulation itself, not only from its data processing agreement.

The four measures it names

The article continues "including inter alia as appropriate", then lists:

(a) the pseudonymisation and encryption of personal data;

(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

"Inter alia as appropriate" is doing real work in that sentence. These are examples, not a closed list, and each is qualified by appropriateness. Encryption is named, but Article 32 does not say every controller must encrypt everything.

Points (c) and (d) are the ones most often under-implemented. (c) is a restoration capability with a time dimension, which is a different claim from having backups; you have to be able to get the data back in a timely manner. And (d) asks for a process that evaluates effectiveness, which means testing whether your controls work, not confirming that they exist.

What Article 32(2) tells you to assess against

In assessing the appropriate level of security, account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

That is a usefully concrete threat list, and it covers the full lifecycle: data in transit, data at rest, and data otherwise processed. It also includes accidental destruction and loss, so availability failures are security failures under the GDPR, not merely operational ones.

Codes of conduct and certification

Article 32(3) provides that adherence to an approved code of conduct as referred to in Article 40, or an approved certification mechanism as referred to in Article 42, may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1.

An element, not a defence. A certification helps you evidence the judgment you made; it does not replace the judgment.

The instruction rule in Article 32(4)

The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless required to do so by Union or Member State law.

This is the clause behind least-privilege access and behind the standard confidentiality undertakings in staff contracts. It reaches employees and contractors alike, and the duty is to take steps, which implies controls you can point to.

How Article 32 connects to breach notification

The two are linked in practice. Whether a personal data breach must be communicated to affected individuals under Article 34 turns partly on whether you had applied appropriate protection measures, in particular measures that render the data unintelligible to anyone unauthorised, such as encryption. Good Article 32 work narrows your Article 33 and Article 34 obligations later. See GDPR breach notification and the 72-hour rule.

For high-risk processing, Article 35 requires a data protection impact assessment, and the measures you choose under Article 32 are part of what that assessment records.

Next step

Article 32 asks what is appropriate for your risk, which first requires knowing which regimes apply to you at all. The free 2-minute Obligation Scan checks your business against GDPR and every US state privacy law at once, then shows what to operationalise. Start with the GDPR compliance pillar for the surrounding obligations.

Compliance checklist

  • Assess the risk first, because Article 32(1) ties the required level of security to the risk and to the nature, scope, context and purposes of your processing.
  • Work through the four named measures in Article 32(1): pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience of systems and services; timely restoration of availability and access after an incident; and a process for regularly testing, assessing and evaluating effectiveness.
  • Treat the restoration requirement in Article 32(1)(c) as a tested recovery capability with a measured time to restore, not as the existence of backups.
  • Schedule the regular testing required by Article 32(1)(d) and keep the results, since the obligation is to evaluate effectiveness rather than to run a scan.
  • Assess against the specific risks named in Article 32(2): accidental or unlawful destruction, loss, alteration, and unauthorised disclosure of or access to personal data transmitted, stored or otherwise processed.
  • Bind everyone with access to process only on the controller's instructions, as Article 32(4) requires, and reflect that in contracts and access controls.

Sources

Last verified: 2026-08-28

Informational, not legal advice.