ISO 27001 Annex A.10 (and A.8.24), Mapped to Certificate Controls
At school, the best maths teachers had a rule: "show your work." Getting the right answer wasn't enough. You had to show - step by step, line by line - how you got there. The point wasn't to be pedantic. It was that the working-out was where understanding lived. The answer was the end. The process was the actual thing.
ISO 27001 is built on the same principle.
If you've been through a PCI-DSS or SOC 2 audit, you've seen variations on this idea. PCI tells you what controls to have. SOC 2 asks you to demonstrate principles. ISO 27001 takes it further: it asks you to document not just what you do, but why you do it, what you considered instead, and how you'll know if it stops working.
For certificates and TLS, this matters in a specific way. The "right answers" - use TLS 1.2 minimum, monitor for expiry, manage keys properly - are the same as for other frameworks. The "show your work" demand is different. You need a policy, a Statement of Applicability, evidence of consistent application, and records that prove the process is alive.
Here's what ISO 27001 actually requires for certificates and TLS, the controls that matter (with the 2013-to-2022 rename), and what an auditor expects to see.
The 2022 update - what changed for cryptography
ISO 27001:2022 - the current version - restructured Annex A. The 2013 version organised controls into 14 sections (A.5 through A.18); the 2022 version reorganised these into 4 themes with 93 total controls.
For cryptography specifically:
- ISO 27001:2013 - Annex A.10 (Cryptography) included A.10.1.1 (policy on cryptographic controls) and A.10.1.2 (key management). ISO 27001:2022 - Annex A.8.24 (Use of cryptography) replaces both, consolidated into a single control with broader scope.
Most people still refer to "Annex A.10" because that's how it was numbered for the better part of a decade. Auditors know what you mean. But your Statement of Applicability and internal documentation should reference the 2022 numbering if you're certified to the current version (and you should be - 2013 certifications expired in October 2025).
Beyond the rename, the substance didn't change dramatically. The same things are required. The structure is just cleaner.
The TLS-relevant controls
Three Annex A controls in the 2022 version touch TLS directly.
A.8.24 - Use of cryptography. The big one. Requires policies governing the use of cryptography, including which algorithms are acceptable, how keys are managed, and how cryptographic controls are reviewed. For TLS, this means:
- A documented policy specifying acceptable TLS versions (1.2 minimum, 1.3 preferred), cipher suites, key lengths. A documented approach to key management - how private keys are generated, stored, rotated, and destroyed. Regular review of the policy as the industry moves (deprecations, new algorithms, post-quantum migration).
A.8.20 - Networks security. Covers how networks are designed and operated to protect data in transit. For TLS specifically, this means having documented standards for encrypted communications across network boundaries, including between internal services where appropriate.
A.5.31 - Legal, statutory, regulatory and contractual requirements. Requires you to identify and meet legal and contractual cryptography requirements. For TLS, this is where industry-specific requirements (PCI-DSS, HIPAA, NIS2, regional regulations) intersect with ISO. You need to know what applies and how you meet it.
The cluster of these three is where most certificate-related audit findings land - either the policy is missing, the implementation drifts from the policy, or the legal context wasn't documented.
The Statement of Applicability
ISO 27001 has a specific document that no other compliance framework requires: the Statement of Applicability (SoA).
The SoA lists every Annex A control. For each one, you state whether it applies to your organisation, why, and how you implement it (or why you've excluded it). It's a single document - usually a long spreadsheet - that maps every control in the standard to your actual implementation.
For TLS-related controls, the SoA needs to say:
- Yes, A.8.24 applies. Here's our cryptography policy (linked). Yes, A.8.20 applies. Here's our network security baseline (linked). Yes, A.5.31 applies. Here are the regulations we identified that affect cryptography (PCI-DSS, HIPAA, etc.).
The SoA is the "show your work" document. The auditor reads it to understand how you've interpreted the standard for your context. It's also where most certified organisations have weak spots - controls listed as "implemented" with no actual evidence linked.
What auditors actually look for
An ISO 27001 auditor's questions on TLS tend to follow a pattern similar to SOC 2, but with an extra layer of "show me the document."
- Show me your cryptography policy. Does it specify acceptable TLS versions, ciphers, and key management practices? Show me evidence the policy is followed. Scan reports, configuration baselines, exception logs. Show me the SoA entry for A.8.24. Does the implementation description match what you actually do? Show me how this policy is reviewed. When was it last updated? Who reviewed it? What changed? Show me your inventory of cryptographic assets. Including certificates, keys, and the systems they protect. Show me an incident. How did you handle a recent cert-related issue? Where's the documentation?
The pattern: every claim needs a document, every document needs evidence, every piece of evidence needs to actually exist and be current.
What you need to be able to show
Four artifacts go a long way for ISO 27001 TLS reviews:
- A cryptography policy that names the standards you follow (often NIST SP 800-52 Rev. 2 by reference) and the cipher suites you accept. A current cert inventory with named owners, generated by automation that's documented in the policy. Continuous monitoring evidence - scan reports showing TLS configuration is staying compliant. An incident or two, handled cleanly with documentation that follows your incident management process.
The same four artifacts that work for PCI-DSS and SOC 2 also work for ISO 27001 - the framing is different but the underlying evidence is the same.
One small ask
ISO 27001 doesn't ask for different things than other compliance frameworks. It asks the same things with more rigour around documentation. The certificate-related work is the same work: inventory, policy, monitoring, ownership, response. TLS Radar provides the inventory and monitoring sides with audit-grade logs that survive an ISO review. The policy and incident process are yours to design. Free tier covers three domains, which is enough to see whether your current setup would hold up to a "show your work" auditor.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.