SOC 2 Encryption Requirements: Data at Rest, In Transit and Key Management

“Does SOC 2 require encryption?” is one of the most searched questions in the compliance world, and the honest answer is a careful “it depends on your commitments, but in practice almost always yes.” SOC 2 is an attestation report prepared by an independent CPA firm against the AICPA Trust Services Criteria. Those criteria are outcome-based. They say what must be achieved, not which product or algorithm to use.

This guide explains where encryption appears in the criteria, what auditors typically test, how to handle key management, which gaps cause exceptions and how to document your approach. It is practical guidance from a readiness perspective, not a substitute for your auditor’s judgment.

Where encryption appears in the Trust Services Criteria

The criteria are published by the AICPA and described on its SOC suite of services page. Encryption is addressed mainly through the Security category (the Common Criteria) and, if you include it, the Confidentiality category.

Points of focus are guidance, not a mandatory checklist, which is why two companies can pass with different designs. For a refresher on the framework, see our guide to the five Trust Services Criteria.

The two questions that matter: what and how

What must be encrypted?

Start with data classification. Customer data, credentials, secrets, personal information and anything you promise to keep confidential in contracts or marketing should be encrypted at rest and in transit. Lower-risk data, such as public marketing content, may not need it. Whatever you decide, your system description and policies must be consistent with reality. Describing encrypted storage that is not encrypted is far worse than not claiming it at all.

How strong must it be?

SOC 2 names no algorithm. Auditors generally look for industry-accepted approaches: modern TLS versions for network traffic, strong symmetric encryption (such as AES) for stored data, and managed keys rather than hard-coded ones. Your own policy should state the minimum standard, and the auditor tests against that statement. Avoid weak or deprecated protocols, and review the guidance from recognized bodies such as NIST when you set the baseline.

Encryption at rest: what to cover

• Databases and storage volumes. Enable provider-native encryption for managed databases, block storage and object storage.
• Backups and snapshots. Backups often hold the same data as production. Encrypt them and restrict who can restore or copy them.
• Logs and analytics stores. They may contain personal or sensitive data. Decide whether to mask data or encrypt the store.
• Endpoints. Full-disk encryption on laptops and mobile devices that access company data, enforced through device management.
• Removable media and exports. Prohibit them or require encryption.
• Third-party SaaS. Understand how your vendors encrypt data you entrust to them, and review their assurance reports. See third-party risk management for SOC 2.

Encryption in transit: what to cover

• Public endpoints. TLS on websites, APIs and customer-facing services, with certificates monitored for expiry.
• Internal traffic. Service-to-service communication, database connections and message queues, especially across networks you do not fully control.
• Remote administration. SSH, VPN or identity-aware proxy access to production.
• Email and file transfer. Use encrypted channels for sensitive attachments and customer file exchanges.
• Third-party integrations and webhooks. Enforce encrypted transport and validate certificates.

Key management: the part auditors probe hardest

Encryption is only as strong as the way its keys are handled. The criteria’s attention to protecting keys means you should expect questions in five areas.

Secrets used by applications, pipelines and integrations deserve the same discipline. Service accounts and API keys are covered in our article on access controls for APIs and non-human identities.

Cloud providers and shared responsibility

Major cloud platforms offer encryption by default for many services, but defaults vary by service and region, and configuration remains your responsibility. A typical split looks like this:

• The provider secures the physical infrastructure and the key service itself, evidenced in its own SOC report.
• You enable, configure and monitor encryption on the services you use, choose key types and control who may use them.

Do not assume that a provider’s report covers your settings. Our guides on AWS security controls for SOC 2 and cloud security best practices explain where those lines fall, and subservice providers and your SOC 2 covers how providers appear in the report.

What auditors typically request

1. Your encryption or cryptography policy with approval and review history.
2. A data inventory or classification showing what is encrypted and why.
3. Configuration evidence: screenshots or exports showing encryption enabled for databases, storage, backups and endpoints.
4. TLS configuration evidence for in-scope endpoints, such as scan results or load balancer settings.
5. Key management settings, rotation records and access lists.
6. Exceptions or risk acceptances for anything not encrypted, with approval.
7. Device management reports for laptop encryption status.

For Type II reports the auditor wants proof that settings were in place for the full observation period, not only on one day. That means keeping dated exports or using monitoring that records configuration over time. Our overview of required SOC 2 documentation helps you plan the evidence set.

Common encryption mistakes that cause exceptions

• Policy without proof. The policy says AES for everything, but nobody can show the setting on the newest database.
• New resources created unencrypted. Infrastructure launched through scripts or by hand skips the default. Enforce encryption with guardrails or policies that block unencrypted resources.
• Forgotten backups, replicas and logs. Primary storage is encrypted while exports and analytics copies are not.
• Expired or misconfigured certificates. A lapsed certificate on a customer-facing endpoint is both an availability and a security problem.
• Keys in code repositories. Secrets committed to source control or shared in chat.
• Everyone is a key administrator. Broad key permissions undermine the control.
• Unencrypted laptops. A single unmanaged device holding customer data is a classic finding.

If you cannot encrypt something

Legacy systems, vendor limitations or performance constraints sometimes make encryption impractical. SOC 2 allows alternative designs if you can show the risk is addressed. Document the reason, record the decision in your risk assessment, describe compensating controls such as network isolation, tight access and monitoring, and obtain management approval. Auditors accept reasoned exceptions far more readily than silence. See our guide on gap analysis from the auditor’s side of the table for how such gaps are evaluated.

A practical encryption checklist for SOC 2 readiness

• Data classification defined and linked to encryption requirements.
• Cryptography policy approved, with minimum standards for transit and rest.
• Encryption enabled on all production databases, storage, backups and snapshots.
• Disk encryption enforced and reported for all company devices.
• TLS enforced on all external and sensitive internal connections, with certificate expiry monitoring.
• Keys stored in a managed service, with least-privilege access and rotation.
• Guardrails prevent creation of unencrypted resources.
• Evidence captured on a schedule and stored with dates.
• Exceptions documented, risk-assessed and approved.

What this means for your business

Customers increasingly ask about encryption in security questionnaires, and enterprise buyers will read the controls section of your report for it. A clear, consistent story that covers data at rest, data in transit and key handling shortens reviews and prevents contract disputes. Treat encryption as a design standard enforced automatically rather than a task people remember.

If you are unsure where your gaps are, our SOC 2 readiness service reviews encryption and related controls before your examination, and our Type I and Type II audit support helps coordinate evidence with your auditor. For day-to-day questions, 24×7 GRC chat and Slack support is available. Readiness support does not replace the independent report, which is issued by a licensed CPA firm.

Frequently asked questions

Does SOC 2 require encryption?

Not by naming a specific technology, but the Security and Confidentiality criteria expect you to protect information appropriately, and auditors almost always look for encryption of sensitive data at rest and in transit. Any deviation needs a documented, risk-based justification.

Is AES-256 required for SOC 2?

No algorithm is mandated. AES-256 is a widely used choice that auditors recognize, and your policy should state the standard you commit to. The auditor tests against what you document.

Do we need to encrypt data in transit inside our own network?

It depends on your risk assessment and architecture. Many companies encrypt internal service-to-service traffic as a defense in depth measure, particularly in shared or cloud networks. If you do not, document why and describe compensating controls.

Does cloud provider default encryption satisfy the auditor?

Often yes for the covered service, but you must show that it is enabled and applies to your resources. Provider defaults differ by service, so keep configuration evidence.

How often should encryption keys be rotated?

SOC 2 sets no fixed schedule. Choose a rotation approach that fits your risk and tooling, document it and show evidence it operates. Automatic rotation in a managed key service makes this easy to prove.

Do laptops need to be encrypted for SOC 2?

If laptops store or access sensitive data, auditors expect disk encryption and a way to prove it, usually through device management reports.

Is encryption enough to meet the Confidentiality criteria?

No. Confidentiality also covers identifying confidential information, limiting access, retention and secure disposal. Encryption is one control among several.

Conclusion

SOC 2 does not hand you an encryption recipe, but it does expect a deliberate, evidenced approach. Classify your data, protect it at rest and in transit with accepted methods, manage keys carefully, enforce settings automatically and keep dated proof. Do that, and encryption becomes one of the easier areas to defend in your examination.