SOC 2 doesn't explicitly mandate a specific encryption algorithm. That surprises most people. But soc 2 encryption requirements still trip up healthcare vendors during audits because the Trust Services Criteria demand you prove your data protection controls are effective, and auditors have very clear expectations about what "effective" looks like in 2026. If you're running AES-256 for data at rest and TLS 1.2+ for data in transit, you're aligned with current benchmarks. Anything less, and you'll have questions to answer.

For healthcare vendors building integrations with EPIC EHR systems, encryption isn't optional or theoretical, it's a prerequisite for earning health system contracts. Hospitals and health networks evaluate your SOC 2 report before granting access to patient data through SMART on FHIR apps. A gap in your encryption controls doesn't just fail an audit; it kills deals. This is exactly why we built VectorCare's no-code platform with SOC 2 and HIPAA compliance baked in from the start, so vendors can focus on their product instead of chasing down cryptographic benchmarks.

This article breaks down what SOC 2 auditors actually evaluate when they review your encryption controls, how those controls map to the Trust Services Criteria, and the specific technical standards you need to meet. Whether you're preparing for your first audit or tightening controls ahead of a renewal, you'll walk away with a clear, actionable understanding of what's required and what's changed heading into 2026.

Why encryption shows up in SOC 2 audits

SOC 2 is built around the Trust Services Criteria (TSC), a framework developed by the AICPA that defines how service organizations protect customer data. Encryption shows up in audits because the TSC doesn't just ask whether you have security controls in place; it asks whether those controls actually reduce risk to an acceptable level. Auditors treat encryption as one of the clearest indicators that a company is serious about data protection, which is why it receives scrutiny in nearly every engagement. You can have strong access controls and detailed incident response plans, but if your data sits unencrypted or moves across networks without protection, auditors will flag it.

The Trust Services Criteria connection

The Confidentiality and Security categories are where encryption requirements live inside the TSC. The CC6 cluster of criteria, which covers logical access controls and data protection, is the specific area auditors probe when they examine how your system handles sensitive information. Meeting CC6.1 requires you to demonstrate that you've implemented controls to restrict logical access to information assets, and encryption is a primary mechanism for doing that. If you store patient data, financial records, or credentials without encryption, you're creating a gap that auditors will document as a finding.

Common Criteria 9.9 also directly addresses the protection of information during transmission. When auditors work through your controls for data in transit, they want to see that your transport layer security is current, correctly configured, and enforced. Using deprecated protocols like TLS 1.0 or 1.1 draws immediate attention because those protocols have known vulnerabilities that auditors are trained to look for. The comparison between your documented policies and your actual technical configuration is where many organizations get caught; your firewall rules and certificate configurations need to match what your written security policy says they do.

Meeting the Trust Services Criteria on paper isn't enough. Auditors pull configuration logs, certificate records, and key management documentation to verify that your written policies reflect what your systems actually do.

What auditors are really evaluating

Auditors aren't just checking whether encryption exists. They're evaluating whether your encryption controls are appropriate for the sensitivity of the data you handle. For healthcare vendors dealing with protected health information (PHI), this bar is significantly higher than it is for a standard SaaS company. HIPAA's Security Rule and SOC 2's soc 2 encryption requirements overlap in ways that force you to satisfy both simultaneously, and auditors who work with healthcare clients understand that overlap. They expect your controls to reflect the combined standard, not just one or the other.

When an auditor reviews your encryption posture, they focus on three areas: what you encrypt, how you manage the keys, and whether your configuration matches your stated policies. Weak key management is one of the most common findings in SOC 2 audits because it's easy to overlook during implementation. You can implement AES-256 across every database you run and still receive an adverse finding if you store encryption keys in the same location as the data they protect, skip documented rotation schedules, or fail to log and restrict access to key material. The algorithm alone doesn't satisfy the auditor; the full lifecycle around that algorithm does.

Healthcare vendors building EPIC integrations through SMART on FHIR apps face additional pressure in this area. Health systems conduct their own vendor security reviews before approving any EPIC integration, and they frequently request your SOC 2 report as part of that evaluation. A clean SOC 2 report with solid encryption controls accelerates those vendor reviews and removes a significant objection during contract negotiations. If your encryption posture has gaps, you'll lose deals before they reach legal review, not because a single audit finding disqualifies you, but because health system security teams use your SOC 2 report as a shortcut to assess vendor risk. Gaps in encryption controls signal that deeper problems may exist elsewhere in your security program.

What SOC 2 requires and what it does not

SOC 2 is principles-based, not prescriptive. That distinction matters enormously when you're preparing for an audit. The AICPA's Trust Services Criteria define the outcomes your security controls need to achieve, not the specific technical methods you must use to achieve them. This gives you flexibility, but it also puts the burden of justification on you. You have to demonstrate that the controls you've chosen are appropriate for the sensitivity of the data you handle, not just that they exist.

What the criteria actually say

The TSC doesn't contain a sentence that reads "you must use AES-256." What it does require, under CC6.1, is that you implement controls to protect information assets from unauthorized access. Encryption satisfies that requirement, but the criteria leave it to you and your auditor to determine whether your chosen approach is adequate. CC9.9 similarly requires you to protect information during transmission without naming a specific protocol. The practical outcome is that auditors interpret these criteria through the lens of current industry standards, and those standards currently point to AES-256 for data at rest and TLS 1.2 or higher for data in transit.

The gap between "SOC 2 doesn't require it" and "auditors expect it" is where most companies get caught off guard.

What SOC 2 does not require

SOC 2 does not require end-to-end encryption for every data flow in your system, nor does it demand that you encrypt data that poses no meaningful risk if exposed. You have room to make risk-based decisions about where encryption is and isn't applied, provided you document your reasoning. If you choose not to encrypt a specific category of data, you need a documented risk assessment that explains why the residual risk is acceptable. Auditors won't automatically flag the absence of encryption in low-risk contexts, but they will flag the absence of a documented rationale.

Understanding these boundaries helps you focus your soc 2 encryption requirements work on the areas that matter most: PHI, credentials, encryption keys, and any data that crosses a network boundary. Healthcare vendors integrating with EPIC through SMART on FHIR apps handle PHI by default, which means every data store and every transmission path your application touches falls into the high-sensitivity category. You don't get to make a risk-based argument that patient data is low risk. That assessment is already made for you.

What auditors expect for encryption at rest

Encryption at rest protects stored data from exposure if someone gains unauthorized access to your physical infrastructure or cloud environment. For SOC 2 auditors reviewing your controls in 2026, the baseline expectation is AES-256, and anything weaker will generate questions. The audit isn't just a checkbox exercise; the auditor wants to see that your encryption covers every location where sensitive data lands, from your primary database to your log files.

The AES-256 standard

AES-256 is the current industry benchmark for data at rest, and auditors treat it as the floor, not the ceiling. The algorithm itself is widely adopted because it offers a 128-bit security margin against brute-force attacks, which places it well beyond the reach of any known attack vector. When you document your soc 2 encryption requirements compliance, the specific cipher and key length you use must appear in your written security policy. If your policy says AES-256 but your database configuration shows AES-128, your auditor will document that discrepancy as a finding.

Auditors cross-reference your written policies against your actual configuration exports. A mismatch between the two is treated as a control failure, not an administrative oversight.

Most cloud providers make AES-256 easy to implement at the storage layer. AWS, Azure, and Google Cloud all offer native encryption options for databases, object storage, and disk volumes that default to AES-256. Your job isn't necessarily to build encryption from scratch; it's to verify that the service-level encryption is enabled, document it, and confirm that your key management practices align with what the auditor expects.

What data sources auditors check

Auditors don't limit their review to your primary application database. They expect every location that holds sensitive data to have encryption at rest applied, and they will ask you to enumerate those locations. Common gaps include analytics pipelines, log aggregation platforms, and data warehouses that teams stand up quickly without running them through the same security review as production systems.

For healthcare vendors, PHI can appear in unexpected places: audit logs, error logs, and reporting tables frequently contain patient identifiers that teams don't always treat as sensitive. Your audit preparation should include a data inventory that maps where PHI lives across your entire environment, not just your core application. Backups and snapshots carry the same encryption requirement as live data, and auditors specifically ask about backup encryption because it's a common gap that teams overlook until the audit surfaces it.

What auditors expect for encryption in transit

Encryption in transit protects data as it moves between systems, whether that's a client browser connecting to your application, your app pulling patient records from an EPIC endpoint, or backend services communicating across your internal network. For SOC 2 auditors in 2026, the baseline expectation is TLS 1.2 at minimum, with TLS 1.3 increasingly treated as the preferred standard. Auditors aren't just confirming that you use TLS; they're verifying that your configuration actively rejects older, insecure protocols and cipher suites.

If your server accepts connections over TLS 1.0 or TLS 1.1, auditors will flag it, even if no one is currently using those connections.

TLS versions and cipher suite configuration

Your soc 2 encryption requirements posture for data in transit starts with knowing exactly which protocol versions your servers accept. Auditors run TLS scans against your endpoints during fieldwork, and they expect the results to match your written security policy. Accepting a deprecated protocol version is a straightforward finding that's easy to avoid, but it shows up in audits regularly because teams configure TLS once and don't revisit it as standards evolve.

Beyond the protocol version, cipher suite selection matters. Weak cipher suites that support export-grade encryption, RC4, or NULL ciphers introduce vulnerabilities even when you're running a current TLS version. Your configuration should explicitly disable weak suites and prioritize forward secrecy ciphers like ECDHE-based options, which ensure that a compromised private key can't be used to decrypt previously captured traffic. Microsoft and AWS both provide documented hardened TLS configurations you can use as a baseline.

Protocol	Auditor Expectation
TLS 1.3	Preferred; demonstrates current standards alignment
TLS 1.2	Acceptable with strong cipher suites
TLS 1.1	Flagged as deprecated; requires remediation
TLS 1.0 / SSL	Immediate finding; must be disabled

Certificate management and enforcement

Certificate validity and management is the second area auditors probe when reviewing your encryption in transit controls. Expired certificates are a common finding because organizations let renewal processes slip, especially for internal service endpoints that don't have a customer-facing alert system watching them. Your audit preparation should include a full certificate inventory that documents every certificate in use, its expiration date, and who owns the renewal process.

Auditors also verify that HTTPS is enforced across all endpoints, not just your primary application URL. Redirect rules must force HTTP connections to HTTPS rather than serving content over plaintext. Healthcare vendors handling PHI through SMART on FHIR integrations need to confirm this enforcement applies to every API endpoint their application exposes, including internal service-to-service calls that developers sometimes leave unencrypted under the assumption that internal traffic is inherently safe.

Key management and evidence auditors ask for

Encryption algorithms are only as strong as the controls around the keys that operate them. Auditors reviewing your soc 2 encryption requirements know this, and they treat key management as a separate area of scrutiny from the encryption configuration itself. Even if you run AES-256 across every data store and TLS 1.3 on every endpoint, weak key management practices will generate findings that undermine everything else you've built.

How auditors evaluate key management

Auditors look at the full lifecycle of your encryption keys: generation, storage, access, rotation, and destruction. Key generation must use a cryptographically secure random number generator, and your documentation needs to confirm this. Storage is where most organizations create problems: storing encryption keys in the same environment as the data they protect defeats the purpose of encryption entirely. Auditors specifically check whether your key management system is logically or physically separate from your application data, and whether access to key material is restricted to only the systems and personnel that require it.

Key rotation schedules are the second common gap auditors surface. Your written policy needs to define how frequently keys rotate, and your actual rotation logs need to prove you follow that schedule. If your policy says annual rotation but your key management system shows keys that haven't rotated in three years, you have a finding. Cloud-native key management services from providers like AWS Key Management Service or Azure Key Vault make automated rotation straightforward and produce the audit logs you need to demonstrate compliance.

Auditors don't accept verbal confirmation that keys rotate. They pull the rotation logs and verify the dates themselves.

Evidence you need to gather before the audit

Your audit preparation should include a dedicated evidence package for encryption controls. Collecting this documentation before fieldwork starts prevents delays and demonstrates organizational maturity. The core items auditors request include:

• Encryption policy documentation that specifies algorithms, key lengths, and rotation schedules for all data classifications
• Configuration exports from your database encryption settings, cloud storage services, and TLS endpoint configurations
• Key management logs showing access history, rotation events, and administrative actions on key material
• Certificate inventory with expiration dates, ownership assignments, and renewal records
• Risk assessment documentation for any data category where you've chosen not to apply encryption

Healthcare vendors handling PHI through EPIC integrations should treat this evidence package as a standing artifact that stays current, not something assembled only when an audit approaches. Health systems review your SOC 2 report during vendor evaluations, and a clean, well-documented controls environment signals that your security program is mature and actively maintained.

Final takeaways

Meeting soc 2 encryption requirements comes down to three things: knowing where your sensitive data lives, configuring your encryption controls to current standards, and keeping the documentation that proves it. AES-256 for data at rest and TLS 1.2+ for data in transit set the baseline, but auditors evaluate your full program, including key management, rotation logs, and certificate inventories, not just the algorithm you selected.

For healthcare vendors building EPIC integrations, the stakes are higher than a clean audit report. Health systems use your SOC 2 controls as a proxy for overall vendor risk, and gaps in encryption give procurement and security teams a reason to stall or reject your contract. Getting your compliance posture right before those conversations start removes a major friction point from every deal you pursue.

If you want HIPAA and SOC 2 compliance handled from day one, see how VectorCare builds it in from the start.