Encryption is not a “nice to have”. Used properly, it is one of the single most effective controls for protecting your information. Used poorly, it creates technical fragility, operational risk, and false confidence. Over my 30 years in governance, risk, and compliance, I have seen far too many businesses flip a switch to encrypt a server, only to lose the decryption keys or use an outdated, broken algorithm that gives zero real protection. Lost keys can be just as damaging as stolen data.
ISO 27001:2022 consolidates former controls into Annex A 8.24 to make sure cryptography is treated as a governed capability. This control ensures your business uses encryption and key management in a controlled, consistent, and risk-appropriate way to protect data confidentiality, integrity, and availability.
Quick Summary: What ISO 27001 Annex A 8.24 Requires
At a practical level, Annex A 8.24 is about the governance of cryptography, not just turning encryption on. ISO 27001:2022 combines old requirements for encryption and key management into a single, cohesive control. Here is what you need to do in plain English:
- Establish a Cryptography Policy: Define clear rules on when, where, and how encryption must be applied across your business.
- Set Approved Cryptographic Standards: Mandate modern, secure algorithms, hash functions, and key lengths while banning deprecated tech.
- Manage the Full Key Lifecycle: Implement strict controls for generating, storing, distributing, rotating, revoking, and destroying keys.
- Protect Keys Better Than Data: Restrict key access using role-based permissions, hardware security, and separation of duties.
- Address Legal and Export Rules: Comply with cross-border regulations, national encryption laws, and contractual obligations.
- Review Cryptographic Strength Regularly: Audit algorithms and key lengths periodically to keep pace with modern computing power.
Why Ad-Hoc Cryptography Is a Major Risk
Applying encryption without governance creates a dangerous illusion of security. When individual teams pick their own tools, store keys in plain text, or use deprecated protocols, you introduce technical risks that can ruin your operations during an incident.
Uncontrolled cryptographic practices expose your business to severe hazards:
- Permanent Data Loss: Losing or corrupting encryption keys, making critical company databases or backups completely unrecoverable.
- Cracked Legacy Algorithms: Relying on obsolete algorithms (like MD5 or SHA-1) that attackers can break easily.
- Exposed Encryption Keys: Storing secret keys in public code repositories, local text files, or alongside the encrypted data itself.
- Compliance and Regulatory Fines: Violating regional export controls or data privacy mandates through unmanaged cross-border data transfers.
My 11 Step Plan to Implement Annex A 8.24 Fast
You do not need a PhD in mathematics to satisfy an ISO 27001 auditor. Here is my pragmatic, 11-step plan to establish an audit-ready cryptographic control framework.
1. Publish a Clear Cryptography Policy
Document an explicit cryptographic policy that aligns with your information classification scheme (Annex A 5.12) and risk appetite. Ensure your policy defines:
- Mandatory use cases for encryption across data at rest, data in transit, and data in use.
- Roles and responsibilities for managing keys and approving cryptographic standards.
- Approved algorithms, minimum key sizes, and prohibited legacy methods.
2. Map Out Where Cryptography Is Required
Identify every location across your business where sensitive data must be encrypted. Prioritise high-risk zones:
- Data in transit over public networks, web interfaces, and internal subnets (TLS/SSL).
- Data at rest on laptops, mobile devices, backup drives, and cloud storage buckets.
- Digital signatures and cryptographic hashing for authenticating software builds and transactions.
3. Select Cryptographic Methods Based on Risk
Apply encryption techniques that match the sensitivity of the underlying data asset:
- Use strong symmetric encryption (like AES-256) for bulk data storage and database fields.
- Use robust asymmetric encryption (like RSA or ECC) for secure key exchanges and digital signatures.
- Use secure salted hashing functions (like SHA-256 or Argon2) for storing user passwords safely.
4. Enforce Standardised Cryptographic Rules
Eliminate custom shortcuts and rogue configurations by locking down permitted technology stacks:
- Prohibit developers from writing custom, home-grown encryption code or algorithms.
- Mandate industry-standard, peer-reviewed cryptographic libraries and validated modules.
- Disable deprecated protocols (like SSLv3, TLS 1.0, and TLS 1.1) across all web servers and firewalls.
5. Implement Full End-to-End Key Lifecycle Controls
Key management is the heart of Annex A 8.24. Build formal processes for every stage of a key’s lifecycle:
- Generation: Use cryptographically secure pseudo-random number generators (CSPRNGs).
- Distribution: Send keys over secure, encrypted channels.
- Rotation: Automatically rotate data encryption keys on a defined schedule (e.g., annually).
- Revocation & Deletion: Instantly revoke compromised keys and securely destroy retired keys.
6. Secure Cryptographic Keys Against Disclosure
A key must always receive stronger protection than the data it protects. Lock down key storage points:
- Store master keys inside dedicated Hardware Security Modules (HSMs) or cloud key management services (KMS).
- Enforce strict least-privilege access and separation of duties so no single person holds total control.
- Never hardcode encryption keys or API tokens in application source code or config files (Annex A 8.28).
7. Assign Explicit Roles and Ownership
Encryption controls degrade quickly when no one takes direct ownership. Assign clear accountability across your team:
- Designate a primary owner responsible for approving cryptographic standards.
- Identify specific system administrators authorised to generate, rotate, or revoke operational keys.
- Audit key access logs regularly to verify that administrative actions are tracked (Annex A 8.16).
8. Balance Encryption with Other Security Tools
Encryption protects confidentiality, but it can blind other defensive monitoring tools if not engineered carefully:
- Ensure network threat detection and malware scanners can inspect encrypted traffic safely at boundaries.
- Confirm that Data Loss Prevention (DLP) agents maintain visibility over sensitive data workflows.
- Verify that backup systems can back up and restore encrypted data without corrupting files.
9. Comply with Legal, Export, and Regulatory Rules
Cryptography is tightly governed by international laws and sector-specific compliance rules:
- Check export and import restrictions if your software uses strong encryption cross-border.
- Verify compliance with regional data sovereignty laws when managing cloud encryption keys.
- Ensure cryptographic controls satisfy contractual commitments made to enterprise clients.
10. Govern External and Cloud Cryptographic Services
Using cloud key management or third-party encryption services does not outsource your ultimate compliance risk:
- Retain ownership and administrative control of your encryption keys when using cloud platforms.
- Verify that third-party cloud vendors support “Bring Your Own Key” (BYOK) or customer-managed keys.
- Ensure cloud key services maintain high availability and disaster recovery failover options.
11. Audit and Update Cryptographic Controls Regularly
What was considered unbreakable yesterday can become vulnerable tomorrow as computing power scales:
- Review approved algorithm lists annually against national security guidelines (e.g., NCSC, NIST).
- Phased out aging key lengths and algorithms before they become security liabilities.
- Conduct routine vulnerability scans to detect misconfigured TLS settings or weak certificates.
Common Implementation Pitfalls and How to Fix Them
When preparing clients for ISO 27001 audits, I frequently spot the same cryptographic mistakes. Here are the main traps and how to solve them:
- Problem: Data Encrypted But Keys Saved in the Same Folder
Ninja Solution: Separate keys from data completely using dedicated cloud KMS or HSM solutions. - Problem: Hardcoded Encryption Keys Inside Application Code
Ninja Solution: Use automated secret-scanning tools in git pipelines and inject keys at runtime via secure environment variables. - Problem: Unrecoverable Data Due to Lost Backup Decryption Keys
Ninja Solution: Store secure, offline, multi-person split backups of master recovery keys in tamper-evident physical safes. - Problem: Expired SSL/TLS Certificates Causing Sudden Uptime Outages
Ninja Solution: Implement automated certificate management tools (like ACME) to renew public certificates automatically.
The ISO 27001 Ninja Bottom Line
ISO 27001 Annex A 8.24 is about treating cryptography as a disciplined, governed capability rather than an ad-hoc technical fix. Encryption preserves data confidentiality, but governance is what protects your encryption.
You do not need to overcomplicate your technical stack to satisfy this control. By establishing clear policies, standardising modern algorithms, enforcing strict key lifecycle management, and keeping keys isolated, you ensure your business protects its sensitive assets safely, predictably, and with full audit confidence.