Key Management Process

1. Purpose

This process controls cryptographic keys from creation to destruction so that encrypted information stays confidential and recoverable. A key that is weak, leaked, lost or kept too long defeats the protection it was meant to give; the steps below prevent each of these outcomes and leave evidence that they were followed.

2. Scope

• In scope: all keys, certificates, passphrases that protect keys and secrets used by the Organisation, including data encryption keys, key encryption keys, TLS and code-signing certificates, SSH keys, API signing keys, database and disk encryption keys, backup encryption keys and keys held in cloud key services or hardware security modules.
• In scope people: system owners, administrators, developers and any supplier that creates or holds keys for the Organisation.
• Out of scope: user login passwords (see the Access Control Policy) and keys that customers manage for their own systems, unless the Organisation operates them on the customer's behalf.
• Which algorithms and key lengths are acceptable is set by the Cryptography Policy and the Cryptography Procedure; this process says how the keys themselves are handled.

3. Terms and Definitions

4. Roles and Responsibilities

5. Key Management Process

5.1 Key hierarchy and key types

5.2 Key generation

1. RequestThe system owner requests a key in the ticketing tool, naming the system, purpose, data classification and algorithm required by the Cryptography Procedure.
2. ApproveThe key manager checks the request against the key hierarchy; keys protecting Restricted data or the root need approval by the Head of Information Security.
3. GenerateCreate the key inside an HSM or approved key management service using a certified random number source; never create keys in a spreadsheet, script on a personal device or from a human-chosen phrase.
4. RecordEnter the key identifier, owner, purpose, algorithm, length, creation date and expiry in the key register; the key value itself is never written into the register.
5. WitnessRoot and KEK creation is run as a ceremony with at least [two] custodians and a witness, using Annexure B.

5.3 Data encryption keys

Data encryption keys are created for each protected data store or application and wrapped by a key encryption key, so that the DEK is never kept in the clear outside memory in use.

5.3.1 Generation procedure

1. CreateThe application or storage service asks the key management service for a new DEK of the approved algorithm and length.
2. WrapThe service returns the DEK in plaintext only to the calling process and in encrypted form (wrapped by the KEK) for storage.
3. StoreThe wrapped DEK is saved with the data or in the key store, with its key identifier and version.
4. ClearThe plaintext DEK is held in memory only for the time needed and cleared after use.

5.3.2 Description procedure

Each DEK is described in the key register so that anyone with authority can find, rotate or retire it without guesswork.

5.4 Key distribution

• Keys are moved only through encrypted, authenticated channels or inside an HSM or key service; they are never sent by email, chat, removable media in the clear, or printed.
• Where a key must be transported physically, it is split into at least [two] components held by different custodians and sent by different routes, with receipt signed.
• Public keys and certificates are distributed with their fingerprints and verified by an out-of-band check before first trust.
• Applications fetch secrets at run time from the secrets vault with an identity of their own; keys are not embedded in code, images or configuration files.
• Receipt and installation are confirmed by the operations team and logged against the key identifier.

5.5 Key storage

• Root keys and KEKs live in an HSM or cloud key service with hardware protection; key material is not exported unless the key type is marked exportable and a recorded approval exists.
• DEKs, SSH keys and API secrets are held in the secrets vault with access controlled by role and logged; access by administrators requires multi-factor authentication.
• Keys are never stored in source code, ticketing tools, shared drives, email, plain configuration or workstation home folders.
• Key stores are separate from the data they protect: a database and its encryption keys must not be accessible with the same credentials.
• Administrators of a key store do not also administer the protected data, to keep separation of duties.

5.6 Key usage

• A key is used only for its recorded purpose, by the named system, and only inside its cryptoperiod.
• Use of root, KEK and signing keys is logged and reviewed by the key manager at least [monthly]; unusual use triggers an investigation under the Incident Management Procedure.
• Signing keys are used through a signing service that authenticates the pipeline and records each signature; developers do not hold signing keys.
• Test and development systems use test keys; production keys must never be loaded onto them.
• Where a key unwraps or decrypts data in bulk, rate limits and alerts are set so that large-scale decryption is noticed.

5.7 Key rotation

Keys are replaced on schedule and whenever risk changes. The system owner is told at least [10 working days] ahead of planned rotation, and systems must be built to rotate without data loss.

• Certificates are tracked with automatic expiry alerts at [60], [30] and [7] days.
• After rotation, the old key remains available for decryption only until all data is re-encrypted or the retention period ends, then it is destroyed.

5.8 Key revocation and destruction

A key is revoked when it is compromised, no longer needed or past its cryptoperiod. Revocation takes effect immediately; destruction follows once the key is no longer needed for recovery.

1. DetectA person who suspects a key is exposed, lost or misused reports it to the service desk as a security incident at once.
2. ContainThe key manager suspends the key, blocks use, and revokes dependent certificates within [1 hour] for Critical systems and [4 hours] otherwise.
3. AssessDetermine what the key protected, who could have used it and what data may be exposed; the Incident Management Procedure applies, including any notification duties assessed by legal and compliance.
4. ReplaceIssue a new key, re-encrypt data and reconfigure systems; record the old key as compromised.
5. DestroyWhen retention and recovery needs end, erase every copy of the key, including wrapped copies, backups and HSM slots, using vendor-supported zeroisation or cryptographic erase.
6. EvidenceTwo people sign the key destruction record (Annexure C); the register shows the key as destroyed with date and method.
7. LearnReview root cause within [10 working days] and close actions.

5.9 Key backup and recovery

• Keys needed to recover data are backed up in encrypted form, in a location separate from the primary key store, and protected by split knowledge or dual control.
• Backups of the root key are held in sealed storage at a second site, with access logged and requiring [two] custodians.
• Recovery of a key is tested by restoring in a non-production environment at least [annually] and after any change to the key hierarchy; the result is recorded.
• Keys used for signing and authentication are not backed up if they can be reissued; the register states which keys are recoverable and which are replaced instead.
• A recovery event needs a ticket, approval by the Head of Information Security and a witness, and the restored key is rotated afterwards if the cause was loss.

6. Key Flow Diagram

The numbered steps below describe the flow of a data encryption key from request to destruction. Each step names the party and the control.

1. System owner raises a key request in the ticketing tool.
2. Key manager validates the request against the key hierarchy and obtains approval.
3. The HSM or key service generates the root or key encryption key in a witnessed ceremony and returns only a key identifier.
4. The key service generates the data encryption key and returns it wrapped by the key encryption key.
5. The wrapped key is stored with the data store; the plaintext key exists only in memory of the calling process.
6. The application fetches and unwraps the key through an authenticated call; each use is logged.
7. On schedule or trigger, the key manager rotates the key; data is re-encrypted and the old version is set to decrypt-only.
8. An encrypted backup of the recoverable key is written to the second site under dual control.
9. On compromise or end of life, the key is revoked, all copies are destroyed and the register is updated with a signed record.

7. Measures

8. Records and Evidence

Annexure A: Key register

Annexure B: Key ceremony record

Annexure C: Key destruction record

9. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

10. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

11. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Cryptography Policy
• Cryptography Procedure
• Information Classification and Handling Policy
• Backup Management and Retention Procedure
• Incident Management Procedure
• Asset Disposal Process
• Access Control Policy
• System Development and Maintenance Procedure