What Is ISO 27001 Annex A Control 8.24?
Control 8.24 of ISO 27001:2022 requires organisations to define and apply rules for the use of cryptography to protect information. That sounds simple enough, but in practice it covers a lot of ground. We are talking about encryption of data at rest and in transit, key management, digital signatures, certificate management, and the policies that govern all of it.
On this page
This control sits within Annex A of ISO 27001, which is the list of 93 controls that organisations use to treat information security risks. Control 8.24 belongs to the Technological Controls category (Theme 8), which was introduced in the 2022 revision of the standard. If you were certified under the older 2013 version, this roughly maps to the old controls A.10.1.1 and A.10.1.2, which covered cryptographic policy and key management respectively.
The reason this control matters so much is straightforward. Cryptography is one of the most reliable tools available for protecting the confidentiality and integrity of information. When it is done well, it stops attackers from reading sensitive data even if they manage to get their hands on it. When it is done poorly, or not done at all, the consequences can be severe. Think data breaches, regulatory penalties, and reputational damage.
If you are working through your ISO 27001 information security management system implementation, this control is one you cannot afford to treat lightly.
What Does Control 8.24 Actually Require?
The control has two main requirements. First, your organisation must establish and implement a policy on the use of cryptography. Second, you must manage cryptographic keys throughout their entire lifecycle. Let us break both of these down.
The Cryptographic Policy
Your cryptographic policy needs to address several things. It should define when and how cryptography must be used within your organisation. It should specify which cryptographic algorithms, key lengths, and protocols are acceptable. It should also cover the circumstances under which cryptographic controls are required, such as when transmitting personal data over a public network or when storing sensitive credentials.
The policy does not need to be a technical document that only your IT team can understand. It should be written in a way that gives your staff clear guidance on what is expected. For example, a policy statement might say that all laptops must have full disk encryption enabled, or that all emails containing customer financial data must be encrypted before being sent externally.
Think about what information your organisation holds and how it moves around. That analysis should drive the scope of your policy. A healthcare provider storing patient records has very different cryptographic needs to a small marketing agency, even though both could be pursuing ISO 27001 certification.
Key Management
Cryptographic keys are the secret values that make encryption work. If your keys are compromised, your encryption is worthless. Control 8.24 requires you to manage keys across their full lifecycle, which includes generation, distribution, storage, use, archiving, and destruction.
Key management is where many organisations fall short. They implement encryption but then store the encryption keys in the same place as the encrypted data, or they never rotate keys, or they have no process for revoking a key when an employee who had access leaves the organisation. All of these are findings that auditors will raise during a certification audit.
Your key management procedures should address who is authorised to generate and manage keys, how keys are stored securely, how long keys remain valid before rotation is required, and what happens when a key is suspected to be compromised.
Real World Examples of Control 8.24 in Practice
Let us look at some practical scenarios to make this more concrete.
Example 1: A SaaS Company Protecting Customer Data
A software company holds sensitive customer data in a cloud database. Under Control 8.24, they would be expected to encrypt the database at rest using a strong algorithm such as AES-256. Data transmitted between the application and end users should be protected using TLS 1.2 or higher. The company should have a documented policy that specifies these requirements, and they should be able to demonstrate that the controls are actually in place, not just written down.
During an audit, the auditor might ask to see the policy, then verify that the database encryption is enabled and that TLS is configured correctly on the web server. They might also ask how the database encryption keys are managed and who has access to them.
If you are a SaaS company working toward certification, the article on how ISO 27001 certification helps SaaS companies close deals faster is worth reading alongside this one.
Example 2: A Professional Services Firm Sending Sensitive Documents
A legal firm regularly sends confidential client documents via email. Their cryptographic policy under Control 8.24 might require that any email containing privileged information must be sent using an encrypted email solution, or that documents must be protected with password encryption before being attached. The policy would also need to address how those passwords are communicated to recipients securely, since sending the password in the same email as the encrypted document defeats the purpose entirely.
Example 3: An IT Managed Service Provider Managing Client Systems
A managed service provider (MSP) holds administrative credentials for dozens of client environments. Their key management obligations under Control 8.24 are significant. They need a privileged access management system that encrypts stored credentials, enforces key rotation, and maintains access logs. They also need a procedure for what happens when a technician leaves the company, including immediate revocation of their access and rotation of any credentials they had access to.
MSPs pursuing ISO 27001 certification face particularly complex cryptographic requirements because they are effectively managing cryptographic controls on behalf of multiple clients simultaneously. The article on ISO 27001 certification for managed service providers covers this in more detail.
Common Gaps Auditors Find With Control 8.24
Having reviewed dozens of ISO 27001 implementations, there are patterns in where organisations struggle with this control. Here are the most common gaps.
Policy Exists But Is Not Followed
Many organisations write a cryptographic policy during implementation and then never actually enforce it. The policy says all laptops must be encrypted, but when the auditor asks for evidence, it turns out that a third of the fleet has never had encryption enabled. A policy without evidence of implementation is a nonconformance waiting to happen.
Weak or Outdated Algorithms
Some organisations are still using cryptographic algorithms that are considered weak by current standards. MD5 and SHA-1 for hashing, or DES and 3DES for encryption, are examples of algorithms that should no longer be used for protecting sensitive information. Your policy should specify approved algorithms and include a review cycle to keep up with current guidance. The NIST Cryptographic Standards and Guidelines is a reliable reference point for current recommendations on algorithm selection.
No Key Management Procedures
Organisations implement encryption but have no documented process for managing the keys. There is no defined key rotation schedule, no procedure for key revocation, and no record of who holds which keys. This is one of the most common findings in ISO 27001 audits related to this control.
TLS Misconfiguration
Organisations assume that having HTTPS on their website means they are compliant. But if the server is configured to accept old versions of TLS or weak cipher suites, the protection is weaker than it should be. Your policy should specify minimum TLS versions and acceptable cipher suites, and you should have a process for testing this regularly.
Third Party Cryptographic Practices Not Assessed
If you rely on third parties to process or store sensitive data, you need to understand their cryptographic practices too. Control 8.24 does not stop at your own systems. Your supplier assessment process should include questions about encryption standards and key management, and this should be documented.
How to Implement Control 8.24 Step by Step
Here is a practical approach to implementing this control in your organisation.
Step 1: Understand What Needs Protecting
Start with your information asset register and risk assessment. Identify the information that, if disclosed or tampered with, would cause the greatest harm to your organisation or your customers. This is what your cryptographic controls should prioritise. You do not need to encrypt everything, but you do need a defensible rationale for what you do and do not encrypt.
Step 2: Write a Cryptographic Policy
Document your policy covering the use cases for cryptography, the approved algorithms and key lengths, the requirements for key management, and the responsibilities of staff and system owners. Keep it readable. A ten-page technical document that nobody reads is not a policy, it is a filing exercise.
Make sure the policy is reviewed at least annually and whenever significant changes occur to your technology environment or threat landscape.
Step 3: Implement the Technical Controls
Enable full disk encryption on all laptops and mobile devices. Configure your servers and applications to use strong TLS versions and cipher suites. Encrypt sensitive data in databases. Implement a password or secrets management solution for storing credentials and cryptographic keys. Use digital certificates from a trusted certificate authority for your public-facing services.
Step 4: Establish Key Management Procedures
Document the lifecycle of your cryptographic keys. Define who is responsible for key management, how keys are generated, where they are stored, how often they are rotated, and how they are revoked when no longer needed. Make sure these procedures are tested, not just written down.
Step 5: Train Your Staff
Your staff need to understand the cryptographic requirements that apply to their roles. This does not mean every employee needs to understand the mathematics behind AES-256. It means they need to know what they are required to do, such as not emailing unencrypted sensitive data, not storing passwords in plain text spreadsheets, and reporting suspected key compromises immediately.
Step 6: Test and Monitor
Regularly test that your cryptographic controls are working as intended. Use tools to scan for weak TLS configurations. Audit your encryption settings on servers and devices. Review access logs for your key management systems. Include cryptographic controls in your internal audit programme.
If you want to make sure your internal audits are genuinely finding gaps rather than just ticking boxes, the guide on how to run ISO internal audits that actually find problems is a useful resource.
How Control 8.24 Connects to Other ISO 27001 Controls
Control 8.24 does not operate in isolation. It connects to several other controls in Annex A, and understanding these relationships helps you implement a more coherent information security programme.
Control 8.20 (Networks Security) and Control 8.21 (Security of Network Services) are closely related because securing network communications typically involves cryptographic protocols like TLS and VPNs. Control 5.14 (Information Transfer) is relevant because it covers the rules for transferring information to external parties, which often requires cryptographic protection.
Control 8.12 (Data Leakage Prevention) and Control 8.11 (Data Masking) are also connected, because encryption is one of the tools used to prevent sensitive data from being exposed. And of course, the overall ISO 27001 risk assessment process should be driving your decisions about where and how to apply cryptographic controls.
If your organisation also handles personal data and is working toward ISO 27701 certification, it is worth noting that cryptographic controls play an important role in privacy protection as well. The ISO 27701 privacy information management system guide covers how these two standards align.
What Auditors Look for During a Control 8.24 Assessment
When an ISO 27001 auditor reviews your implementation of Control 8.24, they are looking for evidence across several areas. Here is what to expect.
They will ask to see your cryptographic policy and check that it is approved, current, and covers the key requirements. They will ask how the policy was developed and whether it was informed by a risk assessment. They will want to see evidence that the controls described in the policy are actually implemented, not just documented.
They will likely ask technical questions or request technical evidence. This might include screenshots showing disk encryption is enabled on devices, TLS configuration reports from scanning tools, documentation of your key management procedures, and evidence of key rotation or certificate renewal activities.
They will also look at your supplier management records to see whether you have assessed the cryptographic practices of third parties who handle your sensitive data.
One thing that catches organisations out is the gap between what the policy says and what is actually happening. Auditors are experienced at spotting this. If your policy says keys are rotated every 90 days but your key management logs show the last rotation was 14 months ago, that is a nonconformance regardless of how well-written the policy is.
Getting Help With ISO 27001 Implementation
Control 8.24 is one of those controls that looks straightforward on the surface but has real depth when you get into the implementation details. Key management in particular is a specialist area, and getting it wrong can undermine the security that your cryptographic controls are supposed to provide.
If you are working through ISO 27001 for the first time, or if you are preparing for a recertification audit and want to make sure your cryptographic controls are solid, working with an experienced ISO 27001 consultant can save you a significant amount of time and reduce the risk of costly nonconformances.
CertBetter connects businesses with verified ISO 27001 consultants and accredited certification bodies across Australia and globally. You submit one form, and you receive up to three competing quotes from vetted providers. It costs nothing to use the platform, and it removes the guesswork from finding someone who actually knows what they are doing with information security management systems.
