Encryption Requirements for ISO 27001, SOC 2, HIPAA & GDPR

None of these frameworks names a specific algorithm or key length — each expects encryption appropriate to the risk. Here is how ISO 27001, SOC 2, HIPAA, and GDPR actually treat encryption, where the safe harbors live, and why key management, not the cipher, is where programs fail.

The starting point: none of them mandate a specific algorithm

The single most useful thing to understand about encryption across ISO 27001, SOC 2, HIPAA, and GDPR is what none of them say. None prescribes a named cipher, a minimum key length, a specific protocol version, or a particular product. There is no line in any of these that reads “use AES-256” or “TLS 1.3 only.” Each is technology-neutral and risk-based: the requirement is to use encryption that is appropriate to the sensitivity of the data and the threats it faces, and to be able to justify the choice you made.

That is deliberate. Standards and regulations that hard-code a specific algorithm would be obsolete the moment that algorithm weakened. Instead they push the decision onto you, the organization, through a risk assessment. The practical consequence is that you cannot satisfy an auditor or a regulator by pointing at a checkbox in a cloud console; you have to show that you decided what to encrypt, chose methods suited to the risk, and can explain the reasoning. Where formal benchmarks exist — NIST guidance in the US, ENISA and national authority guidance in the EU — they are widely treated as the reference for “appropriate,” but they sit outside the four frameworks themselves.

So the honest framing for the rest of this article is this: the four frameworks tell you that encryption is expected and roughly where, they give you safe harbors that reward doing it well, and they leave the specifics to your judgment and current cryptographic guidance. What follows maps each one. This is general information, not legal or audit advice; confirm the current text of any standard or regulation, and your specific obligations, with qualified counsel or your auditor.

ISO 27001: Annex A 8.24 and a cryptographic-controls policy

In ISO/IEC 27001:2022, the encryption anchor is Annex A control 8.24, “Use of cryptography.” It requires that rules for the effective use of cryptography — including cryptographic key management — are defined and implemented. Notice the two halves: it is not enough to turn encryption on; you are expected to have a defined position on when and how cryptography is used, and a deliberate approach to managing keys across their whole lifecycle.

The way ISO 27001 expects you to satisfy A.8.24 is with a documented cryptographic controls policy (sometimes titled an encryption and key management policy). That policy states what categories of information must be encrypted, in transit and at rest; the standards or strength you treat as acceptable; how keys are generated, distributed, stored, rotated, and destroyed; who owns those processes; and how exceptions are handled. Because A.8.24 is one of the controls you assess in your Statement of Applicability, you also have to state whether it applies (it almost always does) and justify your implementation.

What the certification body actually tests is the gap between that policy and reality. Auditors will ask to see that the encryption your policy promises is genuinely in force — that the databases your policy says are encrypted at rest actually are, that key rotation happens on the cadence you committed to, and that someone owns the key store. A clean cryptographic controls policy that does not match operations becomes a nonconformity. The document is the readiness layer; the operating controls are what get certified.

SOC 2: protecting data under the Common Criteria

SOC 2 does not have an “encryption clause” in the way HIPAA or GDPR name encryption directly. Instead, encryption is one of the most common ways organizations meet several of the Common Criteria in the Security category. The two most relevant anchors are CC6.1, which concerns implementing logical access security measures to protect information assets from unauthorized access, and CC6.7, which concerns restricting and protecting the transmission, movement, and removal of information. Encryption in transit and at rest is the usual control an organization maps to these criteria.

The important nuance is that the AICPA Trust Services Criteria describe an objective, not a technique. CC6.1 and CC6.7 ask whether protected information is secured against unauthorized access and whether data is protected as it moves; encryption is how most organizations achieve that, but the criterion is the goal, and your control is your stated answer to it. In a SOC 2 examination you will typically describe a control such as “data is encrypted in transit using TLS and at rest using platform-managed encryption,” and then the auditor tests whether that control operated.

That testing is the heart of a SOC 2 report and where the honesty rules matter most. A SOC 2 report is issued only by a licensed CPA firm after it examines whether your controls were suitably designed (Type I) and operated effectively over a period (Type II). No template, console screenshot, or policy makes you “SOC 2 compliant” on its own — there is no such status to buy. The auditor pulls evidence: configuration exports, a sample of systems, key-management records. Your written control is the claim; the evidence is what earns the opinion.

HIPAA: “addressable” does not mean optional, plus the safe harbor

As the HIPAA Security Rule stands today, it treats encryption as an “addressable” implementation specification in two places: encryption of electronic protected health information (ePHI) at rest, under the access control standard at 45 CFR 164.312(a)(2)(iv), and encryption of ePHI in transit, under the transmission security standard at 45 CFR 164.312(e)(2)(ii). The word “addressable” causes more confusion than any other term in HIPAA, so be precise about it.

Addressable does not mean optional. It means you must assess whether the specification is reasonable and appropriate for your environment, and then do one of three things: implement it; implement an equivalent alternative measure if encryption is not reasonable and appropriate; or, if neither is reasonable and appropriate, document why and what you do instead. You do not get to skip the analysis. For most organizations holding ePHI on laptops, mobile devices, backups, or transmitting it over open networks, encryption will be the reasonable and appropriate choice, and choosing not to encrypt without a documented, defensible rationale is exactly the kind of gap the HHS Office for Civil Rights flags in enforcement. Note also that HHS published a proposed rule (NPRM) in January 2025 that would remove the addressable/required distinction and make encryption effectively mandatory with limited exceptions; as of this writing that proposal has not been finalized, so the addressable framework above remains current law — monitor HHS for the final rule.

HIPAA also offers the strongest direct incentive of the four frameworks: the breach-notification safe harbor. The Breach Notification Rule attaches its duties only to “unsecured” PHI — PHI not rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption or destruction methods specified in HHS guidance. If a lost laptop’s drive was encrypted to that standard and the key was not also compromised, the exposed PHI is generally not “unsecured,” and the loss is generally not a reportable breach. Encryption can take an incident out of breach territory entirely — which is why it is treated as the expected default for portable devices and data in transit. The specific methods sit in HHS guidance rather than the CFR text, so confirm the current methodology at hhs.gov.

GDPR: Article 32 names encryption, Article 34 rewards it

The GDPR is the only one of the four that names encryption in its operative text, and it does so twice. Article 32(1), “Security of processing,” requires controllers and processors to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk — and it lists, as the first named example, “the pseudonymisation and encryption of personal data” in Article 32(1)(a). Encryption is an example of an appropriate measure, not a blanket mandate; whether it is required in a given case turns on the risk-based assessment Article 32 sets up, weighing the state of the art, costs, and the likelihood and severity of risk to individuals.

The second appearance is the reward. Article 34 requires a controller to communicate a personal data breach to affected individuals when the breach is likely to result in a high risk to their rights and freedoms. But Article 34(3)(a) provides that this individual-notification duty does not apply if the controller has implemented appropriate technical and organizational protection measures — “in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption” — and applied them to the affected data. Properly applied encryption can remove the obligation to notify each individual of the breach.

Two honest caveats. First, the Article 34(3)(a) relief is from the duty to notify the individuals; it does not by itself remove the separate duty under Article 33 to notify the supervisory authority, which runs on its own risk test and the well-known 72-hour timeline. Second, the relief depends on the encryption actually rendering the data unintelligible to the attacker — if the key was exposed alongside the data, the protection failed and the exemption does not apply. As always with GDPR, the assessment is fact-specific; confirm against the current Regulation text and your authority’s guidance.

In transit vs at rest — and why key management is the hard part

Across all four frameworks, encryption splits into two settings. Encryption in transit protects data while it moves across a network — in practice, TLS for web traffic, APIs, and email transport, and equivalent protocols elsewhere. It defends against interception on the wire. Encryption at rest protects stored data — disk, database, object storage, backups, portable media — against someone who gets hold of the storage itself, which is the scenario the HIPAA laptop safe harbor is built around. Most programs need both, because they defend against different attacks; encrypting in transit while leaving backups in clear text leaves an obvious hole, and vice versa.

The part that quietly decides whether any of this is real is key management. Encryption is only as strong as the secrecy and discipline around its keys. If keys are stored next to the data they protect, hard-coded in source, shared over chat, never rotated, or held by people who have left, then the data is encrypted in name only — and, critically, the safe harbors evaporate. The HIPAA safe harbor explicitly fails if the key was compromised; the GDPR Article 34 relief fails if the data was not genuinely unintelligible to the attacker. This is why ISO’s A.8.24 calls out key management by name, why SOC 2 auditors ask where keys live and how they rotate, and why a credible encryption policy spends more words on key lifecycle than on cipher choice.

This is also where a documentation layer helps you start. The ComplianceDocs toolkits include the matching policy for each framework — a Cryptographic Controls Policy in the ISO 27001 toolkits, an Encryption and Key Management Policy in the SOC 2 toolkits, an Encryption and Transmission Security Policy in the HIPAA toolkits, and Article 32 security-measure language in the GDPR pack — each an editable starting point with the in-transit, at-rest, and key-lifecycle sections already laid out. Be clear about what that is: the policy is the readiness layer, not the control. No template encrypts a single byte, makes you compliant, or earns a certification or a SOC 2 report — those come from accredited bodies and licensed CPA firms auditing controls that genuinely operate. The toolkit removes the blank-page work so your time goes to actually configuring encryption, locking down the keys, and keeping the evidence. Any time or cost figures you read elsewhere are illustrative estimates, not quotes; actual figures vary by environment and provider.

Frequently asked questions

Does ISO 27001, SOC 2, HIPAA, or GDPR require AES-256 or a specific encryption standard?

No. None of the four prescribes a specific algorithm, key length, or protocol version. Each is technology-neutral and risk-based, requiring encryption appropriate to the sensitivity of the data and the threats it faces, and the ability to justify your choice. Many organizations adopt recognized references such as NIST guidance to define what “appropriate” means, but those benchmarks sit outside the frameworks themselves. The expectation an auditor or regulator tests is that you decided what to encrypt, chose suitable methods, and can explain the reasoning — not that you ticked a named-cipher box.

What does “addressable” mean for HIPAA encryption — is encryption optional?

Addressable does not mean optional. Under the current HIPAA Security Rule, encryption of ePHI at rest (45 CFR 164.312(a)(2)(iv)) and in transit (45 CFR 164.312(e)(2)(ii)) are addressable implementation specifications, which means you must assess whether encryption is reasonable and appropriate for your environment and then either implement it, implement an equivalent alternative measure, or document why neither is reasonable and appropriate and what you do instead. You cannot skip that analysis. For most organizations holding ePHI on laptops, mobile devices, backups, or open-network transmissions, encryption is the reasonable and appropriate choice, and declining to encrypt without a documented rationale is a common enforcement gap. A 2025 HHS proposed rule would make encryption effectively mandatory, but it has not been finalized as of this writing.

Can encryption really get me out of breach notification?

It can, within limits. Under HIPAA, the Breach Notification Rule only applies to “unsecured” PHI; PHI rendered unusable through encryption or destruction methods specified in HHS guidance is generally not unsecured, so its loss is generally not a reportable breach — provided the key was not also compromised. Under GDPR, Article 34(3)(a) removes the duty to notify affected individuals if you applied measures, such as encryption, that render the data unintelligible to an unauthorized person. The relief depends on the encryption actually protecting the data, and under GDPR it does not remove the separate duty to notify the supervisory authority under Article 33.

Which SOC 2 criteria does encryption map to?

Encryption most commonly supports CC6.1, which concerns logical access security measures that protect information assets from unauthorized access, and CC6.7, which concerns restricting and protecting the transmission, movement, and removal of information. SOC 2 does not name encryption as a required technique; the Common Criteria describe the security objective, and encryption in transit and at rest is how most organizations meet it. Your control is your stated answer to the criterion, and a licensed CPA firm tests whether that control was designed suitably and, for a Type II, operated effectively over the period using real evidence.

Why do people say key management is harder than encryption itself?

Because encryption is only as strong as the secrecy and discipline around its keys, and key management is where programs quietly fail. Keys stored next to the data, hard-coded in source, shared over chat, never rotated, or still held by people who have left mean the data is encrypted in name only. It also breaks the safe harbors: the HIPAA breach safe harbor explicitly fails if the key was compromised, and the GDPR Article 34 relief fails if the data was not genuinely unintelligible to the attacker. That is why ISO 27001’s Annex A 8.24 names key management directly and why auditors ask where keys live, who owns them, and how they rotate.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles