No. GDPR never requires encryption. Article 32 requires "appropriate technical and organisational measures to ensure a level of security appropriate to the risk," and then lists encryption as one example of what that might include, prefaced by the words "as appropriate." It is a candidate measure, not a mandate. What the regulation actually requires is that you make a defensible decision and can show your reasoning.
This article covers the exact wording of Article 32 and why the qualifier matters more than the list, the four things Article 32 does require, the single place in the GDPR where encryption is named as something that earns you a concrete benefit, why encrypted data remains personal data, and what to write down so that "appropriate" is a position you can defend rather than a word you borrowed.
What Article 32 Actually Says
Article 32(1) opens with a set of factors: the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, together with the risk of varying likelihood and severity to people's rights and freedoms. Weighing those, the controller and the processor must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
Then comes the list, introduced by "including inter alia as appropriate":
- (a) the pseudonymisation and encryption of personal data
- (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services
- (c) the ability to restore availability and access to personal data in a timely manner after a physical or technical incident
- (d) a process for regularly testing, assessing and evaluating the effectiveness of those measures
Read that list carefully and notice the asymmetry. Items (b), (c) and (d) describe outcomes and processes you plainly need in some form. Item (a) names two specific techniques. It is the only one that reads like a product requirement, which is exactly why it gets quoted out of context and turned into a rule that does not exist.
Article 32(2) then says what to weigh when assessing the appropriate level: in particular the risks presented by the processing, and specifically the risks of accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. That is the sentence that should drive your decision. Encryption is one answer to one of those risks.
Why "Appropriate" Is The Operative Word
"Appropriate" is doing all the work in Article 32, and it is a relative standard, not a floor. Appropriate to what risk, for whose data, at what cost, given what is technically available today.
A team storing marketing contact details faces a different question from a team storing therapy session notes, and the regulation is deliberately built to produce different answers. Recital 83 makes the mechanism explicit: the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. The evaluation comes first. The measure follows from it.
This is also why chasing a named standard is a category error. GDPR specifies no algorithm, no key length, no cipher suite and no distinction between disk-level and field-level encryption. It will not tell you that AES-256 is enough, because "enough" depends on what you are protecting and from whom.
The consequence is uncomfortable: a rule you can fail is also a rule you can pass. Appropriateness can only be assessed after the fact, by a regulator who already knows what went wrong, which is why the reasoning you recorded beforehand is the whole of your defence.
The One Place Encryption Earns You Something Concrete
There is a single provision where encryption is named and where naming it produces a real, mechanical benefit, and most teams do not know it is there.
Article 34(1) says that when a personal data breach is likely to result in a high risk to people's rights and freedoms, you must communicate it to the affected individuals. Article 34(3) sets out three conditions that remove that obligation, and the first is about encryption: where you have implemented appropriate protection measures, those measures were applied to the data actually affected, and they render the data unintelligible to anyone not authorised to access it — "such as encryption."
That is the payoff. Not a lighter regulatory burden in the abstract, but the difference between emailing forty thousand customers to tell them their records were taken and not having to.
Two conditions on it, both easy to miss. First, the exemption is from telling the individuals, not from telling the regulator: Article 33 still obliges you to notify the supervisory authority, generally within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Second, the measures must have been applied to the affected data and must actually have rendered it unintelligible to the attacker. Data encrypted at rest, exfiltrated by an intruder who already had a live application session and a valid key, is not unintelligible to that person. The exemption turns on the facts of the incident, not on the entry in your security policy.
Encrypted Personal Data Is Still Personal Data
Encrypting a dataset does not move it outside the scope of the regulation. If you hold the key, or anyone else could reasonably obtain it, the data remains attributable to identifiable people and every obligation continues to apply: lawful basis, retention limits, access and erasure rights, records of processing, transfer rules.
This trips up more teams than the mandate question does, usually in the form of "the data is encrypted, so it is anonymous." It is not. At best it is pseudonymised, which is a security measure with real value and no effect on scope. The distinction has concrete consequences for what you may keep, for how long, and for what you may do with it, and it is worth getting right — our guide to anonymisation versus pseudonymisation sets out where the line sits and how far you have to go to cross it.
Article 32(1)(a) reinforces the point by naming pseudonymisation and encryption in the same breath, as two security measures of the same kind. Neither is described as a route out of the regulation, because neither is one.
What To Write Down, And What Buyers Will Ask For
Because "appropriate" is a judgment, the deliverable is the judgment itself. Article 5(2) makes you responsible for demonstrating compliance, and Article 24 requires measures you can show. In practice that means a short record covering four things: what personal data you hold and how sensitive it is, which of the Article 32(2) risks apply to it, which measures you chose and which you considered and rejected, and when you will revisit the decision.
Two paragraphs written before an incident are worth more than twenty written after one. The reasoning does not have to be elaborate. It has to exist, be dated, and match what your systems actually do.
A commercial reality runs on a separate track. Enterprise buyers do not ask whether GDPR requires encryption; they ask whether you encrypt at rest, with what, and whether you can prove it. The evidence they want is usually a configuration export rather than a policy statement — what buyers ask for in a security review covers the difference. Passing a vendor review and meeting Article 32 are related problems, and the first is often stricter.
Once you have decided that encryption is appropriate, the implementation questions begin: key management, what to encrypt at which layer, how to handle backups and rotation. Those are engineering decisions rather than legal ones, and our guide to enterprise data encryption covers them properly.
Common Mistakes With GDPR Encryption Requirements
Reading Article 32(1)(a) as a mandate. The phrase "as appropriate" governs the entire list. Quoting the sub-paragraph without it produces a requirement the regulation does not contain, and teams then spend budget defending against an obligation nobody imposed.
Treating encryption as a route out of scope. Encrypted personal data is personal data. Retention limits, erasure rights and transfer rules all still apply, and a dataset you believed was exempt is one nobody has been deleting.
Assuming disk encryption covers the breach that will actually happen. Full-disk encryption protects against a stolen server or a decommissioned drive. It does nothing about a compromised application account querying a live database through a legitimate connection, which is the more common failure.
Never recording the decision. With no documented risk assessment, "appropriate" becomes a claim you assert after an incident rather than a position you took before one. The absence of the record is itself an accountability failure under Article 5(2).
Storing the keys inside the blast radius. Keys held in the same environment as the data they protect will be taken in the same breach, and with them goes the Article 34(3)(a) exemption you were counting on.
FAQ
Does GDPR require encryption at rest?
No. No provision of the GDPR requires encryption at rest, in transit, or anywhere else. Article 32 requires measures appropriate to the risk and offers encryption as one example. For most systems holding personal data, encryption at rest is a reasonable conclusion from that assessment — but it is your conclusion, reached and recorded, not a rule handed to you.
If our data was encrypted, do we still have to report a breach?
To the supervisory authority, yes. Article 33 applies regardless of encryption, unless the breach is unlikely to result in a risk. What encryption can remove is the separate Article 34 duty to tell the affected individuals, provided the measures were applied to the affected data and genuinely rendered it unintelligible to whoever obtained it.
What encryption standard does GDPR require?
None. The regulation names no algorithm, key length or protocol, and it will not. It refers instead to the state of the art, which shifts over time and is meant to. Look to recognised sources such as your national supervisory authority's technical guidance or ISO 27001 for concrete parameters.
Is encrypted personal data still personal data?
Yes, wherever the key exists and could reasonably be obtained. Encryption is a security measure, not an identifiability test. Data does not leave the scope of the regulation until re-identification is no longer reasonably possible by anyone, which is a much higher bar than encrypting a column.
Closing Thought
The absence of a mandate is not the good news it first appears to be. A rule that said "encrypt personal data at rest using AES-256" would be a rule you could satisfy and stop thinking about. Article 32 instead hands you a standard that can only be evaluated in hindsight, by someone who already knows how the breach happened, and asks you to have decided well in advance. That is a harder obligation, not an easier one, and teams that read "not required" as "not our problem" have generally misread it.
ComplyDog will not encrypt your database, and no compliance tool will. What it does is hold the paperwork that makes an Article 32 decision defensible — your records of processing, your subprocessor list, your DPAs and a security page your buyers can read — in one portal on your own domain. That is the part of this that goes stale quietly, and the part regulators and enterprise buyers both ask to see. You can try it free for 14 days, no credit card required.
