Salesforce Backup Architecture for HIPAA and GDPR

Quick Answer

Designing a compliant Salesforce backup architecture for HIPAA and GDPR means going well beyond Salesforce's native export tools. It requires automated near real-time backups, complete metadata protection, field-level audit history with no retention ceiling, granular point-in-time recovery, and backup data stored inside infrastructure you control — not on a vendor's shared servers. In 2026, the enterprise teams with the most defensible compliance posture combine a purpose-built backup platform like Sesame Software with a clear architecture that satisfies auditors, survives data incidents, and operates without developer intervention.

Why native Salesforce backup is not a compliance strategy

Salesforce does not back up your data on your behalf. This is one of the most consequential misunderstandings in enterprise Salesforce administration, and it is stated plainly in Salesforce's own documentation: data protection is the customer's responsibility.

What Salesforce does provide is a set of native tools that offer partial visibility into data changes and limited recovery options. Data Export Service allows manual or scheduled exports of your org data as CSV files — but these are point-in-time snapshots, not continuous backups, and restoring from them means overwriting current data with stale data across the entire org, with no ability to restore individual records or fields. Field History Tracking logs changes to up to 20 fields per object and retains that history for 18 months — far short of HIPAA's six-year retention requirement and SOX's seven-year requirement. The recycle bin retains deleted records for 15 days before permanent removal.

For compliance teams operating under HIPAA or GDPR, each of these limitations is a gap that an audit will find. Eighteen months of field history does not satisfy a six-year retention obligation. Fifteen days of recycle bin coverage does not constitute a deleted record audit trail. A weekly CSV export does not provide point-in-time recovery at the record level. And none of these native tools store backup data outside of Salesforce's own infrastructure — meaning your backup is subject to the same platform risk as your production data.

The architecture question is not whether to supplement native Salesforce tools. It is how to design a backup architecture that satisfies the specific technical safeguard requirements of HIPAA and the accountability and residency requirements of GDPR, while remaining operationally manageable for enterprise IT teams who have more than backup to worry about.

What HIPAA actually requires from a Salesforce backup architecture

HIPAA's Security Rule establishes the technical safeguard requirements for electronic protected health information. For Salesforce environments used in healthcare — Health Cloud implementations, CRM at payers and providers, life sciences CRM — these requirements translate into specific backup architecture obligations.

The Contingency Plan standard requires covered entities to establish and implement procedures to create and maintain retrievable exact copies of ePHI. The word exact is doing significant work here. A CSV export is a copy. An exact, retrievable copy that can be restored to a specific point in time, at a specific record, without corrupting surrounding data is a meaningfully different capability. HIPAA does not specify backup frequency, but the standard of care in regulated healthcare organizations in 2026 is near real-time or sub-hourly backup intervals for Salesforce ePHI.

The Audit Controls standard requires mechanisms to record and examine activity in information systems that contain or use ePHI. For Salesforce, this means field-level audit history for every field on every object that touches ePHI — not the 20-field limit of native Field History Tracking — retained for the full six-year HIPAA retention period. The audit log must be stored outside Salesforce, in infrastructure the covered entity controls, where it cannot be modified or deleted by anyone with Salesforce administrative access.

The Person or Entity Authentication standard, combined with the Audit Controls requirement, means the backup and recovery platform itself must log who accessed backup data, who initiated restore operations, and what the outcome was — creating an audit trail of the backup system's own activity that can be produced during an HHS audit.

The minimum necessary principle requires that access to ePHI — including backup copies of ePHI — be limited to those who need it. The backup platform must support Role-Based Access Control granular enough to limit backup access by user, by object, and by operation type, rather than providing broad administrative access to everyone with credentials.

What GDPR actually requires from a Salesforce backup architecture

GDPR's requirements for Salesforce backup architecture operate across several articles, and the compliance obligations are broader than most enterprise IT teams initially recognize.

Article 5's integrity and confidentiality principle requires that personal data be processed in a manner that ensures appropriate security, including protection against accidental loss, destruction, or damage. This is the data availability obligation that justifies backup in GDPR terms — and it applies to backup data itself, not just production data. Backup copies of personal data must be secured to the same standard as production data.

Article 17's right to erasure creates a backup-specific obligation that is frequently overlooked. When a data subject exercises their right to erasure, the deletion must extend to backup copies — not just production records. A backup architecture that retains deleted records indefinitely without a governance mechanism for propagating erasure requests to backup storage creates a GDPR violation in the backup layer. The architecture must support targeted deletion of specific data subject records from backup storage, not just from Salesforce production.

Article 30's records of processing activities requirement means the backup architecture itself must be documented — what data is backed up, where it is stored, how long it is retained, who has access, and under what legal basis the backup processing occurs. For organizations using cloud-hosted backup platforms where backup data is processed on the vendor's infrastructure, the vendor is a data processor and must be documented as such with a Data Processing Agreement in place. Self-hosted backup architecture, where backup data never leaves the organization's own infrastructure, simplifies the Article 30 documentation significantly.

Article 32's appropriate technical measures requirement includes the obligation to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems. For Salesforce backup, this translates to encrypted backup storage, access controls, backup integrity verification, and recovery testing — all of which need to be documented and demonstrable to supervisory authorities on request.

The five components of a compliant Salesforce backup architecture

A backup architecture that satisfies both HIPAA and GDPR technical requirements, survives an audit, and supports operational incident response is built from five distinct components working together.

Near real-time automated backup

The backup must run automatically, without human initiation, at intervals short enough to minimize data loss exposure. For HIPAA environments, the standard of care is backup intervals of five to fifteen minutes for ePHI. For GDPR environments where personal data availability is an Article 5 obligation, sub-hourly backup intervals are the defensible standard. Sesame Software's backup platform runs automated backups as frequently as every five minutes, creating a continuous recovery timeline rather than daily snapshots that leave hours of potential data loss between backup points.

Manual or scheduled export processes are not acceptable as the primary backup mechanism in a compliance architecture. They create dependency on human action, introduce gaps when the scheduled process fails silently, and produce snapshots rather than continuous recovery points.

Complete metadata backup

Salesforce metadata — object definitions, field configurations, page layouts, permission sets, profiles, workflow rules, validation rules, flows, and other org configuration — is as critical to operational continuity as data records, and it is entirely separate from data backup. Losing metadata through an accidental admin change or a botched deployment can render Salesforce unusable even if all data records are intact.

A compliant backup architecture includes automated metadata capture alongside data backup, with version history that allows comparison between metadata states across time. Sesame Software's Metadata Compare feature provides visual, side-by-side comparison of metadata environments — identifying exactly what changed between two points in time, which is operationally essential for diagnosing post-deployment issues and legally relevant for compliance investigations. Metadata Restore supports recovery through both Workbench and Salesforce CLI methods, giving IT teams the flexibility to restore configuration without engaging Salesforce support.

Field-level audit history with no retention ceiling

Audit history that satisfies HIPAA's six-year retention requirement and SOX's seven-year requirement cannot be built on Salesforce's native Field History Tracking, which retains data for 18 months and covers only 20 fields per object. The backup platform must capture complete field-level change history — every field, every object, every change — and retain it for the customer-defined retention period, stored outside Salesforce in infrastructure the organization controls.

Sesame Software captures complete field-level history with no field count limits and no platform-imposed retention ceiling. Every change is logged with the previous value, the new value, the user who made the change, and the timestamp. Deleted records are retained beyond Salesforce's 15-day recycle bin for the customer-defined retention period — enabling compliance teams to produce the complete lifecycle history of any record, including its deletion, for regulatory or legal purposes.

Granular point-in-time recovery

Recovery capability determines whether a backup architecture is operationally useful or just a compliance documentation exercise. Full-org restore and full-object restore are too coarse for enterprise incident response — they overwrite current data with historical data indiscriminately, creating a second incident in the process of recovering from the first.

The right recovery capability operates at three levels of granularity. Record-level restore brings back a specific record to its state at a specific timestamp. Field-level restore updates specific fields on specific records to their historical values without touching any other data. Value-level restore allows compliance teams to see what a specific field contained at a specific point in time and restore only that value. All three levels should preserve Salesforce's parent-child relational integrity automatically — restoring an Opportunity should not orphan its related Opportunity Line Items, and restoring a Contact should maintain its relationship to its Account.

Sesame Software's point-in-time restore operates at all three levels with automatic relational integrity preservation. Non-technical users — compliance managers, Salesforce administrators, legal team members — can execute targeted restores through the visual interface without engaging a data engineer.

Customer-controlled storage and data residency

Backup data stored on a vendor's shared infrastructure creates the same data residency and compliance exposure as production data processed through a cloud-hosted pipeline. For GDPR data residency requirements, for HIPAA security perimeter obligations, and for national data sovereignty laws, backup data must be stored in infrastructure the organization controls, in the geographic region required by applicable regulations.

Sesame Software stores backup data exclusively in the customer's own environment — on-premise servers, private cloud instances, or the customer's own cloud storage accounts in the required geographic region. Sesame Software retains no copies of customer backup data. The organization controls the storage location, the retention period, the access controls, and the encryption keys. This customer-controlled model is the architecture that satisfies data residency obligations by design rather than by vendor assurance.

Sesame Software versus common alternatives

Understanding how Sesame Software compares to the alternatives enterprise teams most commonly evaluate helps clarify where the architectural differences actually lie.

Sesame Software versus Salesforce native tools

Salesforce's native backup capability — Data Export Service, Field History Tracking, and the recycle bin — covers none of the five components of a compliant backup architecture comprehensively. Data Export produces point-in-time snapshots, not continuous backup. Field History Tracking covers 20 fields for 18 months, not all fields for six or seven years. The recycle bin retains deleted records for 15 days, not for the compliance retention period. Metadata backup is not covered at all. Recovery is full-org or full-object, not record-level or field-level. Native tools are a starting point, not a compliance solution.

Sesame Software versus Own (OwnBackup)

Own is a widely used Salesforce backup platform with a strong product focused on data protection and sandbox seeding. Its usability is good and its Salesforce coverage for standard objects is reliable. The architectural difference that matters for compliance-sensitive organizations is deployment model. Own is a cloud-hosted SaaS platform — backup data is processed and stored on Own's infrastructure, with regional storage options available but no self-hosted or on-premise deployment path.

For organizations under GDPR with strict data residency requirements, or under HIPAA where ePHI must remain within the covered entity's own security perimeter, Own's cloud-hosted architecture requires careful legal and compliance review. Organizations for whom customer-hosted deployment is a hard requirement cannot be served by Own's deployment model regardless of feature capability. Sesame Software's customer-hosted architecture satisfies this requirement without compromise.

Own also covers Salesforce backup specifically — it does not provide data replication, ETL, or data warehousing capability. Organizations that need backup alongside ongoing Salesforce replication to an analytics destination require a second platform to cover the integration use case. Sesame Software covers both within a single self-hosted deployment.

Sesame Software versus Spanning and Druva

Spanning and Druva are both cloud-hosted Salesforce backup platforms, positioned primarily at the mid-market and SMB segments. Both offer straightforward usability and standard Salesforce backup and recovery capability. Neither offers self-hosted deployment, which places them outside the evaluation for organizations with strict data residency or sovereignty requirements. For enterprise IT teams managing HIPAA or GDPR compliance at scale, neither platform provides the audit trail depth, retention configurability, or deployment control that a compliance-grade architecture requires.

Building the audit evidence package

A compliant Salesforce backup architecture is only as valuable as the evidence it produces. Regulators and auditors do not evaluate architecture documents — they evaluate evidence that the architecture is operating as designed. The backup platform needs to produce documentation that supports audit responses without requiring manual compilation of log files and exports.

The evidence package for a HIPAA audit of Salesforce backup typically includes backup job logs showing every automated backup run over the retention period, access logs showing who accessed backup data and when, restore logs documenting every recovery operation including who initiated it and what was recovered, the Business Associate Agreement with the backup vendor if the platform processes ePHI outside the covered entity's infrastructure, encryption documentation confirming that backup data is encrypted at rest and in transit, and RBAC documentation showing that access to backup data is limited to authorized personnel.

The evidence package for a GDPR supervisory authority inquiry includes the Article 30 records of processing documentation for the backup system, data subject erasure request logs showing that deletion requests were propagated to backup storage, data residency documentation confirming that backup data is stored in the required geographic region, the Data Processing Agreement with the backup vendor if applicable, and the data breach notification timeline if the audit is incident-related.

Sesame Software's audit logging captures all of the operational data required to compile these evidence packages. The backup job history, access logs, and restore audit trail are stored within the customer's own environment, accessible to compliance and legal teams through the platform interface without requiring technical data extraction.

Evaluation criteria for enterprise Salesforce backup platforms

When evaluating backup platforms against compliance requirements, these are the criteria that determine whether a platform is architecturally suited to enterprise HIPAA and GDPR environments.

Deployment model is the first and most important filter. Customer-hosted deployment — where backup data is processed and stored inside the organization's own infrastructure — is required for organizations with strict data residency obligations or HIPAA security perimeter requirements. Platforms that cannot offer this are eliminated before feature evaluation.

Backup frequency determines the maximum data loss exposure. Five to fifteen minute backup intervals are the standard for ePHI and GDPR-sensitive personal data. Daily or weekly backup frequency is not a compliant backup strategy for production Salesforce environments containing sensitive data.

Retention configurability must match your regulatory obligation, not the vendor's default. HIPAA requires six years. SOX requires seven. The platform must allow customer-defined retention periods, with backup data stored in customer-controlled infrastructure for the required duration.

Recovery granularity determines operational utility. Record-level and field-level point-in-time recovery is the minimum requirement for enterprise incident response. Full-org and full-object recovery are too coarse for production environments where surgical recovery is necessary to avoid creating collateral data disruption.

Metadata backup and recovery is a separate capability from data backup and must be evaluated separately. The platform must capture org configuration alongside data records, with version history and comparison tooling.

Audit trail completeness — field-level change history for all fields, deleted record tracking, access logging, and restore operation logging — must be verified against your specific compliance framework requirements. Platforms that cover some audit requirements but not others create gaps that surface during audits rather than evaluations.

Non-technical usability for compliance and legal teams determines whether the platform is an operational tool or an IT-managed resource. Compliance managers and legal teams should be able to access audit history, run data subject access reports, and initiate targeted restores without engineering support.

Salesforce Backup and Recovery Frequently Asked Questions

Does Salesforce back up my data automatically?

No. Salesforce states explicitly that data protection is the customer's responsibility. Salesforce provides Data Export Service, Field History Tracking, and the recycle bin as native tools, but none of these constitute automated backup with point-in-time recovery capability. Enterprise IT teams are responsible for implementing a purpose-built backup solution that meets their compliance and recovery requirements.

How frequently should Salesforce be backed up for HIPAA compliance?

HIPAA does not specify a backup frequency in its technical safeguard standards, but the standard of care for ePHI in production Salesforce environments is near real-time or sub-hourly backup intervals. Sesame Software supports automated backups as frequently as every five minutes, which is the interval that provides the lowest data loss exposure for compliance-sensitive Salesforce environments.

What is the difference between Salesforce data backup and metadata backup?

Data backup captures the records stored in Salesforce objects — Accounts, Contacts, Opportunities, Cases, custom object records, and associated field values. Metadata backup captures the org configuration — object definitions, field configurations, permission sets, profiles, workflow rules, flows, and other structural settings. Both are required for a complete backup architecture. Losing metadata through an accidental admin change can make Salesforce non-functional even if all data records are intact.

Can GDPR right to erasure requests be applied to Salesforce backup data?

Yes, and they must be. GDPR Article 17 requires that erasure requests extend to all copies of personal data, including backup copies. A backup architecture must support targeted deletion of specific data subject records from backup storage — not just from Salesforce production. Sesame Software's backup platform supports governed deletion from backup storage as part of a complete GDPR erasure workflow.

How does Sesame Software differ from Own (OwnBackup) for compliance use cases?

The primary architectural difference is deployment model. Own is a cloud-hosted SaaS platform — backup data is processed and stored on Own's infrastructure, with no self-hosted or on-premise deployment option. Sesame Software is customer-hosted — all backup processing occurs inside the customer's own environment, with no data on Sesame Software's servers. For organizations under GDPR data residency requirements or HIPAA security perimeter obligations where customer-hosted deployment is a compliance requirement, Sesame Software satisfies that requirement and Own does not.

What retention period should Salesforce backup data be kept for HIPAA and GDPR?

HIPAA requires six years of retention for records related to ePHI. SOX requires seven years for financial records. GDPR requires retention for the duration of the legitimate purpose plus any applicable litigation or regulatory inquiry period. The backup platform should be configured to the longest applicable retention period across all frameworks the organization operates under, with customer-controlled storage that the organization manages independently of the vendor's default retention settings.

---

---

Found this post helpful? Share it with your network using the links below.