Does SOC 2 Require Encryption? What the Criteria Actually Say

One of the most common questions we get from clients starting their SOC 2 journey is whether SOC 2 actually requires encryption. The short answer we give: SOC 2 does not prescribe specific encryption algorithms, key lengths, or protocols. It is a principle-based framework that requires you to protect data through appropriate controls, and encryption is one of the primary mechanisms we see organizations use to satisfy those requirements. In practice, however, the expectation is clear — auditors evaluate your encryption implementation as a fundamental component of data protection, and virtually every SOC 2-compliant organization we work with implements encryption at rest and in transit. The distinction between "required" and "expected" matters because it gives you flexibility in how you implement encryption while still making it effectively necessary for a clean audit opinion.

This guide explains what the Trust Service Criteria actually say about encryption, what auditors evaluate in practice, the minimum encryption standards expected, and how to document your encryption approach for SOC 2.

What the Trust Service Criteria Say

Principle-Based vs Prescriptive

SOC 2 is fundamentally principle-based, meaning it defines what you must achieve (data protection) rather than how you must achieve it (specific encryption standards). This contrasts with prescriptive frameworks like PCI DSS, which specify exact encryption algorithms and key management procedures.

Framework Approach	SOC 2	PCI DSS
Encryption requirement	Protect data from unauthorized access and disclosure	Encrypt cardholder data with strong cryptography (specific algorithms listed)
Algorithm specification	None — auditor evaluates whether your approach is appropriate	AES-128/256, RSA 2048+, specific protocols listed
Key management	Controls for managing cryptographic keys (principle-based)	Specific key rotation schedules, split knowledge, dual control
Protocol specification	None — auditor evaluates whether protocols are current	TLS 1.2+ explicitly required; older protocols prohibited

Relevant Trust Service Criteria Points

Criteria Point	What It Says	How Encryption Relates
CC6.1 — Logical access security	The entity implements logical access security over information assets	Encryption protects data from unauthorized access even if other access controls are bypassed
CC6.7 — Data transmission controls	The entity restricts the transmission of data to authorized users	Encryption in transit (TLS) ensures data transmitted over networks is protected
C1.1 — Confidentiality of information	Confidential information is identified and protected from unauthorized access	Encryption is a primary control for protecting confidential information at rest and in transit
C1.2 — Disposal of confidential information	Confidential information is disposed of in a manner that protects against unauthorized access	Encryption supports secure disposal (encrypted data is unreadable without keys)
A1.2 — Environmental protection	The entity protects system components from environmental threats	Encryption at rest protects data if physical media is compromised

The "Appropriate Controls" Standard

The Trust Service Criteria use language like "appropriate controls" and "suitable design" rather than specifying encryption. This means your auditor evaluates whether your data protection approach — which almost always includes encryption — is reasonable and effective given your risk profile. In our experience, an organization that stores customer data without encryption at rest would need an exceptionally strong alternative control to demonstrate appropriate data protection, and in practice, no alternative is as universally accepted as encryption.

What Auditors Actually Evaluate

Encryption at Rest

Encryption at rest protects stored data from unauthorized access if physical media, backup files, or database snapshots are compromised.

What Auditors Check	Expected Evidence	Common Implementation
Database encryption	Configuration evidence showing encryption is enabled for databases storing customer data	AWS RDS encryption, GCP Cloud SQL encryption, Azure SQL TDE
Storage encryption	Evidence that storage volumes and object storage are encrypted	AWS S3 default encryption, EBS encryption, GCP Cloud Storage encryption
Backup encryption	Evidence that backups are encrypted	Encrypted backup configurations, KMS-managed backup keys
Encryption algorithm	Verification that the algorithm is current and appropriate	AES-256 is the standard expectation; AES-128 is acceptable
Key management	Evidence that encryption keys are managed securely	Cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault), key rotation policies
Laptop/endpoint encryption	Evidence that employee devices are encrypted	FileVault (macOS), BitLocker (Windows), MDM enforcement evidence

Encryption in Transit

Encryption in transit protects data as it moves between systems, from users to your application, and between internal services.

What Auditors Check	Expected Evidence	Common Implementation
HTTPS enforcement	Evidence that all public-facing endpoints use HTTPS	TLS certificate configuration, HTTP-to-HTTPS redirect, HSTS headers
TLS version	Verification that current TLS versions are used	TLS 1.2 minimum; TLS 1.3 preferred; older versions (TLS 1.0, 1.1, SSL) disabled
Internal service communication	Evidence that internal service-to-service communication is encrypted	Service mesh TLS, internal TLS certificates, VPN for cross-network communication
API encryption	Evidence that API communications are encrypted	HTTPS for all API endpoints, mutual TLS for sensitive service-to-service APIs
Database connections	Evidence that database connections use encryption	SSL/TLS enforcement for database client connections
Email encryption	Evidence that email communication uses encryption where appropriate	TLS for email transport (STARTTLS), encrypted email for sensitive communications

Key Management

Key management is where auditors often find deficiencies, even when encryption itself is implemented correctly.

Key Management Control	What Auditors Evaluate	Best Practice
Key storage	Where encryption keys are stored and how they are protected	Cloud KMS (hardware-backed), never stored alongside encrypted data
Key rotation	Whether keys are rotated periodically	Annual rotation minimum; automated rotation preferred
Access to keys	Who can access encryption keys and how access is controlled	Restricted to authorized personnel; IAM policies limit access
Key backup and recovery	Whether keys can be recovered if primary access is lost	Key recovery procedures documented; tested periodically
Separation of duties	Whether the same person who manages data also manages keys	Separate roles for data administration and key management where feasible
Key lifecycle	How keys are created, distributed, stored, rotated, and eventually destroyed	Documented key lifecycle procedures covering all stages

Minimum Expected Standards

Industry-Standard Encryption Expectations

While SOC 2 does not mandate specific standards, the following represent what auditors and enterprise customers expect as baseline encryption implementation.

Encryption Area	Minimum Expected	Preferred	Unacceptable
Data at rest algorithm	AES-128	AES-256	DES, 3DES, RC4, no encryption
Data in transit protocol	TLS 1.2	TLS 1.3	TLS 1.0, TLS 1.1, SSL 3.0, no encryption
Key management	Cloud-managed KMS	HSM-backed KMS with automatic rotation	Keys stored in application code, shared keys, no key management
Endpoint encryption	Full disk encryption (FileVault/BitLocker)	Full disk encryption enforced via MDM with compliance monitoring	No endpoint encryption, self-managed without enforcement
Database encryption	Cloud-native encryption at rest enabled	Cloud KMS with customer-managed keys (CMK)	No database encryption, deprecated algorithms
Backup encryption	Encrypted backups using same or stronger encryption as source	Encrypted backups with separate key management	Unencrypted backups, backups accessible without encryption

What "AES-256" Means for SOC 2

AES-256 (Advanced Encryption Standard with 256-bit key length) has become the de facto standard for data at rest encryption in SOC 2 environments. While AES-128 is technically sufficient and not considered weak by current cryptographic standards, AES-256 is what enterprise customers expect and what most cloud provider default encryption uses. Implementing AES-256 is straightforward when using cloud provider encryption services, as it is typically the default configuration.

What "TLS 1.2+" Means for SOC 2

TLS 1.2 is the minimum acceptable protocol version for data in transit. TLS 1.3, released in 2018, offers improved security and performance and is increasingly expected. Older versions (TLS 1.0, TLS 1.1) are considered insecure and should be disabled. Auditors will check your TLS configuration and may flag systems that support older protocol versions even if newer versions are also supported.

Documenting Your Encryption Approach

What to Include in Your System Description

Your SOC 2 report's system description should clearly document your encryption approach.

Documentation Element	Content	Example
Encryption at rest overview	General description of encryption for stored data	"All customer data at rest is encrypted using AES-256 encryption managed through AWS KMS"
Encryption in transit overview	General description of encryption for data transmission	"All data in transit is encrypted using TLS 1.2 or higher; TLS 1.0 and 1.1 are disabled"
Key management approach	How encryption keys are managed	"Encryption keys are managed through AWS KMS with automatic annual rotation"
Scope of encryption	What data is encrypted and where	"Encryption applies to all production databases, object storage, backups, and inter-service communication"
Endpoint encryption	How employee devices are encrypted	"All company-managed devices are encrypted using FileVault (macOS) or BitLocker (Windows), enforced through MDM"

Policies to Create or Update

Policy	Encryption-Related Content
Information Security Policy	High-level statement on data protection including encryption requirements
Data Classification Policy	Classification levels with corresponding encryption requirements per level
Encryption Policy (dedicated)	Detailed encryption standards, algorithms, protocols, key management procedures
Key Management Procedures	Specific procedures for key creation, rotation, storage, access, and destruction
Acceptable Use Policy	Requirements for endpoint encryption and secure data handling

Evidence to Maintain

Evidence Type	Source	Collection Frequency
Database encryption configuration	Cloud provider console or API	Continuous via GRC platform integration
Storage encryption configuration	Cloud provider console or API	Continuous via GRC platform integration
TLS configuration	SSL Labs scan, load balancer configuration	Monthly or continuous via monitoring tool
Key rotation records	KMS audit logs showing key rotation events	Annual or per rotation schedule
MDM encryption compliance	Endpoint management platform	Continuous via GRC platform integration
Disabled protocol evidence	Load balancer or web server configuration showing old TLS versions disabled	After configuration changes; periodic verification

Common Encryption Findings in SOC 2 Audits

What Auditors Commonly Flag

Finding	Root Cause	Prevention
TLS 1.0/1.1 still enabled	Legacy compatibility not removed; default configurations not hardened	Disable legacy TLS versions proactively; test for compatibility impact
Unencrypted database connections	Database SSL enforcement not configured; applications connecting without encryption	Enable SSL enforcement on database servers; require encrypted connections
No key rotation evidence	Key rotation not configured or not documented	Configure automatic key rotation in KMS; document rotation schedule
Unencrypted backups	Backup encryption not enabled by default; overlooked during configuration	Enable encryption for all backup services; verify backup encryption status
Endpoint encryption gaps	Some devices not enrolled in MDM; BYOD devices without encryption requirements	Enforce MDM enrollment; require encryption for all devices accessing company data
Missing encryption for internal traffic	Service-to-service communication within VPC not encrypted	Implement service mesh TLS or internal certificate management

Key Takeaways

• We consistently see that while SOC 2 does not prescribe specific encryption algorithms or protocols, encryption is effectively required in practice — the Trust Service Criteria require "appropriate controls" for data protection, and auditors universally evaluate encryption as a fundamental component of that protection
• What we recommend as minimum encryption standards for SOC 2: AES-256 (or AES-128) for data at rest and TLS 1.2 or higher for data in transit — these are not SOC 2 mandates but represent the industry baseline that auditors and enterprise customers expect
• In our experience, key management is where encryption findings most commonly occur: auditors evaluate how encryption keys are stored (cloud KMS preferred), whether keys are rotated (annual minimum), who has access to keys (restricted via IAM), and whether key management procedures are documented
• What we tell clients about encryption documentation: your SOC 2 system description should clearly state your encryption algorithms, protocol versions, key management approach, scope of encryption, and endpoint encryption enforcement — vague statements like "we use encryption" are insufficient
• In our experience, cloud provider default encryption (AWS KMS, GCP Cloud KMS, Azure Key Vault with AES-256) satisfies SOC 2 expectations for most SaaS companies, making encryption implementation straightforward for organizations using major cloud platforms
• We help our clients implement and document encryption controls that satisfy SOC 2 auditor expectations, including key management procedures, TLS configuration verification, and encryption policy development

Frequently Asked Questions

If SOC 2 does not require encryption, can we pass without it?

What we tell clients is: theoretically, SOC 2's principle-based approach means you could demonstrate data protection through alternative controls without encryption. Practically, this is extremely unlikely to work. Every auditor we have worked with evaluates encryption as a baseline expectation for data protection. An organization without encryption at rest or in transit would need to demonstrate alternative controls that provide equivalent protection — and no widely accepted alternative exists. Additionally, enterprise customers who read your SOC 2 report expect to see encryption described in your system description. Absence of encryption would raise significant concerns regardless of auditor opinion.

What encryption do we need for different types of data?

The advice we give most often is that all customer data should be encrypted at rest and in transit as a baseline. For more sensitive data categories, we recommend additional protections. Personally identifiable information (PII) should have AES-256 encryption with access-controlled key management. Financial data should have encryption plus additional access controls and audit logging. Health information (if applicable) should meet HIPAA encryption requirements. The key principle is that your encryption approach should be proportional to data sensitivity — all data gets baseline encryption, and more sensitive data gets stronger protections.

Does cloud provider default encryption satisfy SOC 2?

Based on what we see across our client base, yes, for most organizations. Cloud provider default encryption services (AWS KMS with AES-256, GCP Cloud KMS, Azure Key Vault) are well-established, auditor-recognized encryption implementations. Using cloud-managed encryption satisfies SOC 2 expectations for encryption at rest. For encryption in transit, you need to verify that your application enforces HTTPS (TLS 1.2+) and that internal service communication is encrypted. Cloud provider infrastructure encryption handles storage and database encryption automatically when properly configured. Your auditor will verify that encryption is enabled, not that you are using a specific vendor or implementation.

How do we handle encryption for endpoints and employee devices?

What we recommend to every client is full disk encryption on all company-managed devices, enforced through MDM. Endpoint encryption is evaluated as part of SOC 2 access control and data protection. Auditors expect this as a baseline. For macOS, FileVault is the standard; for Windows, BitLocker. The key is enforcement — your MDM (Jamf, Kandji, Microsoft Intune) should enforce encryption and provide compliance evidence. If you allow BYOD (bring your own device), we advise establishing a policy that requires encryption on personal devices that access company data, and enforcing this through your MDM or conditional access policies. GRC platforms collect endpoint encryption compliance data from MDM integrations, providing automated evidence for your audit.