SOC 2 encryption requirements: in transit, at rest, and key management
SOC 2 never names an algorithm, but auditors expect encryption in transit, encryption at rest, and key management you can actually evidence. Here is what that looks like in practice under CC6 and the Confidentiality criteria.
Where encryption lives in the Trust Services Criteria
There is no single "encryption criterion" in SOC 2; the expectation is woven through the Common Criteria, primarily CC6.1 and CC6.7. CC6.1 calls for logical access controls over protected information, and encryption at rest is one of the controls auditors map to it, because it limits exposure if storage or backups are accessed by someone who bypasses application-layer access. CC6.7 is the more direct hook, requiring the entity to protect information during transmission, movement, and removal, which auditors read as encryption in transit. Because the framework is built on the 2017 Trust Services Criteria with the 2022 revised points of focus, the language stays principles-based rather than prescriptive. That design choice is exactly why two firms can both pass SOC 2 with very different cryptographic stacks, provided each can show its choices are reasoned and consistently applied.
Why SOC 2 names no algorithm, and what auditors expect anyway
SOC 2 deliberately avoids mandating a cipher, key length, or TLS version, because the AICPA wrote criteria meant to outlast any given standard. In practice, however, auditors anchor to widely accepted norms and will question anything weaker. For data in transit, that means TLS 1.2 or higher, with TLS 1.0/1.1 and plaintext protocols treated as findings. For data at rest, AES-256 is the de facto expectation across managed databases, object storage, and backups, with AES-128 generally tolerated but rarely chosen. The right framing for your own policy is risk-based: state what you encrypt, with what, and why that meets your stated objectives, rather than copying a number from a blog.
Key management is where audits actually get hard
Turning on encryption is the easy part; managing keys is what separates a clean audit from a list of exceptions. Auditors want to see keys generated, stored, rotated, and destroyed under defined procedures, with access to key material tightly restricted and separated from access to the data it protects. Most teams satisfy this by leaning on a cloud key management service such as AWS KMS, Google Cloud KMS, or Azure Key Vault, which provides rotation, access logging, and hardware-backed protection out of the box. Customer-managed keys raise the bar and are worth it for sensitive workloads, but they also add operational responsibility you must then evidence. The recurring trap is a self-managed key sitting in a repository, an environment variable, or a wiki, which undermines the entire control.
How Confidentiality criteria raise the bar
If your report includes the Confidentiality category, encryption stops being a baseline hygiene control and becomes tied to protecting specifically classified data through its lifecycle. C1.1 expects you to identify confidential information, and C1.2 expects you to dispose of it securely, which interacts directly with how keys are handled. A common and elegant pattern is cryptographic erasure: when confidential data reaches end of life, you destroy the key rather than chasing every copy, so the ciphertext becomes unrecoverable. That approach only holds up if your key management is mature enough to prove the key was actually destroyed. Confidentiality scope therefore turns encryption and key management into linked controls rather than separate checkboxes.
Evidence auditors ask for, and the gaps that cost you
Expect to provide configuration evidence rather than assertions: TLS settings or scan output showing accepted protocol versions, storage and database configs confirming at-rest encryption is enabled, and KMS settings showing rotation schedules and restricted key access. For a Type 2 report, this evidence must hold across the entire audit period, so a setting that was enabled only in the final week will not demonstrate operating effectiveness. The most common gaps are predictable: an unencrypted backup bucket or snapshot, an internal service or legacy endpoint still allowing TLS 1.0, a database with encryption off because it predates the policy, and keys with no defined rotation or destruction process. Closing these before fieldwork, and keeping the policy and the actual configuration in agreement, is what keeps the encryption section of a SOC 2 boring in the best possible way.