ISO 27001 A.8.24: Govern cryptography and its keys

What A.8.24 requires in practice

Annex A control A.8.24 expects the organisation to define and put into effect rules for the effective use of cryptography, and those rules must include the management of cryptographic keys. Two parts stand out. First, rules are about purpose: whether the aim is confidentiality, integrity, proof of origin or something else, and which approach suits it. Second, keys are part of the control, not an afterthought, because protection is only as strong as the handling of the keys behind it.

The outputs are defined rules for where and how cryptography is used across storage, transfer, endpoints, backups and supplier services, ownership for the key lifecycle from creation to retirement, and evidence that the rules are followed. Legal and contractual requirements affect the decisions and need specialist input. The control applies according to risk treatment and the Statement of Applicability.

Define the protection that is needed

Identify whether the purpose concerns confidentiality, integrity, authenticity or another relevant assurance need. Encryption can protect information against disclosure in appropriate circumstances, while other cryptographic mechanisms can support verification of origin or change. Select the method and implementation for the intended purpose rather than using the word encrypted as a general synonym for secure.

Consider information in storage and during transfer, including endpoint devices, backups and supplier services. Establish approved approaches with competent technical input and review applicable legal or contractual requirements. This guide does not prescribe jurisdiction-specific rules or substitute for specialist assessment of a cryptographic design.

Assign ownership across the key lifecycle

Keys need protection and an understood lifecycle. Determine who can create, access, distribute, change, recover and retire them as relevant to the chosen arrangement. The process should address both unauthorised disclosure and loss: keeping information confidential is of little business value if authorised recovery becomes impossible when a required key is unavailable.

Clarify the role of suppliers. A provider may operate part of the cryptographic service while the organisation controls access or key choices. Understand that allocation and the implications for recovery, termination and incidents. Avoid claiming sole customer control or provider independence unless the actual service arrangement supports it.

Why cryptography governance matters to the business

Encryption is often the safeguard customers and regulators ask about first, and it is also easy to get wrong in ways nobody sees. Enabling a feature without managing who holds the keys, where they are kept and what happens when staff leave can leave information exposed or, equally harmful, unrecoverable. Good governance protects customer data, supports contractual promises, and avoids the cost of discovering after an incident that protection existed in name only. It also gives sales and compliance teams accurate statements to make. At audit, clear rules and owned keys show that technical protection is deliberate and controlled.

How to implement A.8.24

Treat cryptography as a managed capability with owners, rules and checks. A practical path follows. Engage someone with real cryptographic competence for the design choices, because this control is not a place for guesswork. Keep the written rules short, specific and tied to named systems, so that owners can show they follow them and auditors can follow the trail from rule to setting.

1. Identify the information and situations where cryptographic protection is needed, and state the purpose, such as confidentiality or verification.
2. Gather applicable legal and contractual requirements with competent specialist input.
3. Write approved approaches in rules that technical staff can follow, avoiding a blanket claim that everything is encrypted.
4. Cover storage, transfer, endpoint devices, backups and supplier-held information.
5. Assign owners for the key lifecycle, including creation, storage, access, rotation, recovery and retirement.
6. Restrict who can use or administer keys, and record significant key activity.
7. Check suppliers' cryptographic arrangements where they hold or process organisational information.
8. Review the rules when technology, threats or requirements change.

Evidence an auditor expects for A.8.24

An auditor wants to see that cryptographic rules are followed and keys are controlled. Evidence may include:

• the rules governing use and the reasoning behind approved approaches
• records showing who owns and can access keys
• observation of settings on a sample of systems against the rules
• records of key rotation, recovery tests or retirement
• an interview with the technical owner about what happens to keys when someone leaves

Inventory of where protection is applied is more useful than a general statement.

Common nonconformities with A.8.24

Findings typically show that cryptography exists without governance. These arise because turning on a feature feels like completion, whereas an auditor asks who holds the keys, why that approach was chosen and how the arrangement would cope with a leaver or a lost key.

• Encryption enabled on some systems with no defined rules or recorded purpose.
• Keys stored alongside the information they protect, or accessible to too many people.
• No named owner or process for key rotation, recovery or retirement.
• Supplier-held information assumed protected without any check.
• Rules unchanged for years despite changes in technology or requirements.

Illustrative software example: an encrypted backup with no recovery route

Illustrative construction example: protected laptops and exposed recovery information

A hypothetical construction company encrypts project laptops used away from the office. To simplify support, a team stores recovery information in a broadly accessible project folder. The devices report encryption as enabled, but the handling of recovery information weakens the intended protection.

The organisation restricts and assigns responsibility for recovery access, checks the affected arrangements and trains authorised support staff. A safe test confirms that a legitimate recovery request can be completed through the controlled route. The evidence connects the device setting with the supporting process rather than presenting the status icon as complete assurance.

Plan for change, compromise and expiry

Establish what happens when relevant keys or certificates need replacement, become suspect or reach the end of their intended use. Identify affected services and information before making a change that could interrupt access. Keep necessary records so the team can understand which assets depend on the material being changed.

Coordinate with change management and privileged access. Sensitive material should not be placed casually in general documentation or test environments. Where cryptography affects content inspection or other controls, evaluate the interaction and select an appropriate combined arrangement.

Verify the implementation and its operating assumptions

Useful evidence includes the approved purpose, selected approach, responsibility allocation, implemented configuration and relevant lifecycle or recovery tests. These are practical evidence options rather than a prescribed document bundle. Keep evidence appropriately sanitised: proving control should not require exposing secret keys or recovery material in an ordinary audit pack.

Test representative use and failure conditions within authorised limits. Confirm that the expected protection is active and that an authorised user can complete the required business task. Review what happens after a provider change, staff departure or system migration. A technical check may establish that encryption operates while leaving ownership and recovery assumptions unresolved.

Common failures include unmanaged keys, unexplained exceptions and unsupported claims that encryption eliminates every access risk. Use ISMS evaluation to examine meaningful operating outcomes. Cryptography complements appropriate permissions and system protection; it does not automatically correct an overly broad authorised-access decision.