SOC 2 (System and Organization Controls 2) is the most common compliance framework for SaaS companies and technology service providers. If your customers ask “are you SOC 2 compliant?” — and they will — your cryptographic controls are a significant part of the audit.
Cryptography appears primarily under CC6 (Logical and Physical Access Controls) and CC7 (System Operations), but touches nearly every Trust Services Criteria. Auditors examine: how you encrypt data, how you manage keys, how you handle certificates, and whether you can prove it all with evidence.
Here’s what they actually test and how to pass without findings.
Where Cryptography Appears in SOC 2
CC6: Logical and Physical Access Controls
CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets.
Crypto relevance: TLS for data in transit, encryption at rest, certificate-based authentication, key-based access (SSH keys).
CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
Crypto relevance: TLS on all external-facing services, VPN encryption, API authentication with certificates or tokens.
CC6.7: The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes.
Crypto relevance: Encryption of data in transit (TLS), encrypted email for sensitive data, encrypted file transfers.
CC7: System Operations
CC7.1: To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities.
Crypto relevance: Certificate expiry monitoring, weak cipher detection, configuration drift monitoring.
CC7.2: The entity monitors system components and the operation of those components for anomalies.
Crypto relevance: Certificate anomaly detection, unusual key usage patterns, unauthorized certificate issuance.
Additional Criteria (if applicable)
Confidentiality (C1.1-C1.2): Encryption of confidential information at rest and in transit.
Privacy (P4.1-P4.3): Encryption of personal information, key management for privacy data.
What Auditors Actually Test
Test 1: Encryption in Transit
What they check:
- All external-facing services use TLS 1.2+
- No weak cipher suites enabled
- Certificates are valid (not expired, correct hostname)
- Internal services handling sensitive data also use TLS
Evidence to provide:
□ TLS configuration documentation (Nginx/Apache/LB configs)
□ SSL Labs scan results (or equivalent) showing A/A+ rating
□ List of all external endpoints with TLS version and cipher suites
□ Policy stating TLS 1.2 minimum requirement
□ Evidence that TLS 1.0/1.1 is disabled (scan results)Test 2: Encryption at Rest
What they check:
- Databases containing sensitive data are encrypted
- File storage is encrypted
- Backups are encrypted
- Laptop/endpoint encryption is enforced
Evidence to provide:
□ Database encryption configuration (TDE settings, column encryption)
□ Cloud storage encryption settings (S3 SSE, Azure encryption)
□ Backup encryption configuration
□ MDM report showing FDE status on all endpoints
□ Key management documentation (where keys are stored, who has access)Test 3: Key Management
What they check:
- Keys are stored securely (not in plaintext config files)
- Key access is restricted to authorized personnel/systems
- Keys are rotated on a defined schedule
- Key destruction procedures exist
Evidence to provide:
□ Key management policy document
□ KMS/HSM configuration showing key storage
□ Access control lists for key management systems
□ Evidence of key rotation (rotation logs, KMS auto-rotation enabled)
□ Key destruction procedure documentation
□ Audit logs showing key access eventsTest 4: Certificate Management
What they check:
- Certificates are tracked (inventory exists)
- Certificates are monitored for expiry
- Certificate renewal is timely (no expired certs in production)
- Certificate-related incidents are handled
Evidence to provide:
□ Certificate inventory (all certs with owner, expiry, location)
□ Monitoring dashboard showing certificate health
□ Alert configuration (expiry warnings at 60/30/7 days)
□ Evidence of successful renewals (cert-manager logs, ACME logs)
□ Incident records for any certificate-related issues
□ Procedure for emergency certificate replacementTest 5: Access Control with Cryptographic Credentials
What they check:
- SSH keys are managed (inventory, rotation, offboarding)
- API keys/tokens have defined lifetimes
- Service accounts use appropriate authentication
- MFA is enforced (may include certificate-based MFA)
Evidence to provide:
□ SSH key inventory and management procedure
□ API key rotation policy and evidence of rotation
□ Service account credential management documentation
□ MFA enforcement evidence (IdP configuration)
□ Offboarding procedure including credential revocationCommon SOC 2 Findings (Cryptography-Related)
Finding 1: “No formal key management policy”
What happened: The organization uses encryption (AES-256, TLS) but has no written policy documenting how keys are generated, stored, rotated, and destroyed.
How to fix:
# Key Management Policy (minimum viable for SOC 2)
## Key Generation
- Symmetric keys: AES-256, generated via KMS (AWS KMS / Azure Key Vault)
- TLS keys: ECDSA P-256, generated by cert-manager or ACME client
- SSH keys: Ed25519, generated on user's device
## Key Storage
- Encryption keys: AWS KMS (non-extractable, FIPS 140-2 Level 2)
- TLS private keys: Kubernetes Secrets (encrypted at rest via etcd encryption)
- SSH keys: User devices (passphrase-protected)
## Key Rotation
- Encryption keys: Annual (KMS auto-rotation)
- TLS certificates: 90 days (ACME auto-renewal)
- SSH keys: Annual (enforced via policy)
## Key Destruction
- When no longer needed: KMS scheduled deletion (7-day waiting period)
- Offboarding: All user keys removed within 24 hours of termination
## Access Control
- KMS admin: Security team only (2 people)
- Key usage: Application IAM roles (least privilege)
- Audit: All key operations logged to CloudTrail/SIEMFinding 2: “Certificates expired in production”
What happened: A certificate expired causing a service outage. The auditor found no monitoring was in place.
How to fix:
- Deploy certificate monitoring (Prometheus + blackbox_exporter, or CLM platform)
- Alert at 60, 30, 14, 7 days before expiry
- Automate renewal (cert-manager, ACME)
- Document the monitoring setup and alert escalation path
Finding 3: “SSH keys not rotated or inventoried”
What happened: Auditor asked for SSH key inventory. Organization couldn’t produce one. Keys from former employees still active.
How to fix:
- Scan all servers for authorized_keys entries
- Map keys to current employees
- Remove keys for departed employees immediately
- Establish annual rotation schedule
- Consider SSH certificates (automatic expiry)
Finding 4: “Weak TLS configuration”
What happened: External scan found TLS 1.0 enabled on a legacy service, or CBC cipher suites still active.
How to fix:
- Disable TLS 1.0/1.1 on all services
- Remove CBC cipher suites (use AEAD only: GCM, ChaCha20)
- Run quarterly external scans to catch regressions
- Document approved cipher suite list
SOC 2 Readiness Checklist (Cryptography)
Policies and Procedures
- Written cryptography/encryption policy
- Key management procedures (generation, storage, rotation, destruction)
- Certificate management procedures
- SSH key management policy
- Incident response procedure for key/certificate compromise
Technical Controls
- TLS 1.2+ on all external services (verified by scan)
- No weak cipher suites (verified by scan)
- Database encryption enabled (TDE or column-level)
- Cloud storage encryption enabled (SSE/CMEK)
- Full disk encryption on all endpoints (MDM-verified)
- Backup encryption enabled
- KMS/HSM for key storage (not plaintext files)
- Automated certificate renewal (ACME/cert-manager)
- Certificate expiry monitoring with alerts
Evidence and Audit Trail
- Certificate inventory (current, with owners)
- Key rotation evidence (KMS logs, cert renewal logs)
- Access control evidence (who can access keys/certs)
- Monitoring dashboard screenshots
- Alert history (showing alerts were triggered and resolved)
- Incident records (any crypto-related incidents and resolution)
- Offboarding evidence (keys removed for departed employees)
Ongoing Operations
- Quarterly TLS scan (external)
- Monthly certificate inventory review
- Annual key rotation verification
- Annual policy review and update
- Employee offboarding includes credential revocation
Type I vs Type II: What Changes for Crypto
SOC 2 Type I: Point-in-time assessment. Auditor checks: “Do these controls exist today?”
- Evidence: Current configurations, current policies, current inventory
SOC 2 Type II: Period assessment (typically 6-12 months). Auditor checks: “Did these controls operate effectively over the period?”
- Evidence: Logs showing controls worked consistently, alert history, rotation evidence over time, no gaps in monitoring
For Type II, you need continuous evidence — not just “we have monitoring” but “here are 12 months of monitoring data showing no certificate expired without warning.”
FAQ
Q: Does SOC 2 require specific encryption algorithms? A: No. SOC 2 doesn’t prescribe algorithms. It requires “appropriate” encryption based on risk. In practice, auditors expect industry-standard algorithms (AES-256, TLS 1.2+, SHA-256+). Using deprecated algorithms (DES, MD5, TLS 1.0) would be a finding.
Q: Do we need an HSM for SOC 2? A: Not required. SOC 2 requires keys to be “appropriately protected.” Cloud KMS (AWS KMS, Azure Key Vault) satisfies this for most organizations. HSMs are needed for specific compliance requirements (PCI PIN, WebTrust) but not SOC 2 specifically.
Q: How detailed does the certificate inventory need to be? A: Auditors expect: hostname/subject, issuer, expiry date, owner, and renewal method for each certificate. They don’t need every technical detail — but they need enough to verify certificates are tracked and managed.
Q: What if we had a certificate outage during the audit period? A: Document it as an incident. Show: what happened, when it was detected, how it was resolved, and what you changed to prevent recurrence. A single incident isn’t necessarily a finding — but a pattern of incidents (or no response procedure) is.
Q: Is automated certificate renewal sufficient evidence of “key rotation”? A: Yes — if your ACME/cert-manager generates new key pairs at each renewal (which is the default). Each renewal with a new key pair IS key rotation. Document this: “TLS keys are rotated every 90 days via automated certificate renewal (new key pair generated at each renewal).”