SOC 2 Encryption Controls: Data Protection at Rest and in Transit

Priya Nathanson had eleven weeks until her Type II observation period closed, and a $2.4M renewal riding on the report. She was VP of Engineering at Fenwick Ledger, a payments-adjacent fintech that processed reconciliation data for mid-market retailers, and her biggest enterprise customer had made the SOC 2 report a contract condition eighteen months earlier. The readiness assessment her auditor's advisory team ran in week two turned up something she hadn't expected: a production S3 bucket holding three years of transaction exports, sitting on default settings, with server-side encryption never explicitly enabled. It wasn't a breach. Nothing had been exfiltrated. But it was exactly the kind of finding that turns a clean Type II report into a qualified opinion, and it was exactly the kind of finding her customer's procurement team would ask about by name if the exception showed up in Section IV.

Priya's story isn't unusual — it's close to the median. In my fifteen-plus years doing security consulting and SOC 2 readiness work across more than 200 organizations, encryption gaps are among the most common findings I see in pre-audit gap analyses, and among the most avoidable. They're avoidable because the technology is mature, the standards are well documented, and the fixes are usually configuration changes rather than architecture rebuilds. They're common because encryption sits in an awkward spot in the Trust Services Criteria: it's clearly expected, it's tested hard, but it isn't spelled out as a checkbox requirement anywhere in the criteria language itself. This article closes that gap.

Who This Is For

This is written for engineering leaders, security architects, and compliance managers who are building or hardening a SOC 2 encryption program — whether you're six weeks from your first Type II observation period or maintaining controls through your fourth consecutive report. You'll walk away with a working map of where encryption fits inside CC6.1 and CC6.7, concrete configuration guidance for data at rest and data in transit, a practical key management program (including where HSMs and KMS platforms fit and how separation of duties actually gets tested), and the specific evidence artifacts auditors ask for so you're not scrambling to produce them during fieldwork. If you're also carrying ISO 27001 alongside SOC 2, you'll find the crosswalks to Annex A cryptography controls throughout.

Encryption and the Trust Services Criteria: What's Actually Required

Here's the thing that surprises almost every first-time SOC 2 client: there is no criterion in the Trust Services Criteria that says "the entity shall encrypt data." Encryption doesn't get its own control point the way, say, access control provisioning does. Instead, encryption is woven into the points of focus underneath two Common Criteria controls — CC6.1 and CC6.7 — as one of the illustrative ways an organization protects information assets and secures data in motion. Auditors don't test "did you encrypt X" as a standalone yes/no. They test whether your logical access and transmission-protection controls are designed and operating effectively, and for the overwhelming majority of service organizations handling customer data, encryption is how that gets demonstrated.

This matters because it changes how you should think about your evidence. You're not collecting encryption artifacts to satisfy a named "encryption criterion" — you're building the case that CC6.1 (protection of information assets) and CC6.7 (protected transmission and movement of information) are met, and encryption configuration, key management discipline, and certificate hygiene are your primary evidence for that case. Encryption sits alongside — and reinforces — the broader control implementation covered under the SOC 2 Security Criteria, which is the required Common Criteria category every report includes. If you also carry a Confidentiality criteria commitment in scope, encryption does even more work — it's frequently the single largest category of control evidence supporting confidentiality of data classified as sensitive or restricted.

"New clients always ask me which SOC 2 criterion mandates AES-256. I have to explain there isn't one — and that's usually the moment they realize compliance isn't a checklist, it's a risk argument you have to make convincingly to a CPA who's read a lot of system descriptions." — Sam Okafor, CPA, Partner, Baird & Okonkwo LLP

Why Encryption Became the De Facto Standard Anyway

If it's not mandated, why does virtually every SOC 2 report I've reviewed in the last decade show encryption at rest and in transit as implemented controls? Three reasons converge. First, risk assessment exercises conducted honestly almost always surface data exposure as a high-impact risk, and encryption is the most direct, well-understood mitigation available. Second, customer contracts and security questionnaires increasingly name encryption explicitly — "AES-256 at rest, TLS 1.2 or higher in transit" has become boilerplate in vendor security addenda, which means your management assertion needs to match what your customers are already being told. Third, auditors have converged on encryption as expected evidence through sheer repetition: when nearly every peer service organization in a given industry implements it, its absence becomes a red flag that invites deeper testing, not a neutral choice.

The practical upshot is that "encryption isn't literally required" is true but misleading as guidance. Treat it as required unless you have a documented, risk-assessed, and disclosed reason not to encrypt a specific data flow — and even then, expect your auditor to want to see that reasoning in writing.

Encryption at Rest: The Foundation Layer

Encryption at rest protects data stored on disk, in databases, in object storage, and in backups from being read if the underlying storage medium, snapshot, or backup file is accessed outside your normal application path — a stolen laptop, a misconfigured cloud bucket, a decommissioned drive that wasn't wiped, a backup file that leaked to the wrong place. It is distinct from, and complementary to, access control: access control governs who is authorized to query the data through your application; encryption at rest protects the data if someone bypasses the application entirely.

The overwhelming industry standard for encryption at rest is the Advanced Encryption Standard (AES), specifically AES-256 in Galois/Counter Mode (GCM) or XTS mode depending on the use case. AES is a symmetric block cipher standardized by NIST in 2001, validated through the Cryptographic Module Validation Program under FIPS 140, and it remains, more than two decades later, the default choice for virtually every mainstream at-rest encryption implementation — full-disk encryption, database transparent encryption, and cloud object storage all converge on it.

Full-Disk and Volume Encryption

This is the baseline layer and, frankly, the easiest one to get right in 2026 because most modern operating systems and cloud platforms encrypt by default or make it a one-line configuration. Cloud block storage — AWS EBS, Azure managed disks, Google Persistent Disk — all support encryption at the volume level with provider-managed or customer-managed keys, and in most current provider defaults, it's enabled unless explicitly disabled. The gap I see most often isn't disabled disk encryption on primary volumes; it's forgotten volumes — snapshots taken for a migration and never cleaned up, unencrypted AMIs baked before someone flipped the default, or legacy EC2 instances provisioned years before the account-level encryption-by-default setting existed.

Database-Level Encryption

Transparent Data Encryption (TDE) encrypts database files, logs, and backups at the storage layer without requiring application code changes — SQL Server, Oracle, and (via extensions) PostgreSQL and MySQL all support it. TDE is table-stakes for SOC 2 evidence because it's cheap to implement and directly answers the auditor's question about protecting data at rest in your primary data store. What TDE does not do is protect data from someone with legitimate database credentials — a database administrator who can query the table sees plaintext. That's where field-level encryption comes in.

Field-Level and Application-Layer Encryption

For the highest-sensitivity fields — payment tokens, government ID numbers, health data, authentication secrets — encrypting at the field or column level, with keys managed separately from the database credentials, adds a meaningful layer that TDE alone doesn't provide. This is also where tokenization enters the conversation: instead of encrypting the sensitive value in place, you replace it with a non-sensitive token and store the mapping in a segregated vault. For PII and payment data specifically, tokenization plus field-level encryption is increasingly the expected pattern rather than the exception, particularly for organizations that also touch PCI DSS scope.

"We tell every client the same thing: TDE gets you past the auditor's first question. Field-level encryption on your crown-jewel data gets you past the second one, which is 'who besides the application can read this in plaintext?' Most teams haven't thought about the second question until we ask it." — Dana Whitfield, Head of Platform Security, Corvale Systems

Case Study: The Bucket Nobody Encrypted

Back to Priya Nathanson at Fenwick Ledger. The finding — a production S3 bucket with three years of transaction reconciliation exports, relying on the account's default encryption posture rather than an explicit bucket policy — wasn't catastrophic, but it exposed a gap in how her team thought about ownership. Nobody owned "verify encryption configuration across every storage resource"; it had been assumed, correctly at account creation but never re-verified as new buckets were spun up by different service teams over three years.

Her team's remediation ran in three phases over five weeks: an inventory sweep across all storage resources using the cloud provider's config/compliance tooling to flag anything without explicit server-side encryption enabled (they found four more buckets beyond the one the auditor flagged); a policy change enforcing SSE-KMS with a customer-managed key on every new bucket by default, with the account-level setting hard-blocking exceptions; and a quarterly automated scan added to their continuous monitoring stack, feeding a dashboard her compliance lead reviewed monthly. The $2.4M renewal closed on schedule. The Type II report shipped with zero encryption-related exceptions, and Priya's team now treats "storage resource inventory with encryption status" as a standing control, not a one-time fix.

Encryption in Transit: Protecting Data on the Move

Encryption in transit protects data as it moves across networks — between a user's browser and your application, between your services internally, between your system and a third-party API, and during file transfer or backup replication. This is the domain CC6.7 speaks to most directly: restricting and protecting the transmission and movement of information. Where encryption at rest answers "what happens if someone gets the storage medium," encryption in transit answers "what happens if someone is positioned on the network path between two points" — a compromised Wi-Fi network, a malicious intermediate router, a misconfigured load balancer terminating TLS somewhere you didn't expect.

The dominant standard is Transport Layer Security (TLS), now in its 1.3 revision, which succeeded the deprecated SSL protocol family entirely. TLS 1.2, ratified in 2008, remains broadly supported and acceptable for SOC 2 purposes when configured with strong cipher suites, but TLS 1.3 (2018) is the direction every serious security program should be moving, both because it removes a set of legacy cipher suites that have known weaknesses and because it reduces handshake latency, which makes the security upgrade essentially free from a performance standpoint.

Where Transit Encryption Gets Missed

The external-facing TLS story is usually the easy part — most organizations have HTTPS enforced on customer-facing endpoints years before they think about SOC 2. The gaps I find during readiness work cluster in three places: internal service-to-service traffic inside a VPC or cluster that's assumed "safe" because it's behind a firewall (network segmentation is a control, not a substitute for transit encryption); administrative and database connections that get TLS enforcement at the application layer but not at the CLI/tooling layer engineers use for direct access; and third-party and partner API integrations where an older, less security-conscious vendor still only supports TLS 1.0 and nobody has scheduled the conversation about sunsetting that connection.

Internal Transit Encryption and Mutual TLS

For service-to-service communication inside your environment, the maturity curve runs from "encrypted at the perimeter only" to "encrypted everywhere via mutual TLS." Mutual TLS (mTLS) requires both sides of a connection to present and validate certificates, which means services authenticate each other as well as encrypting the payload — a materially stronger posture than one-way TLS, and increasingly the expected pattern in service mesh architectures (Istio, Linkerd, AWS App Mesh) for organizations running microservices at scale. It's not required for every SOC 2 report, but for organizations whose system boundary includes multiple internal services handling regulated or highly sensitive data, auditors increasingly probe whether "encrypted internally" means real mTLS or just an assumption based on network location.

Case Study: The Legacy Endpoint Nobody Remembered

Marcus Webb, CISO at Northgate Health Analytics, a healthtech data-processing firm, described a finding that came up not through the SOC 2 audit itself but through a penetration test his team ran ahead of it — the kind of proactive step I recommend to every client heading into a first Type II. The test found a legacy partner-integration API endpoint, still live, still accepting TLS 1.0 connections from an older reporting system one customer hadn't upgraded in four years. It handled a narrow slice of traffic, but it was in scope, and it would have been an easy exception for the auditor to write up.

Northgate's team had ninety days before the audit period opened. They mapped every external and partner-facing endpoint, confirmed which ones still permitted TLS 1.0/1.1, and worked with the one affected partner on a 45-day migration window to TLS 1.2 minimum, with a hard cutoff enforced at the load balancer after that window closed. They also added a standing quarterly TLS configuration scan across all external endpoints as a permanent control — not just for the audit, but because Marcus's team had learned the hard way that "we upgraded everything" and "we verified everything is still upgraded" are different claims, and only the second one holds up to testing over a twelve-month observation period.

"Pentesting before the SOC 2 audit isn't redundant — it's cheaper. A pentest finding costs you a sprint. The same finding surfacing in Section IV of your report costs you a customer conversation you didn't want to have." — Marcus Webb, CISO, Northgate Health Analytics

Certificate Management: The Operational Discipline Behind TLS

TLS is only as trustworthy as the certificates behind it, and certificate management is where I see otherwise strong encryption programs quietly fail. An expired certificate doesn't just cause an outage — a certificate that expires unnoticed and gets replaced with a self-signed or improperly validated one, even briefly, is exactly the kind of control lapse a Type II audit period is designed to catch, because Type II tests operating effectiveness over time, not just at a snapshot.

The move toward short-lived, automatically rotated certificates (driven heavily by the ACME protocol and tools like Let's Encrypt's automation, as well as internal equivalents such as HashiCorp Vault's PKI engine or cloud-native certificate managers) is worth adopting even outside audit pressure, because it converts "did someone remember to renew this" into "does the automation still have valid permissions," which is a much easier thing to monitor and much harder to silently forget.

Key Management: Where Encryption Programs Actually Live or Die

Here's a pattern I've seen consistently across 200-plus engagements: organizations that get encryption at rest and in transit right, and then fail their audit on encryption anyway, almost always fail on key management, not on the ciphers themselves. AES-256 is AES-256 regardless of who implements it. What separates a defensible program from an indefensible one is how the keys that unlock that encryption are generated, stored, rotated, accessed, and retired.

Key management is the lifecycle discipline governing cryptographic keys from creation through destruction. NIST SP 800-57 is the widely referenced framework for key management practices, and while SOC 2 doesn't mandate adherence to it by name, auditors familiar with the space measure your program against roughly the same lifecycle stages it describes.

HSMs and KMS Platforms

Two categories of tooling dominate modern key management, and understanding the distinction matters for how you talk to auditors about your architecture. A Hardware Security Module (HSM) is a dedicated physical (or cloud-provider-managed virtual) device that generates and stores keys in tamper-resistant hardware, performing cryptographic operations inside the device so the key material itself never leaves it in plaintext. A Key Management Service (KMS) is typically a cloud-native managed service — AWS KMS, Google Cloud KMS, Azure Key Vault — that provides key lifecycle management as an API-driven platform, frequently backed by HSMs under the hood for its own root/master keys.

For most SaaS and cloud-native service organizations pursuing SOC 2, a cloud KMS with customer-managed keys (CMKs) and integrated audit logging is the pragmatic default — it gives you FIPS-validated key protection under the hood, API-driven rotation and access policy, and audit trails that plug directly into the same logging pipeline you're already using for access control evidence. This is also where encryption and logical security overlap most directly: the same system-access authorization controls that govern who can reach production data should govern who can reach the keys protecting it. Dedicated HSMs earn their operational overhead when you're in a regulated industry with explicit FIPS 140-2/140-3 requirements, when a customer contract mandates customer-held key material outside the cloud provider's control plane, or when transaction volume and value justify the additional assurance.

"The KMS-versus-HSM question comes up in almost every architecture review I run. My answer is usually the same: start with a well-configured cloud KMS and customer-managed keys — it clears the SOC 2 bar comfortably for the vast majority of organizations. Move to a dedicated HSM when a specific contract, regulation, or threat model demands it, not because it sounds more secure on a sales call." — Tobias Lindqvist, Cryptography Lead, Meridian Cloud Security

Separation of Duties in Key Management

This is the control auditors probe hardest and the one I see fail most often in otherwise sophisticated environments. Segregation of duties in a key management context means the people who administer encryption keys should not be the same people who can access the data those keys protect without independent oversight, and the people who can approve key rotation or destruction should be distinct from the people who execute it. When one engineer holds KMS admin rights, database admin rights, and production deploy access simultaneously, you don't have a key management control — you have a single point of both technical and organizational failure, and an auditor testing CC6.1 will find it.

Case Study: One Admin, Two Keys, Too Much Access

Elena Vasquez, Director of Compliance at Vaultbridge Payments, a payments-orchestration platform handling merchant settlement data, found this exact issue during her firm's second Type II cycle — the kind of finding that's easy to miss in a first-year audit when the auditor is still learning your environment, and much harder to hide from by year two, when they know exactly where to look. A single senior engineer held KMS administrator rights across the production account, database administrator credentials, and CI/CD deployment access. He was trustworthy and had never misused any of it. That wasn't the point — the auditor's test wasn't about intent, it was about whether the control design itself prevented a single individual from being able to both access sensitive data and independently control the keys protecting it.

Vaultbridge's remediation split the responsibilities across three roles within six weeks: a dedicated key administration role limited to two people on the security team with no production database access; database administration handled by the platform team with no KMS policy-change rights; and a mandatory second-approver requirement on any key policy change, enforced through their infrastructure-as-code pipeline rather than manual process (removing the "someone forgot to get sign-off" failure mode entirely). The auditor's follow-up testing in the subsequent quarter's evidence sample confirmed the control operated consistently, and the finding closed without becoming a qualified opinion.

Key Rotation: Policy, Cadence, and Evidence

Rotation policy is one of the most concrete, testable pieces of a key management program, and it's also where "we have a policy" and "we can prove the policy operated" diverge most sharply. Auditors testing operating effectiveness over a Type II period want to see rotation actually happen on schedule, logged, with no gaps — not just a policy document stating an intended cadence.

Automated rotation (particularly via cloud KMS envelope encryption, where a root key wraps data keys that rotate transparently) removes most of the operational burden and, more importantly for audit purposes, removes the human-memory dependency that turns "annual rotation policy" into "rotation that actually happened eleven months late, or not at all." Where I coach clients hardest is on evidence: rotation needs to produce a timestamped, immutable log entry every time it fires, because "we believe it's rotating" is not evidence — a rotation log export covering the full observation period is.

Algorithm Selection: Staying Current Without Chasing Trends

Cryptographic algorithms age, and part of a mature encryption program is tracking which algorithms remain approved and which have moved into deprecated or forbidden status. NIST Special Publication 800-131A is the standard reference for algorithm transitions in the U.S. federal space, and its guidance has become the de facto industry benchmark even for organizations with no direct federal obligation.

Algorithm selection isn't a one-time architecture decision — it's a standing control. I recommend an annual algorithm and protocol review as a scheduled activity, not a reactive one triggered by an auditor question, cross-checked against current NIST guidance and your cloud/vendor platforms' supported cipher suite lists. This review is cheap — a few hours of a security engineer's time — and it's exactly the kind of proactive evidence that differentiates a mature program from one assembling documentation the week before fieldwork starts.

Confidentiality Tie-In: Encryption as Confidentiality's Primary Evidence

If your SOC 2 scope includes the optional Confidentiality criterion, encryption stops being "strong supporting evidence for CC6.1/CC6.7" and becomes close to the load-bearing control for the entire category. Confidentiality is about protecting information designated as confidential — commercial data, trade secrets, sensitive customer data — throughout its lifecycle from collection to disposal, and encryption at rest and in transit is the most direct technical mechanism for enforcing that protection regardless of who has been granted logical access.

The connective tissue works like this: data classification identifies what's confidential; confidentiality as a Trust Services criterion sets the expectation that classified data receives protection commensurate with its sensitivity throughout its lifecycle; and encryption is how that protection gets technically enforced, both while the data sits in storage and while it moves between systems. Where I coach Confidentiality-scoped clients hardest is on making that chain explicit and traceable — a data classification policy that names categories, a control matrix mapping each category to its required encryption treatment, and evidence that the treatment actually applies where the classification says it should.

There's also a disposal dimension worth naming explicitly: when confidential data reaches end of life, cryptographic erasure — destroying the encryption key rather than attempting to overwrite every copy of the underlying data, which is often technically impractical across cloud storage, backups, and replicas — is an efficient, auditable, and increasingly expected disposal method. It's a natural extension of a mature key management program: if you've built rigorous key lifecycle controls already, cryptographic erasure is nearly free to add as your data disposal mechanism.

Encryption for Subservice Organizations and Cloud Providers

Almost no modern service organization encrypts everything itself end-to-end without leaning on subservice organizations — cloud infrastructure providers, managed database platforms, third-party payment processors, backup vendors. This raises a legitimate question auditors ask directly: how do you get assurance that your subservice organizations' encryption controls are sound, given that under the carve-out method those controls sit outside your own report's tested boundary?

The practical answer runs through vendor risk management: reviewing your subservice organizations' own attestations (their SOC 2 reports, ISO 27001 certificates, or equivalent) specifically for encryption-related control coverage, documenting that review as part of your vendor due diligence process, and — where the carve-out method is used — making sure your own system description clearly identifies which encryption responsibilities are yours versus theirs. This is also where complementary subservice organization controls become relevant: if your cloud provider's report states that encryption key management assumes the customer configures certain settings correctly, that's now your responsibility to operate, not a gap in their coverage.

The Encryption Architecture at a Glance

The diagram below shows how the pieces covered in this article typically connect in a modern SOC 2-scoped environment — from data classification driving requirements, through the KMS/HSM layer, out to where encryption actually gets applied at rest and in transit.

Evidence Auditors Actually Test

This is the section I'd bookmark if I were you. Readiness assessments spend a lot of time on architecture; the audit itself spends its time on evidence. Here's the artifact list I use with clients heading into fieldwork.

"The single biggest predictor of a smooth encryption walkthrough isn't the sophistication of the architecture — it's whether the client can hand me a rotation log without having to go build one from scratch during fieldwork. Real-time evidence beats retroactive reconstruction every time." — Sam Okafor, CPA, Partner, Baird & Okonkwo LLP

Common Findings and How to Avoid Them

Across the readiness assessments and audit support I've done, encryption findings cluster into a fairly predictable set of patterns. Knowing them in advance is most of the battle.

Building the Encryption Policy Auditors Want to See

A written encryption policy is both a control objective artifact and, practically, one of the first documents an auditor requests. It should name the standards you follow (AES-256, TLS 1.2 minimum with 1.3 preferred, NIST SP 800-57-aligned key management practices), define data classification tiers and their corresponding encryption requirements, assign clear ownership for key administration versus data ownership, set rotation cadences by key type, and define your exception process for any system that can't meet the standard (with required compensating controls and a remediation timeline). A policy that exists but that nobody follows is worse for audit purposes than no policy at all, because it creates a documented gap between stated control design and observed operating effectiveness — exactly what a Type II audit is built to catch.

Implementation Timeline: What a Realistic Rollout Looks Like

Clients often ask how long it takes to go from "encryption is inconsistent" to "encryption is audit-ready." The honest answer depends heavily on existing architecture maturity, but here's a representative timeline drawn from engagements of similar scope to Fenwick Ledger's.

Cost Considerations

Encryption implementation costs are usually smaller than clients expect for the technology itself and larger than expected for the process and people time around it. Cloud-native KMS pricing is typically usage-based and modest even at scale; the real cost driver is engineering time spent on inventory, remediation, and building durable automation rather than one-off fixes.

Encryption Alongside ISO 27001: A Quick Crosswalk

If your organization is also pursuing or maintaining ISO 27001 certification, you're not building two separate encryption programs — you're documenting one program against two frameworks. ISO/IEC 27001's Annex A includes a dedicated cryptography control (A.8.24, "Use of Cryptography") requiring a documented policy on cryptographic controls and key management, which maps closely to everything covered in this article. Organizations running ISO 27001 and SOC 2 together typically find encryption is one of the highest-leverage areas for control reuse, because the evidence — configuration exports, key rotation logs, TLS scan results, the encryption policy itself — satisfies both an Annex A control and CC6.1/CC6.7 with no meaningful rework. If you're evaluating which framework to pursue first, the ISO 27001, SOC 2 & NIST CSF crosswalk is worth reviewing before you scope either program, specifically for how it aligns cryptography controls across the three.

Encryption as a Business Opportunity, Not Just a Checkbox

I'll end where I usually end these conversations with clients: treating encryption purely as an audit-compliance cost misses the actual return. A well-documented, well-evidenced encryption program shortens security questionnaire cycles, because "AES-256 at rest, TLS 1.2+/1.3 in transit, keys managed via KMS with documented separation of duties" is an answer that closes a procurement conversation in one email instead of three follow-up calls. It reduces breach impact and breach notification obligations, because encryption at rest is frequently a safe-harbor factor in data breach notification law — encrypted data that's exfiltrated is, in many jurisdictions and many contracts, treated differently from plaintext exposure. And it de-risks the specific scenario that keeps compliance leaders like Priya, Marcus, and Elena up at night: the finding that shows up in Section IV of a report a customer's procurement team actually reads.

The organizations I've watched handle this best don't treat encryption controls as a once-a-year audit-prep sprint. They build the inventory scans, the rotation automation, and the certificate monitoring as permanent operational infrastructure, and the audit becomes a matter of exporting evidence that already exists rather than assembling it under deadline pressure. That's the difference between an audit evidence scramble every observation period and a program that quietly gets easier to prove every year it runs.

If you're heading into a SOC 2 readiness assessment and want a second set of eyes on your encryption architecture — at rest, in transit, and the key management program tying it together — PentesterWorld's team has run this exact assessment across organizations at every stage of the SOC 2 journey. Start with our SOC 2 Readiness Checklist to see where your encryption controls stand today, pull our SOC 2 Policy Pack for a starting-point encryption and key management policy you can adapt rather than write from scratch, and if you want a structured view of every control gap across your environment, our SOC 2 Gap Analysis Tool will map exactly where encryption — and everything around it — stands against the Common Criteria before your auditor does.