ISO 27001 A.8.24: Use of Cryptography

ISO 27001 A.8.24 requires a policy on the use of cryptography, including key management, applied according to risk rather than encrypting everything by reflex. It is a Technological control (A.8), and the thing teams often get flagged on is the key management around the encryption rather than the encryption itself: encryption is enabled almost everywhere, and no document says how keys are generated, stored, rotated, or destroyed, or why each choice was made.

What is ISO 27001 A.8.24?

ISO 27001 A.8.24 Use of cryptography governs how an organization uses cryptographic controls to protect its information, and how it manages the keys those controls depend on. ISO/IEC 27001:2022, Annex A frames the control around a policy on the use of cryptography, including cryptographic key management, defined and applied so that cryptography is used effectively and consistently to meet the organization's security objectives.

In practice, A.8.24 covers two things that stand or fall together: the cryptographic controls themselves (encryption at rest, encryption in transit, algorithms, and protocols) and the key management that makes those controls trustworthy over time. The control is deliberately risk-driven. It does not require that every byte be encrypted with the strongest available cipher. It asks that cryptographic decisions are deliberate, documented in a policy, traced to the organization's risk assessment, and maintained across the full lifecycle of the keys. Choices like the key protection model and where keys live relative to the data they protect are structural decisions, part of the system's security architecture rather than settings toggled per service.

How do you implement A.8.24?

Implementing ISO 27001 A.8.24 comes down to writing a cryptography policy, applying encryption where risk warrants it, and running the key lifecycle as an operating process rather than a one-time setup:

1. Write a cryptography and key management policy. Document which data classes require encryption at rest and in transit, the approved algorithms and minimum key lengths, the protocols permitted (for example TLS 1.2 as a floor, TLS 1.3 preferred), and the rules for key management. The policy is the artifact A.8.24 turns on, and it is the first thing an auditor asks for.
2. Encrypt data at rest where risk warrants it. Apply disk, volume, and database encryption to the data classes the risk assessment identifies as sensitive. Encrypting production customer data is expected; encrypting a public marketing asset is not, and the policy should say so.
3. Encrypt data in transit. Enforce TLS on every channel carrying sensitive data across a boundary, internal service-to-service links included. This is the same territory as A.8.20 network security; A.8.24 governs the cryptographic choices, A.8.20 governs the network path.
4. Choose current algorithms and retire weak ones. Standardize on modern, widely reviewed algorithms (AES-256 for symmetric encryption, RSA-2048 or higher and elliptic-curve equivalents for asymmetric, SHA-256 or higher for hashing). Name the deprecated ones the policy forbids (MD5, SHA-1, DES, RC4, TLS 1.0 and 1.1) so the standard is enforceable.
5. Manage keys across the full lifecycle. Define generation, storage, distribution, rotation, revocation, and destruction for every key type. Keys are generated with sufficient entropy, stored separately from the data they protect, rotated on a defined schedule, revoked when compromised or when staff with access leave, and destroyed so they cannot be recovered.
6. Protect the keys themselves. Keys belong in a key management service or hardware security module rather than in application config files, source code, or a shared drive. Access to key material is restricted, logged, and reviewed, so a key is only reachable by the identities that need it.
7. Trace every cryptographic decision to the risk assessment. For each data class, the risk assessment justifies the encryption applied (or not applied). This traceability is what turns a pile of encryption settings into a defensible program, and it is the link many teams are missing.

Steps 2, 5, and 6 implement meaningfully differently in cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.24 through the provider's managed key and encryption primitives, configured deliberately and evidenced through configuration exports:

• A cloud KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) generates, stores, and controls access to keys, and its access policy and audit log become the key management evidence for the program.
• Envelope encryption protects data keys with a KMS-held master key, so the data key is never stored in plaintext and rotation of the master key does not require re-encrypting all data.
• Key rotation policies in the KMS automate rotation on a defined schedule, replacing the manual rotation that on-prem teams have to schedule themselves.
• Managed TLS through load balancers and provider-issued certificates handles encryption in transit, with certificate issuance and renewal managed by the provider.
• Encryption at rest by default on managed storage, databases, and object stores, with the KMS key reference recorded so each store's key ownership is auditable.
• IAM-scoped key access restricts which roles can use or manage each key, and the KMS audit log records every key use against a named identity.

On-prem / self-hosted

On-prem environments implement A.8.24 with the same outcomes through key custody and encryption tooling the team runs itself. The SOC 2 data protection on-prem guide covers the full implementation; the shape is:

• A hardware security module or a self-hosted key manager (HSM, or HashiCorp Vault) holds and controls key material, with the vault audit log serving as the key access evidence a KMS log would provide in the cloud.
• Disk and database encryption through LUKS, BitLocker, and database transparent data encryption cover data at rest, with keys released from the vault or an HSM rather than stored alongside the data.
• Certificate management through an internal certificate authority issues and rotates the TLS certificates for internal endpoints that a public CA will not cover, with a single certificate inventory tracking expiry.
• Manual rotation on a documented schedule, since there is no managed rotation button, with a runbook defining who rotates each key type and when, and a log proving it happened.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.24?

Evidence for ISO 27001 A.8.24 is paired: the cryptography policy that states the decisions, plus configuration and key management records showing the decisions are implemented and maintained. Teams that export encryption configuration and KMS audit logs automatically, rather than assembling screenshots each audit, spend far less time here; that evidence-automation approach is what GRC engineering covers.

How does A.8.24 map to SOC 2?

ISO 27001 A.8.24 is a Full overlap with SOC 2 CC6.1 and CC6.7. Organizations with an existing SOC 2 program can reuse the same cryptography and key management evidence for the ISO 27001 certification audit with no adaptation.

CC6.1 carries the Uses Encryption to Protect Data and Protects Cryptographic Keys Points of Focus, which map directly onto A.8.24's encryption-at-rest and key-lifecycle requirements, and CC6.7 covers encryption of data as it is stored and transmitted. The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how much of an existing SOC 2 program transfers.

Related controls

ISO 27001 A.8.24 supplies the cryptographic controls that several other Annex A controls rely on. A.8.20 network security governs the network path that A.8.24's encryption in transit protects, so the two are usually evidenced together. A.5.15 access control sets the access rules that also govern who can reach key material, and A.8.5 secure authentication covers the authentication mechanisms cryptography underpins. A.5.34 privacy and protection of PII is a frequent driver of the risk decisions A.8.24 encryption implements. All fall within the framework covered by the ISO 27001 certification guide.

Part of Truvo's control-by-control ISO 27001:2022 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you want a second set of eyes on how cryptography and key management are designed and evidenced as part of an effective security program, Truvo offers scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.24?

ISO 27001 A.8.24 is the Annex A control titled Use of cryptography, in the Technological theme. It requires a policy on the use of cryptography, including key management, defined and applied according to risk. It covers the cryptographic controls themselves, encryption at rest and in transit, approved algorithms and protocols, and the full key lifecycle from generation through destruction, so that cryptography is used effectively and consistently.

What evidence satisfies A.8.24?

A.8.24 evidence is paired: the cryptography and key management policy plus records showing it is implemented. Auditors expect the policy, encryption-at-rest configuration for disks and databases, encryption-in-transit configuration and a certificate inventory, key management and rotation records, and the KMS or HSM access controls and audit log. Linkage from the risk assessment to each encryption decision demonstrates the cryptography is applied by risk rather than by reflex.

Is A.8.24 a new control in ISO 27001:2022?

No. Use of cryptography carried over from the 2013 version of the standard and was not introduced in the 2022 revision. The 2022 revision reorganized Annex A into four themes and placed use of cryptography under the Technological controls as A.8.24, but the control itself, including its key management expectation, is not new.

How do you implement A.8.24 key management in the cloud versus on-prem?

Cloud implementations use a managed KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) for key generation, storage, and access control, with envelope encryption protecting data keys and automated rotation policies handling the lifecycle. On-prem implementations reach the same outcomes with an HSM or a self-hosted key manager such as HashiCorp Vault, disk and database encryption with vault-released keys, an internal certificate authority for TLS, and manual rotation on a documented schedule. The KMS or vault audit log is the key access evidence in both models.

Does A.8.24 require encrypting everything?

No. A.8.24 is risk-driven rather than blanket. It requires a cryptography policy that decides, per data class, where encryption at rest and in transit is warranted based on the risk assessment. Encrypting production customer data and credentials is expected; encrypting public, non-sensitive content is not. The control asks that each cryptographic decision is deliberate, documented, and traceable to an assessed risk.

How does A.8.24 map to SOC 2 CC6.1 and CC6.7?

A.8.24 maps to SOC 2 CC6.1 and CC6.7 as a Full overlap. CC6.1 carries the Uses Encryption to Protect Data and Protects Cryptographic Keys Points of Focus, and CC6.7 covers encryption of stored and transmitted data. Evidence produced for these criteria, the cryptography policy, encryption configuration, key management records, and KMS or HSM access logs, is reusable for A.8.24 without adaptation.