ISO 27001 Certificate Evidence: How a PDF Cert Inventory Supports Logging & Vulnerability Management

By Paul Snyman · Published · 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. An expired TLS certificate is also a real operational risk: an unnoticed expiry means an outage, and outages are exactly the kind of thing an auditor asks how you detect. This guide explains which ISO 27001:2022 controls a timestamped PDF certificate inventory (like the one PingKit Guardian Plus generates) actually supports, and where its limits are.

Specifically, auditors want to see that you know which TLS certificates you have, when they expire, and that you are actively monitoring for expiry. 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 provides evidence for those requirements with minimal effort.

What ISO 27001:2022 Says About Monitoring and Logging

PingKit's Cert Monitor PDF export maps to three Annex A controls in ISO 27001:2022. It's a common assumption that certificate monitoring falls under the cryptography-policy control, A.8.24 (Use of cryptography), but that control is really about key-management policy and algorithm choice. A monitoring log is closer to an operations-and-logging story:

If your organisation also wants evidence specifically for A.8.24, a certificate inventory can support that argument too, key algorithm and size are part of what's checked, but that's a secondary case to make yourself, not what PingKit's PDF export is built to document.

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:

PingKit Guardian Plus includes all of these fields in its ISO 27001 PDF export. Open PingKit, go to Cert Monitor, tap Export, and you have a timestamped PDF ready to hand to your auditor. No spreadsheet maintenance required. (It does not currently include the certificate's serial number or negotiated TLS protocol version, if your audit needs those specifically, note that as a gap.)

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.5.37 (Documented Operating Procedures)

Evidence: Your operating procedures document references PingKit Cert Monitor as the tool used for routine TLS certificate expiry checking, a defined, repeatable process rather than an ad hoc or manual one.

A.8.15 (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.8.8 (Management of Technical Vulnerabilities)

Evidence: The PDF certificate inventory shows every monitored certificate's expiry status at export time, and PingKit alerts at 30, 14, 7, and 1 day before expiry, demonstrating that an expiring certificate (a real technical vulnerability) is detected and flagged before it causes an incident.

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, up to 25 domains per device. If it has a TLS certificate, add it.
  3. That's it for setup. Checks run automatically on a fixed hourly schedule, there's no interval to configure. PingKit alerts you at 30, 14, 7, and 1 day before any certificate expires, also fixed, not a threshold you set.
  4. 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.
  5. Reference PingKit in your SoA as the operational tool for A.5.37, A.8.15, and A.8.8 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 gives the auditor what they need 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.

Auditing servers, not just public TLS endpoints?

Our sister Mac app Noxen runs nightly Linux/VPS security audits and exports ISO 27001:2022, SOC 2, and CIS Controls v8 evidence as PDF, CSV, or NDJSON for SIEM ingestion. Built by the PingKit team.

Visit noxen.app →

Related Articles

Automate Your Certificate Compliance

PingKit Guardian Plus monitors your TLS certificates, alerts you before expiry, and generates ISO 27001-ready PDF evidence on demand.

Download Free on the App Store