ISO 27001 Certificate Evidence: How a PDF Cert Inventory Satisfies Annex A.12

Published April 8, 2026 · 10 min read

If your organisation is ISO 27001-certified — or working toward certification — you already know the drill: document everything, maintain evidence, and be ready to show an auditor that your controls are not just written down but actually operating. One area that catches teams off guard is cryptographic controls under Annex A.10.1 and how they intersect with operations security in Annex A.12.

Specifically, auditors want to see that you know which TLS certificates you have, when they expire, and that you are actively managing their lifecycle. A spreadsheet maintained by hand is technically compliant, but it is also the first thing to go stale. This guide explains what auditors actually look for and how an automated, timestamped PDF certificate inventory — like the one PingKit Guardian Plus generates — satisfies those requirements with minimal effort.

What ISO 27001 Requires for Cryptographic Controls

The relevant controls sit in two places:

• A.10.1.1 — Policy on the use of cryptographic controls: You need a documented policy that covers where cryptography is used, which algorithms are acceptable, key lengths, and lifecycle management.
• A.10.1.2 — Key management: You need to manage the lifecycle of cryptographic keys and certificates, including generation, storage, distribution, rotation, and revocation.

TLS certificates are a primary cryptographic control for any organisation that runs web services, APIs, or internal microservices. The certificate itself is the public half of a key pair, and its lifecycle — issuance, renewal, revocation — falls squarely under A.10.1.2.

Under A.12 (Operations Security), auditors expect evidence that operational processes for managing these controls are in place and functioning. That means you need more than a policy document. You need evidence that the policy is being followed: a current inventory of certificates, their status, and proof that you are monitoring for expiration.

What Auditors Actually Ask For

In practice, the audit conversation around certificates usually covers four questions:

1. Do you have an inventory of all TLS certificates in use? The auditor wants to see a list of every certificate, where it is deployed, and who issued it.
2. Do you track expiration dates and renew certificates before they expire? Evidence that you have a monitoring system and that it has been working — not just that it exists on paper.
3. Are your certificates using acceptable algorithms and key lengths? RSA-2048 or ECDSA P-256 as a minimum. SHA-1 signatures are a finding. TLS 1.0/1.1 is a finding.
4. Can you show me this evidence is current? A report from six months ago does not satisfy the auditor. They want something recent — ideally generated during or just before the audit window.

What a Compliant Certificate Inventory Looks Like

A certificate inventory that satisfies these questions needs to include the following fields for each certificate:

• Domain name — the hostname being monitored
• Issuer — the certificate authority (e.g., Let's Encrypt, DigiCert, Sectigo)
• Subject distinguished name — the entity the certificate was issued to
• Subject alternative names (SANs) — all hostnames covered by the certificate
• Validity period — not-before and not-after dates
• Days until expiry — calculated at the time of report generation
• Key algorithm and size — RSA-2048, ECDSA P-256, etc.
• Signature algorithm — SHA-256 with RSA, etc.
• Serial number — unique identifier from the CA
• Negotiated TLS protocol version — TLS 1.2 or 1.3
• Report generation timestamp — when the inventory was created

Why a Spreadsheet Is Not Enough

Many teams start with a spreadsheet listing their certificates. It works until someone forgets to update it after a renewal, a new service is deployed without adding its certificate to the list, or the team member who maintained it leaves the company.

Auditors know this. A spreadsheet with a "last updated" date from three months ago immediately raises questions about whether the process is actually operating. An automated report generated on demand, pulling live data from the actual certificates being served, is a fundamentally different level of evidence.

The automated approach also catches certificates that the spreadsheet missed entirely — the staging environment someone set up with a self-signed cert, the internal API that was deployed without going through the normal process, or the legacy subdomain that everyone forgot about but is still serving traffic.

Mapping to the Statement of Applicability

Your Statement of Applicability (SoA) needs to show which controls apply and how they are implemented. Here is how Cert Monitor and the PDF export map to the relevant controls:

A.10.1.1 — Policy on Cryptographic Controls

Evidence: Your cryptographic policy document references PingKit Cert Monitor as the tool used for TLS certificate lifecycle monitoring. The policy specifies minimum key lengths (RSA-2048, ECDSA P-256), acceptable signature algorithms (SHA-256+), and required TLS versions (1.2+).

A.10.1.2 — Key Management

Evidence: The PDF certificate inventory demonstrates that all certificates are tracked, their expiration dates are known, and the monitoring system sends alerts before expiry. The report includes key algorithm and size for every certificate, proving that the key management policy is being enforced.

A.12.4.1 — Event Logging

Evidence: PingKit Cert Monitor logs every check — successful or failed — with timestamps. The history of cert checks demonstrates continuous monitoring, not just a point-in-time snapshot.

A.12.4.3 — Administrator and Operator Logs

Evidence: Push notification history and the cert check log show that responsible personnel are being notified of certificate events and taking action when certificates approach expiry.

How to Set This Up in Practice

1. Install PingKit and subscribe to Guardian Plus ($4.99/month or $39.99/year).
2. Add every domain you manage to Cert Monitor. Include production, staging, and internal services. If it has a TLS certificate, add it.
3. Set the check schedule. For most teams, every 6 hours is sufficient. High-security environments may prefer hourly.
4. Configure the expiry threshold. Default is 14 days. If your renewal process is slower (e.g., manual CSR approval), increase this to 30 days.
5. Before each audit window, export the PDF. Tap Export in Cert Monitor and share it via email or AirDrop. The timestamp proves it was generated during the audit period.
6. Reference PingKit in your SoA as the operational tool for A.10.1.2 and A.12.4.1 evidence.

What About Let's Encrypt 90-Day Certificates?

Let's Encrypt certificates have a 90-day lifetime and rely on automated renewal via ACME. This is generally fine, but the automation can silently fail: DNS validation stops working, the certbot cron job gets disabled during a server migration, or a reverse proxy stops serving the challenge response.

Cert Monitor catches these failures because it checks the actual certificate being served, not whether your renewal process thinks it succeeded. If certbot renewed the cert but nginx is still serving the old one because it was not reloaded, Cert Monitor will see the expiring certificate and alert you.

From an ISO 27001 perspective, this is exactly the kind of operational control the auditor wants to see: you are not just relying on the automation to work; you are verifying that it did.

Conclusion

ISO 27001 certificate compliance does not have to be a manual, error-prone process. An automated certificate inventory that pulls live data from your actual endpoints, generates timestamped evidence on demand, and alerts you when something needs attention satisfies the auditor while reducing your operational burden.

PingKit Guardian Plus provides exactly this. Set it up once, add your domains, and let it handle the monitoring and evidence generation. When the auditor asks about your cryptographic controls, you will have a current, comprehensive answer ready on your iPhone.