Building Audit-Ready TLS Evidence (Free Template)
When you travel internationally, the careful traveller keeps a folder. Not metaphorically - a literal folder, or a phone wallet, or a screenshot album. In it: a copy of the passport, the visa, hotel confirmations, emergency phone numbers, any vaccination cards required, a printout of the return flight. Everything organised so that when something goes wrong - a lost passport, a customs question, a hotel disagreement at 11pm - the answer is two seconds away, not "let me search through my email."
Compliance auditors are exactly the same kind of traveller. When they show up, they have questions. They want the answers fast. The auditor who has to wait while you "check with Bob" or "search through SharePoint" is forming opinions about your control environment that aren't favourable.
This piece is the folder. It's a template for the TLS evidence package you should have ready before any compliance audit - PCI-DSS, SOC 2, HIPAA, ISO 27001, NIS2, or any other framework where certificates fall in scope. Most of it is the same regardless of which framework you're audited against. The wording changes; the artifacts don't.
Build this once. Maintain it. The next audit becomes a conversation about evidence rather than a search through tools.
Why audit evidence usually fails
Three patterns we see consistently when teams scramble during audits.
The "we have it somewhere" problem. Evidence exists - in scattered Slack threads, CMDB entries, monitoring tool exports, engineer memory. None of it is curated. Producing it requires hours of digging during a time-bounded audit window.
The "snapshot vs continuous" problem. A team runs a configuration scan the day before the audit, exports the report, presents it as evidence. The auditor asks: "and the day before that? And the month before? How do you know this isn't a one-time thing?" Snapshot evidence is weaker than continuous evidence.
The "named owner is a person who's left" problem. The cert ownership document lists Bob as owner. Bob hasn't worked there in eighteen months. The auditor doesn't say anything sharp; they just write a finding.
The fix for all three is the same: build the evidence package proactively, keep it current, and make it easy to produce when asked.
The four artifacts that always matter
Across PCI-DSS, SOC 2, HIPAA, ISO 27001, and most other frameworks, auditors want four artifacts for TLS:
- A current cert inventory showing what you have, where it lives, and who owns it. Configuration evidence showing TLS configuration meets policy across all endpoints in scope. Renewal and ownership records showing the lifecycle is managed, not accidental. Incident records showing that when something goes wrong, you have a process.
The rest of this piece is the template for each one.
Artifact 1: The cert inventory
Required fields per cert, at minimum:
- Cert identifier. Serial number or fingerprint - something unique that survives renewals. Common Name and SAN list. What this cert is actually for. Issuing CA. Which CA issued it. Issue date and expiry date. Lifecycle markers. System(s) it protects. Service name, hostname, environment (production/staging). Service owner. The team responsible, not a person. Cert owner. Often the same as service owner, sometimes different. Either way, a team-level entity. Scope flags. Which compliance frameworks this cert is in scope for (PCI? HIPAA? SOC 2?). Last verified. When was this entry last confirmed accurate?
Required properties of the inventory itself:
- Generated by automation. Not maintained by hand. The reason: hand-maintained inventories rot. Automation that pulls from multiple sources (CT logs, cloud APIs, internal CAs, network scans) and reconciles them produces a true inventory. Reconcilable. The auditor should be able to ask "how do you know this list is complete?" and get a specific answer involving sources and reconciliation. Historised. You should be able to produce the inventory from any past month, not just today. Auditors sometimes ask "what did your inventory look like six months ago?"
Common gaps to fix before audit:
- Internal certs (from internal CAs) missing from the inventory. Vendor-embedded certs missing entirely. Mobile app cert pins not in inventory. Certs from acquired companies absorbed without their inventory.
Artifact 2: Configuration evidence
Required fields per cert or per endpoint:
- TLS versions supported. Should show 1.2 and 1.3, no 1.0 or 1.1, no SSL. Cipher suites accepted. Should match policy. Chain validity. Full chain present and valid. Hostname coverage. SAN list matches the hostnames being served. Revocation status. Not revoked. OCSP Stapling status. Enabled where applicable. Vulnerability status. No known TLS vulnerabilities (Heartbleed, ROBOT, BEAST, etc.). Last scanned. Recent enough to be meaningful.
Required properties of the configuration evidence:
- Continuous, not snapshot. Daily scans are good. Weekly is the minimum. One-off scans the week of audit are weak evidence. Historical. Reports from previous months prove the configuration has been compliant over time, not just today. Per-endpoint, not aggregate. "Our environment is compliant" is weaker than "each of these 247 endpoints was scanned on these dates with these results." Tied to remediation. When a scan finds an issue, the evidence should show how it was tracked and resolved.
Common gaps:
- Scans that don't reach internal endpoints. Reports that aggregate too much detail to be useful. No record of remediation when issues were found. Scans from before the current policy version.
Artifact 3: Renewal and ownership records
Required fields:
- Renewal log per cert. Each renewal event recorded: when, who/what triggered it, what changed. Ownership history. Who has owned this cert and for what period. Renewal automation evidence. Where ACME or other automation is used, evidence it's working and being monitored. Failed renewal records. When renewals have failed, what happened, how it was resolved.
Required properties:
- Per-cert auditability. For any cert, you should be able to produce its full renewal history. Ownership transition records. When ownership moved between teams (because of a reorg, an acquisition, a departure), evidence it was tracked. Renewal policy alignment. The actual renewal timing should match the documented policy (e.g., "we renew 30 days before expiry").
Common gaps:
- Renewal "evidence" that's just "the cert is current." No documented owner transitions. Ad-hoc renewals with no recorded reason.
Artifact 4: Incident records
Required for the TLS audit context:
- A list of cert-related incidents in the audit period. For each incident: what happened, when, who responded, root cause, time to resolution, preventive actions taken. Evidence the incident response process was followed. Tickets, post-mortems, communication records. A "zero incidents" answer is allowed, but only if monitoring evidence supports it. The auditor wants to see that you'd have caught one if it happened.
Required properties:
- Documented post-mortems. Even for small incidents. The artifact matters more than the size. Tracked preventive actions. Items identified during post-mortems should appear in some sort of follow-up tracking with assigned owners. Pattern recognition. If you've had several incidents of the same kind, the auditor wants to see what changed structurally.
Common gaps:
- "We had no incidents" without monitoring evidence. Post-mortems that name what went wrong but don't track follow-up. Incidents in Slack threads that were never written up.
The template, summarised
A compact version of what you should have ready:
``` TLS Evidence Package (period: [audit period])
- Cert Inventory
- Configuration Evidence
- Renewal and Ownership Records
- Incident Records
This is roughly what we'd want to see if we were the auditor. The specific tools and URLs depend on your environment. The shape is the same.
How to keep it current
The biggest practical question: how do you keep this package current without it becoming a manual project?
Three things help.
The inventory updates itself. Automation pulls from CT logs, cloud APIs, internal CAs daily. The "current inventory" exports are always fresh.
The configuration evidence is generated by the scanner. TLS Radar (or whatever you use) exports compliance reports on a schedule. You don't curate them.
The incident records live where incidents live. Don't try to maintain a separate "audit incidents" log. Point auditors at your incident ticket system, with a filter for cert-related incidents.
The work isn't preparing the package the week of the audit. It's setting up the automation that produces the package continuously, then pointing the auditor at it.
One small ask
A compliance auditor with a folder full of organised evidence is a quick auditor. A compliance auditor watching you search for evidence is the same auditor with a different mood. The cheapest path to the first version is building the inventory and the configuration evidence automation now - well before any audit. TLS Radar produces both, continuously, with audit-grade logs. Free tier covers three domains, which is enough to see what your evidence would look like before you need to show it.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.