Shield Platform Encryption does not protect Salesforce backup exports. The native Data Export Service produces plaintext CSV files in a ZIP archive, and no in-platform setting changes that. Every field encrypted by AES-256 inside Salesforce ships as readable text the moment an administrator clicks download.
HIPAA, GDPR, and SOX all impose encryption and recovery obligations that follow the data, not the platform. Teams that assume Shield covers backups build compliance documentation on a false premise — and discover it during an audit or a failed restore test.
Closing that gap requires work on both sides of the boundary: Shield configuration for data inside Salesforce, and separate AES-256 encryption, TLS 1.2+ verification, and key management controls for every backup path outside it. This article maps each layer administrators and compliance managers must configure, why the regulatory frameworks demand it, and what breaks when any layer is missing.
Where Shield Encryption Stops and Backup Risk Begins
Salesforce acknowledges that native platform features alone leave gaps in an overall data security strategy. Understanding where those gaps emerge prevents administrators from building compliance documentation on incorrect assumptions about encryption coverage.
Shield Platform Encryption implements CBC mode at the application tier and GCM mode at the database tier. Both layers use random initialization vectors and FIPS-validated keys. Salesforce encrypts data at rest with AES-256 server-side encryption by default, while Shield Platform Encryption for field-level encryption is not enabled by default and must be configured by administrators.
Administrators must enable encryption, configure policies for each data type, and run background jobs to encrypt pre-existing records.
The critical limitation is simple. Shield encryption protects data only while it resides within Salesforce infrastructure. The native Data Export Service produces CSV files packaged as ZIP archives. These files contain no encryption.
Trailhead tells administrators to store downloaded backup files securely in a safe location. That guidance confirms that encryption responsibility shifts to the administrator at download.
Additional constraints widen the gap. The free Data Export Service limits exports to seven-day limits. That creates a minimum seven-day recovery point objective. The export path also excludes metadata. Sandbox environments automatically inherit Shield Platform Encryption settings from production during a sandbox refresh and do not require separate manual encryption setup.
Encrypted fields also cannot be used in criteria-based sharing rules or SOQL ORDER BY clauses. Those limits sometimes force administrators to leave specific fields unencrypted.
Regulatory Requirements for Backup Encryption
HIPAA, GDPR, and SOX impose converging obligations on Salesforce backup data. Each framework reaches encryption at rest, encryption in transit, recovery capability, and documented control testing.
HIPAA technical safeguards
HIPAA classifies encryption of electronic protected health information as "addressable" under § 164.312, not optional. Organizations must implement encryption or document why an equivalent alternative is reasonable. For Salesforce teams storing protected health information in backups outside the platform, that analysis applies to exported backup files as well as in-platform records.
A January 2025 proposed rule would remove addressable status entirely. That change would make encryption a required specification for Salesforce backup handling, not only in-platform protection. Recent OCR enforcement actions have imposed penalties up to $1,500,000 for security rule violations.
Those violations include insufficient security measures. That enforcement risk applies directly to Salesforce backup processes when teams export protected data and fail to secure it.
GDPR Article 32 obligations
Article 32(1) lists encryption as an appropriate measure for security of processing. Article 32(1)(c) also requires the ability to restore availability and access to personal data after a physical or technical incident. That requirement creates a direct backup obligation for Salesforce data stored outside the platform.
Article 83(2)(d) makes encryption presence or absence an input to fine calculations. Violations of Articles 25 and 32 carry penalties up to €10,000,000 or 2% of global annual turnover. Documented restore and encryption controls are part of the operating model for Salesforce backup operations, not an afterthought.
SOX Section 404 IT controls
SOX Section 404 requires management assessment of internal controls, including IT controls. When Salesforce stores financially material data, backup encryption and recovery controls fall within IT General Controls reviewed during Section 404 audits.
Backup handling, change evidence, and recovery testing can all affect control design and audit outcomes. Failure to protect that data can constitute a material weakness.
Configuring AES-256 Encryption at Rest
Shield Platform Encryption requires a deliberate multi-step configuration process. Each step builds on the previous one. The sequence below covers the at-rest configuration path administrators must complete.
- Verify licensing. Shield Platform Encryption requires Enterprise, Performance, Unlimited, or Developer Edition with a Shield add-on.
- Assign permissions. The Manage Encryption Keys and Customize Application permissions must be assigned before accessing Encryption Settings. Add Manage Certificates for BYOK configurations.
- Select a key model. Choose between tenant secrets, BYOK, External Key Management, or Cache-only Keys. All models require AES-256-bit keys.
- Configure encryption policies. Navigate to the Encryption Policy page in Setup and select fields, files, and attachments to encrypt individually.
- Encrypt existing records. Use the Data Sync page to trigger background encryption. Enabling a policy does not retroactively encrypt existing data.
- Verify sandbox encryption after refresh. Sandbox environments automatically inherit Shield Platform Encryption settings from production during a sandbox refresh. Verify the inherited configuration matches expectations, and rotate tenant secrets so that sandbox and production do not share the same key material.
For BYOK implementations, Salesforce requires AES-256 keys, and BYOK certificates must use 4096-bit RSA. Separate BYOK configuration is required for each encryption scope. That includes field-level encryption, event log data, search index encryption, and database encryption.
Verifying TLS 1.2+ for Data in Transit
Salesforce supports TLS 1.2 and 1.3. TLS 1.3 support was added for outbound HTTPS callouts. Salesforce still cannot enforce TLS versions on systems that receive backup data. Administrators must perform that verification independently.
Administrators should audit current cipher suite usage in Login History. A custom list view can filter on legacy cipher suites. That view reveals connections using legacy RSA-only key exchange. Salesforce recommends ECDHE-based cipher suites with AES-GCM for connections.
Salesforce cannot configure these integration points automatically. Seven integration points require manual TLS verification:
- Backup storage destination endpoints. The receiving storage system TLS configuration must be verified independently.
- Third-party backup tool TLS libraries. Client-side TLS libraries operate outside Salesforce platform control.
- MuleSoft CloudHub deployments. All TLS 1.0/1.1 inbound connections will be blocked October 31, 2026.
- Exchange/EWS server configurations. Lightning Sync requires TLS 1.2+ enabled server-side.
- Email relay receiving servers. Salesforce may fall back to sending email unencrypted if the receiving server supports only TLS 1.0/1.1 and TLS is set to Preferred/Preferred Verify, but if TLS is Required/Required Verify, the email isn't delivered.
- Outbound callout endpoints. Test TLS 1.3 in sandbox before production deployment.
- BYOK key import operation endpoints. TLS must be enforced on all channels used for key material transfer.
NIST SP 800-52 Rev. 2 states that TLS implementations protecting federal data require a FIPS module, not only approved algorithms. Salesforce backup exports and key material moving through systems subject to federal requirements must meet that standard.
Teams with FedRAMP requirements should verify module validation status before the FIPS 140-2 acceptance deadline. In Salesforce DevSecOps workflows, that check applies to backup transfer paths and key-handling systems outside the core platform.
Selecting the Right Key Management Model
The key management model an organization selects determines who controls encryption keys, who manages rotation, and what happens during a key loss event. Administrators and compliance managers need to evaluate this decision together.
Select Salesforce-managed keys when no HSM infrastructure exists and compliance requirements do not mandate customer control of key material. Select BYOK when regulations require the organization to hold its own keys or when the ability to revoke Salesforce access by destroying key copies is necessary. Select BYOKMS or BYOKV when key management must remain outside Salesforce.
Two practices remain mandatory regardless of model. First, establish secure key backup capability. Shield Key Management Service derives encryption keys on demand from tenant secrets. If a tenant secret is lost, data is unrecoverable.
Second, document the key rotation schedule before enabling encryption in production. Key wrapping mechanisms must match the security strength of the wrapped key. An AES-256 key wrapped using AES-128 drops to 128-bit strength.
Closing the Backup Encryption Gap
The regulatory window for treating backup encryption as a future initiative is closing. HIPAA's proposed rule would eliminate the addressable designation that lets teams defer encryption decisions. MuleSoft CloudHub will block TLS 1.0/1.1 connections by October 2026. The FIPS 140-2 acceptance deadline adds another hard cutoff for teams on federal contracts. Each of these deadlines converts today's configuration gap into tomorrow's audit finding.
The technical work — Shield policies, TLS verification, key model selection — is finite and documented above. What stalls most teams is the operational layer underneath: automating backup processes, generating audit trails that survive examiner scrutiny, and maintaining version control that enables clean recovery when metadata breaks.
Request a demo to see how Flosum closes the gap between in-platform encryption and the backup automation, compliance documentation, and recovery controls auditors expect to find on the other side.
FAQ
Does Shield Platform Encryption protect Salesforce backup exports?
No. Shield protects data while it remains inside Salesforce infrastructure. Native backup exports produce plaintext CSV files packaged in ZIP archives.
What must administrators configure beyond Shield?
Beyond enabling Shield encryption policies, administrators must encrypt pre-existing records, verify TLS on every external endpoint that handles backup data, and select a key management model aligned to their regulatory requirements. Each of those areas is covered in the corresponding section above.
Why do Salesforce backups create a compliance risk?
HIPAA, GDPR, and SOX all impose requirements that extend to data stored outside the originating platform. When backup exports leave Salesforce without encryption, recovery controls, or documented evidence, they fall outside the compliance posture teams have built around in-platform data.
Is TLS 1.2 verification enough for backup workflows?
No. Teams also need to verify the receiving endpoints, client-side TLS libraries, key transfer channels, and any connected systems that handle backup data outside Salesforce.
What role does key management play in backup protection?
Key management determines who controls keys, how rotation occurs, and whether data can be recovered after a key loss event. Poor key handling can make encrypted data permanently unrecoverable.
Thank you for subscribing
