SOC 2 Encryption Requirements: Criteria, Controls, and Evidence

SOC 2 does not prescribe encryption algorithms, key lengths, or TLS versions. The 2017 Trust Services Criteria (with revised points of focus, 2022) require protection against unauthorized access and disclosure, and encryption is the usual control that meets them. At rest it typically supports CC6.1, TLS in transit supports CC6.7, and classified confidential data supports C1.1 when Confidentiality is in scope. On a Type 2, auditors test whether those controls operated through the period.

Unencrypted production stores and plaintext traffic on untrusted networks are hard to defend in a SOC 2 examination. AES-256 and TLS 1.3 are current practice, not named TSC requirements. Classify the data, pick a method, manage the keys, and keep evidence. The SOC 2 Trust Services Criteria and the SOC 2 controls list cover the surrounding criteria, and the mandatory and optional requirements show what SOC 2 asks for beyond encryption.

Does SOC 2 require encryption?

SOC 2 does not list encryption as a named control. Encryption is the usual way to satisfy the logical-access, transmission, and (when Confidentiality is scoped) confidentiality criteria, so expect questions about it for sensitive data.

PCI DSS names protocols and key lengths. SOC 2 asks whether you identified the data, the threats to it, and a control a reasonable person would accept. Encryption is that control for stored data and for data moving across a network. A compensating control has to be equivalent and evidenced.

Two states of data come up in every walkthrough:

• In transit — API calls, browser traffic, service-to-service links, database connections, and backup copies moving between systems. The usual control is TLS.
• At rest — production databases, object storage, disks, and backups. The usual control is AES-family encryption, often provided by the cloud platform, sometimes with application-level encryption on top.

A common gap is encrypting the public website and leaving internal traffic, database connections, or backup pipelines in the clear. It is easy to miss once the load balancer looks fine.

Which SOC 2 criteria does encryption satisfy?

Encryption typically satisfies CC6.1 for data at rest, CC6.7 for data in transit, and C1.1 when Confidentiality is in the report. Encryption is not its own Trust Services family; it is evidence for those criteria.

CC6.8 is malware prevention, not transmission encryption. Transmission sits under CC6.7. Confidentiality protection at rest maps to C1.1 when Confidentiality is in scope; C1.2 is disposal, not an encryption criterion. The SOC 2 security controls page covers the rest of CC6 and CC7, and the library controls behind these criteria are mapped further down.

CBIZ’s 2024 SOC benchmark, which reviewed 73 SOC 2 reports without saying how they were chosen, found Confidentiality in 64.4% of those reports, up from 34% in the prior year’s smaller sample. Security appeared in 100%. That is not a census of all SOC 2 reports, and it does not make encryption a Confidentiality-only topic: CC6.1 and CC6.7 apply on Security-only reports too. Source: CBIZ, 2024 SOC Benchmark Study, part two.

How should you protect data in transit?

SOC 2 does not name a minimum TLS version. Use TLS on every in-scope channel, disable SSLv3 and TLS 1.0/1.1, and keep certificate lifecycle evidence.

TLS 1.2 is the common floor in 2026 practice. TLS 1.0 and 1.1 are treated as findings because they are broken, not because the TSC lists them. NIST SP 800-52 Rev. 2 (final August 2019) requires US federal TLS servers and clients to support TLS 1.2, and to support TLS 1.3 by 1 January 2024, with 1.2 retained for interoperability unless it is not needed. NIST SP 800-52 Rev. 2 is federal guidance, not an AICPA mandate.

SSL, TLS 1.0, TLS 1.1Disable

Known-broken protocols. An endpoint that still offers them is treated as a finding.

TLS 1.2Common floor

The usual minimum in practice. The Trust Services Criteria do not pin a version, so the floor is a rule you write in policy.

TLS 1.3Current practice

NIST SP 800-52 Rev. 2 required US federal TLS servers and clients to support it by 1 January 2024. That is federal guidance, not an AICPA requirement.

TLS 1.3 also drops obsolete ciphers and makes forward secrecy mandatory. If you are staying on 1.2, document why (legacy clients, vendor constraint) and the migration plan. Teams that delay 1.3 because they cannot inspect internal traffic can use NIST SP 1800-37 (final September 2025), which shows ways to keep enterprise visibility while moving off 1.2. NIST SP 1800-37 is about monitoring inside a data center, not a SOC 2 control.

Cipher configuration still matters on 1.2. Disable RC4, DES/3DES, MD5, and anonymous Diffie-Hellman. A defensible 1.2 suite is ECDHE-RSA-AES256-GCM-SHA384. TLS 1.3’s TLS_AES_256_GCM_SHA384 is the usual counterpart. Public endpoints get scanned, and you can run SSL Labs on yours before anyone asks.

Certificate expiry is a control failure, not only an outage. Show procurement from a known CA, deployment of the private key, expiration monitoring, renewal, and revocation if a key is compromised. Logs of automated renewals are Type 2 evidence; a wiki page of dates is not.

How should you protect data at rest?

SOC 2 does not name AES-256. Encrypt in-scope stores with AES-256 unless you have a documented reason to do otherwise, and do not treat full-disk encryption as enough by itself.

AES-256 is the usual choice for new systems. AES-128 is still a published AES variant and is not, by itself, an AICPA finding. You will need a reason if a customer or a federal-adjacent buyer expects 256-bit keys. Do not cite Triple DES as a current default.

The four layers cover different failures, so volume encryption alone leaves the other three open.

Layer	Covers	Does not cover
Volume or disk	Stolen media	Files after boot, privileged database user, network intercept
Database files	Stolen media, files after boot	Privileged database user, network intercept
Application fields	Stolen media, files after boot, privileged database user	Network intercept
TLS	Network intercept	Stolen media, files after boot, privileged database user

• Volume or disk encryption (for example AWS EBS, Azure Disk Encryption) protects a stolen drive. Once the instance is running, the volume is decrypted.
• Database file encryption (SQL Server and Oracle TDE; cloud “encryption enabled” on RDS or Cloud SQL) protects database files on disk. It does not hide rows from a privileged database user.
• Application-level encryption encrypts chosen fields before they are written. That is the only layer that also limits a DBA. It costs engineering time and needs its own key policy.

A defensible SaaS pattern is volume encryption everywhere, database or object-store encryption on anything with customer data, and field-level encryption for the few elements that would be damaging even to an insider (government IDs, credentials, payment tokens). Backups need the same treatment as production. Cloud-native KMS products — AWS KMS, Azure Key Vault, Cloud KMS — are easier to evidence than a homegrown key store because they emit an audit trail of use.

Post-quantum algorithms are not a SOC 2 requirement. NIST published FIPS 203, 204, and 205 on 13 August 2024. If you keep ciphertext for many years, a cryptographic inventory belongs in the risk assessment. It does not, by itself, create an encryption finding.

How should you manage encryption keys?

A working encrypt-at-rest setting is not a control if the key is in a repo, a plaintext env file, or an unrestricted IAM role.

Auditors look at the key’s life, not only at the “encryption enabled” toggle.

1. GenerateCryptographically secure generator

Cloud KMS and HSMs generate keys this way.

2. StoreKMS or HSM

The usual break. Keys in source control, chat, or plaintext config files are a finding.

3. DistributeLeast privilege

Only to the services that need them, with named roles and an audit trail.

4. RotatePolicy and logs

On the schedule your policy sets, with logs showing it happened.

5. DestroyAfter the data is gone

So old ciphertext cannot be decrypted later.

1. Generate with a cryptographically secure generator. Cloud KMS and HSMs do this; /dev/urandom on a laptop in a ticket is not a key-management program.
2. Store in KMS or an HSM. Keys in source control, chat, or .env files are a finding.
3. Distribute only to the services that need them, with named roles and an audit trail.
4. Rotate on a schedule you defined. There is no TSC-mandated 90-day or annual period. AWS-managed key rotation is often annual; that is a vendor default, not an AICPA rule. Prove the schedule you wrote.
5. Destroy when the data is gone, so old ciphertext cannot be decrypted later.

Keep a key-management procedure next to the encryption policy. For Type 2, export KMS or CloudTrail (or equivalent) records covering the observation period; our guide to SOC 2 logging and monitoring controls covers how those records are collected and reviewed. Access to keys is part of your access controls; the SOC 2 access control policy template covers how to write them.

What encryption evidence do auditors request?

SOC 2 encryption evidence is policy, then current configuration, then period logs. Screenshots without a period are Type 1 artifacts. A Type 2 examination needs the logs. The SOC 2 documentation page covers the three layers across all controls; the evidence request list shows which cloud-console pulls usually answer encryption questions.

Policies

• A data-classification policy that states which classes require encryption, in which states.
• An encryption policy that names approved algorithms and protocol floors (write “TLS 1.2 minimum, TLS 1.3 preferred” if that is your rule — it is your rule, not the TSC’s).
• Key-management procedures covering the five stages above, with owners.

Configuration

• Encryption-enabled status for in-scope databases, object stores, and disks.
• Load-balancer or web-server config that disables SSLv3, TLS 1.0, and TLS 1.1 and lists allowed ciphers.
• An external scan of public endpoints (SSL Labs or equivalent) dated inside or just before fieldwork.

Operating evidence (Type 2)

• KMS or equivalent logs showing key use and rotation across the period.
• Certificate issuance and renewal records covering the period.
• A check that resources created mid-period inherited encryption. New buckets and databases created unencrypted are the gap the controls table below describes for encryption at rest.

An auditor’s request often sounds like: “Show the production bucket policy that denies unencrypted uploads, and the CloudTrail events for that KMS key during the period.” Having that packet ready is the work. The SOC 2 evidence request list is the wider process; this page stops at encryption. If your configuration or key-management evidence is thin, readiness firms can close the gap before fieldwork.

Which library controls carry the encryption evidence?

The SOC 2 controls library holds 82 example controls. The table lists the ones that touch encryption or keys, the criteria each supports, and what a Type 2 period adds. These are our example controls, not AICPA requirements.

AC-02 sits beside key management and does not replace it.

Key handling gets little detail in either source. DP-01 asks for keys managed in your provider’s key management service, with limits on who can use or change them. The AICPA’s 2022 revised points of focus (read in October 2026) add, for CC6.1, that the entity protects cryptographic keys during generation, storage, use and destruction, and that cryptographic modules, algorithms and key lengths suit its risk strategy. For CC6.7 they name encryption technologies or secure communication channels for data sent beyond connectivity access points. Neither the library nor the points of focus sets a rotation interval. The AICPA describes points of focus as characteristics that may assist management and the auditor, and says some may not suit a given entity. A 90-day or annual rotation rule is a choice you write into policy and then evidence.

The mid-period gap described earlier is the common failure the library lists for DP-01: a bucket or replica created unencrypted, found when the inventory is compared with a live export. That comparison uses AM-01 evidence, so a current inventory is part of the encryption packet. Backups appear twice. DP-01 lists them in its encryption settings and BC-01 asks the backup configuration to show encryption, so one backup setting can serve both controls.

The rest of CC6 and CC7, from access reviews to incident response, is mapped in the library table on the security controls page.

Questions teams actually ask

Does SOC 2 require encryption of data at rest and in transit?

SOC 2 does not require encryption by name. CC6.1, CC6.7, and, if Confidentiality is scoped, C1.1 are the criteria. Encryption is the usual control for them. A firm that skips encryption needs an equivalent control and evidence that it works.

Does SOC 2 require AES-256 or TLS 1.3?

SOC 2 does not require AES-256 or TLS 1.3. AES-256 and TLS 1.3 are current practice; TLS 1.3 support by 1 January 2024 is a NIST federal date in SP 800-52 Rev. 2, not an AICPA mandate. Write those versions in the company’s policy if they are the standard.

Is AES-256 still considered secure?

AES-256 is still considered secure as of September 2026. A weak mode, padding, or key-handling implementation can still fail.

What TLS version should we set as the floor?

For SOC 2 practice, disable SSL, TLS 1.0, and TLS 1.1. Treat TLS 1.2 as the floor and TLS 1.3 as the target. If an endpoint cannot move yet, record the exception, the owner, and the date.

Do we need a custom key-management service?

SOC 2 does not require a custom key-management service. A cloud KMS or HSM with restricted IAM, logged use, and a written rotation rule is the usual design. Building a custom key store is harder to evidence.