Encryption and GDPR — A Practical Guide to Article 32

Encryption is one of the most effective — and one of the most explicitly named — data protection measures in the GDPR. Article 32 mentions it by name, and yet the lack of encryption on lost and stolen devices remains one of the most common causes of fines imposed by the Polish supervisory authority (UODO). An encrypted laptop that falls out of a backpack on the metro is, at worst, a lost piece of equipment. The same laptop without encryption is a personal data breach — and often a financial penalty too.

The GDPR does not require encrypting everything, always. A risk-based approach applies: the controller decides which measures are appropriate. In practice, however, in many situations — portable devices, external media, transmission over public networks, remote work, special-category data — it is hard to justify not encrypting.

This article explains how encryption is embedded in Article 32 GDPR, how it differs from pseudonymisation and anonymisation, what to encrypt and when, how encryption affects breach obligations, and what lessons follow from UODO decisions.

Encryption in Article 32 GDPR

Article 32 GDPR requires the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security of processing appropriate to the risk. Importantly, the provision lists example measures expressly — and among them, in Article 32(1)(a), it names the pseudonymisation and encryption of personal data.

This does not mean an absolute obligation to encrypt in every situation. The choice of measures depends on the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risk to individuals’ rights and freedoms. The higher the risk and the more sensitive the data, the stronger the safeguards expected. In practice, for mobile devices, portable media or sending data over the internet, encryption becomes a standard that is hard to depart from without good justification.

Encryption vs Pseudonymisation vs Anonymisation

These three concepts are often confused, and the differences have real legal consequences.

Encryption transforms data into a form unreadable to anyone without the key. It is reversible — once decrypted, the data returns to its original form. Encrypted data remains personal data, because whoever holds the key can read it.

Pseudonymisation processes data so that it can no longer be attributed to a specific person without additional information kept separately. Pseudonymised data also remains personal data.

Anonymisation is the irreversible removal of features enabling identification. Properly anonymised data ceases to be personal data and falls outside the GDPR.

The practical takeaway: encryption secures data but does not “delete” it within the meaning of the GDPR. If the aim is to take data permanently outside the GDPR, anonymisation is needed, not encryption.

What to Encrypt and When

Encryption is applied in two basic states of data.

Data at rest. Computer and laptop disks (full-disk encryption, e.g. BitLocker, FileVault, LUKS), portable media (USB sticks, external drives), databases, backups and files containing sensitive data. Full-disk encryption protects data when a device is lost or stolen.

Data in transit. Transmission over a network — the TLS/HTTPS protocol on websites and in services, a VPN for remote work, email encryption (e.g. S/MIME or PGP) when sending sensitive information, and secure file-exchange channels instead of plain email.

It is especially worth encrypting in higher-risk situations: on portable devices and media taken off the premises, in remote and hybrid work, when using the cloud, when transmitting data over public networks, and always when processing special-category data (Article 9 GDPR), such as health data.

Encryption and Data Breaches

This is one of the strongest practical arguments for encryption. Under Article 34(3)(a) GDPR, notifying data subjects of a breach may not be required if the controller has implemented appropriate protection measures and applied them to the data affected by the breach — in particular measures such as encryption that render the data unintelligible to unauthorised persons.

In practice, this means that the loss of a properly encrypted laptop or medium, where the key has not been compromised, can significantly reduce the risk to individuals and allow the controller to avoid notifying them. Note: this does not automatically remove the need to assess the breach and — depending on the circumstances — report it to UODO; the point is that effective encryption genuinely reduces the severity of a breach. The condition, however, is that the encryption is strong and actually applied, and that the key remains secure.

Encryption in UODO Decisions — What the Fines Teach

UODO’s decisions show how seriously the lack of encryption of portable devices is treated.

A stolen university laptop (SGGW). Data of around 100,000 candidates for studies over five years ended up on an employee’s private laptop, also used for work; the device was stolen and the data was not adequately secured. The President of UODO imposed a fine of PLN 50,000, citing among other things a lack of proper oversight and an insufficient assessment of technical measures. The Supreme Administrative Court upheld this position in its judgment of 7 February 2025, confirming that it is the university as controller that answers for the employee’s actions.

Encryption decided but not implemented (Dobrzyniewo Duże municipality). In its risk analysis, the controller correctly identified the risk of laptop theft and decided to encrypt the disk — but in fact did not encrypt it, explaining this by a backlog of other tasks. After the device was stolen, the President of UODO imposed a fine of PLN 8,000, stressing that purchasing and securing equipment is not an extraordinary circumstance. An important lesson: merely planning a measure is not enough — it must be implemented.

A laptop with sensitive data lost on the metro (ZHP). An instructor lost a backpack with a work laptop containing, among other things, health data, national identification numbers, and data of children and volunteers. Given the lack of effective safeguards, the President of UODO imposed a fine of PLN 24,555, recalling that safeguards must not only be implemented but also tested and updated.

The common denominator of these cases is clear: devices and media taken off the premises are among the most exposed, and encryption is a basic protective measure in case they are lost. UODO also expects the risk analysis to cover not only break-ins and theft but also ordinary loss of equipment.

Principles of Sound Encryption

Encryption only works when it is done well. In practice, it is worth following a few rules:

Strong, current algorithms. The standard is AES-256 for data at rest and modern versions of TLS (1.2 or 1.3) for transmission. Outdated and insecure solutions should be avoided.

Proven, ready-made tools. Do not create your own cryptographic algorithms — it is safer to use recognised, tested solutions and libraries.

Up-to-date recommendations. It is worth following the guidance of bodies such as ENISA or NIST, since cryptographic standards change over time.

Full-disk encryption on endpoints. Laptops and mobile devices are best encrypted in full, not just selected files.

Key Management — The Weakest Link

Even the strongest algorithm will not help if the key is poorly protected. Key management is, in practice, the most common weak point of encryption. Keys and passwords should be stored securely and separately from the encrypted data, access should be limited on a need-to-know basis, and recovery keys should be kept in a safe place. Losing a key usually means the irreversible loss of the data, so the process must include copies and recovery procedures. On the other hand, a key stored together with the data, or a password like “abc123”, makes encryption illusory.

Encryption and Accountability

Encryption is not only a technical measure but also an element of accountability (Articles 5(2) and 24 GDPR). Decisions to apply (or not to apply) encryption should follow from a documented risk analysis and be reflected in the security policy. The key lesson from UODO’s decisions is, however, simple: it is not enough to plan encryption on paper — it must actually be implemented, maintained and periodically verified for effectiveness.

Common Mistakes

No encryption of portable devices and media taken off the premises.

Planning encryption without implementing it — the measure exists only in the documentation.

Delegating encryption to employees without providing tools and enforcement.

Weak passwords and poor key protection — the key stored together with the data.

Overlooking loss of equipment in the risk analysis (accounting only for theft).

Confusing encryption with anonymisation and treating encrypted data as deleted.

No encryption of data transmission over public networks.

Checklist — Encryption of Personal Data

1. Carry out a risk analysis covering both theft and loss of equipment.
2. Enable full-disk encryption on laptops and mobile devices.
3. Encrypt portable media (USB sticks, external drives) and backups.
4. Secure data transmission (TLS/HTTPS, VPN, email encryption for sensitive data).
5. Use strong, current algorithms (e.g. AES-256, TLS 1.2/1.3).
6. Implement secure key management and storage of recovery keys.
7. Do not delegate encryption to employees — provide tools and enforce it.
8. Document encryption decisions in the risk analysis and security policy.
9. Factor encryption into breach assessments (Article 34(3)(a)).
10. Periodically test and update the measures applied.

Need Help with Data Security and Article 32 GDPR?

Encryption is one of the pillars of data security — but only when it is properly chosen, implemented and documented. At the Law Office of Dr Joanna Maniszewska-Ejsmont, we help carry out risk analyses, select appropriate technical and organisational measures in line with Article 32 GDPR, and prepare a security policy and documentation demonstrating accountability.