What it is
Encryption controls in SOC 2 sit mainly under CC6.1, which covers logical access to systems and data, and CC6.7, which covers data transmission and movement. The auditor checks two things: that the control is designed well and that it ran across the period. A screenshot of an encrypted disk proves little alone. The auditor wants the inventory behind it and the key that unlocks it.
Expect checks in three areas. Data at rest covers databases, object storage, block volumes, backups and endpoints. Data in transit covers public endpoints, internal service calls, file transfers and admin sessions. Key management covers who can create, use, rotate and delete keys, and how those keys are protected. Secrets such as API tokens and database passwords fall into the same conversation because a strong cipher with a password in a git repo is not much of a control.
Cloud providers encrypt much of the physical layer by default, and that helps, but it does not finish your work. Your auditor will ask what you configured, what you can prove and how your team controls the keys. The provider's own SOC 2 report can support the infrastructure layer. It does not replace your evidence for the services and data you run on top.
How it works
Start with a data inventory and a simple flow diagram. The auditor picks a sample: the production database, a customer upload bucket, nightly backups, a data warehouse or a laptop. For each one, they ask where the data sits, which key protects it and who can decrypt it. If the diagram says data is encrypted but the bucket policy lets a broad group read the key, the control fails.
At rest, the auditor inspects settings for block storage, managed databases, object storage, backup vaults and endpoints. They look for encryption enabled at creation and on older volumes, customer managed keys versus provider managed keys, and whether snapshots inherit encryption. Good evidence is a console export or configuration file showing the resource, the encryption status and the key identifier. A policy statement alone is thin.
In transit, the auditor checks TLS versions, cipher suites and certificate handling on public endpoints. They may scan your hosts or review load balancer and API gateway settings. Internal traffic matters too: service to service calls, database connections and admin interfaces should not fall back to plain HTTP. For file transfers, SFTP or a VPN can count, but you need to show the configuration and who holds the credentials.
For keys, the auditor reads key policies, identity and access rules, rotation settings and deletion protection. They want separation between people who deploy systems and people who can use or delete keys. Rotation can be automatic in a cloud key service or a documented manual process. Evidence includes key policy JSON, rotation history, access review records and tickets for any exception. Secrets belong in a managed secret store, not in environment files copied around.
Why it matters for a business
Customers ask about encryption in security questionnaires long before they ask for the report. A clean SOC 2 report with clear encryption evidence shortens those reviews and gives sales a factual answer. It also forces your team to know where sensitive data lives, which helps during incidents and audits.
Encryption only reduces risk when the keys are controlled. A database encrypted with a key that every engineer can export is protected against a stolen disk, not against an insider or a leaked credential. Auditors know this and focus on key custody. That focus is useful: it pushes you to limit decrypt rights and log key use.
Shared responsibility is part of the story. If you rely on a cloud provider's default encryption, document that choice and the provider report you reviewed. If you manage your own keys, show the key hierarchy and the recovery plan. Losing a key can take data offline, so availability and encryption are connected.
Common mistakes
Claiming encryption everywhere without a data map. The auditor samples a legacy volume or an old bucket and finds it unencrypted. Inventory first, then fix the gaps you find.
Putting the key in the same account or project as the data, with admin rights for the whole team. That passes a checkbox and fails the key management test. Limit key use, separate duties and review access on a schedule.
Leaving TLS 1.0 or 1.1 on an old endpoint, or letting a certificate expire. Both show up in scans and incident tickets. Add certificate expiry monitoring and remove weak protocol settings.
Forgetting backups, snapshots, analytics copies and endpoints. These often sit outside the main application and hold the same customer data. Also avoid secrets in code, plaintext environment files or shared spreadsheets.
How to get started
Build the inventory and the flow diagram this week. List each data store, its encryption status, the key that protects it and the people who can decrypt. Mark the gaps and rank them by exposure.
Set a baseline you can defend: TLS 1.2 or higher on public endpoints, encryption at rest for production stores and backups, a managed key service with rotation, and a secret store for credentials. Write down any exception with an owner and a date.
Collect evidence as you go: configuration exports, key policies, rotation logs, TLS scan results and a short encryption policy. Test a restore from an encrypted backup so you know the key works. Put crypto changes through change management.
If you want a structured start, the SOC 2 readiness assessment from Cloudverg is a fixed price engagement at $7,500 that runs for three weeks and includes a gap assessment, evidence inventory and remediation roadmap. It is one option. A hands-on engineer or an independent CPA firm can also guide the work.
Frequently asked questions
Does SOC 2 require encryption?
SOC 2 does not name a specific cipher or require encryption on every system. The Trust Services Criteria expect controls that protect data in transit and at rest, and auditors test what you actually run. If a system lacks encryption, you need a documented compensating control and evidence it works.
What evidence does an auditor ask for on encryption?
They ask for configuration exports or screenshots that show encryption enabled, key identifiers and key policies, TLS settings, certificate inventories and rotation records. They may also request your encryption policy, a data flow diagram and access reviews for key users. Samples are common, so keep the evidence tied to specific resources.
Is encryption at rest enough for SOC 2?
No. Auditors look at data in transit, key management and access to decryption rights. A system encrypted at rest but reachable over plain HTTP or unlocked by a shared admin key will raise questions. Cover both states and show who can use the keys.