Annex A.8.24 requires organisations to define and implement rules for the effective use of cryptography. Most organisations implement encryption correctly in practice — data is encrypted at rest and in transit, TLS is configured, databases are encrypted. The problem is documentation: a cryptography policy that explains what is encrypted, how, with what standards, and how keys are managed is missing in the majority of first-time certification attempts.
The other common failure is key management. You can have excellent encryption but no documented process for how keys are generated, who has access to them, how they are rotated, and what happens when they need to be revoked. Auditors will ask for both the policy and the key management evidence.
What Your Cryptography Policy Must Cover
The policy does not need to be long — two to three pages is typical. It must cover:
- Approved cryptographic algorithms and minimum key lengths (e.g., AES-256 for symmetric, RSA-2048 or ECC-256 for asymmetric)
- Where encryption is required — data at rest and data in transit
- Approved TLS versions for data in transit (TLS 1.2 minimum; TLS 1.3 preferred)
- Prohibited algorithms (MD5, SHA-1, DES, RC4 — these are weak and must be explicitly prohibited)
- How cryptographic keys are managed (covered in detail below)
- Responsibilities — who is responsible for implementing and maintaining cryptographic controls
Data at Rest vs Data in Transit: Encryption Requirements
| Context | Minimum standard | Evidence auditors check |
|---|---|---|
| Database encryption | AES-256 at rest | Cloud console screenshots, DB config, storage encryption enabled |
| Storage (files, backups) | AES-256 at rest | S3/blob storage encryption config, backup encryption settings |
| Endpoint devices | Full-disk encryption (BitLocker, FileVault) | MDM/device management reports showing encryption status |
| APIs and web applications | TLS 1.2+ in transit | SSL Labs report or equivalent TLS configuration scan |
| Email (sensitive content) | TLS in transit; consider S/MIME for highly sensitive content | Email server TLS configuration, encryption policy |
| VPN / remote access | TLS 1.2+ or IPsec | VPN configuration documentation |
Key Management: The Most Common Gap
A.8.24 requires a policy for the management of cryptographic keys throughout their lifecycle. Many organisations have encryption but no documented key management process. The key lifecycle has five stages, and your policy must address each:
For most cloud-native organisations, the key management evidence consists of demonstrating that your cloud provider's key management service (AWS KMS, Azure Key Vault, GCP Cloud KMS) is in use, configured correctly, and that key rotation is enabled or performed on a defined schedule. You do not need to manage your own key infrastructure — but you do need to document how key management is handled.
What Auditors Specifically Sample
They will ask to see your cryptography policy document — that it exists, is version-controlled, and has been approved.
They will ask you to show encryption is enabled for your databases and storage — typically via cloud console screenshots or config exports.
They will check your TLS configuration for public-facing services — an SSL Labs A-grade or equivalent is a strong indicator.
They will ask about key rotation — how often are keys rotated, is rotation automated, and is there a record of the last rotation?
They may ask about endpoint encryption — can you show that all laptops are using full-disk encryption?
Secrets management
If your organisation stores API keys, database passwords, or other secrets in code repositories or environment files, this is a significant finding under both A.8.24 and A.8.9. A secrets management tool (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) or at minimum a documented secrets rotation process should be referenced in your cryptography policy.
If you want help drafting or reviewing your cryptography policy, our ISO 27001 consulting service covers policy development across all applicable Annex A controls.