Which SOC 2 criteria does domain security touch?

Domain-security checks map to the Common Criteria for logical and physical access. In our mapping the fifteen checks land on CC6.1 (encryption in transit), CC6.6 (boundary protection), CC6.7 (secure transmission of information), CC7.2 (monitoring and detection), and CC2.3 (communicating ownership). TLS covers CC6.1; DNS, DNSSEC, redirects, headers, and CORS cover CC6.6; SPF, DKIM, DMARC, and MTA-STS cover CC6.7; CT-log and TLS-RPT monitoring cover CC7.2.

Is a Domain Audit Report a SOC 2 report?

No. A SOC 2 report is issued by a licensed CPA firm after an audit of your controls. A Domain Audit Report is external evidence you bring to that audit — dated, signed proof of your domain-security posture that your auditor can map to the criteria. It supports the audit; it does not replace the auditor.

Do auditors accept a screenshot of a passing check?

Screenshots are weak evidence because they carry no verifiable date and can be edited. Auditors prefer a reproducible artifact — a signed report with an ISO-8601 timestamp, or a live check the auditor can re-run. The point of evidence is that a third party can confirm it without trusting your word.

How does this map to ISO 27001 and NIST?

The same checks carry their ISO 27001:2022 Annex A controls (A.8.20, A.8.21, A.8.23, A.8.24, A.5.14, A.5.20, A.8.9, A.8.16) and NIST 800-53 families (SC-8, SC-7, SC-20, AC-4, AU-6, SI-4) alongside the SOC 2 criteria, so one report answers questions across all three frameworks.

← blog

SOC 2 domain evidence: what auditors want for your DNS, email, and TLS controls

2026-08-03 · By Arshad Ansari · soc2 · compliance · evidence · tls · dnssec

soc2complianceevidencetlsdnssec

You are three weeks from a SOC 2 Type II observation window and your auditor has asked for evidence of your domain-security controls. You know your DNS and email are configured — but "we set it up correctly" is not evidence. This post explains, control by control, what a SOC 2 auditor is looking for from your domain, using the real Trust Services Criteria your domain checks actually map to.

Everything below reflects the mapping the free 15-check dossier already applies: every finding it produces carries the SOC 2 criterion it supports, so there is no manual cross-walk to invent. (Domain Posture is not a SOC 2 audit and does not replace a CPA firm — it produces the evidence you hand to one.)

The five criteria your domain touches

SOC 2's Common Criteria are broad, but domain security concentrates on five of them. Here is what each one means and which checks satisfy it:

| Criterion | What it covers | Checks that provide evidence | |-----------|----------------|------------------------------| | CC6.1 | Encryption of data in transit | TLS certificate | | CC6.6 | Protection of system boundaries | DNS records, DNSSEC, HTTP→HTTPS redirects, security headers, CORS, web surface | | CC6.7 | Secure transmission of information | MX, SPF, DKIM, DMARC, MTA-STS | | CC7.2 | Monitoring and anomaly detection | CT-log visibility, TLS-RPT reporting | | CC2.3 | Communicating ownership to external parties | WHOIS / RDAP registration |

Fifteen checks, five criteria. No criterion is invented and no check is orphaned — each of the fifteen sits under exactly the criterion it evidences.

Control by control: what the auditor accepts

An auditor is not satisfied by a control existing; they want to see it operating, on a date, in a form they can reproduce. Here is the per-check breakdown with the real control ids from all three frameworks.

CC6.1 — encryption in transit

The single check here is TLS. The auditor wants proof that your public endpoint serves a valid, trusted, unexpired certificate whose hostname matches. This maps to ISO 27001 A.8.24 (use of cryptography) and NIST SC-8(1). Evidence: the certificate's issuer, validity window, and chain — reproducible with a TLS certificate check the auditor can re-run.

CC6.6 — boundary protection

Six checks defend the boundary. DNS records and DNSSEC (ISO A.8.20, NIST SC-20) prove the zone resolves authoritatively and can't be cache-poisoned. HTTP-to-HTTPS redirects (ISO A.8.23, NIST SC-7) prove there is no plaintext fallback. Security headers — HSTS, CSP, X-Frame-Options (ISO A.8.23, NIST SC-7(8)) — harden the browser boundary. CORS (ISO A.8.23, NIST AC-4) proves cross-origin policy isn't wildcard-with-credentials. Web-surface inspection (ISO A.8.9, NIST CM-7) documents what the public files advertise. You can verify each independently: DNSSEC, redirects, and security headers.

CC6.7 — secure transmission

Five checks, all about email as a transmission channel. SPF (ISO A.8.20), DKIM (ISO A.8.24), and DMARC (ISO A.5.14) together prove mail claiming to be from your domain can be authenticated and unaligned mail rejected. MX (ISO A.8.21) documents the inbound topology. MTA-STS (ISO A.8.24) proves inbound SMTP can't be TLS-stripped. All map to NIST SC-8. The auditor wants the actual records — check SPF for the -all qualifier and check DMARC for the enforcing policy.

CC7.2 — monitoring and detection

Two checks show you can detect problems, not just prevent them. CT-log visibility (ISO A.8.16, NIST SI-4) proves certificates issued for your domain are observable — the basis for catching unauthorised issuance. TLS-RPT (ISO A.8.16, NIST AU-6) proves you receive reports when inbound SMTP TLS fails. Together they are your domain-level detective controls.

CC2.3 — ownership

WHOIS/RDAP (ISO A.5.20, NIST PE-2) proves the domain is registered, in active status, and not about to lapse — the ownership and business-continuity evidence auditors expect under CC2.3.

Why a signed report is stronger evidence than a spreadsheet

An auditor's core question about any piece of evidence is: can I trust that this was true on the date claimed? A screenshot fails that test — no verifiable timestamp, trivially editable. A spreadsheet of pasted DNS records fails it too. What passes is an artifact a third party can independently verify.

That is what the $29 Domain Audit Report produces: the same 15 checks, rendered as a PDF plus JSON sidecar, Ed25519-signed and ISO-8601 timestamped, with each finding already carrying its SOC 2 / ISO 27001 / NIST control. Your auditor verifies the signature against a published public key and reads the mapping without a cross-walk. A check that can't complete is flagged inconclusive, not silently passed — so there are no gaps for the audit to surface later.

The report is delivered in 10–30 minutes and carries a signed-or-refunded guarantee: if it doesn't verify against the public key, or your auditor doesn't accept it, you reply within 30 days for a full refund and keep the report. For a team without a GRC function, it replaces $500+ of consultant time spent assembling the same evidence by hand.

Bring evidence, not assertions

The domain-security portion of a SOC 2 audit is one of the few areas where the evidence is fully observable from outside — which means an auditor can, and will, check your claims. Answer with dated, signed proof mapped to the criteria and this section closes cleanly. For the full per-control table rendered from the same mapping, see the SOC 2 evidence page; for the parallel Annex A view, see ISO 27001 evidence.

Run the free 15-check dossier on your domain →

Then attach the signed Domain Audit Report — $29, in your inbox in 10–30 minutes, signed or refunded.

Frequently asked questions

Which SOC 2 criteria does domain security touch?: Domain-security checks map to the Common Criteria for logical and physical access. In our mapping the fifteen checks land on CC6.1 (encryption in transit), CC6.6 (boundary protection), CC6.7 (secure transmission of information), CC7.2 (monitoring and detection), and CC2.3 (communicating ownership). TLS covers CC6.1; DNS, DNSSEC, redirects, headers, and CORS cover CC6.6; SPF, DKIM, DMARC, and MTA-STS cover CC6.7; CT-log and TLS-RPT monitoring cover CC7.2.
Is a Domain Audit Report a SOC 2 report?: No. A SOC 2 report is issued by a licensed CPA firm after an audit of your controls. A Domain Audit Report is external evidence you bring to that audit — dated, signed proof of your domain-security posture that your auditor can map to the criteria. It supports the audit; it does not replace the auditor.
Do auditors accept a screenshot of a passing check?: Screenshots are weak evidence because they carry no verifiable date and can be edited. Auditors prefer a reproducible artifact — a signed report with an ISO-8601 timestamp, or a live check the auditor can re-run. The point of evidence is that a third party can confirm it without trusting your word.
How does this map to ISO 27001 and NIST?: The same checks carry their ISO 27001:2022 Annex A controls (A.8.20, A.8.21, A.8.23, A.8.24, A.5.14, A.5.20, A.8.9, A.8.16) and NIST 800-53 families (SC-8, SC-7, SC-20, AC-4, AU-6, SI-4) alongside the SOC 2 criteria, so one report answers questions across all three frameworks.