DAT-005 Cryptographic Key Management
Description
Cryptographic keys are generated, stored, rotated, revoked and destroyed according to a documented key management policy that names the roles accountable for each activity and the legal and regulatory requirements that constrain key handling. Keys are generated with industry-accepted cryptographic libraries, and the policy records the algorithm strength and the random number generator used. Each secret or private key is provisioned for a single purpose. Keys are stored separately from the data they protect, and access to key material is restricted and logged. Key rotation periods are defined and enforced, and a key is deactivated at the end of its recorded cryptoperiod. A key inventory records every key in use with its purpose, owner, cryptoperiod and current state, and each transition between states (pre-activation, active, suspended, deactivated, compromised, archived, destroyed) is approved and recorded against the inventory entry. Archived keys are held in a repository with least-privilege access. A compromised key is used only to decrypt data already protected by it and never to encrypt. A recovery route for keying material is documented, and the risk of that material being exposed is weighed against the risk of losing access to the data it protects. Changes to cryptographic algorithms, libraries or key management systems carry a recorded analysis of downstream effects, residual risk, cost and benefit before approval. Operation of the key management controls is monitored and reported internally at defined intervals. A maintained list records the protocols or families of protocols, the algorithms, the cipher strengths, the cryptographic solutions and the usage practices approved for use, and the type and strength required for each class of asset, for data at rest and data in transit. Each cryptographic implementation in production resolves to an entry on that list, and an entry withdrawn from it carries the migration route for the implementations that depend on it and the date by which they leave it.
Rationale
Encryption is only as strong as the protection of its keys. Weak or unmanaged key lifecycle is a common failure mode that renders encryption ineffective. Without a recorded state per key, an auditor can confirm that a rotation policy exists and not that any key ever followed it. Explicit states with an inventory behind them make rotation, suspension and compromise handling testable. Decrypt-only use of a compromised key keeps historical data readable while stopping the compromised material from protecting anything new. Recording the algorithm strength per key says what a key is; the approved list says what may be chosen next, which is the artefact an agility approach needs and the one the control previously had nowhere to put. Tying the required strength to the asset class is what stops the list becoming a single floor applied to everything, and the withdrawal route is what makes a deprecation more than an announcement. DAT-004 carries the approved protocol list for transport, which is one section of this list read from the network side.
Applicability (9 profiles)
Annex points 9.2(a) and 9.2(b) are now stated: a maintained list of the protocols, algorithms, cipher strengths, solutions and usage practices approved for use, with the type and strength required per asset class for data at rest and in transit, every production implementation resolving to an entry and a withdrawn entry carrying its migration route, which is what the cryptographic agility approach needs.
Framework Mappings (48)
| CEK-01 | Encryption and Key Management Policy and Procedures | full |
| CEK-02 | CEK Roles and Responsibilities | full |
| CEK-04 | Encryption Algorithm | informative |
| CEK-05 | Encryption Change Management | partial |
| CEK-06 | Encryption Change Cost Benefit Analysis | full |
| CEK-07 | Encryption Risk Management | partial |
| CEK-09 | Encryption and Key Management Audit | partial |
| CEK-10 | Key Generation | full |
| CEK-11 | Key Purpose | full |
| CEK-12 | Key Rotation | partial |
| CEK-13 | Key Revocation | full |
| CEK-14 | Key Destruction | full |
| CEK-15 | Key Activation | full |
| CEK-16 | Key Suspension | full |
| CEK-17 | Key Deactivation | full |
| CEK-18 | Key Archival | full |
| CEK-19 | Key Compromise | full |
| CEK-20 | Key Recovery | full |
| CEK-21 | Key Inventory Management | full |
| LOG-11 | Encryption Monitoring and Reporting | full |
| CEK-01 | Encryption and Key Management Policy and Procedures | full |
| CEK-02 | CEK Roles and Responsibilities | full |
| CEK-04 | Encryption Algorithm | informative |
| CEK-05 | Encryption Change Management | partial |
| CEK-06 | Encryption Change Cost Benefit Analysis | full |
| CEK-07 | Encryption Risk Management | partial |
| CEK-09 | Encryption and Key Management Audit | partial |
| CEK-10 | Key Generation | full |
| CEK-11 | Key Purpose | full |
| CEK-12 | Key Rotation | partial |
| CEK-13 | Key Revocation | full |
| CEK-14 | Key Destruction | full |
| CEK-15 | Key Activation | full |
| CEK-16 | Key Suspension | full |
| CEK-17 | Key Deactivation | full |
| CEK-18 | Key Archival | full |
| CEK-19 | Key Compromise | full |
| CEK-20 | Key Recovery | full |
| CEK-21 | Key Inventory Management | full |
| LOG-11 | Encryption Monitoring and Reporting | full |
| GDPR-Art.32.1 | Technical and Organisational Security Measures | informative |
| HIPAA-164.312.a.2.iv | Encryption and Decryption | informative |
| 8.24 | Use of cryptography | full |
| NIS2-Art.21.2.h | Use of Cryptography and Encryption | partial |
| NIS2-CIR-9 | Cryptography | full |
| IA-7 | Cryptographic Module Authentication | informative |
| SC-12 | Cryptographic Key Establishment and Management | full |
| SC-13 | Cryptographic Protection | full |
Evidence (4)
Key management policy documenting lifecycle requirements for cryptographic keys including generation, storage, rotation schedules, revocation, and destruction.
Example: Cryptographic Key Management Policy (Confluence), approved by CISO, specifying KMS usage, key rotation periods per algorithm (e.g. AES-256 annual rotation), access restrictions, and prohibition on exporting key material outside approved HSM/KMS
Test: Request the key management policy. Verify: (1) covers all lifecycle stages: generation, storage, rotation, revocation, destruction, (2) specifies maximum rotation period per key type, (3) requires keys to be stored separately from the data they protect, (4) restricts access to key material to named roles or systems, (5) approved within 24 months. (6) the approved list exists, names protocols, algorithms, cipher strengths, solutions and usage practices and states the type and strength required for each asset class, at rest and in transit, (7) it carries a review date within the defined interval, and an entry withdrawn since the last review carries a migration route and a date by which the implementations depending on it leave it.
KMS or key vault configuration and audit logs demonstrating active key rotation, separation of key custodianship, and logged access to key material.
Example: AWS KMS key rotation status report (all CMKs), AWS CloudTrail log excerpt showing key usage and access attempts, and key policy JSON showing restricted IAM principals, exported for audit period
Test: Query the key management service or hardware security module that holds the production keys. Verify: (1) automatic rotation is enabled for every key the organisation manages, or a documented cryptoperiod and a manual rotation record exist for it, (2) key access policies restrict use to approved roles or principals, (3) the key access log shows no unauthorised access event in the last 90 days, (4) key material is non-exportable or its export is restricted to the uses the policy names, (5) every key in the inventory resolves to a key present in the service. (6) every algorithm, cipher strength and protocol observed in the production key management service resolves to an entry on the approved list, with no implementation running on an entry that has been withdrawn past its migration date.
Key inventory export listing every key in use with its purpose, owner, cryptoperiod, current state and the date and approver of its last state change.
Example: key-inventory-export-2026-08-31.csv, generated from the key management system
Test: Export the key inventory. Verify: (1) every key protecting production data appears in the export, (2) each entry carries one recorded purpose rather than a list, (3) each entry carries a state drawn from the seven defined states and a date for its last transition, (4) no key sits in the active state past the end of its recorded cryptoperiod, (5) each archived key resolves to a repository whose access list holds only the named key management roles, (6) any key recorded as compromised has no encrypt permission remaining on it.
Cryptographic change analysis for the most recent change to an algorithm, library or key management system, with its approval.
Example: CHG-2026-0412 cryptographic change analysis, approved 2026-05-14
Test: Request the analysis for the most recent cryptographic change. Verify: (1) the analysis is dated before the change went live, (2) it names the systems and the data the change reaches, (3) downstream effects, residual risk, cost and benefit are each stated rather than referred to another document, (4) an approver holding one of the named key management roles signed it, (5) the key inventory entries the change affected carry a state transition dated to the change.
Questions (3)
Does your organisation have a documented cryptographic key management policy that covers the full key lifecycle: generation, storage, rotation, revocation and destruction?
The policy must specify key rotation periods, require keys to be stored separately from the data they protect, restrict and log access to key material, and be approved within the last 24 months.
How are encryption keys managed in your production environment?
Cloud KMS with automatic rotation is the baseline expectation where the environment runs on a cloud provider. Keys managed within the application without separation represent a significant control weakness.
Which of the following does your key management programme record?
The first six items are recorded per key, the last is recorded once for the organisation. Options run from the most commonly held to the least. A programme that records purpose and rotation but no lifecycle state can show that a rotation policy exists without showing that any individual key followed it. The recovery route is the element most often left to the key management platform's defaults, and the approved list is the one most organisations hold somewhere without connecting it to the keys in use.