SOC 2 auditors don’t care what SSL is – they care whether you can prove your certificate management is a controlled, monitored process rather than something that happens whenever someone remembers. That distinction trips up more companies during Type II audits than almost any other technical control, because the certificate itself was never the problem; the missing evidence trail was.
What SOC 2 actually requires around SSL/TLS
SOC 2 doesn’t name SSL certificates anywhere in the Trust Services Criteria. What it names is CC6.1 and CC6.7 – logical access controls and controls over data transmission. Encryption in transit falls under those, and TLS is how you satisfy it. Auditors mapping to CC6.1 will ask three things: is data encrypted in transit, is that encryption configured correctly, and is there a documented process ensuring it stays that way.
That third point is where companies get caught. A Type I audit checks whether the control existed at a point in time. A Type II audit, which is what most enterprise customers actually demand, checks whether it operated effectively over the full review period – typically 6 to 12 months. If your certificate expired for four hours in March because nobody was watching, that’s a control failure during the audit window, even if it’s fixed by the time the auditor shows up in October.
The certificate expiration control gap auditors flag most
The most common finding in SOC 2 readiness assessments involving TLS isn’t a weak cipher suite. It’s evidence of monitoring. Auditors from firms like A-LIGN, Prescient Assurance, or Johanson Group will ask for logs or reports showing certificate status was checked continuously, not just “we renew every year in Q1.” If your only answer is “our ops lead gets a calendar reminder,” that’s a manual control with no independent verification – auditors flag it as a design deficiency even if it happened to work.
A real scenario: a SaaS company going through their first Type II audit in 2024 had auto-renewal configured through Let’s Encrypt via a cron job. It worked for eight months. In month nine, a DNS change broke the ACME HTTP-01 challenge silently, renewal failed, and the cert expired on a Saturday. Nobody caught it until a customer’s integration started throwing SSL errors Monday morning. The auditor’s finding wasn’t about the outage – it was that there was no monitoring layer independent of the renewal mechanism itself, so a single point of failure could run undetected for 48 hours.
Building an auditable certificate monitoring process
An auditor wants to see three artifacts: a policy, evidence of continuous monitoring, and a record of remediation when something went wrong. Here’s what that looks like in practice.
First, document the policy itself – which certificate authority you use, validity periods, who owns renewal, and what the escalation path is when a check fails. This doesn’t need to be long. Two pages naming the CA (DigiCert, Let’s Encrypt, Sectigo, whatever applies), the renewal window, and the responsible role is enough for most Type II reviews.
Second, put continuous monitoring in place with alerting thresholds that give you room to act – 30, 14, 7, and 1 day before expiration is a reasonable cadence, since a single 30-day warning gets buried in inboxes but a tiered sequence forces action. Continuous monitoring beats periodic manual checks specifically because auditors can pull a timestamped log showing the control ran every day of the review period, not just when someone remembered to check.
Third, keep records. Monthly reports with a letter grade (A+ through F) covering certificate chain validity, HSTS configuration, and protocol support give you a dated artifact for every month of the audit window. When the auditor asks “show me evidence this control operated in June,” you hand them June’s report instead of reconstructing history from memory.
Common mistakes that show up in audit findings
Three patterns repeat across readiness assessments. Companies rely on browser warnings as their detection mechanism – by the time Chrome shows “Your connection is not private,” customers have already hit the error, which means the control failed before detection, not after. Teams also monitor only production and skip staging or internal admin panels, then get flagged because CC6.1 applies to any system transmitting sensitive data, not just the public-facing site. And plenty of teams renew certificates manually but never verify the full chain deployed correctly afterward – a missing intermediate certificate breaks older clients silently while curl and modern Chrome show nothing wrong, which is a real gap worth understanding through how intermediate certificates and chains actually work.
Myth: SOC 2 requires EV certificates or a specific certificate type
A persistent misconception is that SOC 2 mandates Extended Validation certificates or a particular CA to pass. It doesn’t. The criteria are outcome-based – encryption in transit, controlled access, monitored operation. A Domain Validated certificate from Let’s Encrypt satisfies CC6.1 exactly as well as an EV certificate from DigiCert, provided the process around it is documented and monitored. Auditors care about TLS 1.2 or 1.3 being enforced, weak ciphers disabled, and the renewal process being demonstrably reliable – not the validation tier printed on the cert.
FAQ
Does SOC 2 require a minimum TLS version?
SOC 2 itself doesn’t specify TLS 1.2 or 1.3 by name, but auditors will flag TLS 1.0 and 1.1 as deficient since both were deprecated by major browsers in 2020 and PCI DSS already bans them. In practice, enforcing TLS 1.2 minimum, with 1.3 preferred, is what passes review without discussion.
Can a single expired certificate fail a SOC 2 Type II audit?
Rarely on its own. Auditors look for a pattern and a root cause. One incident with documented detection, response time, and a fix to prevent recurrence usually gets noted as an exception rather than a failed control. Repeated expirations, or an incident with no monitoring evidence at all, is what turns into a qualified opinion.
Do subdomains and internal tools need the same certificate monitoring as the main site?
Yes, if they transmit in-scope data. A staging environment handling customer data or an internal admin tool touching production databases falls under the same CC6.1 scope as the public site. Auditors specifically ask for the full asset inventory, so building a complete certificate inventory before the audit starts saves a lot of scrambling when the sampling request comes in.
Getting through a SOC 2 review on the TLS control isn’t about buying a fancier certificate – it’s about having dated, continuous evidence that someone was watching the whole time. Start building that evidence trail months before the audit, not the week the auditor sends the sampling request.