SOC 2 audits don't explicitly mandate a specific encryption algorithm, and that ambiguity trips up a lot of engineering teams. If you've been searching for SOC 2 encryption requirements, you've probably noticed that the Trust Services Criteria talk about "logical access controls" and "protecting information during transmission" without spelling out exactly which cipher suite to use. But make no mistake: auditors absolutely expect encryption, and showing up without AES-256 at rest or TLS 1.2+ in transit will raise immediate red flags.

The confusion is understandable. SOC 2 is a controls-based framework, not a prescriptive checklist. That means your organization has to demonstrate how it protects data, document why those choices are sufficient, and prove the controls actually work. For healthcare teams building EHR integrations, where HIPAA adds another compliance layer on top, getting encryption right isn't optional. At SoFaaS, we built our managed SMART on FHIR platform on SOC 2 Type II compliant infrastructure with end-to-end encryption baked in, specifically so healthcare innovators don't have to solve this problem from scratch.

This guide breaks down what auditors actually look for in 2026, covers the specific technical standards you need for data at rest and in transit, and walks through practical implementation steps so you can pass your audit without surprises.

What SOC 2 means by encryption requirements

SOC 2 is built on the AICPA's Trust Services Criteria (TSC), which means it describes what outcome you need to achieve rather than exactly how to achieve it. When auditors talk about encryption requirements, they're referring to the controls your organization uses to protect sensitive data from unauthorized access, whether that data is sitting in a database or moving across a network. The framework doesn't hand you a list of approved algorithms. Instead, it evaluates whether your choices are reasonable, documented, and consistently enforced.

Understanding this distinction matters because many teams assume "no specific algorithm required" means "any approach is acceptable," and that assumption can cost you an audit.

The principle-based approach and what it demands

The AICPA designed SOC 2 to be flexible enough to apply across industries and organization types. That flexibility means you have real discretion in which encryption tools and protocols you select. What you don't have discretion over is whether your controls actually protect the data they're meant to protect. Auditors will ask for evidence that your choices align with current industry standards, and "we used whatever came with the server" won't hold up under scrutiny.

In practical terms, your encryption decisions need to follow recognized standards published by bodies like the National Institute of Standards and Technology (NIST). NIST's guidelines on cryptographic standards provide the benchmarks that auditors use as a reference point, even when SOC 2 itself doesn't cite them directly. If your encryption approach deviates from NIST guidance without a documented justification, expect follow-up questions from your auditor.

What "protection of information" actually covers

The CC6 logical and physical access controls section of the TSC is where most SOC 2 encryption requirements live in practice. CC6.1 requires your organization to implement logical access security measures to protect against threats from sources outside its system boundaries. CC6.7 specifically addresses data transmission, requiring controls that protect information during delivery or communication. Together, these two criteria cover the two scenarios you care most about: data at rest and data in transit.

Your auditor won't simply confirm that encryption exists somewhere in your stack. They'll verify that it applies to all relevant data flows and storage locations, that your encryption keys are managed securely, and that no part of your environment has disabled or bypassed those controls. A single unencrypted database table or an unprotected API endpoint is enough to generate a finding, even if every other system is locked down correctly.

The common misconception about optional encryption

Many engineering teams read SOC 2's principle-based language and conclude that encryption is optional as long as they can describe compensating controls. That reading is incorrect in practice. Auditors treat encryption as a baseline expectation, not as one option among several. If you choose not to encrypt sensitive data, you need an exceptionally strong compensating control narrative, and in most cases the auditor's findings will still reflect the gap regardless.

The situation becomes even more direct for organizations handling protected health information (PHI) under HIPAA. In that context, encryption at rest and in transit isn't just an auditor's expectation backed by professional standards, it's tied to federal regulation. For teams building healthcare applications that connect to EHR systems, your SOC 2 controls and your HIPAA safeguards need to be designed together from the start, not treated as separate compliance workstreams that happen to overlap.

Where encryption fits in the Trust Services Criteria

The Trust Services Criteria are organized into five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations pursuing SOC 2 include Security as a required category, while the others are optional depending on the commitments they make to customers. Encryption touches multiple categories, but its heaviest concentration sits inside the Security category, specifically within the Common Criteria (CC) cluster that governs logical access and data protection.

The Security category and its role in encryption

The Security category is the foundation of every SOC 2 audit. It uses the Common Criteria (CC) series, and those criteria define the controls your system needs to protect against unauthorized access, data loss, and disclosure. When auditors review your SOC 2 encryption requirements, they work through the CC series to determine whether your controls hold up across each part of your environment.

CC6.1 covers the controls you use to restrict logical access to your systems. Auditors look here to confirm that access to encrypted data requires authenticated authorization, and that your key management process ties directly into those access restrictions. CC6.7 is the criterion that addresses data in motion, requiring your organization to demonstrate that information is protected during transmission between systems, both internally and externally. These two criteria work together, and a gap in either one will show up in your audit report.

CC6.7 is the criterion auditors look at most closely when they want to verify your in-transit encryption controls, so map your TLS configuration directly to it in your control documentation.

The Confidentiality category and what it adds

Organizations that include the Confidentiality category in their SOC 2 scope face additional scrutiny on how they handle data that has been designated confidential. Criterion C1.1 requires that confidential information is protected during collection, use, and retention, and C1.2 addresses how that information is disposed of when no longer needed. Both criteria assume encryption as a supporting control.

If your application stores sensitive customer data or protected health information (PHI), adding the Confidentiality category to your audit scope signals to your customers that you take data protection seriously beyond the baseline Security criteria. It also forces your team to build a clearer internal classification system, since you need to identify which data qualifies as confidential before you can document how it's protected. That classification work pays off during the audit because it gives the auditor a clear map between your encryption controls and the data they cover.

What auditors expect for data in transit and at rest

When auditors evaluate your SOC 2 encryption requirements, they split their review into two distinct areas: data moving between systems and data sitting in storage. Each area has its own set of accepted standards, and auditors expect you to address both with documented, enforceable controls, not informal practices that happen to be working. The audit process isn't a theoretical discussion about your intentions; it's a review of evidence that your controls exist, function as described, and cover your entire environment.

Data in transit: TLS standards and protocol versions

For data moving across any network, auditors expect TLS 1.2 as the minimum acceptable protocol, and most auditors in 2026 will flag TLS 1.0 or TLS 1.1 as deprecated and insecure. Your organization should be running TLS 1.3 wherever your infrastructure supports it, since it removes several vulnerable cipher suites that existed in earlier versions and improves handshake performance at the same time.

If your environment still accepts TLS 1.0 or 1.1 connections, disable them before your audit begins, because an auditor who finds legacy protocols enabled will treat it as an active finding rather than a minor note.

Your auditor will want to see configuration evidence, not just a policy document stating that TLS is required. That means TLS scan results or server configuration exports that confirm acceptable protocols are enabled and weak ones are disabled. For systems that interact with EHRs or carry protected health information (PHI), this documentation needs to cover every endpoint, including internal service-to-service communication, not just public-facing APIs.

Data at rest: algorithms, key management, and coverage

For stored data, AES-256 is the accepted standard, and auditors will look for it across databases, file storage, backup systems, and any portable media that could leave your environment. Using AES-128 isn't automatically disqualifying, but you need a clear justification for why you chose it, and that justification will receive scrutiny.

Key management is where many teams fall short. Encrypting data is only half the requirement; you also need to demonstrate that your encryption keys are stored separately from the data they protect, that access to keys is restricted and logged, and that your rotation schedule is documented and followed. Auditors will ask specifically about how keys are stored, who can access them, and what happens when a key needs to be rotated or retired. Platforms like AWS Key Management Service or Azure Key Vault provide audit trails that map directly to these control requirements and make evidence collection straightforward.

How to implement encryption controls in real systems

Satisfying SOC 2 encryption requirements starts with translating policy into actual system configuration. A written statement that your organization encrypts data at rest and in transit means nothing to an auditor unless you can point to specific platform settings, key management controls, and network configurations that back it up. Implementation is where documentation becomes auditable evidence.

Start with your cloud storage and database layer

Most teams store sensitive data across a combination of managed databases, object storage, and backup systems. Each of those locations needs encryption at rest enabled at the platform level, and you need to verify it rather than assume it. AWS, Azure, and Google Cloud all provide default encryption for storage services, but the specific configuration, particularly around key ownership, matters for your audit.

Turning on a cloud provider's default encryption is a good start, but auditors will ask whether you control the keys or rely entirely on provider-managed keys, so confirm that distinction before your audit.

For databases, enable Transparent Data Encryption (TDE) where your platform supports it, and ensure that backups inherit the same encryption settings as the primary data store. An unencrypted backup of an encrypted database is still an audit finding regardless of how well the live environment is protected.

Manage keys as a separate control

Key management is its own discipline, and treating it as secondary will create gaps that auditors find quickly. Store your encryption keys in a dedicated key management service rather than alongside the data they protect, and restrict access to only the systems and roles that require it. Services like AWS Key Management Service and Azure Key Vault provide the access logging and automated rotation capabilities that auditors expect to see tied to your control documentation.

Your key rotation schedule needs to be documented and enforced, not just described in a policy. Set automated rotation where the platform supports it, and log every key access event so you can produce that trail during audit review.

Enforce TLS across internal and external traffic

External API endpoints are the obvious place to enforce TLS 1.2 as a minimum, but internal service-to-service traffic is where teams most often leave gaps. Mutual TLS (mTLS) is the recommended approach for internal communication in environments that carry sensitive data, since it authenticates both sides of the connection rather than just the server.

Run a TLS configuration scan across all endpoints before your audit and document the results. Reports that confirm protocol versions and cipher suites give you evidence that maps directly to your CC6.7 control documentation.

How to document and test encryption for SOC 2

Auditors don't take your word for it. When they review your SOC 2 encryption requirements, they expect a documented control framework that maps your encryption decisions to specific Trust Services Criteria, along with test evidence that proves those controls are operating as described. Documentation and testing aren't administrative overhead you complete after the fact; they're the core of what an auditor reviews.

Build a control inventory that maps to the TSC

Your control inventory should list every encryption control your organization relies on and tie each one directly to a TSC criterion. For encryption specifically, that means mapping your at-rest controls to CC6.1 and your in-transit controls to CC6.7. Each entry in the inventory needs to describe what the control does, which systems it applies to, who owns it, and how frequently it's reviewed.

A control inventory that lists encryption generically without system-level specifics will leave auditors asking follow-up questions that slow down your review process.

Include supporting evidence references alongside each control entry. If your database uses AES-256 through TDE, link to the configuration screenshot or the platform-generated encryption status report. If your TLS configuration is enforced via a load balancer policy, attach the policy export. The goal is to give auditors a direct line between your written controls and the technical reality of your environment, with no gaps to fill in manually.

Test your controls before the auditor does

Internal testing is what separates organizations that pass cleanly from those that accumulate findings. Before your audit window opens, run a TLS scan across all endpoints using a recognized testing tool, and review the output to confirm that no deprecated protocol versions remain enabled. For data at rest, pull encryption status reports from your cloud storage, database, and backup systems to verify that coverage is complete rather than assumed.

Key management controls need their own test cycle. Verify that key access logs are generating correctly, that rotation schedules are executing on time, and that no keys have exceeded their documented rotation period. Platforms like AWS Key Management Service surface this information in their dashboards, so your evidence collection can pull directly from those reports rather than requiring manual verification.

Document the results of every test run, including the date, the scope, who performed the test, and what remediation was taken if issues appeared. Auditors value a consistent testing cadence with documented outcomes far more than a single comprehensive test run completed the week before the audit.

Keep your encryption program audit-ready

Meeting SOC 2 encryption requirements is not a one-time project you finish before an audit and then set aside. Your encryption program needs to run continuously, with regular testing cycles, documented key rotation, and updated control evidence that reflects your current environment. Auditors look for consistency over time, and a clean audit history is built from disciplined, ongoing maintenance rather than last-minute preparation.

For healthcare teams connecting applications to EHR systems, encryption controls also need to stay aligned with both SOC 2 and HIPAA as your infrastructure evolves. Every new integration, new data store, or updated protocol version is a change that your control documentation needs to reflect immediately. Staying ahead of those changes keeps your audit preparation straightforward and avoids findings that stem from gaps between your policies and your actual systems. If you want infrastructure that handles encryption and compliance from day one, launch your SMART on FHIR integration on the VectorCare platform.