SOC 2 evidence: how to prove SSL is monitored

For any organization building trust with its customers, a SOC 2 report is a critical differentiator. It's an independent auditor's report on how your systems handle customer data based on the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy). You, as an engineer, are likely on the front lines, responsible for implementing and maintaining the controls that satisfy these criteria.

One area that auditors consistently scrutinize is SSL/TLS certificate management. Expired or misconfigured certificates aren't just a minor technical glitch; they can lead to service downtime, security vulnerabilities, and a complete breakdown of trust. Proving that you have robust, continuous, and auditable SSL/TLS monitoring in place is non-negotiable for a successful SOC 2 audit.

This article will walk you through what auditors look for, how to gather the necessary evidence, and common pitfalls to avoid.

Why SOC 2 Cares About SSL/TLS Monitoring

Expired SSL/TLS certificates have severe implications that directly violate SOC 2 principles:

  • Security (CC3.2, CC6.1, CC7.1, CC7.2): An expired certificate immediately breaks the secure communication channel, making your service vulnerable to man-in-the-middle attacks, eavesdropping, and data interception. It signals a failure in your security controls.
  • Availability (A1.2): When a critical certificate expires, services often become inaccessible, leading to downtime and a direct breach of availability commitments. Users can't access your service, and internal systems might fail to communicate securely.
  • Processing Integrity (PI1.2): If data is transmitted over an unsecured channel due to an expired certificate, its integrity cannot be guaranteed. This can lead to corrupted or tampered data, affecting the reliability of your processing.
  • Confidentiality (C1.2): Similar to security, an expired cert compromises the confidentiality of data in transit. Sensitive customer information could be exposed.

Auditors aren't looking for perfection, but they are looking for controls that prevent these failures and ensure a swift, documented response when issues arise.

What Does "Monitoring" Mean for SOC 2?

For SOC 2 purposes, "monitoring" isn't just about occasionally checking a few certificates. It implies a systematic, continuous, and auditable process. You need to demonstrate:

  • Completeness: You know about all your certificates, not just the obvious ones.
  • Timeliness: You're alerted well in advance of expiry, not just when a certificate is days away from failing.
  • Actionability: Alerts go to the right people, and there's a clear process for addressing them.
  • Evidence: There's a verifiable trail of monitoring activity, alerts, and subsequent actions.

The goal is to prove that certificate expiry is not a "surprise" event but a managed risk with clear mitigation strategies.

Essential Components of a Robust SSL Monitoring Strategy

To meet SOC 2 requirements, your SSL/TLS monitoring strategy needs several key pillars:

  1. Comprehensive Certificate Discovery & Inventory: You can't monitor what you don't know exists. This involves identifying all certificates across your infrastructure: public-facing web servers, internal APIs, load balancers, CDNs, databases, message queues, and even developer tools.
  2. Continuous Monitoring: Automated checks for certificate expiry, revocation status, key algorithm strength, and potential misconfigurations. This needs to happen regularly, not just once a month.
  3. Proactive Alerting: Timely notifications (email, Slack, PagerDuty, etc.) to the relevant teams (Ops, SRE, Security) with sufficient lead time before expiry.
  4. Defined Incident Response: Documented procedures for certificate renewal, including who is responsible, escalation paths, and target remediation times.
  5. Audit Trail & Reporting: A record of all monitoring activities, alerts sent, and actions taken, which can be presented to an auditor.

Gathering Evidence for Your Auditor

When the auditor comes knocking, they'll want to see proof, not just hear promises. Here's what you'll need:

1. Certificate Inventory List

A comprehensive, up-to-date list of all your certificates. This should include: * Common Name (CN) * Issuer * Expiry Date * Location/Service (e.g., AWS ALB, Nginx server web-01, internal API gateway) * Owner/Responsible Team * Renewal Process (e.g., automated ACME, manual upload, cloud-managed)

How to get it: * Manual spreadsheets: Fragile and prone to human error, especially at scale. Auditors will question its accuracy. * Custom scripts: You might have a script that scans your infrastructure. For external-facing certificates, a simple openssl command can fetch basic details:

```bash
# Get expiry date for an external web server
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | \
openssl x509 -noout -dates
```
This command connects to `example.com` on port `443`, extracts the certificate, and then prints its `notBefore` and `notAfter` dates. While useful for a quick check, this is a one-off for a single cert. Doing this at scale across hundreds or thousands of services is a non-starter for auditable evidence without significant custom tooling around it.
  • Cloud provider inventories: AWS Certificate Manager (ACM), Azure Key Vault, Google Cloud Certificate Manager can provide lists for certificates managed within those services. However, they won't cover on-prem, other cloud providers, or services outside their direct management.
  • Specialized monitoring tools: These tools are designed to discover and centralize all your certificates, regardless of location.

2. Monitoring Configuration and Output

You need to show how you're monitoring. This means: * Screenshots of your monitoring system's configuration, showing the checks for certificate expiry. * Configuration files for any custom scripts or agents. * A demonstration of the monitoring in action, perhaps showing a dashboard with certificate statuses.

Example (and why it's often insufficient for SOC 2): Many engineers start with simple cron jobs and check_ssl_cert scripts.

# In /etc/cron.d/cert_monitor
0 3 * * * root /usr/local/bin/check_ssl_expiry.sh >> /var/log/cert_expiry_checks.log 2>&1

And check_ssl_expiry.sh might contain:

#!/bin/bash
CERT_PATH="/etc/nginx/ssl/my-app.crt"
ALERT_DAYS=30

EXPIRY_DATE=$(openssl x509 -in $CERT_PATH -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $CURRENT_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt "$ALERT_DAYS" ]; then
    echo "ALERT: Certificate $CERT_PATH expires in $DAYS_LEFT days!"
    # Add logic here to send email/Slack alert
    # mail -s "Cert Expiry Alert" security@example.com <<< "..."
fi

While this script checks a certificate and could send an alert, for SOC 2, you'd need to provide: * Proof that this script runs reliably (cron logs, systemd timer logs). * Evidence that the alerts are actually sent and received (email logs, Slack archives). * Proof that all relevant certificates are covered by such scripts. * A clear understanding of who maintains these scripts, how they're version controlled, and how changes are audited. * A centralized view of all these disparate scripts and their statuses – which is where custom solutions often fall short for auditors.

3. Alerting Logs and Incident Response

Auditors want to see that alerts are generated and acted upon. * Alert History: Logs from your alerting system (e.g., PagerDuty, Opsgenie, Slack, email) showing when a certificate expiry alert was triggered, who it was sent to, and when it was acknowledged or resolved. * Incident Tickets: If you use an ITSM like Jira Service Management or ServiceNow, show tickets created in response to expiry alerts, demonstrating the workflow from alert to resolution. * Runbooks/Procedures: Documented procedures for renewing certificates. Who is responsible? What are the steps? What's the escalation path if a cert is about