ISO 27001 A.8.24 - Use of Cryptography

Requirement

“Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented.”

Plain-language meaning

The organization should define when cryptography is required, what approved cryptographic methods may be used, who manages keys, how keys are protected, and how cryptographic controls are operated throughout their lifecycle.

Cryptography is not just “turn on encryption”. Weak algorithms, poor key storage, unmanaged certificates, lost private keys, expired keys, missing revocation, or home-grown crypto can make an apparently secure system fail.

Why this matters

Cryptography can protect confidentiality, integrity, authenticity, and non-repudiation. It can also create serious operational risk if keys are lost, stolen, misused, expired, or generated without proper controls.

Strong cryptography depends on correct requirements, approved algorithms, appropriate key lengths and parameters, legal compatibility, secure key lifecycle management, and consistent implementation.

Implementation guidance

1. Define cryptographic policy

Define approved and prohibited cryptographic uses, algorithms, protocols, key lengths, certificate practices, key storage methods, and responsibilities.

2. Link cryptography to risk

Use Risk Assessment to determine where confidentiality, integrity, authenticity, or non-repudiation require cryptographic controls. The decision should reflect information classification, business process need, legal requirements, performance impact, and operational resilience.

3. Use approved algorithms and parameters

Use industry-standard algorithms and protocols that are not known to be broken. Avoid internally designed algorithms unless cryptographic design is the organization’s specialized business and the design is independently reviewed.

4. Manage keys before production use

Key management should be designed before production keys are generated. Define key generation, distribution, storage, access, backup, escrow, rotation, expiry, revocation, destruction, and compromise handling.

5. Protect different key types appropriately

Secret and private keys require strong protection against disclosure, replacement, modification, and destruction. Public keys and certificates require protection against unauthorized replacement, modification, and destruction.

6. Address legal and third-party dependencies

Some jurisdictions regulate cryptographic algorithms, key escrow, cross-border encryption, digital signatures, or certificate use. Where certification authorities, key services, directory services, timestamping, cloud KMS, or HSM providers are used, define responsibilities and agreements.

Audit guidance

Auditors should verify:

• cryptographic policy or standard is defined and communicated;
• cryptographic decisions trace to risk assessment and business need;
• algorithms, protocols, key lengths, and parameters are suitable;
• internally designed or weak algorithms are not used;
• legal and regulatory requirements are assessed;
• key-management lifecycle procedures exist before production use;
• secret/private keys are protected from disclosure, replacement, modification, and destruction;
• public keys and certificates are protected from unauthorized replacement, modification, and destruction;
• certification authorities or third-party key services are trusted and managed;
• key escrow or emergency recovery cannot be bypassed or abused;
• employees and administrators know the cryptographic procedures relevant to them.

Auditors may need specialist technical expertise. Cryptography details can be easy to misunderstand and difficult to assess from policy text alone.

Evidence examples

Strong evidence

• Cryptographic use cases trace to classification, risk, and legal requirements.
• Approved algorithms and key lengths are defined and current.
• Secret/private keys are stored in approved secure mechanisms.
• Key rotation, expiry, revocation, and destruction are recorded.
• Certificate authorities and third-party key services are reviewed.
• Key escrow or emergency recovery is authorized, tested, and monitored.
• Weak or deprecated algorithms are detected and remediated.

Weak evidence

• “We use encryption” with no standard or inventory.
• Developers choose algorithms independently.
• Keys are stored in source code, scripts, tickets, spreadsheets, or shared drives.
• Certificates expire unexpectedly.
• Private keys are copied without approval.
• No key rotation or revocation process exists.
• Legal restrictions on cryptography are not assessed.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.5.31 Legal, Statutory, Regulatory and Contractual Requirements
• A.5.32 Intellectual Property Rights
• A.5.34 Privacy and Protection of PII
• A.5.20 Addressing Information Security Within Supplier Agreements
• A.8.5 Secure Authentication
• A.8.10 Information Deletion
• A.8.12 Data Leakage Prevention
• A.8.20 Networks Security
• Risk Assessment
• Statement of Applicability
• Cryptographic Controls Policy
• Cryptographic Use Case and Algorithm Register
• Cryptographic Key Management Register
• Certificate Authority and Certificate Review
• Key Escrow and Emergency Recovery Checklist
• Cryptographic Legal Requirements Assessment
• A.8.24 Audit Evidence Pack
• A.8.24 Audit Checklist

KB-ready summary

• Define cryptographic policy and approved methods.
• Base cryptographic use on risk and legal requirements.
• Do not design custom algorithms.
• Manage keys across their full lifecycle.
• Protect private/secret keys and certificate integrity.
• Govern key escrow, recovery, third-party KMS, and CAs.

Templates and checklists

• Cryptographic Controls Policy
• Cryptographic Use Case and Algorithm Register
• Cryptographic Key Management Register
• Certificate Authority and Certificate Review
• Key Escrow and Emergency Recovery Checklist
• Cryptographic Legal Requirements Assessment
• A.8.24 Audit Checklist