GDPR Encryption: What Article 32 Requires
You know encryption is important. But is it actually required? Not always. But more often than most SMBs think. The GDPR explicitly names encryption as a security measure, and the Data Protection Authority (DPA/AP) expects you to take it seriously.
This article gives you a clear overview: when is encryption required, when is it recommended, and what do you need to arrange at minimum as an SMB under Article 32?
What does the GDPR say about encryption?
Article 32 of the GDPR requires you to implement "appropriate technical and organisational measures" to protect personal data. Encryption is explicitly mentioned in that article as an example of such a measure, alongside pseudonymisation.
That doesn't mean the law always mandates encryption. The GDPR is risk-based: the more sensitive the data, the stronger the security needs to be. And encryption ranks high on that list.
What does that mean in practice? If you process personal data and encryption is technically feasible, you need a solid explanation for why you are not using it. "We haven't gotten around to it yet" will not survive an audit.
When is encryption required under the GDPR? (And when is it "recommended")
The line between required and recommended depends on a few factors.
First: the sensitivity of the data. Special categories of personal data (health, religion, biometric data) always call for strong encryption. For ordinary contact details, the bar is lower, but not zero.
Second: the risk in case of a breach. Imagine the data ends up in the open. How serious is the harm to the individuals involved? The greater the impact, the stronger the requirement.
And third: the state of the art. The GDPR takes into account what is technically feasible and affordable. Encryption in 2026 is cheap and widely available. That makes it hard to argue it cannot be done.
Rule of thumb: for special categories of personal data, financial data and national identification numbers, encryption is effectively required in practice. For other personal data, it is strongly recommended, especially when storing or transmitting data outside your own network.
What types of data need to be encrypted?
Not all data needs the same level of protection. The key distinction:
Data at rest is stored data: files on servers, in the cloud, on laptops, on USB drives and in backups. If someone gains physical or digital access to that storage, encryption is your last line of defence.
Data in transit is data on the move: everything sent over the internet, email or internal networks. Think of forms on your website, emails containing personal data and API traffic between systems.
In practice, these are the scenarios where encryption matters most:
- Laptops and mobile devices (loss or theft is a realistic risk)
- Cloud storage containing personal data
- Email traffic with sensitive attachments
- Backups, including those stored offsite
- Databases with customer or employee data
What encryption standards are acceptable?
The GDPR doesn't prescribe a specific standard, but supervisory authorities have clear expectations.
For data at rest, AES-256 is the norm. Virtually all cloud providers support it. For data in transit, the expectation is TLS 1.2 or higher, the protocol behind HTTPS. Older versions (TLS 1.0, 1.1) are considered insecure. And for sensitive communications, end-to-end encryption is expected. Think of tools like Signal for internal messages about privacy-sensitive matters.
Worth stressing: encryption is only as strong as your key management. If the encryption key sits right next to the data, you effectively have nothing. Store keys separately and restrict access to them.
Pseudonymisation is not encryption
These two are often confused. With pseudonymisation, you replace identifying data with a code or alias. The data remains readable but cannot be directly traced back to a person. With encryption, the data is unreadable without the correct key.
They are two different things. Pseudonymisation limits traceability. Encryption prevents access. For serious security, you often want both.
Encryption in practice: what do you need to arrange at minimum?
You don't need military-grade security as an SMB. But you do need at least the following in order:
- HTTPS on all your web properties. No exceptions. Every form, every page, every subdomain.
- Encrypted storage for sensitive files. Use the built-in encryption of your cloud provider (Google Workspace, Microsoft 365, AWS) and verify it is enabled by default.
- Full-disk encryption on laptops. BitLocker (Windows) or FileVault (Mac) are free and can be enabled in a few clicks.
- Encrypted email for sensitive communications. Use TLS verification or a solution like Zivver if you regularly send personal data by email.
- Encrypted backups. Check whether your backup provider offers encryption at rest and whether you manage the keys yourself.
- Secure API connections. All data traffic between systems via TLS 1.2+. No unencrypted connections, not even internal ones.
Want to document which security measures you have in place for each vendor and system? In ComplianceHive you record that in the vendor management and systems inventory. That way, you have an up-to-date overview ready for any audit.
What if you have a data breach but the data was encrypted?
This is where encryption pays off from a compliance perspective. Article 34, paragraph 3a of the GDPR states that you don't need to inform data subjects about a breach if the leaked data is "unintelligible" to anyone who has no right to access it. Encrypted data meets that condition.
Say a laptop with an encrypted hard drive gets stolen, or encrypted backup files leak. In many cases you:
- Do not need to individually inform the data subjects
- Do still need to report the breach to the DPA, but with lower urgency
That saves you time, money and reputational damage. Even if encryption is not strictly required for certain data, this alone is reason enough to do it anyway.
Want to know more about what to do in case of a data breach? Read: What is a data breach and what should you do?
Checklist: GDPR encryption compliance
Use this as a quick check. Go through each item and note whether it is in order, partially done, or still to do. For more on the broader GDPR approach, see the GDPR checklist for SMBs.
- [ ] HTTPS active on all web properties and subdomains
- [ ] TLS 1.2+ on all API connections and data traffic
- [ ] Full-disk encryption on all laptops and workstations
- [ ] Encrypted storage at cloud providers enabled and verified
- [ ] Encrypted backups, including offsite backups
- [ ] Email encryption for messages containing personal data
- [ ] Key management: encryption keys stored separately from data
- [ ] Encryption standards documented per vendor and system
- [ ] Pseudonymisation applied where traceability needs to be limited
- [ ] Security measures documented for audit purposes
In ComplianceHive you record per tool and vendor which encryption standards are used, whether a Data Processing Agreement (DPA) is in place, and how security is arranged. That way you know exactly where you stand during an audit, without having to dig through spreadsheets.
Frequently asked questions about GDPR encryption
What does GDPR Article 32 specifically require for encryption?
Article 32 requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. It explicitly names encryption and pseudonymisation as examples. The EDPB and the Dutch AP interpret this to mean AES-256 for data at rest and TLS 1.2 or higher for data in transit for any organisation processing personal data in the EU — regardless of size.
Is AES-256 mandatory under GDPR or just recommended?
GDPR does not name AES-256 by name, but the AP and EDPB treat it as the current "state of the art" standard under Article 32(1)(a). Using weaker algorithms such as AES-128, 3DES, or RC4 for sensitive personal data would likely not meet the Article 32 standard in a 2026 audit. For sensitive categories (health, biometric, financial data), AES-256 is effectively the minimum bar.
Does full-disk encryption satisfy GDPR Article 32?
Full-disk encryption (BitLocker, FileVault) satisfies the data-at-rest requirement for laptops and workstations, but it does not cover your entire Article 32 obligation. You still need TLS 1.2+ for data in transit, encrypted backups with separately stored keys, and encrypted cloud storage. Full-disk encryption is one layer, not a complete compliance strategy.
What TLS version does GDPR require for data in transit?
The AP and NCSC (Dutch National Cyber Security Centre) guidance requires TLS 1.2 as the minimum and recommends TLS 1.3. TLS 1.0 and TLS 1.1 are considered insecure and must not be used for personal data transmission. This applies to HTTPS on web properties, API calls between systems, email via SMTP with STARTTLS, and any other channel carrying personal data over a network.
If encrypted data is breached, do you still need to notify the AP and data subjects?
You must still report the breach to the AP (Autoriteit Persoonsgegevens) within 72 hours under Article 33, regardless of encryption. However, under Article 34(3)(a), you are exempt from notifying the individual data subjects if the leaked data was properly encrypted and the keys were not compromised — because the data is unintelligible to any unauthorised party. This exemption only applies when key management was sound; if the attacker also obtained the decryption key, the exemption does not apply.
Do SMBs with fewer than 250 employees still need to encrypt personal data under GDPR?
Yes. The 250-employee threshold in GDPR applies only to the record-keeping obligation under Article 30(5), not to Article 32 security requirements. Article 32 applies to every organisation that processes personal data, regardless of size. A freelancer, a 10-person startup, and a 5,000-person enterprise all face the same encryption standard — proportionate to the sensitivity and volume of data they process.
What is the difference between pseudonymisation and encryption under GDPR?
Pseudonymisation (Article 4(5)) replaces direct identifiers with a code or alias. The data remains structured and readable but cannot be directly attributed to a person without a separate mapping table. Encryption renders the data completely unintelligible without the correct decryption key. GDPR Article 32 lists both as complementary measures. Pseudonymisation limits exposure if data is accessed; encryption prevents access altogether. For high-risk processing, the EDPB expects both to be used together.