Does SOC 2 require encryption at rest and in transit?
SOC 2 has no fixed encryption rule. CC6.7 requires the organization to protect information while it is transmitted, moved or removed, and encryption is the most common way to meet that requirement, though it is not the only way. A customer or contract that asks for SOC 2 and expects encryption to be explained should receive an answer built from your own system, not a generic statement that the framework demands AES or TLS at a particular version. The criteria describe the outcome, and your system description, confidentiality commitments and risk assessment determine how strong the protection needs to be and where it must apply.
That means the organization owns this decision and the control behind it. Your team decides which data flows cross untrusted networks, which stores hold customer data at rest, which endpoints and removable media carry it, and what your confidentiality commitments promise. An implementation partner can help configure systems and collect evidence, but only an independent CPA firm examines the design and, for a Type 2 report, tests operating effectiveness over a period. Before the examination starts, confirm with your auditor how they expect you to show encryption coverage, including whether they want evidence for backups, logs and developer workstations as well as production databases.
Start with a data flow inventory and a risk assessment that names every place customer information is transmitted or stored. For each location, record the protection in place, the owner of the setting and the evidence that shows it works, such as TLS configuration scans, disk encryption status reports or key rotation logs. Gaps in this map are the findings auditors most often raise, so treat the inventory as a control document, not a one-time project.
Explicit encryption rules customers bring from the FTC Safeguards Rule or state insurance laws
Customers that are financial institutions under the FTC's jurisdiction, such as certain lenders, brokers and other non-bank financial businesses, must maintain an information security program under the FTC Safeguards Rule. That program expects customer information to be encrypted both on the company's own system and while it moves across networks. When your organization hosts or processes that data for such a customer, the customer may write this rule into its contract and ask you to show how you meet it. A SOC 2 report describes controls the service organization operates against the Trust Services Criteria. It does not, by itself, state that customer information meets the Rule's encryption expectations, so the customer will usually ask for specific evidence in addition to the report.
- Encryption on the company's system: Show where customer information is stored encrypted, which algorithms and key lengths are used, and who controls the keys.
- Encryption in transit: Show that network paths carrying customer information use current transport encryption, including internal service-to-service traffic.
- Testing obligations: The Rule also calls for annual penetration testing and vulnerability assessments, with system-wide scans every six months unless continuous monitoring is in place (FTC guidance).
- Evidence the customer can read: Configuration exports, certificate inventories and test reports matched to the period covered by the contract.
- Scope of responsibility: Agree in writing which party operates each control, especially where a cloud provider or hosting partner runs part of the stack.
Confirm with your counsel whether the Safeguards Rule applies to your customers and to the data you handle, and ask each customer to name the specific encryption clauses it expects you to meet.
The NAIC Insurance Data Security Model Law (#668) is a model, not a federal rule. Section 4D lists security measures a licensee implements where appropriate. Among them is encryption of nonpublic information sent over external networks or stored on portable devices. The same section also lists secure development practices, multi-factor authentication where effective and audit trails. Insurers and their vendors in a state only face these duties if that state has enacted the model law or its own version, and the wording and effective dates vary by state. Customers in states that have not adopted the model may still ask for the same controls through contract terms or their own vendor management programs.
- Adoption depends on the state: Ask each insurance customer which state law governs it, and whether that law follows the model text.
- External networks: Encryption applies to nonpublic information sent beyond the organization's own network, including through partner and API connections.
- Portable devices: Laptops, removable media and backup copies that hold nonpublic information need encryption, which links this requirement to your endpoint controls.
- Vendor flow-down: Customers under the model may push these expectations to you as a service provider, so map which clauses your contract accepts.
- Evidence: Records showing encrypted volumes on portable devices, encrypted transport settings and key rotation history.
Before accepting any state-specific encryption term, have the buyer's counsel confirm the applicable state law and the exact obligation it places on the service provider.
How OpenBao and cert-manager produce key management evidence
Encryption in transit and at rest depends on keys and certificates being issued, rotated and used under control. OpenBao and cert-manager each produce a different slice of that evidence, and the organization still owns the policy, access decisions and review that auditors test.
OpenBao transit engine for application data
The transit secrets engine encrypts and decrypts application data without storing the data itself, so applications send plaintext in and receive ciphertext back while keys stay inside OpenBao. For CC6.7 and the confidentiality commitments, this separates data protection from key custody. Confirm in the OpenBao documentation which data paths your applications call, and document which datasets are routed through transit and which are not.
Signing and verifying with OpenBao
The same engine can sign and verify data, which supports integrity checks on artifacts, configuration or messages whose origin matters to a reviewer. Auditors look for a clear statement of what is signed, who may request signatures and how verification results are used. Confirm the supported algorithms and signing operations for your OpenBao version, and record which pipelines or services depend on them.
Versioned keys and rotation
Transit keys are versioned, so new encryption can use a current key version while older versions remain available to decrypt existing data. Rotation schedules, minimum decryption versions and any re-encryption of stored data are the decisions an assessor will ask about. Write the rotation interval into the key management standard, and confirm the rotation and minimum version settings in the documentation before you describe them to an auditor.
Access control and audit logs for key use
Policies in OpenBao decide which identities may encrypt, decrypt, rotate or export with a given key, and the audit device records requests made against those paths. Together they give evidence that key use is restricted to authorized processes and can be traced afterward. Confirm which audit devices your deployment enables and where the logs go, since the log is only evidence if it is retained and reviewed.
TLS certificate issuance with cert-manager
cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from configured issuers, including ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or self-signed issuers. The issuer choice determines who controls the trust chain, so record it as a design decision under CC6.7. Confirm the issuer configuration and the certificate resource settings in the cert-manager documentation for your version.
Certificate storage and automatic renewal
cert-manager stores issued certificates in Kubernetes Secrets and renews them before they expire, which removes manual renewal as a source of outages and expired certificates. Evidence includes certificate resources, renewal events and expiry monitoring. Confirm how renewal timing is set in your environment, who can read those Secrets through Kubernetes RBAC, and whether expiry alerts reach the team that owns the service.
Preparing encryption controls before the examination
This sequence turns encryption from a general policy statement into documented scope, standards, configurations and exception records that an auditor can select and test. Each step produces an artifact the organization owns, and the auditor samples from those artifacts during fieldwork.
Identify confidential and customer data flows
Map which systems hold confidential and customer data, where that data is created, stored, transmitted and deleted, and which third parties receive it. Engineering and the data owners do this together, and the output is a data flow inventory with a named owner for each flow. The step is complete when the inventory covers every system in the SOC 2 system description and each flow can be traced to a control.
Set encryption standards per data class
Write a standard that states, for each data class, whether encryption at rest and in transit is required, which algorithms and key lengths are approved, and which endpoints must use them. Management approves the standard, and the security function confirms that it matches the confidentiality commitments in the service agreements. The approved document is the baseline the auditor will compare configurations against.
Configure TLS and certificate lifecycle
Engineers enforce TLS on every external and internal path identified in the inventory, disable protocol versions and cipher suites that the standard excludes, and issue certificates through an approved issuer. Where Kubernetes workloads need certificates, cert-manager can request them from an issuer such as ACME, an internal CA or HashiCorp Vault, store them in Kubernetes Secrets and renew them before expiry. The closing evidence is the configuration as code plus a scan report showing the enforced settings.
Set key rotation and access rules
Define how encryption keys are generated, stored, rotated and retired, and who may request or use them. OpenBao's transit secrets engine can encrypt and decrypt application data without storing it and supports versioned keys with rotation, so the rotation schedule and key policies become configuration that can be reviewed. The output is a key management procedure, signed key policy files and a list of identities permitted to use each key.
Collect configuration and log evidence
Gather dated evidence that the standard is in force: TLS scan results, certificate inventories with issuance and renewal records, key policy exports, and audit logs showing key creation, rotation and use. The security or compliance lead pulls these on a schedule, so that a sample from any period in the observation window can be produced. Evidence is stored in a location with restricted access and a documented retention rule.
Document exceptions and compensating controls
Where a system cannot meet the standard, record the exception, the business reason, the risk accepted, the compensating control, the approver and the date for review. Management signs off on each exception, and the security function confirms that the compensating control operates. The exception register is a document the auditor can read directly, and an undocumented exception is more likely to become an audit finding than a documented one.
Confirm scope with the auditor before fieldwork
Share the data flow inventory, encryption standard, configuration evidence and exception register with the CPA firm so it can confirm which systems and controls are in scope and which evidence it will request. Ask the auditor to state the sampling approach and any evidence format it requires. The step is complete when the auditor has acknowledged the scope in writing and the evidence list matches what the team has collected.
Who owns encryption controls and who prepares the evidence
Encryption under SOC 2 splits into four roles that are easy to blur. The organization decides what must be encrypted and accepts the residual risk, an implementation partner configures the systems and collects proof, the CPA firm tests the controls and issues the report, and customers decide whether an additional rule applies to them. DeployOpen sits in the implementation role only: it does not issue reports or certificates.
The organization owns the control
Management decides which data is in scope, which encryption standard applies, and who may hold keys. It writes the encryption and key management policy, assigns an owner for each control, and signs the management assertion the auditor relies on. Under CC6.7, the organization must show it protects information while it is transmitted, moved or removed. Delegating the work to a partner does not transfer that accountability, so the internal owner should be named in the control matrix before fieldwork begins.
The partner configures and documents
An implementation partner such as DeployOpen can deploy OpenBao for transit encryption and key rotation, configure cert-manager to issue and renew TLS certificates for Kubernetes or OpenShift workloads, and set TLS versions and cipher settings on internal and external endpoints. It also assembles the evidence: configuration exports, key rotation logs, certificate inventories and change records. Confirm in the statement of work exactly which systems and evidence are included, and who keeps the records after handover.
The CPA firm tests and reports
The CPA firm is the only party that tests design and, for a Type 2 report, operating effectiveness over the observation period. It selects samples of certificates, key rotations and encrypted data stores, then reads the evidence and issues the opinion. Ask the firm early which encryption samples it will request, how it will verify that keys and certificates were in place throughout the period, and whether it expects a system description covering the encryption tools.
Customers and counsel set extra rules
Customers decide whether a rule beyond SOC 2 applies to them. A bank or insurer may cite the FTC Safeguards Rule or a state insurance data security law that names encryption explicitly, and their counsel will read the SOC report against those rules. SOC 2 does not decide that question. Ask each customer to list the specific encryption rules in its contract, then map them to controls and evidence, since a report alone may not answer them.
What encryption work costs and what drives it
No supplied figure exists for what encryption work costs, so the only reliable starting point is a written scope and quote. The cost of meeting CC6.7 for encryption in transit and at rest splits into four components, and each is paid to a different party. Internal engineering time is the largest and least visible: someone must inventory data stores, decide where keys live, rotate certificates and fix services that still accept plaintext. The implementation partner is paid for scoped work such as deploying OpenBao, wiring its transit secrets engine into applications and configuring cert-manager issuers. Tooling is usually open source with no license fee, but running OpenBao and cert-manager still takes operating time for upgrades, backups, unseal procedures and monitoring. The CPA firm charges for testing the controls over an observation period in a Type 2 examination, and that fee follows the number of controls and samples, not the cost of the encryption itself.
Several factors drive effort up. The number of data stores matters most: each database, object bucket, backup target and message queue needs an encryption decision and evidence that it is in place. Legacy systems that cannot terminate TLS or accept modern cipher suites often require wrapper services or replacement, which is the costliest item in many programs. Certificate sprawl, meaning certificates issued by several tools with inconsistent renewal, adds work that cert-manager can reduce for Kubernetes workloads but cannot remove for systems outside the cluster. Third-party endpoints, such as payment gateways, vendor APIs and customer-facing integrations, are outside your control, so you must document what they support and how you verify it.
When you request a quote, ask the partner to list every data store, endpoint and certificate issuer in scope, state which items are one-time (design, migration, initial key setup) and which recur (rotation, renewal monitoring, upgrades, audit support), and name who performs each task. Ask the CPA firm to confirm in writing which encryption samples it will test and how much evidence it expects per sample. Confirm the scope with your own inventory first, because a quote built on an incomplete list will understate the work.
Encryption questions buyers ask before a SOC 2
Does SOC 2 specify which encryption algorithm or key length to use?
No. The 2017 Trust Services Criteria do not name an algorithm, cipher suite, key length or protocol version. CC6.7 asks the organization to protect information while it is transmitted, moved or removed, and the points of focus mention encryption technologies and secure communication channels as examples. The auditor therefore tests whether your chosen mechanisms fit your risk assessment and whether you can show they are applied consistently. Your policy should state the minimum standards you adopt, such as current TLS versions and approved ciphers, and your scan or configuration evidence should show that systems meet them. Confirm the current baseline your auditor expects, since they will judge the choice against your own risk analysis.
Is TLS alone enough to satisfy SOC 2 encryption expectations?
Usually not on its own. TLS protects data in transit, which addresses the transmission part of CC6.7, but CC6.7 also covers information that is moved or removed, including removable media and endpoint devices. Confidentiality commitments under C1.1 and the access point in CC6.1 may also require protection of stored confidential data. Many organizations pair TLS on every external and internal path with encryption on laptops, backups and removable media. Ask your auditor which data flows and storage locations fall within the system description, because the scope decides which protections must be evidenced.
Do we need encryption at rest for every data store?
Not necessarily every store, but every store that holds in-scope information needs a documented decision. The auditor will expect you to identify where confidential and customer data lives, including databases, object storage, backups, logs, caches and developer workstations. Your risk assessment should explain which stores are encrypted, which compensating controls apply where encryption is not used, and why. Confirm with your auditor how they want exceptions documented, because an undocumented gap is more likely to become a finding than a justified one.
Can our own engineers implement SOC 2 encryption controls without outside help?
Often yes, if the team has the time and skills for the work. The engineering tasks include choosing mechanisms, configuring them, managing keys, rotating certificates and collecting evidence. The organization owns the controls and the policies, and it remains responsible for them regardless of who builds them. An implementation partner such as DeployOpen can plan, configure and document self-hosted systems inside your own infrastructure under a written scope, but it does not issue reports. Cost depends on the number of systems, the state of existing configuration and how much evidence automation you need. Ask any provider for a written scope, deliverables and the handover documents before work starts.
What evidence will the SOC 2 auditor request for encryption?
The auditor will ask you to show that encryption is designed and, for a Type 2 report, operating throughout the observation period. Typical evidence includes the encryption and transmission policy, a system inventory marking which data stores are encrypted, TLS configuration and scan results for external endpoints, certificate issuance and renewal records, key management procedures, key rotation logs, and disk encryption status reports for endpoints. Auditors usually sample items from those records, so you should be able to produce them quickly and show who approved exceptions. Confirm the sampling expectations and evidence format with your CPA firm before fieldwork begins.
Does an FTC Safeguards Rule or NAIC model law require more than SOC 2?
They can. SOC 2 is an attestation of your controls against chosen criteria, while the FTC Safeguards Rule and the NAIC Insurance Data Security Model Law are regulatory obligations placed on specific financial institutions and insurance licensees. The Safeguards Rule requires encryption of customer information on the company's system and in transit, along with penetration testing and vulnerability assessments on set schedules. The NAIC model law lists encryption of nonpublic information sent over external networks or stored on portable devices as a measure a licensee implements where appropriate. A SOC 2 report does not by itself satisfy these rules, so ask your customer which explicit encryption and testing terms apply and map them to your controls.
How DeployOpen scopes and prepares encryption evidence
DeployOpen prepares the encryption controls, configuration and records that a SOC 2 examination for encryption at rest and in transit will test, inside the client's own infrastructure. The independent CPA firm performs the examination and issues any report; DeployOpen does not issue audit reports, attestations or certifications.
How we scope
- Agree in writing which systems, data stores and transmission paths fall under the encryption controls.
- Confirm which confidential data classes and customer encryption rules apply to the service.
- Name the open-source components, key owners and the evidence the chosen CPA firm expects to see.
How we build
- Configure TLS for externally and internally exposed services, including certificate issuance and renewal with cert-manager.
- Set up OpenBao transit encryption and versioned key rotation for application data where the scope requires it.
- Restrict key access to named roles and enable audit logging for every key operation.
How we hand over
- Deliver a control matrix mapping each encryption measure to its criterion, owner and evidence source.
- Document configuration baselines, key rotation procedures and certificate lifecycle runbooks as version-controlled files.
- Provide test results and sample evidence packs so your CPA firm can sample them during fieldwork.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing of encryption controls are available as a retainer.
- Ask us to confirm during scoping which evidence your auditor will accept before any tooling is changed.
