By Yair Knijn · August 5, 2025
Your ISO 27001 cert says you manage cryptography. The auditor wants the evidence.
The compliance owner walks into the surveillance audit holding a four-page Cryptography Policy that survived the last certification cycle untouched. It says the right things: TLS 1.2 minimum, RSA-2048 or P-256, keys rotated annually, certificates from an approved CA. The quiet assumption in that binder is that the document is the control. It isn't, and the auditor is about to show why.
ISO 27001 certifies controls that operate, not the prose describing them. A policy with no renewal logs, no asset inventory, and no key-lifecycle records is a nonconformity that hasn't been written up yet.
Annex A 8.24 and 5.9: what the controls actually demand
The 2022 revision makes the gap concrete. Control 8.24 (Use of Cryptography) asks for a documented process across the full key lifecycle: generation, distribution, storage, rotation, revocation, and destruction, each with an audit trail. That last clause is the one teams skip. Rotation as an intention is not rotation as a record. Control 5.9 (Inventory of Information and Other Associated Assets) treats your certificates and keys as register assets, each with an owner, a location, and a classification. A certificate with no nameable owner is a 5.9 finding before it is anything else.
Together the two controls describe what a PDF cannot: a current inventory, plus a per-asset history proving the lifecycle was operated rather than promised.
Policy versus operating effectiveness
Auditors test design and operating effectiveness separately. Your policy clears the design test in five minutes. Operating effectiveness is a sampling exercise: the auditor pulls three certificates and asks you to walk the evidence. When was this one last renewed, who approved it, where is the private key, what algorithm and length, when does it expire. If the answer is "I'd have to check the load balancer," the control is not operating, whatever the binder claims.
The failure pattern repeats. Policies get written by the compliance function and operated by whoever installed the certificate two years ago, usually through a console click that left no trace. The two never reconcile. The wildcard three teams share, the expired internal CA still trusted by half the fleet, the renewal someone did by hand at 2am and never logged: invisible to the policy, obvious to the sample.
The evidence an auditor will ask you to produce on the spot
Have these ready before the opening meeting, not scrambled together afterward:
- A current certificate inventory with owner, hostname or SAN, issuer, key type and length, and expiry, reconciled against what is actually serving traffic.
- Renewal records per certificate showing the date, who or what performed it, and the validation method used.
- Key storage evidence: where private keys live, the access controls on them, and proof they are not sitting in a repo or a shared drive.
- Revocation and destruction records for retired keys, not only the live ones.
- Exception handling: the cert that breached policy, the ticket, and the remediation date.
Every item is a record produced by an operation, not a statement of intent. If someone assembles this from logs the night before, you don't have a control. You have a fire drill that occasionally passes.
Generate the evidence as a byproduct of the work
The dependable way to satisfy 8.24 and 5.9 is to stop treating evidence as a reporting chore and let it fall out of the renewal process. When issuance, validation, rotation, and revocation run through one automated path, the inventory is that system's live state and the renewal log is its history. Nothing to reconstruct, because nothing was done by hand. Automate Certificates keeps that record per Environment: every certificate, its validation method per SAN, its owner, and a timestamped lifecycle trail you export when the auditor names a sample. The policy stops standing in for the control and becomes what it was meant to be: an accurate description of a system that demonstrably runs. See how the inventory and lifecycle records work in our features.