Does SOC 2 require encryption? What the criteria say and what auditors check

Updated 25 October 2026

Not by name. No Trust Services Criterion lists encryption, an algorithm or a key length as a mandatory control. The criteria ask that you protect data from unauthorized access, restrict how it moves, and, if Confidentiality is in your scope, protect confidential information, and encryption is the ordinary way to do all three. The three outside guides cited here agree on that, so an auditor is likely to ask how data is protected at rest, in transit and on laptops, and how the keys are managed. The part that binds you most is your own policy: whatever it says you encrypt, and how often you rotate keys, is what gets tested against records.

Short answer: not named in the criteria, and expected in practice

A SOC 2 report is written by a CPA firm after it examines your controls against the Trust Services Criteria. Those criteria describe outcomes and leave the means to you. Three guides on this exact question land in the same place on the requirement and differ on detail:

All three publishers have a commercial interest in compliance work, and their baselines are their own advice, so read them as one side. They agree on the fact that matters: there is no SOC 2 rule that says "encrypt with this algorithm". They also point to the same practical risk, which is that an auditor or a customer's security review will ask what protects the data and expect a specific answer you can show. None of this replaces the criteria themselves, so confirm wording with your CPA firm.

The criteria encryption supports

The generated Encryption and Key Management Policy is mapped to two criteria, and a third applies when you add the Confidentiality category to your scope:

• CC6.1 (Logical access security): The company protects its systems and data with identity, authentication, authorization, encryption and network controls that are designed around what needs protecting.
• CC6.7 (Data in transit and on removable media): Data is protected while it moves: encrypted in transit, restricted from being copied to unmanaged devices or removable media, and shared only through approved channels.
• C1.1 (Identifying and protecting confidential information): The company defines what counts as confidential, labels or classifies it, and applies handling and retention rules so it stays protected for as long as it is kept.

The guides do not map encryption to these criteria identically, and it is worth knowing before an auditor raises one. All three tie the transmission criterion CC6.7 to data in transit. SOC2Auditors.org puts encryption at rest under CC6.1, and QCecuring ties both TLS and encryption at rest to CC6.1. Agency lists CC6.7 for transit, C1.1 for protecting confidential information at rest and in transit, and also maps at-rest encryption to the availability criterion A1.2, which is its own reading. A criterion mapping is an interpretation. What an auditor tests is how your described controls meet the criteria in your scope, and the SOC 2 controls list shows how the criteria group.

What to encrypt, and the evidence to keep

The criteria leave the list to you, so the list is your policy's scope. These are the places a policy like the one below covers, with the evidence that usually answers the question.

SOC2Auditors.org describes the evidence in three layers: the policies, the current configuration, and, for a Type II report, operating evidence such as key access logs, certificate records and checks that new resources were encrypted. It adds that a screenshot with no period attached is a Type I artifact (SOC2Auditors.org). That is the author's reading, and it matches how a Type II report looks at a period rather than a date. The SOC 2 evidence checklist covers how to collect evidence across a period.

What the generated policy commits you to

A policy is a statement of what you do, and the auditor tests it against records. The excerpts below are not written by hand. They are rendered from the policy template for the Northwind Cloud Inc sample intake, so they change when the template does. Company, cloud and tool names in them are the sample's.

Data in transit

Encryption and Key Management Policy, 4.1: Data transmitted over public networks, between Northwind and its users, and between services across a network trust boundary is encrypted with TLS 1.2 or higher, TLS 1.3 preferred. Public endpoints enforce HTTPS, send HTTP Strict Transport Security headers with at least a one-year max-age, and use plaintext HTTP only to redirect; other plaintext protocols are prohibited.

Encryption and Key Management Policy, 5.6: TLS review. Each quarter Engineering scans every public Northwind endpoint with an external TLS analysis tool, confirms a grade-A-equivalent result, disables any weak cipher suites or protocol versions and records the results. Certificate expiry alerts fire at 30 and 7 days.

Data at rest

Encryption and Key Management Policy, 4.2: All production data at rest on AWS and Vercel, including databases, object storage, volumes, snapshots, backups and log storage, is encrypted with AES-256 or a provider-equivalent algorithm, enabled before any data is written. Stores holding customer data use keys held in the provider's key management service, never keys embedded in application code.

Encryption and Key Management Policy, 4.11: Data classified Confidential or Restricted under the Data Classification and Handling Policy is encrypted at rest and in transit without exception, including when exported, emailed, shared with vendors or backed up.

Backups and vendors

Encryption and Key Management Policy, 5.9: Backup and vendor verification. Engineering confirms that backups in AWS Backup use a key separate from the primary data key and that restore tests decrypt successfully. Vendor reviews confirm each vendor encrypts Northwind Cloud Inc data in transit and at rest to this standard, with evidence recorded for Supabase, Stripe, Datadog and Slack.

Laptops and phones

With a device management tool named: Encryption and Key Management Policy, 4.9: All laptops and mobile devices used for company work have full-disk encryption enabled, enforced and reported through Kandji. Approved removable media is encrypted with AES-256.

With none named: Encryption and Key Management Policy, 4.9: All laptops and mobile devices used for company work have full-disk encryption enabled. Approved removable media is encrypted with AES-256.

With none named: Encryption and Key Management Policy, 5.7: Endpoint verification. Each quarter every person attests that full-disk encryption is enabled on their devices; People Operations tracks completion and escalates non-compliance to the Security Owner within 7 days.

The device wording changes with your answer to the device management question. See does SOC 2 require MDM for the evidence an auditor asks for on laptops and phones, and the no-tool path.

The policy also covers cryptographic review (5.10): at each policy review the Security Owner compares the approved algorithm list with current NIST and industry guidance and records a migration plan for anything nearing deprecation. Data classed Confidential or Restricted under the Data Classification and Handling Policy is covered by 4.11 above, and the Backup and Recovery Policy is where backup schedules and restore tests live.

Algorithms and versions: your choice, written down

Because the criteria set no algorithm, the specifics in your policy come from you or from the template you adopt. The Policyseed templates commit to TLS 1.2 or higher with TLS 1.3 preferred, AES-256 or a provider-equivalent algorithm at rest, and an approved algorithm list that prohibits older options. That is the template's position. It is in line with what the guides above recommend, and it is not a SOC 2 rule, so if you run something different, change the sentence before you adopt it. For reference, the rendered approved list reads:

Encryption and Key Management Policy, 4.3: Approved algorithms are AES-128 or AES-256 in GCM or another authenticated mode, ChaCha20-Poly1305, RSA of at least 2048 bits, ECDSA and ECDH on P-256 or P-384, Ed25519, X25519 and SHA-256 or stronger. MD5, SHA-1 for signatures, DES, 3DES, RC4, RSA below 2048 bits, SSL, TLS 1.0 and TLS 1.1 are prohibited. Northwind Cloud Inc does not implement custom cryptographic algorithms or protocols.

The risk to avoid is an aspirational sentence. A policy that says AES-256 everywhere while a legacy database sits unencrypted gives the auditor a ready-made finding, whereas a narrower sentence plus an approved exception for the legacy system is easier to defend.

Key management, where the sources focus

Encryption is only as strong as the way its keys are handled, and the guides stress this. Agency says key management is where encryption findings most commonly occur in its experience (Agency). SOC2Auditors.org describes a lifecycle of generating, storing, distributing, rotating and destroying keys, ideally in a cloud key management service or hardware module with restricted access and logged use (SOC2Auditors.org). QCecuring lists the things an auditor checks: no keys in plaintext configuration files, restricted access, a defined rotation schedule and destruction procedures (QCecuring).

On rotation the sources disagree. Agency's baseline table lists annual rotation as a minimum with automatic rotation preferred, while SOC2Auditors.org states that the criteria mandate neither an annual nor a 90-day period, so the interval is a policy choice. Both can be true: the criteria set no interval, and a publisher can still recommend one. The generated policy makes its own choice and states it:

Encryption and Key Management Policy, 4.4: Encryption keys are generated inside the cloud provider's key management service or an equivalent hardware-backed service and never leave it in plaintext. Application data uses envelope encryption with data keys wrapped by a root key in the key management service. Key material is never exported or committed to GitHub.

Encryption and Key Management Policy, 4.6: Rotation follows a defined schedule: key management root keys at least annually with automatic rotation where supported; broadly privileged service credentials and API tokens every 90 days; other application secrets at least every 12 months; and any key or secret immediately when compromise is suspected or when a person with direct access leaves or changes role.

Encryption and Key Management Policy, 5.1: Inventory. Engineering maintains an inventory of every key management key, secrets manager entry, SSH key, signing key and TLS certificate with owner, purpose, location, rotation schedule and last rotation. It is reviewed quarterly against live configuration on AWS and Vercel and in GitHub Actions; anything unrecorded is documented or removed.

The inventory in 5.1 is the evidence base for the rest. Each rotation is recorded in it, so the control is shown by dated entries rather than by a policy sentence. Write a schedule you can keep, because the schedule you write is the one that is tested.

When something cannot be encrypted yet

Every real environment has a gap: a legacy integration that cannot speak TLS 1.2, a vendor tool that stores exports unencrypted, an old backup. The template's exceptions section handles this with a written request that names the system, the risk, the compensating controls and a remediation date, approved by the Security Owner, and by Executive Management too when customer data is involved. Approved exceptions are recorded in the exception register, last no more than 12 months and are reviewed at each policy review. The free policy exception register is built for this, and SOC 2 exceptions and qualified opinions explains how the CPA firm treats a control that did not operate. Whether an encryption gap becomes an exception in a report is the firm's decision, not ours.

Before a customer asks

Encryption questions turn up in customer security reviews as well as in audits, and the answer should say the same thing your policy does. The free security questionnaire answers tool drafts answers from your generator answers and the policies generated from them, which keeps what you send customers consistent with what you wrote. To see how your whole posture looks first, take the free SOC 2 readiness assessment. If you want the policy wording tailored to your stack, the Audit Kit ($59, one time) tailors all 22 policies from your answers. None of these tools encrypts anything for you or replaces the CPA firm's examination.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.