Theme comparison · encryption
Encryption requirements by framework
Compare encryption requirements across SOC 2, ISO 27001, GDPR, and HIPAA, including control references, risk decisions, SaaS evidence, and exceptions.
Frameworks covered: SOC 2, ISO/IEC 27001, GDPR, HIPAA
Key differences
| Dimension | Approach A | Approach B |
|---|---|---|
| SOC 2 | CC6.1 and related logical-access criteria expect protections aligned to commitments and risk; confidentiality criteria strengthen data-protection expectations. | No universal algorithm is prescribed; auditors test the entity’s stated encryption controls, key handling, exceptions, and operation. |
| ISO 27001 | A.8.24 requires rules for effective cryptography and key management based on legal, contractual, and risk needs. | The SoA records applicability, while procedures should cover approved algorithms, ownership, rotation, revocation, backup, and key custody. |
| GDPR | Article 32 names encryption and pseudonymisation as possible appropriate measures; Articles 5 and 25 shape protection by design. | Encryption is risk-based rather than universally mandatory, but failures require defensible proportionality and state-of-the-art analysis. |
| HIPAA | Encryption and decryption at §164.312(a)(2)(iv) and transmission encryption at §164.312(e)(2)(ii) are addressable specifications. | A regulated entity must implement them when reasonable and appropriate or document an equivalent alternative or justified decision. |
| At-rest coverage | SOC 2 and ISO scope follow systems and risk; SaaS teams normally encrypt databases, object storage, backups, endpoints, and secrets. | GDPR and HIPAA analysis follows affected personal data or ePHI, including replicas, exports, support tools, and vendor storage. |
| In-transit coverage | TLS for public endpoints, service-to-service traffic, administrative access, and file transfer is common shared implementation. | Evidence must address legacy protocols, certificate renewal, internal trust boundaries, and regulated-data transmission risk. |
| Breach effect | Encryption can reduce exposure and audit impact only when keys, access, and implementation remain effective. | GDPR and HIPAA breach analyses may treat properly protected data differently, but encryption does not automatically excuse every notice. |
Control overlap
One SaaS cryptography standard can serve all four frameworks when it is grounded in data classification and risk. Map database and object-storage encryption, TLS, secrets handling, and KMS controls to /controls/soc-2/cc6-1, ISO A.8.24, GDPR Article 32, /controls/hipaa/164-312-a-2-iv, and /controls/hipaa/164-312-e-1. Retain cloud configuration exports, TLS scans, KMS policies, key-rotation events, backup settings, mobile or endpoint status, and approved exceptions. Framework differences remain important: SOC 2 tests commitments, ISO expects SoA and cryptographic governance, GDPR weighs risks to individuals, and HIPAA requires documented treatment of addressable specifications for actual ePHI.
Sequencing advice
For a SaaS platform, inventory sensitive fields and ePHI/personal-data paths before writing a blanket “AES-256 everywhere” policy. Establish cloud KMS ownership, prohibit plaintext public transport, automate TLS and storage guardrails, isolate production keys, rotate credentials, log key use, and cover backups and exports. Remediate internet-facing and regulated-data paths first, then legacy internal traffic based on documented risk. Create an exception record with asset, data, compensating controls, approver, and expiry. Collect configuration evidence continuously for SOC 2 and ISO while retaining GDPR and HIPAA rationale tied to data risk; test restore and key-loss scenarios so encryption does not undermine availability.