GDPR and Encryption: What EU Law Actually Requires

Meta was fined EUR 1.2 billion by the Irish Data Protection Commission in May 2023 for violating GDPR data transfer rules. WhatsApp received a EUR 225 million fine in 2021 for transparency failures under the same regulation. Neither fine was specifically about encryption, but both cases turned on whether the companies had implemented appropriate technical and organizational measures to protect personal data.

GDPR Article 32 is the provision that governs data security under the regulation. It names encryption as one example of an appropriate measure. It does not mandate encryption outright. This distinction matters. Companies that treat GDPR as a checkbox for "encrypt everything" miss the actual legal standard, which is risk-based and contextual.

This post breaks down what Article 32 says, what the European Data Protection Board (EDPB) guidelines add, how enforcement actions have interpreted the requirement, and what encryption choices satisfy the law in practice. You can test the algorithms discussed here using the AES Encrypt/Decrypt tool and the RSA Encrypt/Decrypt tool.

Article 32 of the GDPR, titled "Security of processing," requires controllers and processors to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk." The full text is available at gdpr.eu Article 32. The article lists four examples of measures that can satisfy this requirement:

1. The pseudonymisation and encryption of personal data. 2. The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services. 3. The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. 4. A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures.

Encryption appears in item (a), but as an example, not a mandate. The word "appropriate" appears twice in the opening paragraph, and the article instructs organizations to consider "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."

This means a small blog collecting email addresses faces different encryption obligations than a hospital processing patient records. The law does not say "encrypt all personal data." It says "assess your risk and implement measures appropriate to that risk, and here are some examples of measures you might choose."

The EDPB (European Data Protection Board) has published guidelines that clarify how Article 32 applies in practice. The EDPB Guidelines 01/2021 on Examples regarding Data Breach Notification discuss encryption as a mitigation factor. When a data breach occurs, the fact that the stolen data was encrypted can reduce the risk to individuals, which in turn affects whether the breach must be reported to supervisory authorities within 72 hours.

The EDPB's position is consistent across multiple guidelines: encryption is strongly recommended but not universally required. The risk-based approach means that for high-risk processing (health data, financial data, biometric data), encryption is effectively expected. For low-risk processing, other measures may suffice.

What counts as "encryption" under GDPR? The regulation does not specify algorithms or key lengths. In practice, supervisory authorities expect industry-standard encryption. AES-256 for data at rest and TLS 1.2 or 1.3 for data in transit are the baseline expectations. Using deprecated algorithms like DES or RC4 would not satisfy Article 32 because they fail the "state of the art" test. You can verify your AES implementation using the AES Encrypt/Decrypt tool.

Article 32 lists pseudonymization and encryption together in the same bullet point, but they are different techniques with different legal consequences. Pseudonymization replaces identifying fields with pseudonyms (tokens, randomized IDs). Encryption transforms data into ciphertext that can only be read with a decryption key.

The GDPR treats pseudonymized data as personal data because it can be re-identified with additional information. Article 4(5) defines pseudonymization as processing personal data "in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information." That additional information (the mapping table) must be kept separately and subject to technical and organizational measures.

Encrypted data is also still technically personal data under GDPR, but encryption provides stronger protection. If an attacker steals an encrypted database without the keys, the data is unreadable. If they steal a pseudonymized database and the mapping table, the data is fully re-identified.

For compliance purposes, encryption is the stronger measure. Pseudonymization reduces risk but does not eliminate it. Many organizations use both: pseudonymize data for day-to-day processing, encrypt the pseudonymized data at rest, and encrypt the mapping table separately with stricter access controls.

GDPR does not distinguish between encryption at rest and encryption in transit, but both are expected under the risk-based approach. Encryption in transit protects data as it moves between systems. Encryption at rest protects data stored on disk, in databases, or in backups.

For data in transit, TLS 1.3 (defined in RFC 8446) is the current standard. TLS 1.2 is still acceptable but is being phased out. The cipher suite negotiated during the TLS handshake determines the encryption algorithm, and modern suites use AES-GCM or ChaCha20-Poly1305. You can inspect cipher suites using the TLS Cipher Suite Lookup tool.

For data at rest, AES-256 in GCM mode is the most common choice. Full-disk encryption (LUKS on Linux, BitLocker on Windows, FileVault on macOS) provides transparent encryption at the storage layer. Database-level encryption (TDE in SQL Server and Oracle, pgcrypto in PostgreSQL) encrypts data within the database engine. Application-level encryption, where the application encrypts data before writing it to the database, provides the strongest protection because the database administrator cannot read the plaintext.

The choice depends on the threat model. If the threat is physical theft of disks, full-disk encryption suffices. If the threat is a compromised database administrator or a SQL injection attack, application-level encryption is necessary because the attacker never gets access to plaintext.

Encryption without key management is security theater. If the encryption keys are stored next to the encrypted data, an attacker who compromises the system gets both. GDPR does not specify key management requirements in detail, but the "appropriate measures" standard implies that key management must match the sensitivity of the encrypted data.

NIST Special Publication 800-57, Recommendation for Key Management, provides the framework that most EU supervisory authorities reference when evaluating key management practices. The key recommendations include: using a hardware security module (HSM) for key generation and storage, rotating keys at defined intervals, separating key custody from data custody, and destroying keys securely when they are no longer needed.

Key derivation functions matter here too. If you derive encryption keys from user passwords, you must use a slow hashing function like Argon2 or PBKDF2 to resist brute-force attacks. Using a raw SHA-256 hash of a password as an encryption key is not adequate because modern hardware can compute billions of SHA-256 hashes per second. The PBKDF2 and Argon2 tool lets you test key derivation parameters.

A common compliance failure is encrypting data but storing the key in an environment variable on the same server. This satisfies a literal reading of "we encrypt the data" but fails the risk-based test because an attacker with server access gets both the ciphertext and the key.

The Irish Data Protection Commission (DPC) has been the lead supervisory authority for many major GDPR cases because large tech companies have their EU headquarters in Ireland. Two cases illustrate how encryption factors into enforcement.

In May 2023, the DPC fined Meta EUR 1.2 billion for transferring European user data to the United States without adequate safeguards. The decision focused on Article 46 (transfers to third countries) rather than Article 32, but the DPC noted that the lack of consistent encryption across transferred data streams increased the risk to data subjects. The fine was the largest GDPR penalty to date.

In September 2021, the DPC fined WhatsApp EUR 225 million for transparency violations under Articles 13 and 14. The investigation found that WhatsApp had not adequately documented its data processing practices, including how it encrypted user data and how long it retained encryption keys. The fine was not for failing to encrypt but for failing to demonstrate that its encryption practices met the Article 32 standard.

The pattern across enforcement actions is clear: supervisory authorities expect encryption for high-risk data, and they expect documentation showing that the encryption implementation is appropriate to the risk. Organizations that encrypt but cannot explain their key management, algorithm choices, or threat model face the same enforcement risk as those that do not encrypt at all.

The SHA-256 Hash Generator can help you verify data integrity as part of a broader security posture, and the encoding vs encryption vs hashing post explains why these three concepts are frequently confused in compliance documentation.