Encryption Policy Template: Algorithms, Key Management and Data States

Most encryption failures are not broken algorithms but unmanaged keys, legacy protocols nobody switched off, and decisions about cryptography that no policy ever assigned to an owner. This template sets out which data must be encrypted in each state, an approved algorithms table, key and certificate rules that treat keys as non-human identities with named owners, and a post-quantum migration clause tied to NIST and NCSC timelines. It is written for CISOs, security architects and platform teams; have legal and compliance review it before adoption. For the concepts behind it, see the Cryptography Basics Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [CISO] and [12 months], with your own terms and values. Bracketed values are suggested defaults, not external requirements.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• Consider keeping the approved algorithms table (section 4.2) as a separately versioned standard, so it can change with NIST or NCSC guidance without re-approving the policy.
• Section 4.1 uses the levels Public, Internal, Confidential and Restricted from the Data Classification Policy Template; rename them to match your scheme.
• Place this policy beneath your top-level policy. See the Information Security Policy Template.

1. Purpose

This policy sets the requirements for the use of cryptography at [Organisation] to protect the confidentiality, integrity and authenticity of information: when encryption is mandatory, which algorithms and protocols are approved, how keys and certificates are managed, and how [Organisation] will migrate to post-quantum cryptography. Its aim is that every key has an accountable owner and weak or quantum-vulnerable cryptography is retired on a plan, not in an emergency.

2. Scope

This policy applies to all information owned, processed or held by or on behalf of [Organisation], and to all systems, applications, devices and services that store, process or transmit it, including:

• Endpoints, servers, databases, storage, backups and SaaS applications under [Organisation]'s control.
• Network connections, APIs, service-to-service traffic, email and file transfers, and applications developed by or for [Organisation].
• Cryptographic keys of every type: data encryption keys, key encryption keys, signing keys, TLS and code signing private keys, SSH keys, and the keys behind API tokens and workload identities.
• Digital certificates, certificate authorities, hardware security modules (HSMs) and key management services (KMS).

It applies to all staff and contractors who design, build, operate or procure these systems. Third parties that hold [Organisation] data must meet equivalent requirements through contract (section 4.8).

3. Roles and responsibilities

4. Policy statements

4.1 When encryption is required

1. Passwords and other authenticators must never be stored encrypted for later decryption. They must be stored using an approved password hashing function (section 4.2).
2. For practical guidance on device and storage encryption, see the Disk Encryption Guide and the Encryption Guide.

4.2 Approved algorithms and protocols

Only the algorithms below may be used for new systems. Implementations must use [Organisation]-approved, maintained cryptographic libraries or modules. Where [Organisation] is required to use validated cryptography, modules must hold a current FIPS 140-3 certificate.

1. The [Cryptography lead] must review this table at least [annually] and when NIST or NCSC guidance changes.

4.3 Cryptographic inventory

1. [Organisation] must maintain an inventory recording, for each key, certificate and cryptographic dependency: owner, purpose, algorithm and key size, location, creation and expiry or rotation dates, and the systems and data it protects.
2. The inventory must be updated automatically from KMS, certificate management and scanning tools where possible, and reconciled at least [quarterly]. See the Cryptographic Inventory and CBOM Guide.

4.4 Keys and certificates as non-human identities

A key or certificate that authenticates a workload, signs code or tokens, or decrypts data is a non-human identity. It must be governed with the same rigour as a privileged account.

1. Every key and certificate must have a named human owner and a documented purpose. A key without an owner must be assigned one within [10 working days] or disabled.
2. Keys must be generated inside an HSM or approved KMS using an approved random number generator, or on the device that will use them. Private keys must not be generated on shared workstations or sent by email or chat.
3. Root and issuing CA keys, token signing keys and code signing keys must be held in an HSM validated to [FIPS 140-3 Level 3] and must be non-exportable. Administrative operations on these keys require [dual control].
4. Data encryption keys must be protected by key encryption keys held in the KMS (envelope encryption). Keys must never be stored alongside the data or backups they protect.
5. Keys, secrets and private keys must never be stored in source code, container images, configuration files, tickets or personal password vaults. Applications must obtain them at runtime from [approved KMS or secrets manager] using workload identity rather than a static credential. See the Secrets Management Guide.
6. Access to use a key (decrypt, sign) must be granted separately from access to administer it and from access to the encrypted data store.

4.5 Key lifecycle and rotation

1. Rotation must be automated where supported. Keys past their rotation date must alert the owner and [security operations].
2. Deactivated keys may be retained only to decrypt or verify existing data, for no longer than [the retention period of that data], and must then be destroyed. Destruction must be recorded in the inventory.
3. Certificate renewal must be automated, with alerts at [30] and [7] days before expiry. See the Machine Identity, PKI and Certificate Lifecycle Guide.

4.6 Suspected key compromise

1. Suspected compromise of any key or certificate must be reported to [security operations] immediately and handled as a security incident.
2. The owner must revoke or disable the key, issue a replacement, re-encrypt or re-sign affected data where needed, and confirm that every relying system has stopped trusting the old key, within [24 hours for signing and CA keys].

4.7 Post-quantum migration

1. [Organisation] must plan to retire quantum-vulnerable public key algorithms (RSA, ECDSA, EdDSA, DH and ECDH) in line with [NIST IR 8547 and NCSC guidance], aiming to complete migration of all systems by [2035] and of high-priority systems by [2031].
2. By [2028], the [Cryptography lead] must complete discovery of quantum-vulnerable cryptography and publish a migration plan that prioritises long-lived confidential data, firmware signing and trust anchors.
3. New systems and products must support the approved post-quantum algorithms in section 4.2, or be upgradeable to them. External TLS endpoints should enable hybrid X25519MLKEM768 key exchange where supported.
4. Certificates and trust anchors must not be issued with validity periods extending beyond the planned migration date for that system.
5. Systems must be designed for crypto-agility: algorithms and key sizes configured, not hard-coded. See the Post-Quantum Cryptography Migration Guide and the Crypto-Agility Guide.

4.8 Third parties and cloud providers

1. Contracts with providers holding Confidential or Restricted data must require encryption at rest and in transit to the standard in section 4.2, notification of key compromise within [24 hours], and, for Restricted data, [customer-managed or customer-held keys].

5. Exceptions

1. Requests to use legacy or prohibited cryptography, or to store keys outside approved services, must be submitted to [the exception register] with the systems affected, business reason, compensating controls and a removal date.
2. Exceptions are approved by [CISO] for Restricted data and [Head of security architecture] otherwise, never by the system owner.
3. Exceptions expire after no more than [12 months] and are reviewed every [6 months]. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

1. [Organisation] must log all administrative operations and use of keys in HSMs and KMS, and forward these logs to [the SIEM]. Alerts must cover: key deletion or disabling, key policy changes, decrypt operations from unexpected identities or locations, bulk decrypt activity, and use of expired or deactivated keys.
2. External and internal endpoints must be scanned at least [monthly] for prohibited protocols and cipher suites, expiring certificates and weak keys.
3. The [Cryptography lead] must report quarterly to [the CISO] on:
   • Percentage of keys and certificates in the inventory with a named, current owner.
   • Percentage of keys rotated within their rotation period.
   • Certificates expired in production, and certificate-related outages.
   • Endpoints still offering TLS 1.0 or 1.1, or prohibited cipher suites.
   • Percentage of systems with a quantum-vulnerable dependency that have a migration plan.
4. Compliance with this policy is subject to internal audit at least [annually]. Breaches by staff may be handled under [disciplinary procedure].

7. Review and approval

Implementation guidance

Where the default values come from

• Algorithm retirement: NIST SP 800-131A Rev. 3 is still an initial public draft (October 2024). It proposes disallowing ECB mode and 3DES for encryption, deprecating SHA-1 and 224-bit hash functions through 31 December 2030 and then disallowing them for applying protection, and moving block ciphers and hash functions to a 128-bit security strength from 1 January 2031. AES-128, AES-192 and AES-256 remain acceptable. Treat these as planning targets until it is final.
• Post-quantum timeline: the draft NIST IR 8547 proposes deprecating RSA, ECDSA, EdDSA, DH and ECDH at 112-bit security after 2030 and disallowing all of them after 2035, and names FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) as replacements. The NCSC sets three milestones: discovery and an initial plan by 2028, highest-priority migration by 2031, and complete migration by 2035.
• TLS: the NCSC prefers TLS 1.3, accepts TLS 1.2 with its profiles, says to disable TLS 1.0, 1.1 and SSL, and recommends hybrid key exchange such as X25519MLKEM768.
• Validated modules: the NIST CMVP moves FIPS 140-2 certificates to the Historical list after 21 September 2026, for existing systems only.
• Cryptoperiods: the rotation values in section 4.5 are suggested defaults. Set your own using the cryptoperiod guidance in NIST SP 800-57 Part 1 Rev. 5.

Rollout

1. Build the cryptographic inventory first from KMS, HSM and CA exports and a TLS scan of all endpoints, then assign owners before enforcing rotation. An alert to nobody fixes nothing.
2. Switch on default encryption and automatic key rotation, then move Confidential and Restricted stores to customer-managed keys.
3. Before disabling TLS 1.0 and 1.1, log clients that still negotiate them for [30 days] and contact owners. Keep the previous configuration ready to restore for a named legacy client under an exception.
4. Automate certificate issuance and renewal before shortening validity periods. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
5. Start the post-quantum plan with systems protecting data that must stay confidential beyond 2035, and with firmware and code signing roots.

Failure patterns this policy is written to prevent

• Keys stored with the data: in the GoTo breach, the attacker exfiltrated encrypted backups together with an encryption key for a portion of them. Section 4.4 forbids storing keys with the data they protect.
• Decryption keys in a person's vault: the LastPass breach showed backup decryption keys held in an engineer's vault inheriting that engineer's endpoint weaknesses.
• Signing keys that never retire: in the Storm-0558 key breach, a 2016 consumer signing key that should have been retired in 2021 remained valid after manual rotation stopped, with nothing alerting on its age.

Framework mapping

Sources for the default values

• NIST: SP 800-131A Rev. 3 (initial public draft), Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST: IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: Cryptographic Module Validation Program
• NCSC: Using TLS to protect data
• NCSC: Timelines for migration to post-quantum cryptography

Related NHI Mgmt Group resources: Encryption Guide · Cryptographic Key Management Guide · Post-Quantum Migration for NHIs Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Data Classification Policy Template