# ISO 27001 A.8.24: Use of Cryptography

Source: https://truvocyber.com/blog/iso-27001-a-8-24-use-of-cryptography
Published: 2026-08-03
Topic cluster: ISO 27001

> ISO 27001 A.8.24 use of cryptography: how to write a crypto policy, run the key management lifecycle, encrypt by risk, and map it to SOC 2 CC6.1 and CC6.7.

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.

At a glance

- **Theme:** Technological (A.8)

- **Source:** ISO/IEC 27001:2022, Annex A

- **New in 2022:** No

- **SOC 2 mapping:** [CC6.1](/blog/soc-2-cc6-1-logical-access-security), [CC6.7](/blog/soc-2-cc6-7-data-transmission) (Full)

- **Part of:** the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies)

## 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](/blog/what-is-security-architecture) rather than settings toggled per service.

Outbound email is one place where the key lifecycle is easy to overlook, and the guide to [what DKIM is](https://truvocyber.com/blog/what-is-dkim) explains how a mail server signs each message with a private key, how receivers fetch the public key from a DNS TXT record under a selector, and why rotating that selector belongs in the same policy.

## 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](/blog/iso-27001-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.

Key insight

**A.8.24 is half encryption and half key management, and the key management half is where readiness fails**

Encryption is usually already on. The cryptography policy, the key lifecycle records, and the traceability from each encryption choice back to the risk assessment are what an ISO 27001 auditor probes and what many teams have not written down.

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](/blog/soc2-data-protection-on-prem) 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

Implementation theme
Cloud
On-prem / self-hosted

Key custody
Cloud KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS)
HSM or self-hosted key manager (Vault), local custody

Key protection model
Envelope encryption, KMS-held master keys
HSM-backed master key, vault-sealed data keys

Key rotation
Automated KMS rotation policy
Manual rotation on a documented schedule and runbook

Encryption at rest
Managed storage and database encryption by default
LUKS, BitLocker, database TDE with vault-released keys

Encryption in transit
Managed TLS, provider-issued certificates
TLS via internal CA, certificate inventory and rotation

Key access evidence
KMS access policy and audit log
Vault or HSM audit log, access-control records

## 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](/blog/grc-engineering) covers.

Artifact
What it demonstrates
Cadence

Cryptography and key management policy
Cryptographic decisions are defined and tied to risk
Reviewed at least annually

Encryption-at-rest configuration (disk, volume, database)
Sensitive data is encrypted where risk warrants
Point-in-time per audit period

Encryption-in-transit configuration (TLS, certificate inventory)
Data crossing boundaries is encrypted
Point-in-time per audit period

Key management and rotation records
Keys are generated, rotated, and destroyed on schedule
Per rotation, reviewed per cadence

KMS or HSM access controls and audit log
Key material is protected and access is attributable
Continuous, reviewed per cadence

Risk assessment linkage to encryption decisions
Each cryptographic choice traces to an assessed risk
Reviewed at least annually

Watch out

**Encryption switched on everywhere with no key management behind it**

A common readiness observation is a team that enables disk, database, and TLS encryption across the estate, so every store reports encrypted, yet has no cryptography policy, no record of how keys are generated or rotated, and nothing tying the encryption choices to the risk assessment. The controls are present; the management around them is the half of A.8.24 an auditor probes.

The fix is straightforward: write a one to two page cryptography policy naming approved algorithms and key lifecycle rules, point the policy at the KMS, HSM, or vault that already holds the keys, enable or document rotation on a schedule, and add a short section to the risk assessment justifying the encryption applied to each data class. The encryption was already done; the policy and the key lifecycle records are what convert it into evidence.

For the externally visible half of encryption in transit, Truvo's free [SSL checker](https://truvocyber.com/tools/ssl-checker) tests HTTPS reachability, the HTTP to HTTPS redirect and HSTS strength for any domain and maps the result to A.8.24.

Free download · Excel

ISO 27001 Evidence Checklist

The evidence list an internal auditor works from: 138 items across clauses 4 to 10 and all 93 Annex A controls, with owner, status and location columns ready for your team. Enter your email to download it.

(function initLmChecklist(){ if (window.hbspt && window.hbspt.forms) { window.hbspt.forms.create({ region: "na3", portalId: "341945322", formId: "e9f8aeed-ff99-4c1b-860f-5eafb34bc993", target: "#lm-iso-evidence-list-form", css: "" }); } else { setTimeout(initLmChecklist, 200); } })();

## How does A.8.24 map to SOC 2?

ISO 27001 A.8.24 is a Full overlap with SOC 2 [CC6.1](/blog/soc-2-cc6-1-logical-access-security) and [CC6.7](/blog/soc-2-cc6-7-data-transmission). 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.

SOC 2 criteria
Overlap type
Evidence reusable in both directions

CC6.1, CC6.7
Full
Cryptography and key management policy, encryption-at-rest and in-transit configuration, key management and rotation records, KMS or HSM access controls and audit log

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](/blog/iso-27001-soc-2-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](/blog/iso-27001-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](/blog/iso-27001-a-5-15-access-control) sets the access rules that also govern who can reach key material, and [A.8.5 secure authentication](/blog/iso-27001-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](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies).

Certificate issuance has a DNS-side control as well: the guide to DNSSEC covers [CAA records](https://truvocyber.com/blog/what-is-dnssec), which name the certificate authorities allowed to issue for a domain so a mis-issued TLS certificate is refused at the CA rather than discovered afterwards.

### Cryptography that survives the audit

Truvo designs encryption and key management as part of an effective security program that evidences itself continuously.

[Book Your Strategy Call](/contact-us)

*Part of Truvo's control-by-control ISO 27001:2022 Annex A reference series. Start from the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies) 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](/contact-us).*
 

## 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.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is ISO 27001 A.8.24?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What evidence satisfies A.8.24?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Is A.8.24 a new control in ISO 27001:2022?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How do you implement A.8.24 key management in the cloud versus on-prem?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Does A.8.24 require encrypting everything?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How does A.8.24 map to SOC 2 CC6.1 and CC6.7?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    }
  ]
}