How to Implement ISO 27001:2022 Annex A 8.24: The Use of Cryptography

How to Implement ISO 27001 Annex A 8.24

In the world of information security, cryptography is your final line of defence. If the firewalls fail, the passwords are guessed, and the physical doors are breached, encryption is the only thing standing between a hacker and your sensitive data. It turns readable assets into useless gibberish for anyone without the key.

ISO 27001:2022 Annex A 8.24, “Use of cryptography,” is the control that governs this crucial area. It isn’t just about switching on BitLocker and hoping for the best; it’s about having a structured, managed approach to how you use encryption across your entire organisation.

What is the Objective of Annex A 8.24?

The core objective of this control is ensuring the proper and effective use of cryptography to protect the confidentiality, authenticity, integrity, and non-repudiation of information. In simpler terms, it forces you to define what you encrypt, how you encrypt it, and most importantly, how you look after the keys.

Many organisations make the mistake of thinking encryption is a “set and forget” technology. However, if you lose the decryption key, that secure data is as good as gone. If you manage the keys poorly, the encryption offers no protection at all.

Step-by-Step Implementation Guide

Implementing Annex A 8.24 requires a mix of policy, technology, and strict process management. Here is a practical roadmap to getting it right.

1. Assess Your Risks and Requirements

Before you encrypt everything in sight, you need to understand what actually needs protection. Encryption consumes resources and adds complexity, so it should be applied based on risk. Ask yourself:

  • What legal or regulatory requirements do we have? (e.g., GDPR, HIPAA, PCI-DSS).
  • What data, if lost or stolen, would cause significant harm to the business?
  • Do we need to protect data at rest (on hard drives), in transit (over the internet), or both?

2. Create a Cryptography Policy

You cannot rely on ad-hoc decisions by your IT team. You need a formal policy. This document should outline the general principles your organisation follows regarding encryption.

According to the experts at Hightable.io, a good cryptography policy should clearly define the type of encryption used and the strength of the algorithms. You don’t need to list every single mathematical formula, but you must establish a standard (e.g., “We use AES-256 for data at rest”). This policy acts as the rulebook that auditors will check your systems against.

3. Master Key Management

This is the most critical part of Annex A 8.24. You can have the strongest lock in the world, but it is useless if you leave the key under the doormat. You must establish a “Key Management Lifecycle” that covers:

  • Generation: Keys should be generated using secure random number generators.
  • Distribution: How are keys securely handed to the people or systems that need them?
  • Storage: Keys should never be stored alongside the encrypted data. Use Hardware Security Modules (HSMs) or secure vaults like Azure Key Vault or AWS KMS.
  • Rotation: Keys should be changed regularly to limit the impact if one is compromised.
  • Revocation and Destruction: When a key is no longer needed (or if an employee leaves), how is it destroyed to prevent future access?

4. Choose the Right Algorithms

Don’t try to invent your own encryption. This is the “Golden Rule” of cryptography. Always use standard, peer-reviewed, and public algorithms that are widely accepted as secure (such as AES for storage and TLS 1.3 for transmission).

Avoid proprietary algorithms or outdated standards like DES or MD5, which have known vulnerabilities. Your implementation plan should include a periodic review of these standards because what is considered “secure” today might be broken by quantum computing tomorrow.

Cryptography is powerful, and governments like to control it. Some countries have strict laws regarding the import and export of encryption software. Others may demand that authorities have access to decryption keys under specific legal circumstances.

When implementing this control, especially if you operate globally, ensure you aren’t accidentally breaking local laws by using or exporting strong crypto tools in restricted jurisdictions.


ISO 27001 Toolkit Business Edition

Common Pitfalls to Avoid

Hard-coding Keys: One of the most common findings in audits (and data breaches) is finding API keys or encryption passwords hard-coded directly into software source code. This is a massive security failure.

Losing the Keys: It sounds simple, but if you encrypt your backups and then lose the key management server in the same disaster, your backups are useless. Always have an offline, secure backup of your critical keys.

A Quick Checklist for Annex A 8.24

To ensure you are ready for your ISO 27001 audit, run through this quick checklist:

  • Do you have a documented Policy on the Use of Cryptography?
  • Are encryption keys managed separately from the encrypted data?
  • Is there a process for revoking keys if a staff member leaves?
  • Are mobile devices and laptops encrypted by default?
  • Do you use industry-standard protocols (e.g., HTTPS/TLS) for all external data transfers?
  • Have you verified that your use of encryption complies with the laws of the countries you operate in?

Why This Control Matters

Implementing Annex A 8.24 is about more than just compliance. It is about rendering your data valueless to a thief. By following the guidance provided by resources like Hightable.io and adhering to strict key management processes, you ensure that even if your perimeter is breached, your secrets remain safe.

About the author

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.

Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.

As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.

His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.

Stuart Barker - High Table - ISO27001 Director
Stuart Barker, an ISO 27001 expert and thought leader, is the author of this content.
Shopping Basket
Scroll to Top