SOC 2 Encryption Requirements: Criteria, Controls, and Evidence

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. For the surrounding criteria, see the SOC 2 Trust Services Criteria and the SOC 2 controls list.

Does SOC 2 require encryption?

SOC 2 does not list encryption as a named control. Most examinations still expect it for sensitive data because encryption is the usual way to satisfy logical-access, transmission, and — when Confidentiality is scoped — confidentiality objectives.

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. That pattern shows up in vendor write-ups of this topic and in fieldwork because 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.

Criterion	What the criterion is about	Encryption’s job	Evidence an auditor can sample
CC6.1 (Security)	Logical access to information assets	Encryption at rest so a stolen volume or copied database file is not readable without the key	Console or IaC showing encryption enabled on in-scope stores
CC6.7 (Security)	Restrict transmission, movement, and removal of information	TLS (or equivalent) on the channels that carry in-scope data	Scanner or config showing TLS 1.0/1.1 and weak ciphers disabled
C1.1 (Confidentiality, if scoped)	Identify and protect confidential information	Encryption that follows the classification, not a blanket “everything is encrypted” claim	Classification policy plus encryption settings on the systems that hold those classes

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.

CBIZ’s 2024 SOC benchmark, a convenience sample of 73 SOC 2 reports, 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. It does explain why buyers and auditors now ask about encryption even when a company started with a narrow Security scope. 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. Auditors still treat it as current industry practice when they ask why an endpoint still offers only 1.2.

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; SSL Labs is the tool many auditors and buyers already ran before they asked you.

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.

Three layers cover different failures. Using only the bottom layer is the usual mistake.

• 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.

Store	Typical control	Evidence that usually suffices
AWS S3	SSE-KMS (or SSE-S3) enforced on the bucket	Bucket policy or Block Public Access plus default encryption setting
AWS RDS / Azure SQL / Cloud SQL	Storage encryption enabled at create time	Console or API export showing encryption on
Azure Blob / GCS	Service-side encryption with a customer-managed key where required	Storage-account or bucket encryption setting

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. 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.

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 spun up unencrypted are a frequent sample miss.

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 collection guide is the wider process; this page stops at encryption.

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 control most firms use to meet 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. It is the default symmetric algorithm in new cloud services and in NIST-aligned guidance. 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.