SOC 2 Encryption Requirements for SaaS: What to Protect and Prove
Map SOC 2 encryption requirements to SaaS data paths, key management, and source evidence. Avoid promising a fixed algorithm or treating a setting as proof of control operation.
SOC 2 encryption requirements start with the data your SaaS service handles and the controls you promise to operate. Protecting data at rest and in transit may be part of those controls, but no one encryption setting covers every database, backup, export, and network path. Map each path, choose a suitable mechanism and key owner, then collect source evidence that shows the control works for the scoped service. Ask the CPA firm what it will need to examine.
What does SOC 2 require for encryption?
The AICPA Trust Services Criteria provide benchmarks for evaluating controls over Security and any selected optional categories. They are not a universal cipher list or a preset cloud configuration. Management designs controls for its service boundary, risks, system requirements, and customer commitments; the CPA firm examines the controls and supporting evidence.
Encryption can help protect information, but it does not replace access control, monitoring, secure handling, or deletion. A database may be encrypted on disk while an overly broad application role can still read every row. The SOC 2 controls guide shows how to define the owner, activity, and source evidence for each control instead of adopting a generic “encryption enabled” row.
Where can customer data leave an encrypted path?
Start with one real customer-data flow. Follow it from the browser or API through every service, storage system, backup, support workflow, and export. Mark where it is stored, transmitted, decrypted, or copied. A small team can use this worksheet:
| Path to check | Control question | Source evidence to test |
|---|---|---|
| Client to application | Which connection protects the request and response? | Live endpoint configuration and a dated connection test |
| Application to database or queue | Which internal links carry the data, and where can it be read? | Service configuration, network settings, and access rules |
| Database and object storage | Which scoped resources store the data, and is protection enabled there? | Resource inventory, provider configuration export, and change history |
| Backups and snapshots | Do copies use approved protection and a controlled restore path? | Backup policy, storage configuration, job results, and restore-test record |
| Support exports and local copies | Who can create a copy, where does it go, and when is it removed? | Export procedure, approved destination, access record, and deletion result |
| Keys and secrets | Who can use, change, rotate, or recover the keys? | Key-system configuration, access review, rotation or replacement record |
The table is a discovery aid, not an AICPA list of mandatory artifacts. Remove paths that do not exist and add those your product actually uses. Keep the SOC 2 scope and data diagram current when engineers add a new service or export. A setting on one storage bucket cannot speak for a copy made by a support script.
How should you handle keys and secrets?
The NIST key management guidance explains why protection depends on the key as well as the algorithm. OWASP’s cryptographic storage guidance recommends planning key generation, storage, access, rotation, and retirement as part of the system design. These are technical references for engineering, not extra SOC 2 criteria.
For each key or key service, record the owner, authorized roles, dependent resources, rotation or replacement trigger, recovery process, and source of the audit trail. Test whether a person who leaves the team loses access, and whether an old key can still decrypt data that must remain available. Keep plaintext keys, passwords, tokens, and recovery codes out of Git. OWASP warns against checking keys into version control; moving a key to a private repo does not make it safe.
If you use a cloud provider’s managed encryption, state which work the provider performs and which settings and access decisions remain yours. The cloud-provider SOC 2 guide explains why the provider’s report does not cover your own configuration and operation.
What evidence shows the control worked over time?
Test the evidence path before the candidate Type 2 period. Export a scoped resource list, inspect a representative configuration, and verify that your retrieval steps show the account, environment, resource, setting, and time. Then test how changes to that setting are reviewed. If a resource can be created without the expected protection, record the gap and the owner who will fix it.
For a Type 1 date, a current configuration may support a point-in-time question. For Type 2, the CPA firm may need to understand whether the control operated during the specified period, including changes and exceptions. A new screenshot at fieldwork cannot recreate an earlier configuration. Keep dated source exports, change records, review results, and any exception follow-up that match the actual control. The SOC 2 evidence collection workflow shows how to connect those artifacts to the right source and dates.
Do not send raw data or key material just because the CPA firm asks for proof. Confirm its specific request and use an approved transfer channel. Keep sensitive exports in the right source system or restricted storage, with a safe evidence reference where possible. The evidence repository guide covers the limits of putting artifacts in Git.
Does encryption select the Confidentiality category?
No. Security’s Common Criteria form the SOC 2 baseline. Confidentiality is an optional category about information designated as confidential; it appears in the report only when included in the engagement scope. A team might use encryption controls under Security without proposing Confidentiality, or propose Confidentiality because the report user needs its additional criteria examined. The Confidentiality versus Privacy guide shows how to make that report decision from information flows and commitments.
You can keep the data-path map, proposed controls, key-system references, and reviewed evidence links in FileGRC’s Git-native GRC workspace. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. Starter records are proposals, not compliance claims. FileGRC does not encrypt your infrastructure, store live secrets, run source systems, perform the SOC 2 examination, or decide whether evidence is sufficient. Management operates the controls; the CPA firm makes the examination judgments.
Run your SOC 2 program as files in Git.
Keep policies, controls, work, and evidence indexes in a repository your team and agents can inspect. Add optional FileGRC Autopilot email and Slack reminders to keep work moving.
Frequently asked questions
Does SOC 2 require encryption at rest and in transit?
SOC 2 evaluates controls against the applicable Trust Services Criteria, scoped risks, and service commitments. Encryption often supports protection of stored and transmitted information, but the control design and evidence must fit the actual service. Confirm the planned controls with the CPA firm rather than relying on a generic checklist.
Does SOC 2 require AES-256 or a specific TLS version?
The AICPA Trust Services Criteria do not set one universal cipher, key length, or TLS version for every SOC 2 report. Choose current, suitable mechanisms for your risks and commitments, document them, and verify their configuration and operation in each scoped path.
Is cloud-provider encryption enough for SOC 2?
A provider setting may protect a scoped storage service, but it does not establish coverage for every database, backup, export, local copy, or network path. Check the provider responsibility, your configuration, key access, and the evidence your company can retrieve.
Is a screenshot of an encryption setting enough evidence?
A dated screenshot may show one configuration at one time. It may need a source export, resource inventory, change history, key-access review, and proof that the setting covered the right resources during the report period. The CPA firm decides whether the evidence is sufficient.
Can encryption keys or secrets go in a FileGRC repository?
Do not put plaintext credentials, private keys, tokens, or recovery codes in Git. Keep them in an approved key or secrets system. FileGRC can hold safe control records and evidence references; any retained ciphertext must follow the company's approved access, key, and rotation rules.
Does encryption mean the Confidentiality category is included?
No. Encryption is a possible control for protecting information. A SOC 2 report includes Confidentiality only when that category is selected in the engagement scope and its criteria are examined. Check the report user's request and the CPA firm's agreed scope.