Contrary to popular belief, SOC 2 does not mandate a strict list of cryptographic controls. Instead, it evaluates whether an organization has implemented appropriate encryption controls based on risk. That distinction matters: auditors care less about whether you check a specific box and more about whether your encryption strategy effectively protects sensitive data.
This guide breaks down how encryption fits into SOC 2 compliance, where auditors look for it, and how to design encryption controls that hold up during a SOC 2 Type I or SOC 2 Type II audit.
What “SOC 2 encryption requirements” really means
The System and Organization Controls 2 (SOC 2) framework was created by the American Institute of Certified Public Accountants (AICPA) to help service organizations demonstrate that their systems are secure and trustworthy.
SOC 2 assessments evaluate controls against the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. The AICPA’s 2017 Trust Services Criteria (updated with revised points of focus in 2022) is the document auditors reference when evaluating your controls.
But here’s the key nuance:
SOC 2 is a controls report, not a prescriptive encryption standard.
Instead of dictating exact technologies, SOC 2 asks auditors to determine whether controls are appropriately designed and operating effectively to meet the Trust Services Criteria. This means encryption is often expected—especially for sensitive or regulated data—but it’s not universally “required” in every scenario.
| Scenario | Encryption expectation |
|---|---|
| Public marketing website | TLS likely required |
| Internal operational logs | May depend on risk classification |
| Customer database with PII | Encryption almost always expected |
The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t, even if your encryption is technically sound, expect follow-up questions.
How auditors evaluate “appropriate” encryption for your risk profile
SOC 2 audits are risk-based. Auditors don’t walk in with a checklist of mandatory algorithms. Instead, they assess whether your encryption posture makes sense given the data you handle.
They typically ask questions like:
- What types of data does the system process?
- How sensitive is that data?
- What threats could expose it?
- What encryption controls mitigate those risks?
Organizations that process PII, financial records, or proprietary customer data will be expected to demonstrate stronger encryption controls than a company that only handles non-sensitive internal metrics.
Evidence often includes encryption policies, architecture diagrams, key management procedures, configuration evidence from cloud services, and monitoring and audit logs. The point isn’t just having encryption—it’s having evidence that encryption is in place and working as described. If you’re working from a SOC 2 compliance checklist, make encryption evidence a line item, not an afterthought.
For a SOC 2 Type I, auditors evaluate control design at a single point in time. They’re asking: “Are these controls designed in a way that should work?”
For a SOC 2 Type II, auditors test whether encryption controls operated consistently over time, typically across a 6–12 month period. This is where SOC 2 Type II continuous monitoring becomes essential. It’s one thing to set up encryption correctly on a Tuesday—it’s another to prove it was running properly every day for the last nine months.
The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t—even if your encryption is technically sound—expect follow-up questions.
Criterion | Role of encryption | Key focus |
Security (mandatory) | Primary | TLS for network communication, secrets protection, key management, access control enforcement |
Confidentiality | Primary | Protecting sensitive data at rest (e.g., AES-256, TDE) and in transit |
Privacy | Important | Encrypting PII, credentials, and identity documents; works alongside retention and data minimization controls |
Availability | Supporting | Encrypted backups, secure recovery data |
Processing Integrity | Supporting | Tamper protection during data transmission and processing |
Security is the only mandatory criterion in every SOC 2 audit, but if you’ve included Confidentiality or Privacy in your scope, encryption becomes a central control,not a supporting one. For organizations weighing SOC 2 against other standards, our comparison of ISO 27001 vs SOC 2 can help clarify the differences.
Encryption scope: what auditors will examine
Auditors evaluate encryption within the boundaries you define. That means scoping decisions matter as much as the technical implementation.
A mature SOC 2 environment classifies data into tiers,public, internal, confidential, and regulated,and applies encryption requirements accordingly. Customer data almost always receives the strictest protections, while internal operational metrics may be risk-based. If you haven’t built a formal data classification policy, expect auditors to flag that gap.
Data type | Encryption expectation |
Customer database | Mandatory encryption |
Employee HR records | Strong encryption |
Internal monitoring metrics | Risk-based |
Two scoping pitfalls that auditors flag regularly: production data copied into staging or development environments without encryption (if real data is present, it needs production-grade protections), and unclear cloud shared responsibility. Cloud providers operate under shared responsibility models,infrastructure security may be the provider’s job, but data encryption configuration is almost always yours. Organizations using services like AWS KMS, Azure Key Vault, or Google Cloud KMS must demonstrate what the provider manages, what they manage, and how both are verified.
Data in transit and at rest: what you need to encrypt
In transit
The industry standard is TLS 1.2 or TLS 1.3 for any data crossing a network boundary,external APIs, admin portals, and internal microservices where the risk justifies it. The rule is simple: if sensitive data moves between systems, it should be encrypted. Auditors increasingly ask about internal service-to-service traffic, not just external connections. Organizations using service mesh frameworks or zero-trust models are well positioned here.
Don’t overlook remote access (VPNs, bastion hosts, zero-trust gateways), file transfers (SFTP over plain FTP), and certificate lifecycle management,an expired TLS certificate that causes an outage is both an availability problem and evidence that controls aren’t operating effectively.
At rest
Encryption at rest protects stored data from unauthorized access. The most common implementations include:
- Databases: Transparent Data Encryption (TDE), column-level encryption, or application-level encryption,typically using AES-256
- Cloud storage: server-side encryption, client-side encryption, or envelope encryption (where a data encryption key is itself encrypted by a key encryption key)
- Endpoints: full-disk encryption on employee laptops and mobile devices, enforced via MDM
- Secrets: credentials and API keys stored in dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault) instead of config files or plaintext environment variables
- Backups: encrypted backups with restricted restore access and defined retention schedules. Some organizations use crypto-shredding,destroying encryption keys to render stored data permanently unreadable
The key question auditors ask isn’t which algorithm you use,it’s whether you can demonstrate it’s actually configured and running where it should be.
Encryption key management
If there’s one area where SOC 2 audits succeed or fail on encryption, it’s key management. Strong encryption with weak key management is a contradiction,and auditors know it.
They evaluate centralized key management (via services like AWS KMS, Azure Key Vault, Google Cloud KMS, or HSMs for high-security environments), rotation policies (annually at minimum, with revocation capabilities for compromised keys), separation of duties (key administrators, developers, and the security team should have distinct roles and permissions), and audit logging of key creation, usage, and administrative changes.
Customer-Managed Keys (CMK) and Bring Your Own Key (BYOK) are available on many platforms but are not required for SOC 2 compliance. Managed KMS services are typically sufficient.
Cryptography standards auditors commonly expect
While SOC 2 doesn’t mandate specific algorithms, these are the widely accepted baselines:
Cryptographic control | Common standard |
Transport encryption | |
Symmetric encryption | |
Hashing | |
Asymmetric encryption | RSA or ECDSA |
Auditors also expect weak and deprecated protocols to be disabled,SSL 3.0, TLS 1.0/1.1, DES, 3DES, MD5, and SHA-1 should not be active. Some organizations in government or regulated sectors adopt FIPS 140-3 validated modules, but most SaaS companies pursuing SOC 2 do not need FIPS certification.
How to document encryption in your SOC 2 control narrative
A common mistake is over-promising encryption controls in policy language. Organizations write aspirational statements that sound impressive but are impossible for auditors to verify,and that creates findings.
Instead, write accurate, testable controls. Compare these two examples:
❌ Poor control language:
"All data is encrypted everywhere."
✅ Better control language:
"Customer data stored in production databases is encrypted at rest using AES-256 with keys managed by the centralized KMS platform. Key rotation occurs annually, and access to keys is restricted to the infrastructure team via IAM role-based policies."
The better version is specific, scoped, and verifiable. An auditor can test each claim: Is the database encrypted? With AES-256? Through KMS? Are keys rotated annually? Is access restricted? That’s five testable assertions instead of one vague promise.
When writing control narratives, use the format: [What data] is protected by [what mechanism] with [what key management] and [what access restriction]. It makes life easier for everyone,your auditor, your security team, and your future self during the next audit cycle.
Final thoughts
Encryption is one of the most visible,and most misunderstood,parts of SOC 2 compliance.
The framework does not prescribe specific algorithms or tools. Instead, auditors evaluate whether your encryption controls appropriately protect sensitive data within your risk environment. Organizations that implement strong data classification, centralized key management, and well-documented encryption policies typically pass SOC 2 encryption reviews with minimal friction.
The organizations that struggle are usually the ones with a gap between policy and practice,where the documentation says one thing and the infrastructure does another. Close that gap, and you’ve solved 80% of the problem.
If you’re preparing for a SOC 2 Type I or Type II audit, start here:
- Map where sensitive data exists across your environment
- Review transport and storage encryption for gaps and misconfigurations
- Validate key management controls, including rotation and access policies
- Document evidence before the audit begins, not during it
A proactive assessment can dramatically reduce audit timelines and prevent costly remediation during the examination period. With the right tooling and preparation, you can make SOC 2 happen in weeks, not months. If you’re evaluating compliance platforms, our comparison of Drata vs Vanta can help you choose the right fit.
Learn more about how to prepare your encryption controls for audit, or contact us to identify gaps before auditors do.
FAQ: SOC 2 encryption requirements
Does SOC 2 require encryption at rest?
Not explicitly. However, encryption at rest is generally expected when storing sensitive data such as PII or customer information. An organization that stores customer data without encryption would need an exceptionally strong risk justification.
Does SOC 2 require encryption in transit?
In most practical scenarios, yes. Secure transport protocols like TLS 1.2 or TLS 1.3 are widely considered baseline security controls. The IETF formally deprecated TLS 1.0 and 1.1 in 2021, and auditors reflect that in their expectations.
What TLS version is expected for SOC 2?
TLS 1.2 or TLS 1.3 are considered the secure industry standards. TLS 1.3, the newer protocol, offers improved performance and stronger security defaults.
Are customer-managed keys required?
No. Managed KMS services from cloud providers are usually sufficient for SOC 2 purposes.
How does encryption relate to Confidentiality vs Security?
Security focuses on protecting systems overall,think of it as the perimeter. Confidentiality focuses specifically on protecting sensitive data within those systems. Encryption supports both criteria, but the evidence auditors request may differ depending on which category they’re evaluating.
What's the difference between SOC 2 Type I and Type II for encryption?
Type I evaluates the design of encryption controls at a point in time. Type II evaluates whether those controls actually operated effectively over a sustained period (typically 6–12 months). Type II is the more rigorous assessment and the one most customers and partners look for.
Is encrypting passwords enough?
No. Passwords should be hashed (not encrypted),using algorithms like bcrypt, scrypt, or Argon2,and organizations should implement proper secrets management for credentials and API keys. Encryption is reversible; hashing is not. That distinction matters for both security and compliance.
How does SOC 2 encryption compare to ISO 27001?
Both frameworks expect encryption as part of a broader security program, but they’re structured differently. ISO 27001 specifies controls in Annex A, while SOC 2 evaluates controls against Trust Services Criteria. For a detailed comparison, see our guide on ISO 27001 vs SOC 2.