A.8.24ISO 27001Last reviewed 19 February 2026

ISO 27001 A.8.24: Use of cryptography

Encryption is only as strong as how you manage it. You can use AES-256 everywhere, but if your keys are sitting in a config file on GitHub, you have achieved nothing. This control covers both the cryptographic standards you adopt and - critically - how you handle the keys.

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start my free ISO 27001 assessmentNo account · No credit card · Save when useful

Requirement summary

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

Check the source wording and scope in ISO/IEC 27001:2022. The guidance below explains how to approach a review.

In Plain Language

You need defined rules for which algorithms, key lengths, and protocols are approved for different use cases. Data at rest, data in transit, authentication, digital signatures - each has specific requirements. And you need to explicitly ban deprecated algorithms that are still lurking in many environments.

Key management is where most organisations stumble. Generation, distribution, storage, rotation, backup, revocation, destruction - every stage of the key lifecycle needs a documented process. Auditors will dig into this because it is one of the most common areas where the implementation does not match the policy.

How to Implement

Write a cryptographic policy that defines approved algorithms, key lengths, and protocols for each use case. Base it on NIST SP 800-175B or equivalent guidance. At minimum: AES-256 for symmetric encryption, RSA-2048 or ECDSA P-256 (or stronger) for asymmetric, SHA-256 (or stronger) for hashing, TLS 1.2+ for transport. Explicitly ban DES, 3DES, MD5, SHA-1, TLS 1.0/1.1.

Encrypt data at rest. Use transparent data encryption or column-level encryption for sensitive database content. Enable full-disk encryption on every endpoint and portable device. Encrypt backup media. Use encrypted storage services in cloud environments. Document what is encrypted and how.

Encrypt data in transit. Enforce TLS 1.2 or later for all web traffic. Use SFTP or FTPS for file transfers, TLS for SMTP and S/MIME for end-to-end email encryption, and VPNs with strong ciphers for remote access. Disable fallback to unencrypted protocols. Consider certificate pinning for critical connections.

Build a proper key management programme. Use an HSM or dedicated KMS for storing and managing keys for critical applications. Define lifecycle procedures: generate keys with cryptographically secure random number generators, distribute over secure channels (never in plain text), store in HSMs or KMS (never in source code or config files), rotate on a defined schedule based on key type and usage, maintain secure backups with key escrow, revoke compromised keys immediately, and destroy keys securely when retired.

Get certificate management under control. Maintain a full inventory of digital certificates. Monitor expiration dates and automate renewal wherever possible. Use certificate authorities that follow industry standards. Implement certificate transparency monitoring and revoke compromised certificates promptly.

Be aware of import and export regulations. Some countries restrict the use, import, or export of strong cryptography. Make sure you are compliant in every jurisdiction where you operate or transmit encrypted data.

Evidence to review

Cryptographic policy defining approved algorithms, key lengths, and protocols
Encryption configuration records for data at rest and data in transit
Key management procedures and key lifecycle documentation
Certificate inventory and management records
HSM or KMS deployment and configuration records

Common Mistakes

No cryptographic policy defining standards for the organization
Deprecated algorithms or protocols are still in use (TLS 1.0, SHA-1, 3DES)
Cryptographic keys are stored in source code, configuration files, or spreadsheets
Certificate management is ad hoc leading to unexpected expirations
Key rotation is not performed or is not tracked

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	SOC 2 CC6.1: Logical and Physical Access - Security Software, Infrastructure, and Architectures	Partial overlap
SOC 2	SOC 2 CC6.7: Logical and Physical Access - Transmission of Data	Related
GDPR	GDPR Art.32(1)(a)	Equivalent
NIS2	NIS2 Art.21(2)(h): Cryptography and Encryption Policies	Equivalent

Frequently Asked Questions

What encryption algorithms should we use?

Stick with AES-256 for symmetric encryption, RSA-2048 or ECDSA P-256 (or stronger) for asymmetric, SHA-256 or SHA-3 for hashing, and TLS 1.2+ for transport security. Avoid DES, 3DES, RC4, MD5, SHA-1, TLS 1.0, and TLS 1.1 - these are all considered broken or deprecated. Follow NIST or equivalent national guidance. And start thinking about post-quantum cryptography - it is not urgent yet, but it should be on your roadmap.

How should we manage cryptographic keys?

Use HSMs or cloud KMS services for anything critical. The golden rule: never store keys in source code, config files, or next to the encrypted data. Generate them with cryptographically secure random number generators. Set and enforce rotation schedules. Keep secure backups with proper escrow procedures. Maintain a key inventory so you always know what keys exist, who owns them, and where they are in their lifecycle.

Track ISO 27001 compliance in one place

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start Free Assessment

Start without an account · Sign up only to save

Start my free ISO 27001 assessment