How to Use Encryption Without Making Life Impossible
ISO 27001 Control 8.24 Use of cryptography is about making sure you use encryption and related techniques deliberately and safely – not just because “we should probably turn on SSL”.
Cryptography underpins so many things now: VPNs, disk encryption, TLS, digital signatures, API tokens, certificates, backups, and more. Done well, it protects confidentiality, integrity, authentication and non-repudiation. Done badly, it creates blind spots, outages, and a false sense of security.
This control expects you to decide where cryptography is needed, choose how you’ll use it, and manage keys properly, rather than leaving it to individual products and ad-hoc decisions.
This guide walks through what ISO 27001 Control 8.24 is really asking for, and how to build a practical, business-friendly approach to cryptography.
What ISO 27001 Control 8.24 Actually Requires
In plain English, ISO 27001 Control 8.24 – Use of cryptography expects you to:
- Decide when and why cryptography is needed (based on risk and legal requirements).
- Define policies and standards for algorithms, key sizes, protocols and usages.
- Put in place proper key management through the full key lifecycle.
- Make sure cryptographic controls are implemented consistently, not differently in every system.
- Consider how encryption interacts with monitoring, forensics and access control.
- Keep an eye on changes in cryptographic best practice and update your approach when needed.
The goal is not to “encrypt everything and hope for the best”, but to use cryptography in a controlled, auditable and future-proof way.
Step 1 – Decide Where You Actually Need Cryptography
Start with your information and risk picture, not with tools.
Common reasons to use cryptography:
- Confidentiality
– Protecting personal data, customer data, financial records, credentials, and trade secrets.
– Encrypting data at rest on laptops, servers, backups and removable media.
– Encrypting data in transit (web, APIs, VPNs, messaging). - Integrity
– Detecting unauthorised changes to files, messages or transactions (hashing, MACs, digital signatures). - Authentication
– Verifying users and systems (certificates, SSH keys, tokens, mutual TLS). - Non-repudiation
– Proving someone did (or signed) something, such as a transaction, contract, or approval.
For ISO 27001 Control 8.24, you should be able to show:
- Which types of data must be encrypted (by classification).
- Which scenarios require cryptographic protection (e.g. remote access, mobile devices, backups, key transactions).
- Where cryptography is optional, and where it is mandatory.
Step 2 – Create a Topic-Specific Cryptography Policy
Rather than scattering rules across documents, ISO 27001 Control 8.24 is easiest to evidence with a cryptography policy or standard that pulls it all together.
That policy should cover:
- Principles and objectives
– Why you use cryptography, and when it is required or recommended. - Scope
– Systems, applications, services, cloud platforms and devices that must follow the policy. - Data classification and usage rules
– Which classifications require encryption at rest and/or in transit.
– Any special rules for certain data types (e.g. payment data, health data). - Approved algorithms, key sizes and protocols
– A list of allowed ciphers, minimum key lengths and preferred protocols.
– Clear statement that non-approved or deprecated algorithms must not be used. - Implementation guidance
– Expectations for data at rest (e.g. full-disk encryption, database TDE, application-level encryption).
– Expectations for data in transit (e.g. TLS 1.2+/1.3, VPN standards).
– Rules for digital signatures, certificates and hardware security modules where applicable. - Legal and regulatory considerations
– Any relevant laws, sector rules, or export restrictions you need to comply with.
This becomes your reference point for all projects and technical teams using cryptography.
Step 3 – Establish Strong Key Management (The Bit Everyone Forgets)
Cryptography is only as strong as its key management. ISO 27001 Control 8.24 specifically wants you to think about the key lifecycle, not just the algorithm.
Your key management approach should cover:
- Key generation
– Keys generated using strong, approved random sources.
– No manual or predictable key creation. - Key storage
– Keys stored in secure locations: HSMs, cloud key management services, or secure vaults.
– Never hard-coded in source code, config files in plain text, or shared via email/chat. - Key distribution
– Keys and certificates distributed only to authorised systems and people, using secure channels.
– Clear process for provisioning and de-provisioning keys and certificates. - Key use and access control
– Least-privilege access to keys; admin and operational access separated where possible.
– Multi-factor authentication and strong controls for key custodians. - Key rotation and expiry
– Defined rotation periods for different key types (e.g. short-lived session keys, longer-lived root keys).
– Procedures for regular renewal of certificates and keys before expiry. - Key revocation and compromise handling
– A clear process for revoking keys and certificates quickly if compromised or mis-issued.
– Integration with incident response (e.g. replacing keys and re-issuing certificates after an incident). - Key backup, recovery and destruction
– Secure backup of critical keys (where loss would cause business continuity issues).
– Proper destruction of obsolete keys so they cannot be recovered.
– Documented, controlled key recovery procedures (with logging, approvals and dual control where appropriate). - Logging and auditing
– Logging important key operations (generation, rotation, use, deletion) where feasible.
– Periodic review of key inventories and access rights.
This is often where auditors dig in for ISO 27001 Control 8.24, because weak key management can quietly undermine otherwise “strong” cryptography.
Step 4 – Standardise Algorithms, Protocols and Configurations
To avoid every team choosing their own settings, define approved cryptographic standards and stick to them.
Typically this includes:
- Algorithms and key sizes
– Symmetric: e.g. AES with appropriate modes (GCM/CCM rather than outdated modes).
– Asymmetric: widely accepted public-key algorithms with appropriate key sizes.
– Hashing: modern secure hash functions; avoid deprecated ones. - Protocols
– Transport: modern versions of secure protocols (e.g. TLS 1.2+), with older versions disabled.
– Network: secure VPN standards (e.g. IPsec, modern SSL VPN equivalents).
– Email / file: approved mechanisms for secure email and file encryption where required. - Configuration hardening
– Disable weak ciphers, legacy protocols and insecure modes.
– Use strong certificate validation, including revocation checking where appropriate.
– Use secure defaults in development frameworks and cloud services. - Review and update
– Periodically check your standards against current best practice.
– Plan for replacing algorithms and key sizes when they become deprecated.
Documenting this in a cryptographic standard makes it straightforward to show how you meet ISO 27001 Control 8.24 in a consistent way.
Step 5 – Apply Cryptography Coherently to Data at Rest and in Transit
Now you have rules and standards, you can apply them consistently.
Data at rest
Think about:
- Full-disk encryption for laptops and mobile devices.
- Encryption for servers and VMs in higher-risk scenarios (e.g. untrusted hosting, co-location, cloud).
- Application or database-level encryption for particularly sensitive fields (e.g. credentials, payment information).
- Encryption of backups and archives, especially when stored off-site or in the cloud.
Data in transit
Consider:
- Encrypted communication channels for all external traffic (web, APIs, remote access).
- Internal TLS for traffic between services, especially in cloud and microservices environments.
- Encrypted remote access (VPN, ZTNA) for staff and administrators.
- Secure protocols for admin access (e.g. SSH instead of telnet).
The key from an ISO 27001 Control 8.24 perspective is that this is driven by classification and risk, not left to chance.
Step 6 – Think About Monitoring, Inspection and Operations
Encryption can sometimes hide threats and hinder investigations if you don’t plan for it.
When implementing cryptography:
- Content inspection
– Consider where you need to inspect encrypted traffic (e.g. HTTPS proxying for outbound web traffic).
– Make sure any decryption for inspection is done in a controlled way, with clear justifications and privacy considerations. - Access control for decryption
– Limit who can use decryption tools or access plaintext data.
– Log all use of key-escrow, decryption tools, and forensic access. - Forensics and incident response
– Ensure you can access necessary keys (under strict controls) to investigate serious incidents.
– Build cryptography considerations into your incident response playbooks. - Performance and availability
– Assess the performance impact of encryption, especially on high-volume services.
– Size infrastructure appropriately so cryptographic controls don’t cause outages.
ISO 27001 Control 8.24 doesn’t want encryption to break your ability to detect, investigate and respond – just for you to handle that trade-off thoughtfully.
Step 7 – Address Legal, Regulatory and Third-Party Aspects
Cryptography doesn’t live in a vacuum – you also need to think about law, regulation and suppliers.
Consider:
- Privacy and data protection
– Use cryptography to support compliance (e.g. protecting personal data under GDPR or other privacy laws).
– Be clear which data is encrypted, where, and how it’s protected. - Jurisdiction and export restrictions
– Some countries still have restrictions or special requirements around strong cryptography or key disclosure.
– Cross-border data transfer rules may expect a certain level of protection. - Government and law enforcement access
– Understand any applicable obligations for lawful access or disclosure.
– Balance these with your duty to protect confidentiality and your commitments to customers. - Third-party services
– Certificate authorities, managed encryption services, cloud KMS/HSM providers.
– Contracts should address: roles and responsibilities, SLAs, incident handling, and liability.
Documenting these considerations helps you show that ISO 27001 Control 8.24 is satisfied in your regulatory and business context, not just technically.
Step 8 – Plan for Change: Crypto Agility and Future Trends
Cryptography is one area where things will definitely change over time. ISO 27001 Control 8.24 expects you not to freeze everything in time.
You don’t need to adopt every new technology immediately, but you should:
- Build crypto agility
– Design systems so that algorithms, key sizes and protocols can be changed without a complete rebuild.
– Avoid hard-coding cryptographic choices deep into applications where possible. - Watch for deprecation and new risks
– Keep an eye on standards bodies and major vendors for changes in recommended algorithms.
– Plan for replacing older cryptographic methods before they become unsafe. - Track emerging areas (at a sensible level)
– Post-quantum cryptography: awareness and medium-term planning for future migration.
– More advanced approaches (e.g. homomorphic encryption, stronger use of digital signatures) where they make business sense.
– Integration of cryptography into zero-trust architectures (encrypt by default, authenticate everything).
You don’t have to be cutting-edge to satisfy ISO 27001 Control 8.24 – but you do need to show you’re not stuck on outdated methods.
Quick Implementation Checklist for ISO 27001 Control 8.24
Use this to gauge where you are with the use of cryptography:
- ISO 27001 Control 8.24 (Use of cryptography) is covered in a topic-specific cryptography policy/standard.
- You’ve defined where cryptography is required, based on data classification, risk and legal obligations.
- There is a list of approved algorithms, key sizes and protocols, and deprecated options are disallowed.
- A key management process covers generation, storage, distribution, use, rotation, revocation, recovery and destruction.
- Encryption is applied consistently to data at rest (devices, servers, backups) and data in transit (web, APIs, remote access) where needed.
- Cryptography is implemented in a way that still allows monitoring, inspection and forensics under controlled conditions.
- Legal, regulatory and contractual aspects of cryptography (privacy, cross-border data, third-party services) are identified and addressed.
- There is a process to review and update cryptographic standards as best practice evolves.
- Projects and changes are checked for compliance with your cryptography standard.
- Relevant staff (architects, developers, admins, security) receive guidance and training on your cryptography approach.
Bringing It All Together
ISO 27001 Control 8.24 – Use of cryptography – is about more than “we use TLS, so we’re fine”.
If you:
- Decide where cryptography is needed based on risk and regulation,
- Define clear, approved standards for algorithms, keys and protocols,
- Manage keys properly across their whole lifecycle, and
- Keep an eye on how cryptography affects monitoring, operations and future change,
you’ll turn encryption from a scattered collection of settings into a coherent, well-governed control – and you’ll be able to demonstrate to an auditor that cryptography is helping your ISMS, not quietly undermining it.
Explore the ISO 27001 Controls