Does SOC 2 require encryption?

SOC 2 does not prescribe specific technical controls — it evaluates whether your controls are sufficient given the risks you face. In practice, failing to encrypt customer data at rest and in transit will produce findings in almost every SOC 2 audit. CC6.1 (logical access) and CC6.7 (restricted transmission) are the primary criteria where encryption evidence is requested.

What encryption algorithm does SOC 2 require?

SOC 2 does not specify algorithms by name. Auditors reference NIST guidance — SP 800-111 for storage encryption and SP 800-52 for TLS — as the recognized standards for 'appropriate' encryption. In practice, AES-128 or AES-256 at rest and TLS 1.2+ in transit are what auditors expect to see. Using MD5, SHA-1 hashes for passwords, or TLS 1.0/1.1 will result in a finding.

What is CC6.7 in SOC 2?

CC6.7 is the Trust Services Criterion requiring that the entity restricts the transmission of confidential information to authorized users and protects it during transmission. This is the primary criterion for in-transit encryption. Auditors will request SSL Labs reports showing TLS configuration for public endpoints and evidence of TLS on internal service communication.

Does SOC 2 require TLS 1.3?

No — TLS 1.2 is sufficient for SOC 2 compliance when configured with strong cipher suites. TLS 1.3 is preferred and demonstrates stronger security posture, but TLS 1.2 with AEAD cipher suites and ECDHE key exchange satisfies CC6.7 requirements. TLS 1.0 and 1.1 will result in a finding.

What evidence does a SOC 2 auditor check for encryption?

Auditors typically request: SSL Labs reports (A rating minimum for public endpoints), database encryption screenshots showing at-rest encryption enabled, cloud storage bucket encryption settings, KMS key rotation logs (not just a policy — actual rotation event logs), and password hashing algorithm confirmation. Type II audits require this evidence to cover the entire audit period, not just a single point in time.

Is AWS KMS sufficient for SOC 2 compliance?

Yes. AWS KMS, GCP Cloud KMS, and Azure Key Vault are all accepted for standard SOC 2 compliance. They provide FIPS 140-2 Level 2 validated HSM-backed key management, access logging, and key rotation. A dedicated FIPS 140-3 Level 3 HSM is not required for SOC 2 — it becomes necessary for PCI DSS Level 1 PIN encryption, FedRAMP High, and similar high-assurance frameworks.

SOC 2 Encryption Controls: What Auditors Actually Check

Introduction

The most common SOC 2 finding is not a missing policy. It is an unencrypted S3 bucket from a developer sprint three years ago that nobody noticed was holding customer data. Understanding encryption at rest vs in transit helps prevent these gaps.

SOC 2 encryption requirements are not about having the right documents. They are about evidence that your encryption controls are actually working — and have been working throughout the audit period. A SOC 2 Type II audit covers 6 to 12 months of operational history. A beautiful encryption policy written the week before the audit window closes helps no one.

SOC 2 (Service Organization Control 2) is an attestation standard from the American Institute of CPAs (AICPA). An independent CPA firm reviews your controls against the Trust Services Criteria (TSC) and produces a report. It is not a certification — it is an attestation. The two criteria most relevant to encryption are CC6.1 (logical access and data protection controls) and CC6.7 (restricted and protected transmission of confidential information), as defined in the AICPA Trust Services Criteria 2017 document with 2022 updates.

This article maps each TSC criterion to the exact encryption evidence an auditor will request. It distinguishes the nice-to-have posture improvements from the must-have controls that, if missing, will produce a finding. Understanding this distinction before your audit period begins is what allows you to address gaps with enough operational history to demonstrate ongoing effectiveness.

What Is SOC 2?

SOC 2 is an attestation framework for service organizations — SaaS companies, data processors, cloud providers — that store or process customer data. It was developed by the AICPA as part of the Trust Services Criteria framework.

Key distinctions:

Attestation, not certification: A CPA firm attests that your controls are designed and operating effectively. There is no pass/fail certification body.
Type I: Point-in-time assessment of control design. Faster to obtain; shows controls are in place but not that they have worked over time.
Type II: Period-of-time assessment (typically 6–12 months) of control operating effectiveness. The industry standard for enterprise sales cycles and procurement requirements.
Five Trust Services Categories: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations seek Security + one or two others.

What Is CC6.1 and CC6.7?

CC6.1 — Logical and Physical Access

CC6.1 requires that the entity uses logical access security software, infrastructure, and architectures over protected information assets. Under the AICPA TSC 2017 (with 2022 updates), this criterion includes points of focus specifically addressing encryption as a compensating control for access: even if someone gains unauthorized access to the database server, they cannot read the data without the encryption key.

What this criterion covers for encryption:

Database encryption at rest
Disk/volume encryption for servers and workstations
Encryption of backups
Access controls on encryption keys (KMS IAM policies)

CC6.7 — Restricted Transmission

CC6.7 requires that the entity restricts the transmission of confidential information to authorized internal and external users and protects it during transmission. This is the primary home for in-transit encryption under the TSC framework. For federal systems, similar requirements are mapped in FISMA compliance and NIST SP 800-53.

What this criterion covers:

TLS configuration on public-facing endpoints
TLS for internal service-to-service communication
API gateway configuration
Email transport encryption

How SOC 2 Encryption Audits Work

The Evidence Request List

When your auditor prepares the evidence request list for encryption, expect requests in these categories:

At-rest encryption:

Database encryption screenshots — AWS RDS, GCP Cloud SQL, or Azure SQL showing encryption-at-rest enabled.
S3 bucket encryption settings showing server-side encryption (SSE-S3 or SSE-KMS) enabled on all buckets containing customer data.
EBS/disk volume encryption confirmation for EC2 instances.
Backup encryption settings and a tested restoration log.
KMS key policy showing access restricted to authorized roles.

In-transit encryption: 6. SSL Labs report (ssllabs.com) showing an A or A+ rating for all public-facing endpoints. 7. TLS version confirmation showing TLS 1.2 minimum and TLS 1.0/1.1 disabled. 8. Internal service communication certificates — mTLS configuration, service mesh certificate authority.

Key management: 9. KMS or HSM usage confirmation — who can create, access, and delete keys. 10. Key rotation policy document and, critically, the actual rotation event logs proving rotation occurred during the audit period. 11. Separation of duties documentation — who can create/delete keys versus who can use keys for encryption.

Password and credential management: 12. Password hashing algorithm confirmation — Argon2id or bcrypt. Not just a policy — the auditor may request a code reference or security scan result. 13. Secrets manager configuration confirming no plaintext credentials in environment variables, config files, or source repositories.

Must-Have vs Nice-to-Have

Must-Have (missing these produces findings):

TLS 1.2+ with A-rated SSL Labs report on public endpoints
Encryption at rest for databases and cloud storage containing customer data
Encrypted backups
Key rotation documentation with actual rotation event evidence
Password hashing with Argon2id or bcrypt (not MD5 or SHA-1)

Nice-to-Have (improve posture but rarely cause findings):

FIPS 140-3 Level 3 dedicated HSM (cloud KMS at Level 2 suffices)
TLS 1.3 exclusively (TLS 1.2 with hardened cipher suites is acceptable)
Certificate pinning for mobile applications
Perfect Forward Secrecy documentation (implied by ECDHE cipher suites)

This video explains the Trust Services Criteria that SOC 2 audits are built on. The sections above map the specific CC6.1 and CC6.7 criteria to the exact encryption evidence your auditor will request.

SOC 2 Audit Readiness Checklist

Use this checklist before your audit window opens. Type II audits require evidence spanning the entire period — controls enabled on the day the auditor arrives are insufficient.

CC6.1 — At-Rest Encryption Evidence

AWS RDS / GCP Cloud SQL / Azure SQL: confirm encryption-at-rest is enabled (screenshot with date)
S3 / GCS / Azure Blob: all buckets containing customer data have SSE enabled; verify no public buckets
EBS volumes / Persistent Disks: encryption enabled for all instances handling customer data
Database backups: encryption confirmed with tested restore log (not just an enabled flag)
KMS key policies: document which roles can create, rotate, and use each key
AWS Config rule or equivalent: automated check that no unencrypted storage exists

CC6.7 — In-Transit Encryption Evidence

SSL Labs A-rating: run against all public-facing domains, export PDF with timestamp
TLS 1.0 and TLS 1.1: explicitly disabled on load balancers, API gateways, and web servers
Internal APIs: TLS enabled for all service-to-service calls (confirm in network policy or service mesh config)
Database connections: TLS required for all database client connections (not just application-level)
Email relay: TLS required for SMTP submission and between relays (STARTTLS enforced)

Key Management (CC6.1 supporting evidence)

KMS auto-rotation enabled: annual rotation configured for all customer-data keys
Rotation event logs: export 12-month key rotation log from CloudTrail or equivalent
Key access log: confirm KMS decryption events are logged and anomalies are alerted
Separation of duties: document who manages key policies vs. who uses keys in applications
Key destruction procedure: documented and tested for when a key must be retired

Password and Credential Management (CC6.1)

Password hashing: Argon2id or bcrypt confirmed — document the algorithm and cost factor
Secrets management: all secrets in a vault (AWS Secrets Manager, HashiCorp Vault) — no plaintext in env vars
Repository scanning: run Gitleaks or equivalent — confirm no secrets in version history
MFA: enforced for all human access to production systems and the AWS/GCP/Azure console

Operational Evidence for Type II (all of the above must span the audit period)

Monthly SSL Labs snapshots archived for the full audit period
Key rotation event logs covering the full period (12 months for annual rotation)
AWS Config or Security Hub report showing no encryption findings throughout the period
Access review evidence: quarterly review of KMS key access policies documented

SOC 2 Type I vs Type II Encryption Evidence

Evidence Type	SOC 2 Type I	SOC 2 Type II
Encryption config screenshot	Today’s state	Evidence from start and end of period
TLS report	One current report	Multiple scans documented over the period
Key rotation	Policy + initial setup	Actual rotation event logs during the period
Password hashing	Current algorithm	Evidence of consistent use over the period
Trusted by enterprise buyers	Sometimes	Standard procurement requirement
Time to achieve	1–3 months	6–14 months from audit start

The difference matters for how you prepare. A Type I audit can be addressed by enabling encryption and generating evidence right before the audit. A Type II audit requires that controls were in place and consistently operating throughout the audit window — typically the 12 months preceding the report date. Starting your encryption remediation six months before a planned Type II audit gives you enough operational history.

Real-World Use Cases

SaaS startup preparing for enterprise sales: Enterprise procurement teams routinely require SOC 2 Type II reports before signing contracts. A startup enabling RDS encryption, S3 SSE-KMS, and a documented key rotation schedule 12 months before their target report date has sufficient history. One that scrambles to enable controls two weeks before the auditor arrives will get a finding for lack of operational evidence.

Multi-cloud organization: A company running workloads across AWS and GCP needs encryption evidence from both environments. AWS KMS and GCP Cloud KMS both provide FIPS 140-2 Level 2 validated key management and are both accepted for SOC 2. The auditor wants to see key access policies, rotation configurations, and access logs from each environment — not just one.

Finding remediation: A company that received a finding in a prior SOC 2 for unencrypted S3 buckets must demonstrate remediation in the next audit. This requires showing when the fix was implemented, confirming all newly created buckets are encrypted by default (S3 bucket policy denying unencrypted uploads), and scanning for previously unencrypted buckets using a tool like AWS Config.

Common Mistakes to Avoid

Having a key rotation policy but no rotation evidence. Auditors ask for the policy to understand intent, but they ask for logs to verify operation. If your policy says keys rotate annually and your KMS log shows no rotation events in the audit period, you have a finding. Enable automatic key rotation in AWS KMS (annual rotation is a checkbox) and verify the rotation events appear in CloudTrail logs.

Unencrypted legacy S3 buckets. The most common finding. Development and data-analysis buckets created before encryption-by-default policies were implemented often slip through. Run an AWS Config rule or Security Hub check to find all S3 buckets lacking SSE. Use a Service Control Policy (SCP) to deny creation of unencrypted buckets organization-wide.

TLS 1.0 or 1.1 still enabled. A legacy API endpoint or admin panel running on an older framework may have TLS 1.0 enabled for compatibility. The SSL Labs test will catch this. NSA and CISA jointly recommended eliminating TLS 1.0 and 1.1 in their 2021 advisory. Any auditor who runs SSL Labs on your endpoints will flag this immediately.

MD5 or SHA-1 password hashing. This is consistently one of the most severe findings in SOC 2 encryption reviews. MD5 is completely broken for password storage — it is fast, unkeyed, and has demonstrated collisions since 2004. Argon2id or bcrypt with cost ≥ 10 is the OWASP minimum. If your legacy application hashes passwords with MD5, remediation before the audit window opens is essential.

Getting Started

Three weeks before your audit window opens, run a complete encryption inventory. For AWS, use Security Hub with the FIPS encryption checks enabled and AWS Config with managed rules for S3 encryption, RDS encryption, and EBS encryption. For GCP, use Security Command Center. For Azure, use Microsoft Defender for Cloud. Generate a report and remediate any gaps before the audit window begins.

Document your encryption decisions in a one-page encryption policy covering: what algorithm you use for at-rest encryption, what TLS version minimum you enforce, how you manage and rotate keys, who has access to keys, and how password hashing is implemented. This document becomes your control description for the auditor.

For key rotation, enable automatic annual rotation in your KMS for all customer-data keys. Verify that rotation events appear in your cloud audit log. Export a 12-month slice of key rotation logs to include in your evidence package.

Run the Qualys SSL Labs test on every public-facing domain before your audit window opens. An A rating confirms TLS 1.2+ with strong cipher suites. Address any configuration issues immediately — auditors will run this test themselves.

For the compliance comparison with GDPR encryption requirements, see GDPR encryption requirements: Article 32 explained. For evaluating whether your encryption key management requires a dedicated HSM versus managed KMS, read hardware security modules explained.