Guide Low priority ISO 27001Audit EvidenceTLS

ISO 27001 Evidence for TLS and Access Logs

10 min read

Auditors do not usually ask for magic. They ask reasonable questions that become painful when infrastructure evidence lives across hosts, Slack, CI logs, and someone’s laptop.

For TLS and access, the evidence should already exist because the workflow produced it.

Evidence chain for TLS and access

1
Control
2
Request
3
Approval
4
Action
5
Verification
6
Review

Evidence quality by source

Screenshots 38%

Useful once, weak as a process.

Host logs 52%

Detailed but scattered.

GRC uploads 60%

Good collection, not always live proof.

Workflow audit trail 86%

Evidence created during real work.

TLS evidence

Keep certificate owner, expiry, issuer, renewal workflow, delivery target, reload result, endpoint probe result, and exception history.

The important detail is the live endpoint result. Inventory alone is not evidence that production served the right certificate.

Access evidence

Keep who requested access, who approved it, which host or secret was accessed, what scope was granted, when it expired, and whether 2FA was used.

Shared SSH keys make this harder because they collapse many people into one credential.

Secret evidence

Keep version history, change actor, access logs, owning group, rotation date, dependent systems, and rollback history.

The evidence is stronger when it comes from the system used by engineers, not a manually assembled PDF.

Evidence to keep

  • ✓ Certificate inventory and live endpoint probe results.
  • ✓ Renewal, delivery, reload, and failure records.
  • ✓ SSH/RDP access requests, scopes, expiry, and session records.
  • ✓ Secret read/change history and version rollback records.
  • ✓ Exception records with owner and review date.

Related reading and workflows

Try the workflow against real infrastructure

Use the hosted evaluation at trust.certlocker.io for a walkthrough, or run a one-month onsite evaluation against your own certificates, hosts, secrets, and access paths.