GDPR Article 32 does not make encryption mandatory in every case. It says controllers and processors must adopt measures suited to the risk, and lists examples including pseudonymisation and encryption of personal data, ongoing confidentiality, integrity, availability and resilience, and the ability to restore access to personal data promptly after an incident.
What the text lists
Article 32(1) lists, among measures as appropriate:
- the pseudonymisation and encryption of personal data;
- the ability to ensure the 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 after a physical or technical incident.
The measures are to be chosen taking account of risk, which means the choice depends on what you process and how.
Reading it correctly
- Encryption is named, not mandated everywhere. It is an example of an appropriate measure. A regulator will ask whether your measures matched the risk.
- Availability counts. Backups and tested restores are part of the picture, not an extra. See a backup restore drill.
- Pseudonymisation is its own measure. Replacing identifiers with codes, with the mapping kept apart, reduces exposure but the data is still personal data.
- It applies to processors too. Your vendors owe you the same, and you should ask.
Article 5(1)(f) sets the principle behind it: appropriate security, including protection against unauthorised processing and accidental loss, destruction or damage.
A practical mapping
- Encryption. Things to show: Encryption at rest and in transit settings and key management. See levels of encryption at rest and TLS settings.
- Pseudonymisation. Things to show: Where used, and where the mapping is stored.
- Confidentiality and integrity. Things to show: Access control, logging, change control.
- Availability and resilience. Things to show: Backups, redundancy, tested restores.
- Restoring access. Things to show: Restore drill records and timings.
The article has further points beyond the three quoted above, so read the full text before building a compliance mapping.
Evidence matters
Being able to show what you did and when is as important as doing it. Safeguard's compliance and evidence automation can collect this kind of evidence in one place.
Questions a regulator or customer may ask
In practice the questions are concrete. What personal data do you hold and where? Which of it is encrypted at rest and in transit, and how are keys managed? Who can read it, and is that access logged? How quickly could you restore it after an incident, and when did you last prove that? Do your processors meet the same bar, and what do your contracts say? A one page answer for each, backed by dated evidence, is far more convincing than a policy statement. If some data is not encrypted, record the risk reasoning that made that acceptable at the time.
Quick check
Must we encrypt all personal data?
The article does not say that in so many words. It lists encryption as a measure to consider based on risk, so document your reasoning where you do not encrypt.
Does Article 32 mention backups?
It does not use the word. It requires the ability to restore availability and access to personal data after an incident, which backups serve.
This is general information, not legal advice.
Sources
Last reviewed: 19 October 2026.
