A compliance manager starts audit prep expecting a routine review. Then a recent Salesforce deployment reveals changed encryption settings and incomplete audit evidence. That is where encryption risk becomes personal. Invisible configuration drift can turn a normal audit into a scramble to explain who changed what and when.

This article explains how Salesforce encrypts data at rest and in transit. It also shows which frameworks apply and where standard platform controls leave operational gaps. IT compliance managers and system administrators will see why encryption governance depends on cryptographic settings. They will also see why it depends on controlled deployments.

How Salesforce Encrypts Data at Rest and in Transit

Salesforce uses different encryption models, and the wrong choice can disrupt filtering, reporting, and compliance workflows. This section shows how each option protects data and where operational tradeoffs appear.

Shield Platform Encryption

Shield Platform Encryption uses HSMs to derive Data Encryption Keys from partial key secrets. Because key material never exists in plaintext outside the HSM boundary, exposure at the application layer is significantly reduced—even if an attacker gains access to the database, the keys themselves remain protected.

One of Shield's core advantages is flexibility in how encryption keys are managed. Administrators can choose from several key models depending on their organization's security posture and regulatory obligations:

• Salesforce-managed keys for operational simplicity when internal key management is not required
• Customer-supplied keys (BYOK) for organizations that need to meet data sovereignty mandates by controlling their own key material
• External Key Management using services like AWS KMS or Azure Key Vault, which keeps key lifecycle management entirely outside Salesforce
• Cache-Only Keys where key material never persists in Salesforce, giving organizations the highest degree of control over data access

Shield also supports two encryption scopes, each suited to different protection needs. Database Encryption covers the transactional database broadly, including metadata, Chatter posts, and transaction logs. Field-Level Encryption, by contrast, targets specific fields and offers a choice between two modes: probabilistic encryption provides stronger protection by generating unique ciphertext for each encryption operation, while deterministic encryption sacrifices some of that strength so that filtering and exact-match lookups can still function. Choosing between them depends on whether the field needs to support queries or whether maximum confidentiality is the priority.

Classic Encryption

Classic Encryption is Salesforce's legacy approach to field-level protection, relying on a 128-bit AES key to secure both standard and custom fields on supported objects. Access to decrypted values is gated behind the "View Encrypted Data" permission, so only users with that explicit grant can see the underlying content. While Classic Encryption still functions, its scope is narrow compared to Shield Platform Encryption, which covers a broader range of fields, data elements, and encryption modes. For that reason, new implementations should prioritize Shield unless a specific constraint requires the legacy model.

Encryption in Transit

Salesforce protects data in transit by default—all sessions use TLS, and Platform APIs use HTTPS as the standard transport protocol. However, that built-in protection only covers the Salesforce side of the connection. When data moves between Salesforce and external services like AWS, the integration design determines whether encryption holds end to end. These cross-platform connections rely on SSL certificates and mutual authentication, a process that confirms server identity on both sides before any data is exchanged. Teams need to verify that every connected service maintains the same transport standard, because a single integration that falls back to a weaker protocol can undermine the security of the entire data flow.

Regulatory Frameworks That Require Salesforce Data Encryption

Knowing how Salesforce encrypts data is only part of the task. Compliance teams must also map those controls to formal obligations, because each framework defines what must be protected and documented.

HIPAA (45 CFR § 164.312)

HIPAA treats encryption as something organizations should strongly consider for data stored on systems and sent over networks. It is listed as an “addressable” safeguard, which does not mean optional; instead, organizations must decide whether encryption is reasonable for their situation. If they do not use it, they need justification documentation showing why, perform a risk analysis, and use another protection that works just as well or explain why no equivalent alternative is reasonable.

HIPAA also requires some compliance documentation to be kept for at least six years, but that rule does not apply to all medical records. Each organization must evaluate its own unique risks and requirements against HIPAA standards. 

GDPR (Articles 25 and 32)

Unlike HIPAA, which allows organizations to justify not encrypting data under certain conditions, GDPR takes a more prescriptive stance: encryption choices must be proportionate to the risk involved. That assessment applies across the full Salesforce processing lifecycle, from the moment personal data is collected to when it is deleted. This is especially relevant for teams managing customer records, consent data, and cross-border access, where data may pass through multiple Salesforce environments, integrations, and geographic regions, each introducing new risk that encryption controls need to address.

Article 32 requires appropriate technical and organizational measures to ensure a level of security appropriate to the risk, which may include, as appropriate, the pseudonymization and encryption of personal data. Article 25 extends that requirement throughout the processing lifecycle.

PCI DSS (Requirements 3 and 4)

PCI DSS sets the clearest encryption rules for Salesforce environments that handle cardholder data. Where HIPAA and GDPR allow organizations to weigh risk and choose proportionate controls, PCI DSS is more rigid: if your Salesforce org stores, processes, or transmits payment card information, specific encryption requirements apply with no room for alternative controls.

In practice, this means that stored Primary Account Numbers must be rendered unreadable using encryption, truncation, or hashing under PCI requirements. It also requires strong cryptography for cardholder data in transit over public networks, which directly affects how teams configure integrations between Salesforce and external payment processors or financial systems. For Salesforce administrators, this makes the choice of encryption scope and key management model a compliance requirement rather than a best practice.

SOX (Section 404)

SOX brings a different angle to the encryption conversation. While the frameworks above focus on how data itself must be protected, SOX is primarily concerned with whether changes to financial systems are governed by traceable internal controls.

SOX Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting. If encryption settings protecting financial data are modified during a Salesforce deployment and there is no documented evidence of who made the change, why, and when, that gap becomes a reporting risk.

To meet that requirement, teams typically map their technical encryption and retention controls to established governance frameworks such as COSO, COBIT, or ISO 27001, which provide the structured control objectives that SOX auditors expect to see documented.

Where Standard Salesforce Encryption Falls Short

Meeting encryption requirements is not the same as sustaining them in production. Standard Salesforce controls protect data, but they still leave feature limits, retention gaps, and deployment risks that matter during audits.

Functional Restrictions on Encrypted Fields

Encrypted fields protect sensitive data, but they can also break features that teams rely on. That tradeoff affects architecture decisions long after encryption is enabled.

Certain encrypted fields cannot be used in criteria-based sharing rules. Some cannot support similar opportunity searches. Others do not work with external lookup relationships.

Some encrypted fields also break SOQL limits. Encryption overhead can also reduce storage by about 10 to 20 percent for text fields.

Managed packages must be installed before enabling encryption on certain fields. Otherwise, installer failures can occur. Sensitive fields that drive business logic, record access, or integrations may require redesign. That work often happens before encryption is viable.

Audit Trail Retention Gaps

Strong encryption settings still need durable audit evidence. Salesforce keeps key setup history for a limited period, and that creates risk when regulators review older changes.

Salesforce Setup Audit Trail retains data for only 180 days. That window falls short of the retention mandates discussed above. Correct encryption settings do not replace missing audit evidence during an examination.

Deployment Security Blind Spots

Even correct encryption settings can be undone during release activity. Standard Salesforce deployment tools do not enforce security controls across complex pipelines.

Standard Salesforce change sets were built for point-and-click administration. They were not built for automated pipeline orchestration. That leaves gaps when security configurations move between environments.

Change sets provide no automated rollback for metadata deployments. They also provide no security validation gates before code reaches production. They do not include integrated audit capture for deployment actions. Encryption configurations can drift when metadata moves between environments with different active settings.

What an Effective Encryption Governance Strategy Requires

Once the platform limits are clear, the next step is governance that closes those gaps. Encryption settings alone are not enough when teams must retain evidence, control deployments, and recover from mistakes.

1. Extended audit retention that meets multi-year regulatory mandates and does not depend on the platform's default retention window
2. Deployment-level audit records that capture who deployed metadata changes, when they did it, and what happened
3. Version control for security configurations that tracks every change to encryption settings, field security, and permission sets with full attribution
4. Automated rollback capability that supports rapid recovery when deployments overwrite security configurations
5. Policy-based deployment gates that block noncompliant changes from reaching production without manual review

These capabilities close the gap between correct encryption settings and a sustainable control posture across environments and release cycles.

Closing the Gap with Purpose-Built DevSecOps

Encryption protects Salesforce data, but governance protects the settings and evidence around it. Regulated teams need both controls working together when release activity can change security posture.

DevSecOps solutions purpose-built for Salesforce address the deployment side of this problem. Flosum provides deployment pipelines for Salesforce metadata and supports the governance controls outlined above.

Longer-term review depends on retaining deployment evidence outside Salesforce's default windows. Complete deployment history and change documentation reduce audit preparation time when deadlines approach. Request a demo with Flosum to explore how purpose-built Salesforce DevSecOps supports your compliance requirements.