ISO 27001 SSL Certificate Management Controls Explained

ISO 27001 SSL Certificate Management Controls Explained

ISO 27001 SSL certificate management comes down to proving that your organization knows which certificates it has, who owns them, and how they are renewed, protected and retired. For an ISMS lead or sysadmin preparing for a certification or surveillance audit, it helps to know which Annex A controls touch TLS certificates, what evidence auditors actually ask for, and where teams usually lose points. This guide maps those controls to day-to-day certificate work, so audit preparation produces something useful beyond the paperwork.

The timing matters. The transition period from ISO/IEC 27001:2013 to the 2022 revision ended on October 31, 2025, so every valid certificate is now audited against the 93 controls in the 2022 Annex A. Several old control references from the 2013 numbering no longer apply.

Which Annex A Controls Cover SSL Certificates

No control in ISO 27001 is called “SSL certificate management”. Certificates fall under several controls at once, and an experienced ISMS lead maps them explicitly in the Statement of Applicability (SoA) rather than assuming the auditor will connect the dots.

A.8.24 Use of cryptography is the core control. It replaced the 2013 controls A.10.1.1 and A.10.1.2 and requires rules for effective use of cryptography, including key management. ISO/IEC 27002:2022 section 8.24 spells out the key lifecycle: generating keys, issuing and obtaining public key certificates, storing, updating, revoking, recovering, archiving and destroying them, plus logging these activities.

A.5.9 Inventory of information and other associated assets requires an asset inventory with named owners. Certificates and their private keys are assets. If a certificate isn’t in the inventory, the control has a gap, whether or not the certificate is still valid.

A.8.9 Configuration management, new in the 2022 version, covers secure configurations of hardware, software, services and networks. TLS protocol versions, cipher suites, HSTS headers and OCSP stapling belong here.

A.8.16 Monitoring activities, also new, expects networks, systems and applications to be monitored for anomalous behavior. Certificate expiration monitoring and Certificate Transparency log monitoring are natural evidence for this control.

Supporting controls include A.8.32 Change management for certificate renewals and replacements, A.5.22 Monitoring of supplier services for CDNs and SaaS platforms that terminate TLS on your behalf, and A.5.30 ICT readiness for business continuity when an expired certificate could take down a critical service.

The Myth: ISO 27001 Requires a Specific Certificate Type or TLS Version

A common belief is that ISO 27001 demands EV certificates, a particular key length, or TLS 1.3 everywhere. It doesn’t. The standard is risk-based and technology-neutral, and Annex A tells you what to control, not which algorithm to pick.

That cuts both ways. You define the requirements yourself in a cryptography policy, and then the auditor holds you to exactly what you wrote. If your policy says “TLS 1.2 minimum, RSA 2048 or ECDSA P-256, maximum certificate validity per CA/Browser Forum rules”, every public endpoint must meet that. Writing an ambitious policy you can’t enforce is a faster route to a nonconformity than writing a modest one you can.

An A+ SSL grade doesn’t prove compliance either. It is good evidence for A.8.9, but an auditor will still ask who owns the certificate and how the renewal was approved.

Building Audit-Ready Certificate Controls Step by Step

A seasoned compliance lead usually builds the program in this order, because each step produces evidence for the next:

1. Write the cryptography policy. Cover approved algorithms, minimum TLS versions, approved CAs, maximum validity and key storage requirements. Keep it to 2-4 pages.

2. Build the inventory. Combine scans of your IP ranges, cloud provider APIs (AWS Certificate Manager, Azure Key Vault, GCP Certificate Manager) and Certificate Transparency searches on crt.sh. A practical method is described in the guide on building an SSL certificate inventory. Every entry needs an owner, a hostname, an issuer, an expiry date and a key location.

3. Define the renewal procedure. Document how renewals happen, who approves them, and how changes are logged. ACME automation counts as a procedure if it is written down and its failures are monitored.

4. Protect private keys. State where keys live (HSM, Key Vault, file system with restricted permissions) and who can access them. The article on private key protection covers practical storage options.

5. Monitor and review. Set staged expiration alerts, for example 30, 14, 7 and 1 days out, and review the certificate inventory at least quarterly as part of internal audits.

Validity periods make step 3 more urgent. Under CA/Browser Forum ballot SC-081, maximum public TLS certificate validity dropped to 200 days on March 15, 2026, falls to 100 days in March 2027 and to 47 days in March 2029. A manually renewed estate of 150 certificates already means roughly 270 renewals a year, which is too many to handle without a documented, largely automated process.

A Typical Surveillance Audit Scenario

Picture a mid-sized SaaS company in its first surveillance audit after recertification. The auditor samples ten certificates from the inventory. All are valid and renewed through cert-manager on Kubernetes. Then the auditor runs a crt.sh query on the company’s domain and finds a wildcard certificate issued by a different CA eight months ago, deployed on a staging load balancer that a former contractor set up.

The certificate is valid and the site works. It still produces a minor nonconformity against A.5.9 because the asset has no owner and isn’t in the inventory, and a possible observation against A.8.24 because the CA isn’t on the approved list. The fix takes an afternoon. The corrective action report, root cause analysis and follow-up evidence take considerably longer.

Common Mistakes That Lead to Nonconformities

Inventories built once and never reconciled. Teams export a spreadsheet before the stage 1 audit and stop updating it. Six months later it contradicts what CT logs show. Reconciling against Certificate Transparency data monthly closes this gap cheaply.

Treating vendor-managed certificates as out of scope. Certificates on Cloudflare, Akamai, Shopify or a marketing platform’s custom domain still serve your users. A.5.22 expects you to monitor supplier services, so these belong in the inventory with the supplier noted as the operator.

Logging renewals nowhere. ISO 27002 guidance on 8.24 explicitly mentions logging key management activities. Automated renewals that leave no trace in a ticketing system or change log are hard to evidence. Even a simple renewal log exported from your ACME client is enough.

A detailed approach to collecting this evidence is described in building an SSL certificate audit process for compliance.

Exceptions and Edge Cases

Internal PKI changes the picture. Certificates issued by an internal Microsoft AD CS or HashiCorp Vault CA don’t appear in public CT logs, so discovery must rely on network scans and CA database exports. Air-gapped OT environments may legitimately run certificates with 5-10 year validity, which is acceptable if the risk assessment justifies it and the SoA reflects it.

For small teams under 10 people, auditors generally accept a lighter process: one owner, a shared inventory and automated alerts. The requirement is consistency, not bureaucracy.

FAQ: ISO 27001 and Certificate Management

Does ISO 27001 require automated certificate monitoring?
No. It requires effective control, and manual tracking is acceptable in principle. In practice, with 200-day maximum validity and shrinking, manual processes rarely hold up at audit time for more than a few dozen certificates.

Is an expired certificate an automatic nonconformity?
Not automatically. An expiry that was detected, handled through incident management and followed by corrective action can actually demonstrate a working ISMS. Repeated expiries with no root cause analysis are what auditors flag.

Which control covers TLS configuration such as cipher suites?
Primarily A.8.24 for cryptographic choices and A.8.9 for keeping configurations consistent and reviewed. A.8.20 Networks security can also apply to protecting data in transit.

Summary: Turning Certificate Controls into Evidence

ISO 27001 doesn’t tell you which certificates to buy. It asks you to prove that every certificate is known, owned, protected and renewed according to rules you wrote yourself. Map A.8.24, A.5.9, A.8.9 and A.8.16 explicitly in your SoA, reconcile your inventory against CT logs every month, and keep a renewal log. Before the next audit, run your own crt.sh query on your domains first, because the auditor may well do the same.