top of page
Sesame Software

Salesforce Backup and Recovery Software for IT Teams

  • May 28
  • 9 min read

Updated: Jun 5

Salesforce does not back up your data — and compliance frameworks like HIPAA, SOX, GDPR, and CCPA require you to prove you can recover it. Mid-sized enterprise IT teams need Salesforce backup and recovery software that combines automated near real-time backups, configurable retention policies, full audit trails, end-to-end encryption, and regular restore testing. Sesame Software's Backup and Recovery platform is purpose-built for exactly this — providing point-in-time restore, patented history tracking, and flexible on-premises or SaaS deployment so your data stays in your control, not ours. With 30+ years of enterprise expertise and support for every major compliance framework, Sesame Software gives IT teams the tools to protect Salesforce data, satisfy auditors, and recover fast when something goes wrong.


Why Mid-Sized Enterprises Can't Rely on Salesforce's Native Data Protection

Salesforce is where your business lives — customer records, pipeline data, contracts, support history. And yet, Salesforce does not back up your data for you.

Salesforce shut down its own data recovery service in 2020. The platform offers a manual weekly export for full data backups and a Recycle Bin that retains deleted records for just 15 days. For a mid-sized enterprise managing thousands of records, compliance obligations, and audit cycles, that is not a backup strategy — it is a liability.

IT leaders responsible for Salesforce data protection need to answer three questions:

  1. If a user deletes 10,000 records today, how quickly can you restore them — and to what point in time?

  2. If a compliance auditor requests a full activity log from 18 months ago, where do you go?

  3. If your Salesforce org is unavailable, how long before operations recover?

The answers depend entirely on the Salesforce backup and recovery software you've put in place before the incident.


What Compliance Actually Requires From Your Backup Strategy

Compliance frameworks don't just ask you to "have backups." They specify what those backups must prove. Here's what compliance frameworks typically measure mid-sized enterprise IT teams against:


HIPAA (Healthcare)

  • Protected Health Information (PHI) must be recoverable in the event of system failure

  • Access to ePHI must be logged and auditable

  • Retention: typically 6 years minimum


SOX (Finance/Public Companies)

  • Financial records must be retained for 7 years

  • Audit trails must demonstrate who changed what data and when

  • IT controls must be documented and testable


GDPR (EU Data Subjects)

  • Right to erasure: you must be able to delete specific records — and prove you did

  • Data must be protected with appropriate technical measures (encryption)

  • Breach notification windows require knowing exactly what was exposed


CCPA (California Consumer Privacy)

  • Consumer data requests require knowing what you hold and where

  • Deletion requests require confirmed removal across systems, including backups


Each of these frameworks demands capabilities that go well beyond "we export a CSV every Sunday." A compliance-focused Salesforce backup strategy requires four specific capabilities: retention policies, audit trails, encryption, and regular restore testing.


The Four Pillars of Compliance-Focused Salesforce Backup


1. Configurable Retention Policies

Not all data ages the same way. A healthcare org must retain patient interaction records for years; a consumer brand may need to purge certain personal data on request within 30 days. Your automated Salesforce backup solution must let IT define retention rules at the object, record type, or policy level — not apply a single default to everything.


What to look for:

  • Configurable retention windows per data category (30 days, 1 year, 7 years)

  • Automated expiration and purge workflows that log when records are removed

  • The ability to hold specific records under legal hold, overriding standard retention

  • Separation of backup storage from production Salesforce, so data persists independently of org-level changes


A system where your IT team sets the rules — and the platform enforces them automatically — removes the human error risk that compliance auditors look for.


2. Full Audit Trails

An audit trail is proof. It answers: who accessed what, who changed what, who deleted what, and when.


Salesforce's native audit log (Setup Audit Trail) retains only 180 days of changes and covers configuration-level activity — not data-level changes like record edits, field updates, or mass deletions. For compliance, that's a significant blind spot.


Your compliance-focused Salesforce backup solution should capture:

  • Field-level change history with before/after values

  • User attribution on every change (including API-driven changes)

  • Deletion events, including cascade deletions through parent-child relationships

  • Metadata changes — when a field was added, removed, or renamed

  • A complete record of all backup jobs, restore jobs, and admin activity within the backup platform itself


This creates an immutable chain of custody that compliance teams and external auditors can rely on.


3. Encryption — In Transit and At Rest

Encryption is table stakes for enterprise Salesforce backup solutions. But the specifics matter enormously:

  • In transit: All data moving between Salesforce and your backup environment should be encrypted using TLS 1.2 or higher

  • At rest: Backup data stored on disk should be encrypted using AES-256 or equivalent

  • Key management: Where are the encryption keys held? Ideally, your organization controls the keys — not the vendor

  • Storage location: Can you store backup data in your own cloud tenant, on-premises infrastructure, or a specific geographic region to satisfy data residency requirements?


The strongest posture for mid-sized enterprise IT is a solution where your data stays in your environment — never passing through or residing on the vendor's servers. This satisfies GDPR data residency requirements, minimizes breach exposure, and keeps your security team in control.


4. Regular Restore Testing

A backup you've never tested is not a backup — it's a hope.

Compliance frameworks increasingly require organizations to demonstrate that backups are recoverable, not just that they exist. HIPAA's contingency planning requirements, SOX IT controls documentation, and ISO 27001 all include restore testing as a measurable control.


Your restore testing program should cover:

  • Frequency: At minimum quarterly full restore tests; monthly spot checks on critical objects

  • Scope: Test single-record restores, partial object restores, and full org point-in-time restores

  • Non-technical staff: Can a Salesforce admin (not a DBA) execute a restore? The best Salesforce data recovery tools are designed for this

  • Relational integrity: When you restore a parent record, do its child records restore correctly? Relationship fidelity is often where restores silently fail

  • Documentation: Every test should produce a timestamped log that can be presented to auditors


The goal is to be able to say — with evidence — exactly how long a restore takes, who can perform it, and what data is recovered. That's a compliance statement, not just an operational one.


Evaluating Salesforce Backup and Recovery Software: An IT Team's Checklist


When evaluating enterprise Salesforce backup solutions, mid-sized IT teams should assess vendors against these criteria:


Backup Frequency and RPO

  • How often does the solution capture changes? Hourly, every 15 minutes, near real-time (every 5 minutes)?

  • What is the Recovery Point Objective you can actually achieve — and can you document it?


Recovery Granularity and RTO

  • Can you restore a single record, a filtered subset, a full object, or the entire org?

  • Can you restore to a specific point in time, or only to the last backup?

  • How long does a full restore actually take? Get a number, not a range.


Metadata Backup

  • Does the solution back up Salesforce metadata (custom objects, fields, flows, layouts, permission sets) as well as data?

  • Can you compare metadata between environments (e.g., production vs. sandbox) to identify configuration drift?


Compliance Certifications

  • Does the vendor's platform support GDPR, HIPAA, SOX, and CCPA workflows?

  • Does the vendor hold SOC 2 Type II certification for their own infrastructure?


Deployment Flexibility

  • Can the solution run on-premises within your own infrastructure, or only as a SaaS product?

  • If SaaS, where is data stored? Is a private cloud or dedicated tenant available?

  • Is there a self-hosted option for organizations with strict data residency requirements?


Integration and Automation

  • Does the solution offer a REST API for integration with your monitoring stack (Datadog, New Relic, Splunk)?

  • Can your team trigger backup jobs and restore operations programmatically via CI/CD pipelines or cron schedulers?

  • Does it integrate with your identity provider (Azure AD/Entra, Okta) for SSO and RBAC?


Sandbox Seeding

  • Can you populate a sandbox environment with anonymized or masked production data for testing?

  • Is data anonymization built in, or does it require a separate tool?


How to Build a Compliance Backup Runbook for Your Salesforce Org


Once you've selected your backup tools for IT teams, the operational practice matters as much as the technology. Here's a framework for a compliance-ready Salesforce backup runbook:


Define Your Data Tiers

Not all Salesforce objects carry the same risk. Categorize your objects:

Tier

Examples

Backup Frequency

Retention

Critical

Accounts, Contacts, Opportunities, Contracts

Every 5–15 minutes

7 years

Important

Cases, Leads, Custom Objects

Hourly

3 years

Operational

Tasks, Events, Chatter

Daily

1 year

Metadata

Custom Fields, Flows, Profiles

Daily + on change

3 years


Establish Your Recovery Objectives

Document these before an incident, not during:

  • RPO (Recovery Point Objective): Maximum acceptable data loss. For most mid-sized enterprises: under 1 hour for critical data

  • RTO (Recovery Time Objective): Maximum acceptable downtime. Target: under 4 hours for critical object restoration


Assign Roles and Access

  • Who can authorize a restore? (IT lead, Salesforce admin, data governance officer)

  • Who executes the restore? (Should not require DBA-level access)

  • Who validates the restored data? (Business stakeholder sign-off)

  • Who documents the incident and the recovery? (Required for compliance reporting)


Schedule and Document Restore Tests

Create a recurring calendar of restore tests:

  • Monthly: Single-record spot check on 3–5 critical objects

  • Quarterly: Full object restore for Accounts, Contacts, and Opportunities

  • Annually: Full point-in-time restore of the entire org to a sandbox

  • After every major deployment: Metadata restore test


Each test produces a written record: what was restored, from when, by whom, how long it took, and whether relational integrity was maintained. That record is your compliance evidence.


Build Your Incident Response Playbook

Document the specific steps your team takes if:

  • A user reports mass record deletion

  • A developer accidentally overwrites production data via API

  • A rogue process corrupts a critical object

  • A Salesforce org experiences an unexpected outage

Each scenario maps to a different restore path. Having the playbook written before the incident reduces recovery time significantly and ensures the right people are in the right roles.


Common Mistakes Mid-Sized Enterprise IT Teams Make with Salesforce Backup


Assuming Salesforce handles it. The most dangerous mistake. Salesforce is responsible for platform availability — not your data. That responsibility is yours.


Backing up data but not metadata. A restore that brings back your records but not the custom fields, validation rules, and page layouts those records depend on is an incomplete restore.


Never testing restores. A backup job that completes successfully is not proof that data is recoverable. Test the restore.


Storing backups in the same org. If your Salesforce org is compromised or unavailable, you can't access backups stored inside it. Backups must live outside the production environment.


No documented retention policy. "We keep everything forever" creates compliance risk under GDPR and CCPA. A documented, automated retention policy protects you.


Overlooking parent-child relationships. Restoring a Contact without its associated Activities, Cases, and Opportunities creates orphaned records and data integrity problems. Your restore tool must understand and preserve relational structure.


What to Ask During a Salesforce Backup Vendor Demo


When evaluating mid-sized enterprise Salesforce backup vendors, move beyond slide decks and ask these questions live:

  1. Show me a point-in-time restore of a single record with full field history.

  2. Walk me through how your system handles a cascade deletion — if a parent Account is deleted, what happens to the child records?

  3. Where, exactly, is our backup data stored? Show me the architecture diagram.

  4. How do I produce a compliance report showing all backup and restore activity for the last 12 months?

  5. Can a non-technical Salesforce admin execute a restore without IT involvement?

  6. What happens to our data if we cancel our contract with you?

  7. Show me how you configure retention policies per object.

  8. What does your audit trail look like for a field-level data change?


If a vendor can't answer these live, that's the answer.


The Business Case: Why Compliance Backup Is an Investment, Not a Cost


Mid-sized enterprise IT leaders often have to justify backup and recovery budget to finance and executive leadership. Here's the frame:

  • Average cost of a data breach in 2024: $4.45 million (IBM Cost of a Data Breach Report)

  • Salesforce-related data loss incidents — accidental deletion, runaway automation, bad data migration — are among the most common causes of CRM data loss

  • Regulatory fines for GDPR violations reach up to 4% of global annual revenue

  • Audit findings that result from inadequate data retention controls create remediation costs that far exceed the cost of prevention


The compliance backup platform is not the expense. The absence of one is.


Summary: What a Compliance-Ready Salesforce Backup Strategy Looks Like


For mid-sized enterprise IT teams, a compliance-focused Salesforce backup and recovery approach requires:


Illustration of cloud data security: servers, database stacks, laptop, key, fingerprint, and shield linked by blue network lines.

  • Automated backups running as frequently as every 5–15 minutes for critical objects

  • Configurable retention policies aligned to HIPAA, SOX, GDPR, and CCPA requirements

  • Full audit trails capturing field-level change history, user attribution, and deletion events

  • End-to-end encryption (TLS in transit, AES-256 at rest) with customer-controlled key management

  • Flexible storage — on-premises, private cloud, or hybrid — to satisfy data residency requirements

  • Metadata backup and comparison alongside data backup

  • Documented restore testing on a monthly and quarterly schedule, with written evidence

  • Non-technical restore capability — business users can execute recoveries without DBA involvement

  • API-driven integration with your existing monitoring, automation, and identity infrastructure


When these elements are in place, your Salesforce data is protected, your compliance posture is defensible, and your team has a tested, documented recovery path before the incident — not during it.

Not Sure Where to Start with Salesforce Backup and Recovery?


We can help.


Schedule a demo today. See Sesame Software deliver secure Salesforce backup and recovery, enterprise data backup, and flexible data integration — all in one place.

Sesame Software connects Salesforce to on-premise or cloud systems. Healthcare organizations use this connection to build a complete, unified view of their data.



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



bottom of page