Why an encryption policy matters
Encryption is only as good as the decisions behind it: which data, which algorithms, who holds the keys. An encryption policy records those decisions so they are consistent, defensible and auditable — rather than left to whoever configured each system.
What to include
- Scope — data at rest, data in transit, backups, and removable media.
- Approved algorithms — name current standards (e.g. AES-256 for data at rest, TLS 1.2+ for transit) and explicitly retire weak ones.
- Key management — generation, storage, rotation, revocation and recovery; keys never live next to the data they protect.
- Responsibilities — who owns keys, who can request decryption, separation of duties.
- Data in transit — minimum TLS versions, certificate management, internal traffic.
- End-user devices — full-disk encryption on laptops and phones.
- Exceptions — how an exception is requested, approved and time-boxed.
Common mistakes
- Listing algorithms once and never retiring deprecated ones (TLS 1.0/1.1, SHA-1).
- Treating key management as an afterthought — it is the hardest and most-audited part.
- No exception process, so teams quietly bypass the policy.
Framework alignment
Maps to ISO 27001:2022 Annex A 8.24 (use of cryptography), the SOC 2 confidentiality criteria, and NIST CSF Protect (PR.DS).