ISO 27001 Cryptography: Control A.8.24 and Key-Lifecycle Evidence

Cryptography can protect confidentiality, integrity, authenticity and accountability, but only when the organisation governs where it is used and manages keys throughout their lifecycle. Encryption enabled in a product setting is not, by itself, evidence that ISO/IEC 27001 Annex A control 8.24 is working.

Control 8.24 concerns rules for effective cryptography and cryptographic key management. The organisation determines whether the control is necessary through risk treatment and other requirements, documents applicability in the Statement of Applicability and operates the chosen measures.

This guide focuses on the decisions and evidence an auditor can test without reproducing the standard’s text or prescribing one technology.

Start with risk and obligations

Identify where cryptography supports a defined need:

• sensitive information stored on devices, databases, backups or removable media;
• information moving across untrusted or shared networks;
• authentication and privileged access;
• software, message or record integrity;
• digital signatures and non-repudiation needs;
• secure exchange with customers and suppliers; and
• regulatory, contractual or jurisdictional requirements.

Do not begin with a universal command to encrypt everything. Cryptography creates dependencies involving key availability, recovery, performance, interoperability and lawful access. Select measures after considering information classification, threat scenarios, consequences, architecture and existing controls.

The risk score calculator can support consistent prioritisation, but technical decisions still need rationale and accountable approval.

Establish a cryptographic policy and technical standard

A concise policy should define purpose, authority, scope, principles, exceptions and review. A supporting technical standard can change more frequently and specify approved protocols, algorithms, key sizes, certificate rules, product configurations and migration dates.

Keeping policy and technical detail separate helps the organisation update deprecated technology without seeking executive approval for every engineering change.

Define:

• who approves cryptographic rules;
• which data classes and use cases require protection;
• approved and prohibited mechanisms;
• key and certificate ownership;
• lifecycle requirements;
• exception and risk-acceptance routes;
• supplier and cloud-service expectations;
• monitoring and inventory requirements; and
• review triggers such as new guidance, compromise or platform change.

The control should be proportionate. A low-impact public website and a service holding regulated customer records should not automatically receive identical design.

Build an inventory of cryptographic use

An organisation cannot govern what it cannot locate. Maintain a useful inventory of cryptographic dependencies, not merely a list of certificates.

Record items such as:

Field	Why it matters
Service and owner	Connects technology to accountability
Protected information or function	Shows the security objective
Location and environment	Supports scope and exposure analysis
Mechanism and version	Enables review against approved rules
Key or certificate owner	Identifies lifecycle responsibility
Provider or custody model	Clarifies shared responsibility
Expiry or rotation trigger	Prevents unmanaged ageing
Recovery dependency	Supports availability and resilience
Exception status	Exposes accepted deviation

Automated discovery from certificate managers, cloud platforms, code repositories or configuration tools can improve coverage. Reconcile the inventory with service ownership and architecture records so orphaned items become visible.

Govern the entire key lifecycle

Keys need controls from creation to destruction. Design requirements for:

1. Generation: use suitable random generation and authorised systems.
2. Registration and ownership: identify the key, purpose, custodian and affected service.
3. Distribution: prevent exposure while delivering keys or credentials to approved users and systems.
4. Storage: protect keys separately from the data they secure where appropriate and limit access.
5. Use: restrict purposes, services and operations according to approved rules.
6. Rotation and renewal: respond to time, usage, role change, technical guidance or risk.
7. Revocation: rapidly invalidate compromised, superseded or unauthorised keys and certificates.
8. Backup and recovery: preserve availability where recovery is required, with equivalent protection and tested procedures.
9. Archival: retain keys only when needed to access protected records or meet obligations.
10. Destruction: make retired material unusable and retain evidence of authorised disposal.

The official NIST key-management guidance provides detailed principles for managing cryptographic keying material. An organisation should select guidance appropriate to its legal, technical and sector context.

Clarify cloud and supplier responsibility

Cloud key-management services can improve control, but the provider does not remove customer responsibility. Document who configures keys, approves administrators, controls rotation, reviews logs, handles deletion and responds to compromise.

Distinguish provider-managed, customer-managed and externally held keys. Each model changes custody, operational burden, recovery options and evidence.

Review:

• tenant and administrative separation;
• identity and privileged-access controls;
• key export settings;
• logging and alert coverage;
• region and jurisdiction;
• backup and recovery behaviour;
• deletion semantics; and
• contract and exit arrangements.

The access-control governance guide helps connect key administration to identity, authorisation and periodic review.

Manage certificates as operational assets

Expired or misissued certificates can interrupt services or weaken trust. Assign owners, discover externally and internally exposed certificates, monitor expiry and define emergency replacement.

For high-impact services, test renewal before the deadline. Record issuance authority, subject, environment, renewal method and dependency. Alerts without an accountable response path are weak control evidence.

Control secrets in software delivery

Cryptographic keys, signing material and service secrets should not be embedded casually in source code, build logs, images or shared files. Use controlled secret stores and limited, workload-specific access where feasible.

Integrate scanning, code review and deployment controls. When a secret is exposed, removal from the latest code is insufficient; treat it as compromised, revoke or rotate it and investigate access.

Separate development and production material. Protect signing keys used to establish software or update integrity, and record who can invoke signing operations.

Plan for failure and change

Cryptography can fail through compromise, expiry, lost custody, provider outage, software defects or obsolete mechanisms. Define response actions before the event.

A cryptographic incident plan should address:

• identification of affected data and services;
• emergency revocation or rotation;
• deployment sequencing and rollback;
• stakeholder and regulatory decisions;
• preservation of evidence;
• recovery of legitimate access; and
• review of related keys or trust relationships.

Do not hard-code one algorithm or key size into long-lived policy. Maintain a review process informed by authoritative guidance and product support. This supports migration when technology or threat knowledge changes.

Distinguish design from operating evidence

Design evidence shows how the control is intended to work:

• policy and technical standard;
• risk and applicability decisions;
• key-management procedures;
• architecture and data-flow records;
• supplier responsibility model; and
• defined exceptions.

Operating evidence shows that it worked:

• generated inventories and reconciliation results;
• access approvals and reviews;
• key rotations and certificate renewals;
• configuration records;
• alerts and response actions;
• recovery tests;
• exception reviews; and
• revocation or destruction records.

A screenshot of an “encryption enabled” setting proves little about population, period, custody or lifecycle.

Audit with risk-based sampling

Use the Annex A control lookup to place control 8.24 alongside related identity, logging, configuration and supplier controls.

Select a sample across different use cases: a customer-facing connection, stored sensitive data, a backup, a privileged service, a signing process and a cloud-managed key. For each, trace the risk, approved rule, configuration, ownership and recent lifecycle event.

Ask:

• Is the use case covered by the inventory?
• Does the mechanism follow the current technical standard?
• Who can use or administer the key?
• Has rotation, expiry or revocation been tested?
• Are logs reviewed and exceptions current?
• Can the service recover without uncontrolled key exposure?

Pass: Risk-based rules are current, key responsibilities are explicit, sampled uses follow the standard and lifecycle events leave reliable evidence.

Partial: Strong encryption is widely enabled, but inventories are incomplete, certificate ownership is unclear or rotations depend on manual memory.

Fail: Keys are shared or embedded, obsolete mechanisms remain without accepted exception, or the organisation cannot recover access to critical encrypted data.

Treat cryptography as a managed system

Effective cryptography is not a one-time configuration. Connect risk, data, architecture, identity, lifecycle, monitoring and incident response. Keep technical rules current and test whether normal operation produces evidence.

The control context was cross-checked against the official ISO/IEC 27002 overview. Specific implementation choices must reflect the organisation’s risks, obligations and approved technical authorities.