SOC 2 and TLS: What Auditors Actually Check
A SOC 2 audit is not like going to the dentist. The dentist has a known procedure. They clean your teeth, count them, look for cavities, and send you home with a small toothbrush. The visit fits in a slot.
A SOC 2 audit is more like going to a thoughtful doctor for an annual physical. They have a checklist, but they also have judgment. They look at how you walk in. They ask questions you weren't expecting. They follow up on whatever surprised them in the first ten minutes. Two patients with the same chart can leave with very different conversations.
That's the practical difference between PCI-DSS and SOC 2. PCI tells you exactly what to do. SOC 2 tells you what to demonstrate, and the auditor decides what counts.
For TLS specifically, this matters. PCI gives you a prescriptive list of requirements (4.2.1, 4.2.1.1, and so on). SOC 2 gives you principles - "information is protected during transmission" - and then asks what you do to live up to that principle, and whether they believe you.
Here's what auditors actually ask about TLS, what they're looking for, and what you need to be able to show.
SOC 2 vs PCI - principles vs prescription
PCI-DSS is a checklist with numbers next to each item. You either have it or you don't.
SOC 2 is built around the AICPA's Trust Services Criteria - Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most companies in scope are audited against Security and Confidentiality. The criteria are principles, not rules. "Logical and physical access controls protect the system from unauthorised access" is the kind of language you see.
This means two things in practice.
One: the bar is set by the auditor's judgment of what's reasonable. A well-run small SaaS and a well-run enterprise will both pass, but with different evidence and different controls. There is no single right answer.
Two: documentation matters more than for PCI. The auditor has to be convinced. The way you convince them is by showing your work - your processes, your evidence, your monitoring, your incident history.
For TLS, this means you can't get away with "we use HTTPS." You need to show how you decided what "strong" means, how you enforce it, and how you'd know if something drifted.
The Trust Services Criteria that matter for TLS
Three TSC sections come up most often around certificates.
CC6.7 - Transmission of confidential information. Plain text: information in transit is encrypted, and the encryption is appropriate.
Auditors will ask: - What encryption do you use for traffic carrying customer data? - How do you verify it's actually being used? - Do you support TLS 1.2 minimum, ideally 1.3? - How would you know if a service started accepting a weaker cipher?
CC6.1 - Logical access security. Includes access to systems that issue and manage certificates.
Auditors will ask: - Who can issue a cert on behalf of your organisation? - Who can change TLS configuration on production systems? - Are these privileges reviewed periodically? - What happens when an employee leaves?
CC7.1 - System monitoring for vulnerabilities and security events. Includes monitoring of cert-relevant systems.
Auditors will ask: - How do you monitor for cert expiry? - How do you monitor for cert misissuance? - How do you detect TLS configuration drift? - What's your response process when monitoring detects an issue?
There are other criteria that touch TLS (CC2 for communications, CC4 for monitoring of controls, A1 for availability), but these three are where the cert-specific evidence lands.
What auditors actually ask
A SOC 2 auditor's questions tend to follow a pattern.
First, the process question: "walk me through how you handle TLS certificate renewals."
If your answer is "Bob handles it," they will ask "and what happens when Bob is on holiday?" If your answer is "we have automation," they will ask "how do you know the automation is working?"
Second, the evidence question: "show me an example of a renewal in the last quarter."
You should be able to produce: the renewal event, who approved or triggered it, when the new cert went into production, and confirmation that the old cert was retired.
Third, the drift question: "how would you know if a system started accepting TLS 1.0?"
The answer they're looking for involves continuous monitoring, scan reports, and a documented response process. The answer they don't want to hear is "we'd find out when something broke."
Fourth, the incident question: "tell me about a cert-related issue in the last twelve months and what you did about it."
Saying "we haven't had any" is fine, but they will probe - is that because you don't have any, or because you don't notice them?
What you need to be able to show
For a SOC 2 audit covering TLS, four artifacts go a long way.
A current cert inventory, generated by automation. Same as PCI - but here, the auditor isn't checking it against a prescriptive requirement. They're checking that you have a process that produces it.
TLS configuration evidence, ideally from periodic scans. Reports that show you're enforcing TLS 1.2+, with documented exceptions (and remediation timelines) for any that don't.
Renewal evidence, showing a recent example end-to-end. Not just "the script ran" - but the ticket, the approval, the deployment, the verification.
An incident or two, handled cleanly. The auditor wants to see that when something goes wrong (and something always does), you have a process. A small incident, well-documented, is more valuable than zero incidents claimed.
The reason SOC 2 is easier than PCI in one sense: there's no specific list of ciphers you must reject. The reason it's harder: you have to convince the auditor that what you do is reasonable, and "we just use HTTPS" is not reasonable.
One small ask
A SOC 2 audit isn't trying to catch you out. It's trying to confirm that you have systems, not heroics. The TLS portion is mostly about three things: knowing what you have, knowing what configuration is in production, and being able to respond when something changes. TLS Radar gives you the inventory and the continuous monitoring; the response process is yours to design. Free tier covers three domains, which is enough to see whether your current setup would survive a question or two.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.