ISO 27001 Annex A 8.24: implement and audit cryptography

The due-diligence questionnaire asks how customer data is encrypted and who controls the keys. Your answer is a confident one-liner with no key management behind it, and the deal sits in security review.

This guide covers ISO 27001 Annex A 8.24 for CISOs, heads of security and cloud leads at 25 to 250-person firms. It shows what the control requires, how to write the policy, and how to automate the evidence an auditor will sample. Most of the work is closing key-handling gaps, not buying tooling. For a cloud-native firm, the policy, the sole-custody fixes and MDM enforcement come to around one to two weeks of effort.

What does ISO 27001:2022 Annex A 8.24 use of cryptography require?

ISO/IEC 27001:2022 Annex A control 8.24 use of cryptography requires written rules on two things. The first is where encryption is mandatory and to what standard. The second is how cryptographic keys are created, stored, rotated and destroyed. Auditors spend most of their time on the key lifecycle.

ISO/IEC 27001:2022 Annex A 8.24 use of cryptography does not tell you to encrypt everything. The trigger for "where" is your data classification under A.5.12 and your risk picture. Each decision follows what the data is worth and who could harm it, which is why classification has to exist before the cryptography policy can say anything useful.

The control is preventive, and it serves confidentiality first. It also covers integrity, through signatures, hashes and message authentication. Availability belongs here too. Lose the only copy of a key and the data behind it is gone, as surely as if the disk had died.

Two neighbouring controls shape the edges. Legal limits on encryption, such as export controls, cross-border rules and lawful-access requests, link this control to A.5.31 on legal and regulatory requirements. Reliance on outside certificate authorities brings in supplier oversight under A.5.22. Neither changes the core requirement: written rules, and keys under control.

Why does ISO 27001 A.8.24 pair algorithm rules with key lifecycle governance?

Encryption only protects data when the algorithm is vetted and the key is controlled. Weak or missing encryption exposes data to outsiders, while badly governed keys can lock the business out of its own data. Enterprise DDQs and insurer forms ask about both, so A.8.24 governs algorithms and the key lifecycle together.

ISO 27001:2022 control 8.24 use of cryptography formalises what good engineering already wants. Nobody wants a stolen laptop to be readable, and nobody wants a production database that only one person can open. The control asks you to write down how you prevent both.

"Everything is encrypted" is a claim. A key lifecycle is evidence.

The two failure modes run in opposite directions, which is why splitting the control into algorithm rules and key administration fails:

• Exposure: a stolen laptop without disk encryption can be a reportable personal data breach, and possibly an ICO conversation.
• Lockout: a departed engineer who was the only person able to unlock a production dataset creates a self-inflicted ransomware event, with no attacker required.

Auditors know both stories. They test the key lifecycle because a marketing claim costs nothing to make. A DDQ answer that names the algorithms, the KMS and the recovery arrangement tends to close the question. Most cloud-native firms already have the machinery to give it.

How do you write an approved-algorithm cryptography policy for A.8.24?

ISO 27001 Annex A.8.24 needs a short policy of two to three pages. It names approved algorithms and minimum strengths: AES-256 for symmetric encryption, TLS 1.2 or higher (preferring 1.3) in transit, and modern RSA or elliptic-curve key lengths. It also says where encryption is mandatory, and allows only standard, independently reviewed mechanisms.

A good cryptography policy, which auditors read first and then test reality against, covers six points:

• Approved algorithms and minimum strengths. Name them, so "which algorithms are approved here" has a written answer.
• Mandatory encryption scope. Laptops and mobile devices, removable media, data in transit, and classified data at rest as set by your classification scheme.
• Standard mechanisms only. The NCSC Device Security Principles for Manufacturers: Protect data at rest and in transit say implementations of cryptography should come from a standard, well-reviewed library. Custom implementations are less likely to have had a proper security review.
• A protocol floor. The Information Commissioner's Office (ICO) Guidance on Encryption and Data Transfer rules out every version of SSL. The NCSC Guidance on Using TLS to Protect Data points to TLS 1.2 and 1.3 with recommended cipher suites, and says to disable TLS 1.0 and 1.1. It also notes that TLS 1.3 removes some old encryption options. Configure servers so a client cannot negotiate down to a weaker version, and hold SSH and VPN settings to the same floor.
• Integrity mechanisms. Signed builds and verified artefacts in the release pipeline, plus checksums on critical transfers, where integrity is the point.
• Legal limits and monitoring. Record the outcome of your export-control and local-law check, and note how encrypted traffic affects any content-inspection tooling you rely on.

Two pitfalls turn a sound policy into shelfware. Deprecated algorithms survive in legacy corners: the policy says AES-256 while an old service still terminates TLS 1.0. And blanket "encrypt everything" mandates, ungrounded in classification, break content inspection, complicate debugging and get quietly ignored.

A cryptography policy nobody follows is worse than a narrower one people do.

Should you use cloud KMS instead of hand-rolled key handling or an HSM?

Yes. AWS KMS, Azure Key Vault and GCP KMS turn key generation, storage, rotation, access logging and destruction into configuration rather than manual procedures. At 25 to 250 staff, a dedicated hardware security module is rarely justified, and the policy still has to describe the lifecycle the KMS performs.

Write the lifecycle into the policy even though the platform does the work:

• Creation and use: who can create keys and who can use them.
• Rotation: the expectation for each class of key.
• Compromise: revoke, re-encrypt, investigate.
• Recovery: backup and recovery arrangements, so loss of a key is survivable.
• Destruction: including crypto-shredding, where destroying a key renders the remaining ciphertext permanently unreadable.

The KMS also produces your core exhibit. Key inventory, access policies, rotation settings and an audit log of creation, use, rotation and revocation all come out of the same service. For data in transit within a cloud service and through its external interfaces, the NCSC Cloud Security Principle 1: Data in Transit Protection says the provider should be responsible for the encryption and key management. That is another reason to lean on managed services.

The usual failure is keys in the wrong place. They sit hardcoded in repositories, in plaintext config or in a shared password-vault entry everyone can read. Meanwhile the policy describes a KMS nobody fully adopted. Scan repositories for secrets, move each one into the KMS, and the policy and the estate finally describe the same thing.

How do you eliminate sole custody of production cryptographic keys?

Give no individual exclusive access to a production key. Use least-privilege KMS roles, MFA on key administration and a break-glass path owned by more than one person. When someone leaves, revoke their access, assess and rotate the keys they could reach, and confirm recovery arrangements so the business is never locked out.

Sole custody is the most damaging failure at this scale because it stays invisible until it isn't. One engineer holds the only path to a production key, and offboarding turns into data loss. Close the gap in this order:

1. Map who can reach each production key. Read key policies, grants and any shared secrets, and list every identity with a path.
2. Apply least privilege. Separate administering a key from using it, so no role holds both without a reason.
3. Require MFA on key administration. Console and API access to key policies both count.
4. Create a multi-person break-glass path. At least two owners, sealed credentials, and an alert and review every time it is used.
5. Test recovery. Prove the business can regain access without the person who set it up.

Offboarding then becomes a short checklist. Rotation is a judgement. A leaver who only had role-based access through single sign-on needs revocation. One who ever handled exported key material or shared secrets needs the keys rotated. The leaver trigger can come straight from the HR system, as the automation section shows.

Rehearse it once before the audit. Pick the engineer with the widest key access and walk through the day they leave. Any step that sounds impossible in your setup is the finding you would rather discover first.

How do you prove endpoint devices are encrypted without a policy spreadsheet?

Turn on BitLocker and FileVault by policy through MDM and report compliance centrally. Each laptop's encryption status then comes from live data rather than a spreadsheet of promises. The central report also exposes the unenrolled stragglers that a hand-kept register never shows.

Configure BitLocker for Windows and FileVault for macOS in your MDM, so a laptop that isn't encrypted shows as non-compliant. Where your MDM supports it, that laptop also loses access to company resources until it is fixed. Scope matters as much as the setting. Phones, tablets and removable-media controls belong in the same report, because the policy names them as mandatory encryption territory.

The report should show three things:

• Encryption status per device, with the recovery key escrowed so a forgotten password does not become data loss.
• Enrolment coverage against the asset register, so a device missing from the MDM appears as a gap.
• Last check-in, so stale devices get chased rather than assumed.

A spreadsheet records what someone believed on the day they filled it in. MDM data records the state of each device now, including the contractor laptop enrolled late. At 50 staff, one export answers the DDQ line and leaves no stragglers hiding in the average.

What do auditors sample for ISO 27001 Annex A 8.24?

Auditors pull the KMS access list for one production key and check it against leavers. They pick a device from the asset register and ask for its MDM encryption status. They compare a live TLS endpoint with the policy's approved suites, and ask for the key-compromise playbook and a record of a real key event.

Expect questions as well as exports:

• "Which algorithms are approved here, and where is that written?"
• "How did you decide what data gets encrypted at rest?"
• "Walk me through the life of a production key: who created it, who can use it, when does it rotate, what happens if it leaks?"
• "Your lead engineer resigns tomorrow. What happens to the keys they could access?"
• "Show me that this laptop, pick one, is encrypted."

Each sample tests a different claim: offboarding discipline, fleet coverage, and whether the policy matches what is running. Build the evidence pack before the audit. It holds the policy with its algorithm list, the KMS configuration and audit log, MDM compliance reports and TLS scan results for external endpoints. Add one record of a real key event: a rotation after a departure, a certificate-expiry response or a compromise playbook entry all qualify.

In certification-body practice, findings grade by how far the control falls short:

• Major: no key-management arrangements at all, or unencrypted laptops holding client data.
• Minor: a policy that names no algorithms, a rotation setting that contradicts the policy, or one unenrolled device.
• Pattern: several minors in the same area aggregate into a major.

How can you automate key inventories, expiry monitoring and drift detection?

Cloud platforms emit the evidence natively. Scheduled KMS API exports become the key register. Expiry monitoring with lead-time alerts turns certificate lapses into routine tickets. Continuous MDM and cloud-config rules check encryption coverage and raise a ticket whenever configuration drifts from policy.

The key inventory is a live query. KMS APIs enumerate keys, owners, rotation state and access policies, so a scheduled export is the register. Drift such as rotation switched off or wildcard access raises a ticket instead of waiting for the next audit.

A certificate lapse is a process failure long before it is an outage.

Encryption posture runs as continuous checks. MDM and cloud-config rules flag an unencrypted volume, a public bucket without encryption or TLS below your floor. The DDQ answer "we monitor encryption coverage" becomes literally true.

Offboarding hooks into key access. A leaver event in the HR system triggers a KMS access review for that identity. That closes the sole-custody gap as a workflow rather than a memory test.

Set-and-forget rotation is the pitfall these checks exist to prevent. A rotation setting nobody reviews drifts, and the first sign is an outage. Alert on the setting as well as the date.

Frequently asked questions