GDPR Encryption Requirements: Article 32 Explained

Introduction

GDPR encryption requirements live in Article 32, which never names AES-256. But supervisory authorities across Europe have made one thing clear: if your users’ data is breached and it was not encrypted, you will answer for it.

The law uses the phrase “appropriate technical and organisational measures” — deliberately flexible language that scales with the sensitivity of data and the state of current technology. Today, the state of the art for data at rest is AES-256; for data in transit, it is TLS 1.3 (with TLS 1.2 as an acceptable minimum). These are not controversial interpretations. The European Data Protection Board (EDPB) has documented exactly which encryption configurations satisfy the Article 34 breach-notification safe harbor and which do not.

Understanding the GDPR encryption requirements above has a direct financial consequence: Article 34 of GDPR exempts organizations from notifying affected data subjects after a breach if the data was properly encrypted and the key was not compromised. A single laptop theft can require notifying thousands of individuals — unless FileVault or BitLocker was enabled and the recovery key was stored separately. The regulatory safe harbor exists because the data is genuinely useless to the attacker.

This article translates the law into concrete technical standards, organized by data risk tier, with the EDPB scenarios that define the boundary between “notification required” and “notification exempt.”

GDPR Encryption Requirements: What Is Article 32?

GDPR Article 32 is the law’s core security requirement, enacted under Regulation (EU) 2016/679 of the European Parliament and of the Council. It obliges both data controllers (organizations that determine how data is used) and data processors (vendors who process data on behalf of controllers) to implement appropriate technical and organizational measures.

Article 32(1)(a) specifically lists “the pseudonymisation and encryption of personal data” as examples of appropriate measures. The qualification “as appropriate” gives organizations discretion — but that discretion narrows rapidly as data sensitivity and processing volume increase.

Three interpretive principles govern Article 32:

• “State of the art” means current best practices, not cutting-edge research. AES-256 qualifies; MD5 or unencrypted storage does not.
• “Appropriate to the risk” means proportional. A forum storing usernames has lower requirements than a clinic storing medical records.
• “Taking into account costs” means technical and financial constraints are relevant — but they must be weighed against the nature and volume of personal data. Processing millions of records shifts the cost-benefit analysis substantially.

Article 32 also applies to data processors under Article 28, meaning any cloud provider or SaaS vendor you use to process EU personal data must contractually commit to the same encryption standards you maintain — and you must verify that commitment.

How GDPR Encryption Works in Practice

Risk-Tiered Encryption Standards

The EDPB and national supervisory authorities have published guidance establishing a de facto risk tier. Each tier maps to specific legal obligations under Articles 9, 32, 33, and 34.

Very High Risk — Special Category Data (Article 9): Health, biometric, genetic, religious, political, sexual orientation, and racial/ethnic origin data. Minimum standard: AES-256 at rest with HSM or managed KMS key storage; TLS 1.3 in transit; key rotation at least annually.

High Risk — Financial and Identity Data: Bank account details, payment card information, identity documents, authentication credentials. Minimum standard: AES-256 at rest; TLS 1.2+ in transit; key rotation at least annually; separate key storage from data.

Medium Risk — Standard Personal Data: Names, email addresses, IP addresses, location data, behavioral data. Minimum standard: AES-128 or AES-256 at rest; TLS 1.2+ in transit.

Low Risk — Non-Sensitive Personal Data: Publicly available preferences, aggregated usage data. Minimum: TLS in transit; encryption at rest recommended.

The Article 34 Breach Notification Safe Harbor

The most valuable technical consequence of proper encryption is the Article 34 safe harbor. When personal data is breached, organizations must:

• Always notify the supervisory authority (Article 33) within 72 hours if the breach is likely to result in a risk to individuals.
• Notify affected data subjects (Article 34) unless appropriate technical measures make the data unintelligible to unauthorized persons.

The EDPB Guidelines 01/2021 document three scenarios with explicit rulings:

Scenario 1 (No notification required): A laptop containing encrypted personal data is stolen. The encryption key was stored separately from the device. The encryption algorithm is state-of-the-art (AES-256). No notification to data subjects required — the data is unintelligible to the thief.

Scenario 2 (Notification required): Same laptop, but the AES-128 decryption key was stored as a file on the same device. The key was accessible alongside the ciphertext. Notification required — the data is effectively unprotected.

Scenario 3 (Notification required): Unencrypted laptop stolen. Mandatory notification.

Key Management Under GDPR

GDPR does not specify key management procedures, but ENISA guidance and supervisory authority decisions establish what “appropriate” looks like:

1. Encryption keys must be stored separately from the encrypted data.
2. Access to keys must be logged and access-controlled.
3. Key rotation should occur at least annually for high-risk data categories.
4. Key backup and recovery procedures must be tested regularly.
5. Third-party processors must sign Data Processing Agreements (DPAs) explicitly covering encryption obligations (Article 28(3)(c)).

Cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) satisfies most of these requirements for standard personal data. Special category data may warrant dedicated HSMs — particularly for organizations subject to sector-specific regulation like eHealth or financial services.

VIDEO · READY 16:9

PLAY

GDPR Explained

GDPR Compliance Checklist

Use this checklist to assess your organization’s Article 32 posture before a supervisory authority audit or a data breach event. Items marked with the legal citation are the most frequently examined by DPAs.

Data Inventory and Classification (Article 30 — Records of Processing Activities)

1. Maintain a Record of Processing Activities (RoPA) documenting every system that holds personal data
2. Classify each data store by risk tier (Article 9 special category, financial, standard personal data)
3. Document the encryption algorithm, key management method, and TLS version for each system in the RoPA
4. Identify all third-party processors handling EU personal data (required for Article 28 DPAs)

Encryption at Rest (Article 32(1)(a))

1. AES-256 enabled for all databases holding special category or financial data
2. AES-128 minimum (AES-256 preferred) for all other personal data stores
3. Encryption at rest enabled on database backups — not just live databases
4. Encryption keys stored in a dedicated KMS or HSM, not alongside the encrypted data
5. Key access logs enabled and reviewed at least quarterly

Encryption in Transit (Article 32(1)(a), Recital 83)

1. TLS 1.2 minimum enforced on all public-facing endpoints handling personal data
2. TLS 1.3 enabled and preferred where possible (especially for special category data)
3. TLS 1.0 and TLS 1.1 explicitly disabled
4. Internal service-to-service communication (databases, APIs, queues) uses TLS
5. SSL Labs A-rating confirmed for all public-facing domains (ssllabs.com)

Key Management (ENISA Pseudonymisation Guidelines, adopted by DPAs)

1. Annual key rotation implemented and verified with actual rotation event logs
2. Separation of duties: key creation/deletion role separate from key usage role
3. Key backup and recovery procedure documented and tested annually
4. Key lifecycle (generation, distribution, storage, rotation, destruction) documented

Data Processing Agreements (Article 28)

1. DPA signed with every third-party processor handling EU personal data
2. DPA explicitly covers the processor’s encryption obligations under Article 28(3)(c)
3. Processor encryption commitments verified (not just contractual — audit reports or certifications)

Breach Response Readiness (Articles 33 and 34)

1. Breach detection capability exists and is tested (SIEM, anomaly detection, or equivalent)
2. 72-hour supervisory authority notification procedure documented (Article 33)
3. Data subject notification procedure documented for when safe harbor does not apply (Article 34)
4. Safe harbor eligibility checklist: key separation confirmed, algorithm is state-of-the-art
5. Breach log maintained for all incidents, including near-misses (Article 33(5))

Penalties Reference (Article 83)

1. Understand that Article 83(4) fines apply to Article 32 violations: up to €10 million or 2% of global annual turnover
2. Understand that Article 83(5) fines apply to Article 9 (special category) violations: up to €20 million or 4% of global annual turnover

Encryption vs Pseudonymisation vs Anonymisation

The table reveals a frequently misunderstood point: encryption and pseudonymisation are not anonymisation. Tokenized customer IDs are still personal data — the organization holds the mapping table needed for re-identification. Truly anonymous data (where re-identification is not reasonably possible) exits GDPR’s scope entirely, but achieving real anonymisation is substantially harder than most data minimization efforts produce.

Real-World Use Cases

SaaS platforms handling EU user data: A European e-commerce platform storing customer order history must encrypt the database containing names, addresses, and purchase details at rest (AES-256), transmit all data over TLS 1.2+, and store encryption keys in a managed KMS separate from the database server. If a database backup is stolen, the EDPB Scenario 1 analysis applies: no subject notification if key separation was maintained.

Healthcare applications: A patient portal storing health records (Article 9 special category data) must implement the highest tier: AES-256 at rest with HSM-backed key storage, TLS 1.3 in transit, annual key rotation, and documented key access logs. Any breach of properly encrypted health data avoids the notification requirement — critical given the sensitivity of medical information.

SaaS with US-EU data flows: Under the GDPR adequacy framework, organizations managing cross-border data transfer from EU to US must implement appropriate safeguards. Standard Contractual Clauses (SCCs) require the data importer to implement encryption meeting GDPR Article 32 standards. In practice, this means AES-256 at rest and TLS 1.2+ in transit at minimum, with key management controls documented in the transfer impact assessment.

Common Mistakes to Avoid

Storing encryption keys alongside encrypted data. The EDPB Scenario 2 ruling makes this explicit: co-located keys eliminate the safe harbor. A database encrypted with AES-256 where the key is stored in a config file on the same server provides no meaningful protection — an attacker who accesses the server gets both. Use a managed KMS or HSM with key storage physically and logically separated from the encrypted database.

Treating pseudonymisation as anonymisation. Many organizations replace customer IDs with tokens, retain the mapping table, and claim they no longer hold personal data. They do — the tokenized data is pseudonymised, not anonymised. GDPR applies in full. The risk reduction is meaningful (a stolen tokenized dataset without the mapping table is harder to exploit), but it does not reduce GDPR obligations.

Encrypting at rest but skipping in transit. Data intercepted between your application server and database is plaintext unless in-transit encryption is enabled. Enable TLS for all internal service communication, not just public-facing endpoints. Database drivers, message queues, and internal APIs all support TLS.

No documented encryption policy for Article 30. Article 30 of GDPR requires organizations to maintain Records of Processing Activities. This record must describe the technical security measures implemented for each processing activity. Auditors and supervisory authorities may request these records. Document your encryption algorithms, key management procedures, and rotation schedules as part of your Article 30 records.

Ignoring processor obligations under Article 28. Many organizations encrypt their own infrastructure but fail to verify that their SaaS vendors and cloud processors do the same. Every data processor must commit to appropriate technical measures under Article 28(3)(c). Request encryption evidence — SOC 2 Type II reports, ISO 27001 certificates, or their own audit results — from every processor handling EU personal data.

Getting Started

Begin with a data inventory: identify every location where personal data is stored (databases, file systems, backups, logs, object storage). For each location, note the risk category of the data and the current encryption status. This inventory is also your Article 30 Records of Processing Activities foundation.

Classify each data store by the risk tier framework above. Special category health or biometric data is the highest priority for remediation. Standard personal data — names, emails, IP addresses — is medium priority but still requires encryption.

For each unencrypted data store, implement encryption at rest using AES-256-GCM with keys managed by a KMS separate from the data store. For databases on AWS, enable RDS encryption (backed by AWS KMS). For GCP, enable Cloud SQL encryption with CMEK. For Azure, use Transparent Data Encryption with Azure Key Vault.

Verify TLS configuration for all endpoints handling personal data using SSL Labs (ssllabs.com). An A-rating confirms TLS 1.2+ is enabled and weak cipher suites are disabled. Confirm that internal services — databases, queues, internal APIs — also use TLS.

For the regulatory comparison with US compliance frameworks, read SOC 2 encryption controls and what auditors actually check. For the technical details of the lost-device safe harbor and FDE implementation, see full-disk encryption: BitLocker and FileVault explained. If you process UK residents’ data, note that post-Brexit the UK retained its own version of these obligations under the UK Data Protection Act 2018, which now diverges from EU GDPR on some enforcement details.