Encrypted production data that loses protection during a sandbox refresh, a Marketing Cloud transfer, or a deployment is not a theoretical risk—it is the audit finding compliance leaders keep discovering too late.

The bottom line: Salesforce platform encryption, even with Shield enabled, does not deliver end-to-end data protection on its own. Compliance leaders need a five-layer encryption framework—covering data at rest, in transit, at the application layer, in key management, and across deployment pipelines—to close the gaps regulators examine.

That stance comes from documented product limitations. Salesforce encryption tools leave exposure points in cross-cloud transfers, sandbox refreshes, encrypted field functionality, and deployment audit evidence. These are not edge cases. They are known behaviors that create pressure when auditors assess data movement, key control, and release operations across environments.

For Chief Data Officers and compliance managers responsible for Salesforce protection, this article provides the layered framework needed to identify and close those gaps before an auditor does. Readers will learn what five layers enterprise organizations should document, where platform defaults fall short, and how deployment pipeline controls close the exposure points most teams overlook.

Where Salesforce Encryption Falls Short

Salesforce encryption is not a single setting—it is a tiered model, and each tier comes with limits that affect what compliance leaders can actually prove in an audit. Understanding those limits starts with knowing what each tier covers, where Shield forces functional compromises, and where encryption drops off entirely.

What each tier covers—and what it does not

Salesforce operates two tiers of encryption, and the gap between them creates documented regulatory exposure:

• Classic Encryption ships with standard licenses. It uses 128-bit AES and covers only custom text fields. It cannot encrypt files, attachments, or standard fields, and does not support Bring Your Own Key.
• Shield Platform Encryption requires a paid add-on. It upgrades to AES 256-bit and extends coverage to standard fields, files, and attachments.

Shield closes the most visible coverage gaps—but upgrading does not eliminate trade-offs. Compliance leaders who stop at "we have Shield" risk overestimating their data protection posture.

Shield narrows functionality, not just risk

Even with Shield enabled, encrypted fields cannot be used in:

• Criteria-based sharing rules
• ORDER BY clauses
• WHERE filters
• Aggregate functions

Those restrictions force design decisions. Organizations that need deduplication on encrypted fields, for example, must use deterministic encryption, which is cryptographically weaker due to its static initialization vector. The result is a trade-off between platform functionality and encryption strength—one that compliance teams must document and defend.

Where encryption breaks entirely

The functional trade-offs above still assume data stays within the Shield-protected environment. It often does not. Two documented gaps remove encryption protection altogether:

1. Marketing Cloud transfers — Studio imports do not support Platform Encryption. When personal data moves from Sales Cloud or Service Cloud into Marketing Cloud, it loses its encryption in transit. For organizations subject to GDPR or HIPAA, that transfer becomes an unprotected hand-off of regulated data.
2. Sandbox refreshes — Shield encryption configuration is applied to sandbox environments by default when Shield Platform Encryption is enabled in production and the sandbox is refreshed. Yet sandboxes refreshed with production data can remain unprotected. Development and QA teams may be working with real customer data that has silently lost its encryption layer.

These are not edge cases—they are documented product behaviors. Together with the functional trade-offs above, they show why platform settings alone do not prove end-to-end protection across Salesforce environments and connected services.

What Regulators Actually Require

Auditability, retention, design controls, and key governance affect compliance outcomes—regulators examine far more than a Salesforce encryption setting.

Four regulatory frameworks govern Salesforce encryption obligations for multinational enterprises. Each one extends beyond a platform-level setting. CDOs managing global operations must map those requirements to Salesforce configurations and deployment controls.

GDPR

GDPR requires encryption to be built into system design and applied to personal data protection. Late or partial configuration does not satisfy that expectation.

Article 32(1)(a) explicitly names data encryption of personal data as a security measure. Article 25 requires appropriate technical and organisational data protection measures to be integrated at the time of system design, while encryption is primarily addressed as a risk-based technical measure under Article 32 and is not mandated by Article 25 to be configured only at design time.

Maximum penalties reach €20 million or 4% of global annual turnover. For Salesforce teams, that raises the cost of leaving personal data exposed in transfers, sandboxes, or release processes.

HIPAA

HIPAA requires audit controls and treats encryption as a control that must be implemented or formally justified. That makes configuration gaps difficult to defend.

The Security Rule designates audit controls at 45 CFR 164.312(b) as required with no exceptions. Encryption for data at rest and in transit is classified as addressable. Regulated entities must implement it or document equivalent alternatives. In Salesforce environments, that standard applies to how teams protect data and record changes across environments.

SOX and PCI DSS

SOX and PCI DSS extend encryption obligations into control design, documented architecture, and key accountability. Technical settings alone do not satisfy those requirements.

SOX Section 404 requires management assessment of internal controls, with IT controls covering user access, change management, and audit logging for financial data systems. In Salesforce, those expectations apply to financial data configurations and the release process around them.

PCI DSS v4.0 introduced crypto architecture requirements. It also mandates that key custodians formally acknowledge their responsibilities in writing. For Salesforce teams, that makes key ownership and deployment evidence part of the compliance record.

5 Encryption Layers Enterprise Organizations Need

One missing layer can expose protected Salesforce data during storage, transfer, key handling, or release operations. These five layers close the gaps auditors review.

A compliant Salesforce data protection strategy needs five layers of encryption and control coverage. Each layer maps to specific controls and addresses gaps that single-tier encryption cannot cover. Missing coverage in any layer increases audit exposure.

1. Encryption at rest

Encryption at rest must cover live records and backup data. Field-level encryption alone does not complete this layer.

NIST SP 800-53 Rev. 5, Control SC-28 requires cryptographic protection of information at rest, including backup data. Organizations should activate Shield for all fields containing sensitive data. They should also build a field-level encryption traceability matrix that connects data classification to encryption method.

2. Encryption in transit

Encryption in transit must cover every runtime connection. That includes Salesforce APIs and third-party connectors, not only browser sessions.

All runtime communication must be encrypted, even for public data endpoints. In Salesforce, that requirement applies to browser sessions, integrations, and API traffic between environments and connected services. Salesforce enforces TLS 1.2 minimum, with TLS 1.3 as the current recommendation. Every integration point requires explicit verification.

3. Application-layer encryption

Application-layer encryption requires trade-offs between confidentiality and functionality. Field usage should determine the encryption mode.

Probabilistic encryption provides maximum confidentiality for fields that do not require search. Deterministic encryption supports filtering and deduplication at reduced cryptographic strength. Selecting encryption modes based on field use cases helps Salesforce teams balance security and functionality.

4. Cryptographic key management

Key management is its own control layer. Compliance teams need ownership, lifecycle control, and documented custody.

NIST SP 800-57 Part 1 Rev. 5 defines key lifecycle states from pre-activation through destruction. In Salesforce programs, that lifecycle affects how teams assign custody, rotate keys, and document control over encrypted data. Organizations should use own keys over vendor-provided keys for maximum control. Hyperforce-based instances support external keys through AWS KMS integration.

5. Deployment and backup encryption

Deployment and backup controls protect data when it moves outside steady-state platform use. Auditors examine whether protected Salesforce data stays protected during releases and retention—any lapse here undermines the other four layers.

NIST SP 800-53 Control CP-9(8) mandates cryptographic protection of backup information at primary and alternate storage locations. The CSA matrix governs deployment pipeline security through its Change Control and Configuration Management domain. In Salesforce, this layer covers release operations, backup protection, and the evidence trail around both.

These five layers must function as a unified encryption architecture, not as isolated controls. Gaps between layers create the exposure points that auditors target during compliance assessments.

Organizations should build a cross-layer encryption matrix. It should map each data element to its encryption method at rest and in transit. It should also map application-layer encryption, key management, and deployment pipeline controls.

The matrix should document the responsible key owner. It should also document the encryption standard applied and the verification method for each layer.

This matrix serves as the primary audit artifact for encryption coverage across environments. Without this consolidated view, compliance teams cannot identify where data transitions between layers without protection. It also gives reviewers one document that links each sensitive field to its full encryption chain.

Organizations that maintain this matrix continuously reduce audit preparation time. They also reduce the risk of discovering gaps under regulatory scrutiny.

The Deployment Pipeline Blind Spot

Encryption at rest, in transit, at the application layer, and through key management only holds if the deployment pipeline does not undo it. For most Salesforce organizations, that is exactly where protection quietly breaks down.

Salesforce native audit tools cap retention at 180 days and 18 months—yet regulatory mandates under HIPAA and SOX require six to seven years of evidence. Neither native record captures which CI/CD job triggered a deployment, which policy gates were evaluated, or the integrity state of artifacts at deployment time. That gap between what auditors request and what the platform retains is where compliance findings take root.

The threat landscape is accelerating. The FBI's September 2025 advisory documented active threat groups targeting Salesforce platforms through credential theft and compromised OAuth tokens from integrated applications. Pipeline threats like exposed secrets, unsigned artifacts, and weak access controls on pipeline infrastructure compound the risk. NIST SP 800-204C already requires logging all activities associated with code and build updates—a scope that extends well beyond what Salesforce natively records.

The five-layer framework in this article gives compliance leaders a defensible architecture. But architecture without execution is just documentation. The layer most organizations leave unfinished is the one that connects every other layer to provable, long-term audit evidence: the deployment pipeline.

Automated deployment pipelines purpose-built for Salesforce close that gap by generating immutable audit trails, enforcing policy-based controls, and retaining deployment evidence for as long as regulators require. The next audit cycle is not waiting for your team to catch up. Request a demo with Flosum and close the blind spot before it becomes a finding.

FAQ

What is the biggest Salesforce encryption gap for compliance leaders?

The most commonly overlooked gap is not limited to field encryption. It is the break between encrypted production data, cross-cloud transfers, sandbox refreshes, backups, and deployment pipelines. Auditors often focus on those transition points because they reveal whether encryption controls remain consistent across environments.

Is Salesforce Shield enough for regulatory compliance by itself?

No. The article shows that Shield strengthens encryption coverage, but documented limitations remain in areas such as Marketing Cloud transfers, sandbox configuration, encrypted field functionality, and deployment audit provenance. Compliance teams still need layered controls beyond platform encryption alone.

Why does key management matter as much as encryption itself?

Encryption only provides full control when the organization can govern the key lifecycle, ownership, rotation, and verification process. That is why the framework in this article treats cryptographic key management as its own layer rather than a background administrative task.

Why are deployment pipelines part of data protection?

Deployment pipelines can expose secrets, move misconfigured metadata into production, and leave incomplete audit evidence if they are not controlled. For regulated Salesforce environments, pipeline governance becomes part of encryption assurance because it determines whether compliant configurations stay compliant over time.

How should enterprises document encryption coverage for audits?

A cross-layer encryption matrix is the most practical starting point. It maps each sensitive data element to its encryption method at rest, in transit, at the application layer, in key management, and in deployment and backup processes, giving auditors a single artifact to review.