Why you need a cryptography policy
Encryption is the single most powerful tool in your compliance stack. It's mentioned in GDPR Art. 32, ISO 27001 A.10, SOC 2 CC6.7, HIPAA §164.312, PCI DSS Req 3 and 4, NIS2 Art. 21(2)(h), and dozens of enterprise security questionnaires. It also triggers the GDPR breach notification safe harbour — if your data is properly encrypted and the keys weren't compromised, you may not need to notify affected individuals after a breach.
But "we use encryption" isn't enough. What algorithm? What key length? Who manages the keys? What happens when a key needs to be rotated? What protocols are explicitly prohibited? A cryptography policy answers all of these — and gives you audit evidence that your encryption programme is systematic, not ad-hoc.
The compliance requirements at a glance
| Framework | Reference | Requirement |
|---|---|---|
| ISO 27001:2022 | A.8.24 / A.10.1.1 | Policy on use of cryptographic controls; appropriate use of encryption |
| ISO 27001:2022 | A.10.1.2 | Key management — generation, storage, distribution, retirement, destruction |
| SOC 2 | CC6.7 | Transmission and storage of sensitive data encrypted; logical access controls include encryption |
| GDPR / UK GDPR | Art. 32(1)(a) | Pseudonymisation and encryption of personal data as TOMs |
| GDPR / UK GDPR | Art. 34(3)(a) | Breach notification safe harbour: no individual notification if encrypted data was compromised and keys uncompromised |
| HIPAA | §164.312(a)(2)(iv) | Encryption and decryption of ePHI — addressable safeguard (implement or document equivalent alternative) |
| HIPAA | §164.312(e)(2)(ii) | Encryption of ePHI in transit — addressable safeguard |
| PCI DSS v4.0 | Req 3.5 | Primary account number (PAN) must be unreadable anywhere stored — strong cryptography required |
| PCI DSS v4.0 | Req 4.2.1 | Strong cryptography for PAN in transit; TLS required over open/public networks |
| NIS2 | Art. 21(2)(h) | Cryptography and, where appropriate, encryption as one of 10 mandatory security measures |
Approved algorithms: what to use in 2026
Algorithm selection is where policies go wrong most often — either by being too vague ("we use strong encryption") or by listing deprecated algorithms without realising they're deprecated. Here's what to specify:
Symmetric encryption (data at rest)
- AES-256-GCM — gold standard. Use for all data at rest in new systems. GCM provides authenticated encryption (integrity + confidentiality in one operation).
- AES-128-GCM — acceptable for specific performance-constrained cases. Not preferred but not broken.
- ChaCha20-Poly1305 — excellent for mobile and high-throughput use cases where hardware AES acceleration isn't available. IETF RFC 8439.
Asymmetric encryption and key exchange
- ECDH with P-256 or P-384 — preferred for key exchange in new systems
- X25519 — modern, fast, recommended for new TLS configurations
- RSA-4096 — acceptable for legacy compatibility; prefer ECDSA/ECDH for new systems
- RSA-2048 — minimum acceptable; do not use for new systems
Digital signatures
- Ed25519 — preferred for new systems
- ECDSA with P-256 or P-384 — standard for TLS certificates
- RSA-PSS with SHA-256 — acceptable for legacy compatibility
Hashing
- SHA-256, SHA-384, SHA-512 — approved for general-purpose hashing
- HMAC-SHA256 — for message authentication and API request signing
- ⚠️ Critical: For password storage — NEVER use SHA-* directly. Use: Argon2id (OWASP recommended, RFC 9106), bcrypt (min work factor 12), or scrypt. Passwords hashed with SHA-256 are trivially crackable with GPUs.
Prohibited algorithms — explicitly ban these
Your policy must explicitly prohibit deprecated algorithms. "We don't use them" is not the same as "they are prohibited and engineers know it."
| Algorithm / Protocol | Why Prohibited | Reference |
|---|---|---|
| DES / 3DES | SWEET32 birthday attack; NIST deprecated 2019 | CVE-2016-2183, NIST SP 800-131A |
| RC4 | Statistical biases exploitable in practice; NOMORE attack | RFC 7465 (prohibits RC4 in TLS) |
| MD5 | Collision attacks since 2004; used in Flame malware certificate forgery | RFC 6151 |
| SHA-1 | SHAttered collision attack (2017); Chrome/Firefox/Edge no longer trust SHA-1 certs | RFC 9155 |
| RSA < 2048-bit | Factorable with modern hardware | NIST SP 800-131A |
| SSL 2.0 / 3.0 | DROWN (SSL 2.0), POODLE (SSL 3.0) attacks; formally deprecated | RFC 7568, RFC 6176 |
| TLS 1.0 / 1.1 | BEAST, POODLE vulnerabilities; PCI DSS prohibited since June 2018 | RFC 8996, PCI DSS Req 4.2.1 |
| AES-ECB mode | Identical plaintext blocks → identical ciphertext; no semantic security (the penguin problem) | NIST recommendation against ECB |
| Custom cryptography | No peer review; high probability of subtle implementation flaws | Universal cryptographic principle |
Encryption at rest: what must be encrypted
Everything. But let's be specific about what "everything" means for SaaS:
- Production databases — AES-256, managed via cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault). Enable encryption at the storage layer and verify it's on.
- Object storage — S3/GCS/Azure Blob server-side encryption. Default encryption is on for most modern buckets, but verify it's AES-256, not AES-128.
- Backups — use separate backup keys. If production keys are compromised, backups shouldn't be decryptable with the same keys.
- Developer laptops — full-disk encryption (FileVault on macOS, BitLocker on Windows). Mandatory. Verify via MDM. Every data breach involving a stolen laptop is a reportable GDPR breach if the disk wasn't encrypted.
- Secrets and credentials — NEVER in plaintext. Use AWS Secrets Manager, HashiCorp Vault, Doppler, or 1Password Secrets Automation. Secrets in environment variables exposed in CI/CD logs is one of the most common security failures.
- Special category / PHI / PCI data — consider field-level or column-level encryption as an additional layer on top of disk encryption, especially for data that enterprise customers are most sensitive about.
Encryption in transit: TLS correctly
The baseline in 2026: TLS 1.2 minimum, TLS 1.3 preferred. TLS 1.0 and 1.1 are prohibited by PCI DSS and should be explicitly banned in your policy.
| Connection Type | Minimum Standard | Notes |
|---|---|---|
| External web / API | TLS 1.2 + HSTS | HSTS with min 1-year max-age; includeSubDomains recommended |
| Internal microservices | TLS or mTLS | mTLS preferred for sensitive internal APIs; TLS minimum for all |
| Database connections | TLS required if remote | Localhost connections within same host may be exempt |
| Email (outbound) | STARTTLS / TLS | Opportunistic TLS at minimum; S/MIME or PGP for sensitive content |
| Remote admin access | SSH with key authentication | Password auth disabled; no Telnet; no FTP |
| VPN | IKEv2/IPSec or WireGuard | For production system access from untrusted networks |
Key management: the part most teams forget
Encryption without key management is security theatre. If your keys are poorly managed, an attacker who obtains your keys can decrypt everything — and there's no meaningful difference between encrypted-with-compromised-keys and unencrypted.
The key management lifecycle every policy must cover:
- Key generation — use a cryptographically secure random number generator (CSPRNG). Cloud KMS handles this for you. Don't generate keys manually or with predictable seeds.
- Key storage — keys must never be stored alongside the data they protect. AWS KMS, GCP Cloud KMS, Azure Key Vault, and HashiCorp Vault all handle this correctly. Never store keys in environment variables, config files, or source code.
- Key distribution — secure channel only. If you need to share a key (e.g. for backup recovery), use a secure channel (not email) and split custody if the sensitivity warrants it.
- Key rotation — annual minimum for most keys. Immediately on suspected compromise. Immediately on departure of any personnel with key access. TLS certificates: 90-day cycle with auto-renewal strongly preferred.
- Key revocation — have a documented process for emergency key revocation. Cloud KMS provides this. Know how to execute it under pressure.
- Key destruction — NIST 800-88 compliant destruction. For cloud-managed keys, "delete" the key material in KMS and document it. For hardware, destroy the HSM or use cryptographic erasure.
The GDPR breach notification safe harbour
This is one of the most valuable — and most misunderstood — aspects of encryption compliance. GDPR Art. 34(3)(a) says you don't need to notify affected individuals after a data breach if "the controller has implemented appropriate technical and organisational protection measures... which render the personal data unintelligible to any person who is not authorised to access it, such as encryption."
In plain English: if your data is properly encrypted and the encryption keys were not compromised in the breach, you may not need to send breach notifications to your customers' end-users. You still need to notify the supervisory authority under Art. 33 (72-hour rule), but the reputational and legal exposure of mass individual notification is avoided.
The safe harbour applies when:
- The data was encrypted with a strong algorithm (AES-256-GCM or equivalent)
- The encryption keys were NOT compromised in the breach (keys stored separately)
- The encryption was applied before the breach (not retroactively)
This makes key management a GDPR compliance issue, not just a security one. Separate key storage from data storage.
5 common cryptography policy failures
| Failure | Common Pattern | Fix |
|---|---|---|
| Passwords hashed with SHA-256 | Developer used bcrypt for new passwords but legacy users still have SHA-256 hashes — found during audit | Migrate legacy hashes on next login; enforce Argon2id for all new hashes |
| Secrets in environment variables in CI/CD logs | API keys printed in build logs, accessible to all engineers | Move to secrets manager; add pre-commit secret scanning |
| TLS 1.0 still enabled for "compatibility" | Enterprise customer requires TLS 1.0 support; team enables it without policy update or exception | Document formally as exception with compensating controls; work to remove |
| Encryption keys stored in same database as data | "Encrypted" database where the encryption key is in a config column in the same DB — not actually encrypted | Move keys to cloud KMS; data and keys must be in different storage systems |
| Backup encryption keys same as production keys | Production key compromise → all backups decryptable | Use separate backup encryption keys; rotate independently |
Generate your Cryptography & Encryption Policy
A free Cryptography & Encryption Policy Generator creates a complete policy covering approved algorithms, encryption at rest and in transit, key management lifecycle, TLS standards, and compliance framework mappings for ISO 27001 A.10, SOC 2 CC6.7, GDPR Art. 32, HIPAA, PCI DSS, and NIS2.
Related generators: Information Security Policy, Access Control Policy, Data Classification Policy, Vulnerability Management Policy, SOC 2 Gap Assessment.
Related reading: GDPR Art. 32 TOMs for SaaS, Access Control Policy Guide, SOC 2 Gap Analysis Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Cryptographic requirements vary by compliance framework, jurisdiction, and system architecture. Engage a qualified information security professional for your specific implementation.