SOC 224 April 2026 7 min read

SOC 2 Encryption Requirements: What You Need to Implement

SOC 2 requires encryption of data in transit and at rest. Learn which criteria apply, what encryption standards are acceptable, and how to document your encryption controls.

Key Takeaways

CC6.1 covers encryption in transit; the Confidentiality criteria (C1.1) address encryption at rest for confidential data.
TLS 1.2 or higher is required for all data in transit — deprecated protocols (TLS 1.0, SSL) must be disabled.
Customer data at rest must be encrypted using AES-256 or equivalent — cloud-native encryption (AWS KMS, S3 SSE) satisfies this for most use cases.
Laptop full-disk encryption (FileVault on macOS, BitLocker on Windows) is required for all devices that access in-scope systems.
Key management is as important as encryption itself — keys must be rotated, access to keys must be controlled, and key usage must be logged.

In this guide

Which Criteria Cover Encryption
Encryption in Transit
Encryption at Rest
Laptop Full-Disk Encryption
Key Management Requirements
Database Encryption
Evidence Auditors Collect

Which Criteria Cover Encryption

Encryption requirements in SOC 2 are distributed across multiple criteria. CC6.1 addresses logical access security, within which auditors expect encryption in transit as a foundational access control — intercepted plaintext traffic is equivalent to unauthorized access. CC6.7 addresses the protection of data transmitted over the internet, where encryption in transit is a direct requirement. The Confidentiality category (C1.1, C1.2) addresses protection of confidential information at rest — encryption is the primary mechanism for satisfying C1.1 for data stored in cloud infrastructure.

For companies that have scoped to Security only (Common Criteria, no additional TSC), encryption at rest for customer data is still expected under CC6.1 as a baseline security control. Auditors rarely see SOC 2 companies without encryption at rest as this is table-stakes for cloud infrastructure — AWS S3 default encryption and RDS encryption are trivial to enable.

Endpoint encryption (laptop full-disk encryption) is covered under CC6.4 (physical security) — if a laptop is stolen and the drive is encrypted, the data is not compromised. Auditors test this as part of the physical security cluster rather than the data encryption cluster, but the control is functionally an encryption requirement.

Encryption in Transit

All data transmitted between your customers' browsers and your application must be protected by TLS 1.2 or higher. Deprecated protocols — TLS 1.0, TLS 1.1, and SSL 3.0 — must be explicitly disabled. Configure your load balancer (ALB, CloudFront, nginx) to enforce a minimum TLS version and acceptable cipher suites. Tools like Qualys SSL Labs or ssl.im can verify your TLS configuration and are useful for generating evidence.

Internal service-to-service communications within your production environment should also use TLS — not plaintext HTTP. If your microservices communicate over an internal network, it is tempting to skip TLS for simplicity, but a compromised service or a misconfigured routing rule could expose plaintext traffic. Service mesh solutions (Istio, AWS App Mesh with mTLS) or explicit TLS configuration in each service satisfies this requirement.

API endpoints must enforce HTTPS-only connections. Configure HTTPS redirects (HTTP → HTTPS) at the load balancer level so that no plaintext API traffic reaches your application. Add HSTS (HTTP Strict Transport Security) headers to instruct browsers to always connect over HTTPS and prevent protocol downgrade attacks.

Encryption at Rest

Customer data stored in AWS must be encrypted at rest. For S3, enable default bucket encryption using SSE-S3 (AES-256) or SSE-KMS (customer-managed keys). For RDS and Aurora databases, enable storage encryption at creation time — this cannot be enabled retroactively on an existing unencrypted database without a migration. For DynamoDB, encryption at rest is enabled by default. For EBS volumes (EC2 instance storage), enable encryption-by-default at the account level in AWS Console.

AES-256 (Advanced Encryption Standard with 256-bit keys) is the accepted standard for SOC 2 purposes. Cloud-native encryption with cloud-provider-managed keys (SSE-S3) is acceptable for most SOC 2 engagements. Customer-managed keys (CMK via AWS KMS) provide stronger auditability and control and may be required by enterprise customers in their security addendums, but are not a SOC 2 requirement for the Security TSC.

Backup data must also be encrypted. Automated RDS backups and snapshots inherit the encryption setting of the source database. For backups exported to S3, ensure the destination bucket has encryption-at-rest enabled. For third-party backup solutions, verify that the backup data is encrypted before leaving your environment.

Laptop Full-Disk Encryption

Full-disk encryption (FDE) on all company-managed laptops is required for SOC 2. The rationale: laptops contain authentication credentials, code repositories, and potentially sensitive customer data. A stolen unencrypted laptop is a data breach. FDE protects against this risk category. On macOS, this is FileVault. On Windows, this is BitLocker. On Linux, this is dm-crypt/LUKS at disk setup time.

Device management is typically used to enforce and monitor FDE compliance. MDM solutions (Jamf for macOS, Microsoft Intune for Windows, Kandji as a cross-platform option) can enforce FileVault or BitLocker, verify FDE status continuously, and report compliance rates to your compliance dashboard. Auditors will ask for evidence that FDE is enforced — a compliance report from your MDM showing 100% of in-scope devices with FDE enabled is the expected evidence format.

BYOD (bring your own device) policies introduce complexity. If employees use personal laptops to access production systems, those devices must also have FDE enabled and be enrolled in MDM. Most SOC 2-compliant companies either prohibit BYOD for access to production systems or require enrollment in MDM as a condition of BYOD access. A clear, enforced policy on this point is necessary for CC6.4.

Key Management Requirements

Encryption is only as strong as your key management. If encryption keys are stored in plaintext alongside the data they protect — or are accessible to any engineer without restriction — the encryption provides little protection. Key management requirements for SOC 2 include: keys must be stored in a dedicated key management service (AWS KMS, HashiCorp Vault, GCP Cloud KMS), access to keys must be restricted via IAM policies, and key usage must be logged.

Key rotation is an expected practice. AWS KMS supports automatic key rotation annually. Application-level secrets (API keys, database passwords, JWT signing keys) should be rotated regularly and stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than in environment variables, hardcoded in code, or in plaintext configuration files. Secrets detection in CI (git-secrets, truffleHog, GitHub secret scanning) catches accidental key exposure before it reaches production.

Document your key management practices in your encryption policy or information security policy. Specify: what key management system is used, who has access to keys and how that access is controlled, the key rotation schedule, and the process for revoking and replacing compromised keys. Auditors will review this policy and may verify that the described practices are implemented in your KMS configuration.

Database Encryption

Database encryption covers two distinct scenarios: encryption at rest (the database files on disk are encrypted) and field-level or application-level encryption (specific sensitive fields within the database are encrypted at the application layer before storage). SOC 2 requires the former; the latter is a higher standard appropriate for specific sensitive data types.

Encryption at rest for managed database services (RDS, Aurora, Cloud SQL, Azure SQL) is a checkbox at provisioning time. Enable it. For self-managed databases on EC2, ensure the underlying EBS volume is encrypted. Verify that your database is encrypted by checking the "Encrypted" field in the AWS RDS console and capturing a screenshot as evidence.

Application-level encryption (encrypting PII, health data, or financial data fields before they are stored) goes beyond SOC 2 requirements but is expected by healthcare and financial services customers. If you handle PHI, HIPAA requires field-level encryption or equivalent protection. If your SOC 2 scope includes the Privacy TSC, stronger encryption practices for personal data are implied under P6 (data security and disposal).

Evidence Auditors Collect

For encryption controls, auditors typically request: (1) TLS configuration screenshots from your load balancer or CDN showing minimum TLS 1.2 and disabled deprecated protocols; (2) SSL Labs scan results or equivalent showing your encryption configuration grade; (3) AWS console screenshots showing S3 bucket encryption settings, RDS encryption status, and EBS encryption defaults; (4) MDM compliance report showing FDE status for all in-scope devices; (5) your encryption policy describing standards and key management; and (6) AWS KMS key policy screenshots or equivalent showing access restrictions.

Common gaps found in first-time SOC 2 audits: an S3 bucket that was created before encryption-at-rest was enforced and was never migrated; a legacy EC2 instance with an unencrypted EBS volume; a developer laptop enrolled in MDM but with FileVault reported as disabled; or an API endpoint that still accepts HTTP connections.

Compliance automation platforms that integrate with AWS Config and your MDM can continuously monitor encryption compliance and generate real-time reports. AWS Config rules such as `s3-bucket-server-side-encryption-enabled`, `rds-storage-encrypted`, and `ec2-ebs-encryption-by-default` provide automated evidence that encryption is enforced across your environment.

Frequently Asked Questions

Does SOC 2 require end-to-end encryption (E2EE)?

SOC 2 does not require end-to-end encryption in the technical sense (where even the service provider cannot read the data). The standard requires encryption in transit (TLS) and encryption at rest (AES-256 or equivalent). E2EE is appropriate for specific use cases (messaging, healthcare data) and may be required by your customer contracts, but it is not an AICPA criterion.

Is TLS 1.2 still acceptable or do we need TLS 1.3?

TLS 1.2 with strong cipher suites is still acceptable for SOC 2 as of 2026. TLS 1.3 is strongly preferred and should be the default for new deployments, but TLS 1.2 is not a finding on its own as long as weak cipher suites (RC4, 3DES, export-grade ciphers) are disabled. Configure your load balancer to prefer TLS 1.3 while allowing TLS 1.2 for client compatibility.

We use AWS S3 with SSE-S3. Is that sufficient or do we need KMS?

SSE-S3 (server-side encryption with Amazon S3-managed keys) satisfies the SOC 2 encryption-at-rest requirement. SSE-KMS (customer-managed KMS keys) provides additional auditability (key usage in CloudTrail logs) and access control (key policies restricting which IAM principals can use the key for decryption). SSE-KMS is the better security posture and may be required by enterprise customers, but SSE-S3 is sufficient for a passing SOC 2 audit.

Does database encryption at rest protect against SQL injection attacks?

No. Encryption at rest protects against physical media theft and unauthorized access to the storage layer. SQL injection attacks operate at the application layer, where the database engine has already decrypted the data to process queries. Encryption at rest and application input validation / parameterized queries are complementary controls that address different attack vectors.

What should our encryption policy contain?

An SOC 2 encryption policy should cover: (1) minimum encryption standards for data in transit (TLS 1.2+, approved cipher suites); (2) encryption standards for data at rest (AES-256 or equivalent, specific services and configurations required); (3) full-disk encryption requirements for endpoints; (4) key management requirements (KMS usage, rotation schedule, access controls); and (5) exceptions process for any legacy systems that cannot be immediately migrated to encrypted configurations.