How to Implement ISO 27001 Annex A 8.24 Use of Cryptography

Implementing ISO 27001 Annex A 8.24 requires the establishment of rigorous rules for the use of cryptography to ensure the confidentiality, integrity, and authenticity of information. This control mandates the deployment of centralised key management, secure algorithms, and automated encryption for data at rest and in transit. The primary business benefit is protecting sensitive assets from unauthorised access and interception.

ISO 27001 Use of Cryptography Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.24. This control mandates the formulation and enforcement of rules for the effective use of cryptography to protect the confidentiality, integrity, and authenticity of information.

1. Define Approved Cryptographic Algorithms

Control Requirement: Organisation-wide rules must define which cryptographic algorithms are permissible and which are banned.

Required Implementation Step: Create a technical standard document explicitly listing allowed cipher suites (e.g., AES-256, RSA-2048+, Ed25519) and explicitly banning deprecated ones (e.g., DES, MD5, SHA-1). Update your web server (Nginx/Apache) and load balancer configurations to technically reject connections using banned ciphers.

Minimum Requirement: A configuration file exists that blocks TLS 1.0 and 1.1 connections.

2. Implement Centralised Key Management

Control Requirement: Cryptographic keys must be managed securely throughout their lifecycle, from generation to destruction.

Required Implementation Step: Deploy a dedicated Key Management Service (KMS) or Secrets Manager (e.g., HashiCorp Vault, AWS KMS, Azure Key Vault). Move all hardcoded encryption keys out of source code and configuration files and into this secure vault, injecting them only at runtime.

Minimum Requirement: No encryption keys are stored in the application source code repository.

3. Enforce Data at Rest Encryption

Control Requirement: Sensitive data stored on physical media or databases must be encrypted to prevent unauthorised physical access.

Required Implementation Step: Enable Full Disk Encryption (FDE) (e.g., BitLocker, FileVault, dm-crypt) on all company laptops and servers. Configure database engines (SQL/NoSQL) to use Transparent Data Encryption (TDE) for all tables containing PII or financial data.

Minimum Requirement: Stolen laptops or hard drives are unreadable without the decryption key.

4. Secure Data in Transit

Control Requirement: Information transmitted over networks must be protected against interception.

Required Implementation Step: Configure all internal and external endpoints to require HTTPS using TLS 1.2 or 1.3. Implement HSTS (HTTP Strict Transport Security) headers to force browsers to refuse unencrypted HTTP connections.

Minimum Requirement: All web traffic scores an ‘A’ on the Qualys SSL Labs test.

5. Establish Key Rotation Procedures

Control Requirement: Cryptographic keys must be changed regularly to limit the impact of a potential compromise.

Required Implementation Step: Configure automated key rotation schedules within your cloud provider or KMS (e.g., rotate Customer Master Keys every 90 or 365 days). For manual keys (like SSH or GPG), set calendar reminders to regenerate and redistribute keys annually.

Minimum Requirement: Evidence of at least one key rotation event in the last 12 months.

6. Secure Key Generation

Control Requirement: Keys must be generated using strong random number generators to ensure unpredictability.

Required Implementation Step: Ensure that key generation processes use a cryptographically secure pseudo-random number generator (CSPRNG). On Linux servers, ensure applications read from `/dev/urandom` or use a hardware entropy source (HSM/TPM) rather than weak software libraries.

Minimum Requirement: Keys are not generated using predictable seeds like timestamps.

7. Implement Digital Signatures for Integrity

Control Requirement: Cryptography should be used to verify that data has not been tampered with.

Required Implementation Step: Sign all internal software release artifacts and binaries using a private signing key. Configure your deployment servers to verify this signature before executing any update to ensure the code hasn’t been altered in transit.

Minimum Requirement: Software updates fail to install if the digital signature is missing or invalid.

8. Manage Encryption Regulations

Control Requirement: The use of cryptography must comply with relevant country-specific laws and export controls.

Required Implementation Step: Audit your cryptographic usage against the export control laws of your jurisdiction (e.g., Wassenaar Arrangement). If you distribute software globally, ensure you have the necessary classification numbers (ECCN) documented for your encryption modules.

Minimum Requirement: Legal counsel has reviewed the export status of your cryptographic software.

9. Segregate Keys from Data

Control Requirement: Keys used to encrypt data should not be stored alongside the data itself.

Required Implementation Step: Architect your storage solution so that encrypted database backups are stored in a different location (e.g., a separate S3 bucket or physical site) than the keys required to decrypt them. Ensure different Identity and Access Management (IAM) roles control access to the data vs. the keys.

Minimum Requirement: An admin with access to the database backups does not automatically have access to the decryption keys.

10. Plan for Key Compromise

Control Requirement: A process must exist to handle the situation where keys are lost or stolen.

Required Implementation Step: Create a “Key Compromise Protocol” or “Revocation Plan.” This must list the exact CLI commands required to revoke a compromised certificate (CRL/OCSP) or rotate a master key immediately. Test this process in a non-production environment.

Minimum Requirement: A documented “Runbook” exists for immediate key revocation.

ISO 27001 Annex A 8.24 SaaS / GRC Platform Implementation Failure Checklist

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Approved Algorithms	SaaS tool asks “Do you use encryption?” (Yes/No).	You click “Yes,” but your legacy payment server is still using Triple DES and TLS 1.0, which are easily broken.
Key Management	SaaS tool verifies a “Key Management Policy” document exists.	The policy is signed, but the root database password is stored in plain text in a `config.php` file on the web server.
Data in Transit	SaaS tool checks for an SSL certificate.	The certificate is valid, but it is self-signed or using a weak 1024-bit RSA key that triggers browser warnings.
Key Rotation	SaaS tool sends a reminder email once a year.	The SSH keys used by developers to access production have not been rotated in 5 years, even after staff left the company.
Disk Encryption	SaaS tool asks for a screenshot of BitLocker.	BitLocker is enabled, but the recovery keys are saved in a shared Google Drive folder accessible to the whole company.
Compromise Plan	SaaS tool asks “Do you have an incident plan?”.	When a developer accidentally commits an AWS Secret Key to GitHub, nobody knows how to revoke it, leading to a $50k mining bill.
Regulatory Compliance	SaaS tool ignores export laws.	You unknowingly violate US or UK export controls by providing high-grade encryption software to a sanctioned entity.

About the author