GDPR Encryption Requirements: When Must You Encrypt Data?
GDPR
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.