How to write an encryption policy

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).

Primary sources

ISO/IEC 27001:2022 — Annex A control 8.24, use of cryptography (iso.org/standard/27001).
NIST Cybersecurity Framework — Protect function, Data Security (nist.gov/cyberframework).
ANSSI — guide des mécanismes cryptographiques et recommandations de gestion des clés (ssi.gouv.fr).

Generate it in minutes

See a sample encryption policy or generate yours free.

Frequently asked questions

Which encryption algorithms should the policy approve?

Name current standards explicitly — for example AES-256 for data at rest and TLS 1.2 or higher for data in transit — and explicitly retire weak ones such as TLS 1.0/1.1 and SHA-1. Review the list periodically, because "approved once, never updated" is a common audit gap.

Why is key management the hardest part of an encryption policy?

Because encryption is only as strong as how keys are generated, stored, rotated, revoked and recovered. Keys must never live next to the data they protect, and access needs separation of duties. It is the part auditors scrutinise most, so treat it as central, not an afterthought.

What should an encryption policy cover beyond algorithms?

Scope (data at rest, in transit, backups, removable media), key management, responsibilities, minimum TLS versions and certificate handling, full-disk encryption on end-user devices, and an exception process that is requested, approved and time-boxed so teams do not quietly bypass it.