GDPR Article 32: security of processing

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.

Where Article 32 sits in the Regulation

Article 32 rarely comes up on its own, and knowing which articles it hands off to is most of the practical value.

Upstream, it is the operational expression of the integrity and confidentiality principle in Article 5(1)(f). Article 32 is how you discharge that principle rather than a separate idea.

Sideways, it binds processors directly, and the contractual version of the same duty appears in Article 28, which requires the processor to take all measures required pursuant to Article 32. A processor therefore owes the duty twice, once by Regulation and once by contract.

Downstream, a failure of Article 32 measures is what produces a personal data breach, which triggers the 72-hour notification to the supervisory authority under Article 33 and, where the risk is high, communication to the affected people under Article 34. Article 34(3)(a) then loops back: a controller does not have to tell individuals if it had applied appropriate technical and organisational protection measures, in particular measures that render the data unintelligible, such as encryption. Encryption done under Article 32(1)(a) is what buys that relief.

Where the processing is high risk, the assessment obligation in Article 35 requires the DPIA to describe the measures envisaged, and it cites Article 32 by name.

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.

Article 32(1)(a) to (d) in the Regulation's own words

Article 32(1) opens with the balancing test, then names four measures. The official consolidated text reads:

"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, including inter alia as appropriate:

(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."

Two qualifiers govern that list. "Inter alia" means it is not exhaustive, so satisfying all four does not by itself discharge the obligation. "As appropriate" means none of the four is mandatory in every case, so encryption is not required everywhere, but declining to encrypt is a decision you have to be able to justify against the balancing test in the opening words.

Notice that (b), (c) and (d) are phrased as abilities and processes rather than as controls. Article 32 asks whether you can restore access and whether you regularly test, which is why a backup you have never restored from is weak evidence under (c).

The duty falls on "the controller and the processor". Both, independently.

Article 32(2), (3) and (4) in the Regulation's own words

The rest of the article is short enough to quote entire, and each paragraph does a distinct job.

"2. 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."

Paragraph (2) names the risk categories the assessment has to address: destruction, loss, alteration, unauthorised disclosure, and unauthorised access, each covering data in transit, at rest, or otherwise processed. Note that accidental destruction sits alongside unlawful disclosure. Availability failures are security failures under Article 32, not merely operational ones, which is why paragraph (1)(c) asks about restoration.

"3. 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 of this Article."

Paragraph (3) is permissive and carefully hedged. Certification is "an element by which to demonstrate compliance", not a safe harbour and not a presumption. A certificate is evidence that goes into the assessment; it does not replace it.

"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 he or she is required to do so by Union or Member State law."

Paragraph (4) is the internal-authority rule, and it is the one most often left out of security documentation. It reaches natural persons acting under the controller's or processor's authority, which in practice means employees and contractors with access. The obligation is to take steps ensuring they process only on instructions, with the single exception of a legal requirement under Union or Member State law. Access control, role definitions, confidentiality undertakings and training are how that duty is discharged, and none of them appear in the paragraph (1) list of measures.

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.