Which ISO 27001 controls does TLS monitoring support?

Primarily the cryptography and secure-configuration controls in Annex A (2022): use of cryptography, secure network services, and configuration management. Continuous TLS, header and DNS checks give an auditor evidence these controls operate in practice, not just on paper.

Do I need a screenshot or a continuous record for ISO 27001?

A screenshot proves a single moment. ISO 27001 surveillance audits check that controls keep operating, so dated records over time — showing TLS stayed valid and configuration held — are stronger evidence and reduce back-and-forth with the auditor.

Is this a replacement for an ISMS platform?

No. An ISMS or GRC platform manages the whole framework. A focused monitor produces the specific technical evidence for your external encryption and configuration controls, cheaply, and feeds it into whatever system you keep your evidence in.

ISO 27001 evidence for TLS, headers & DNS: what auditors actually ask for

Updated August 2026 · about a 6-minute read

ISO 27001 doesn't fail you for having an imperfect config on one day — it fails you for not being able to show that your controls operate. When an assessor picks your encryption-in-transit control, they want evidence it held across the period, not a reassurance that it's fine right now. For your public-facing endpoints, that means dated records of your TLS, security headers and DNS — the kind a one-off scan can't give you.

Where TLS and configuration live in Annex A

The 2022 revision of ISO 27001 Annex A trimmed the control list, but the relevant ones are clearly there:

Use of cryptography — data in transit protected with modern TLS (1.2+), valid certificates from a trusted CA, and a managed certificate lifecycle.
Secure configuration — services configured to a known-good baseline and kept there, which for a website means security headers like HSTS and a Content-Security-Policy staying in place.
Networks security & secure services — DNS integrity and email authentication (SPF, DMARC) as part of the perimeter.

None of these are exotic. What trips teams up is proving they were continuously true.

The evidence gap: "it's fine now" vs "it held all period"

ISO 27001 uses surveillance audits precisely because a control that worked at certification can quietly drift. The evidence an assessor values reflects that:

Weak evidence	Strong evidence
A scan screenshot from last week.	Dated records showing TLS valid and headers present every day of the period.
"We renew certificates when they expire."	An alert log showing expiries were flagged and acted on in advance.
A config file in a repo.	Proof the deployed site actually served that configuration over time.

What to monitor, and what it maps to

Watch the three external surfaces daily and keep the dated results:

TLS / certificates — validity, expiry, chain, protocol version → cryptography control.
Security headers — HSTS, CSP and the rest → secure-configuration control. See the headers guide.
DNS & email auth — SPF, DMARC, CAA → network and email security. See checking your DMARC record.

The same approach underpins SOC 2 — if you're pursuing both, see SSL monitoring as SOC 2 evidence. The controls differ; the evidence is the same dated, continuous record.

You don't need a full ISMS platform for this slice

An ISMS or GRC suite manages your entire framework and is priced for it. For the specific job of proving your external encryption and configuration controls held all period — and being alerted the moment one slips — a focused monitor is cheaper and faster to stand up. Perimeter's Compliance plan produces a dated, audit-ready report plus a hosted, read-only evidence page you can hand straight to your assessor.

See what your evidence would look like

Run your domain through the free checker — the same engine that produces the dated Compliance report. TLS, headers and DNS, graded in seconds. No signup.

See the Compliance plan → · dated report + hosted evidence page