A Salesforce administrator discovers a bulk deletion after the recycle window has passed. With no documented restore path, every hour increases business risk. The same pressure hits compliance managers when change history expires before an audit and DevOps teams when a failed integration corrupts production data.

These scenarios share a common root: backup risk in Salesforce environments is operational. It shows up as lost customer records, broken automations, and emergency remediation work after bad changes or destructive events. Without a policy that defines retention, restoration steps, and test frequency, teams are left reacting instead of recovering.

This article shows how to build a Salesforce data backup and recovery policy that closes those gaps. It aligns the policy to established contingency and resilience standards, maps the Salesforce platform limits that create recovery exposure, and walks through the test procedures that prove restoration actually works.

With this policy structure, Salesforce teams can set defensible recovery targets, close native backup gaps, and produce audit-ready restoration evidence.

Where Native Salesforce Backup Falls Short

Salesforce provides built-in backup mechanisms, but their constraints create recovery gaps for organizations with regulatory retention needs or recovery targets shorter than a week. Those gaps shape what recovery, retention, and audit readiness look like in practice, and the backup policy needed to close them.

Data Export Service

The Data Export Service enforces a 7-day interval between manual exports. Data created or modified inside that window may be missing from the last native export. For Salesforce administrators, that gap directly affects achievable recovery point objectives.

Additional constraints further limit the service's usefulness as a recovery tool:

• Full exports only: No built-in mechanism for incremental exports, which increases processing time for large orgs
• 48-hour file availability: Export files are automatically deleted after 48 hours
• No metadata coverage: The tool does not export metadata
• Fragmented output: The output consists of separate CSV files with isolated data and scattered parent-child relationships
• No completion SLA: Export jobs may take several days or longer if system queues are busy

These limitations mean the Data Export Service functions more as an archive tool than a restore-ready backup.

Salesforce Backup

Salesforce Backup is a paid add-on that improves coverage over the Data Export Service. It enables customers to create backup copies of Salesforce data natively, set retention policies, and restore data back into Salesforce organizations.

Key capabilities and constraints include:

• Backup frequency: One backup per 24-hour cycle, with no sub-daily options
• Encryption: All backup data is encrypted both at rest and in transit
• RPO gap: Most enterprises want backups of mission-critical data to be no older than 15 minutes, but the daily ceiling falls well short of that target
• Customization limits: Configuration options may be more limited compared to third-party tools

For organizations with sub-daily RPO requirements or high transaction volume, this ceiling creates a policy gap that must be addressed through supplemental controls.

Recycle Bin and record deletion

Deleted record recovery depends on the Recycle Bin. Key constraints include:

• Default retention window: 15 days before permanent deletion (up to 30 days in some Salesforce Classic editions with extended retention)
• Post-deletion query window: The emptyRecycleBin() API references that deleted records can typically be queried for about 24 hours after removal from the Recycle Bin, not 15 days
• Per-license cap: A 5,000-record limit per license further constrains recovery for high-volume teams
• Object size ceiling: Native tools cannot back up objects above 2.147 billion records

Those limits matter for large Salesforce data models and long-lived production instances.

Setup Audit Trail

Salesforce's native Setup Audit Trail retains records for only 180 days. The UI only displays the 20 most recent entries at any given time, and older changes within the 180-day window are hidden from view unless exported. For teams with long retention mandates, that creates a documentation gap the backup policy must close with separate controls.

Salesforce's native logging capabilities provide a foundation for tracking changes, but they fall short of long-term compliance requirements. Key retention ceilings include:

• Setup Audit Trail: Logs expire after 180 days
• Field History Tracking: Caps at 18 months
• Salesforce Shield with Field Audit Trail: Can extend retention up to 10 years, but requires an additional paid add-on and careful storage planning

These ceilings are significantly shorter than the multi-year retention periods required by regulations like SOX (7 years), HIPAA (6 years), and GDPR (variable based on lawful processing).

Without proactive exports or supplemental tooling, audit evidence simply expires. The backup policy must account for these retention ceilings and define compensating controls, such as:

• Scheduled log exports to external storage
• Third-party archiving solutions
• Shield-based extensions with Field Audit Trail

These constraints do not make Salesforce unsuitable for regulated environments. They do mean the policy must identify each gap and map it to a compensating control.

Ten Components of an Effective Backup and Recovery Policy

A Salesforce backup policy must translate recovery goals into operating rules and evidence. These ten components create that structure and make audits, restoration, and ownership repeatable.

Established contingency, backup, incident, and resilience guidance provides the framework behind these components. The list below consolidates those requirements into one operating model for Salesforce teams.

1. Policy scope and governance statement

Document platform scope, resource requirements, and training schedules. Designate an ISCP Coordinator to own annual reviews and documentation. This component establishes organizational ownership; the operational details of backup frequency and incident-level authorities are defined in components 4 and 6.

2. RTO and RPO definitions

Set a Recovery Time Objective and Recovery Point Objective for each system. RTO defines maximum time to restore service. RPO defines maximum acceptable data loss measured in time.

RTO must be shorter than the Maximum Tolerable Downtime. That gap leaves time for data reprocessing after a restore. For Salesforce services, verify that provider recovery capabilities align with targets.

3. Data classification and backup tiers

Organize data into tiers based on business value and recovery priority. Cover all Salesforce data assets, regardless of location. Include application-level integrity and infrastructure-level integrity in the classification model.

4. Backup specifications

Document the backup method first. Specify whether each tier uses full, incremental, or differential backups.

Then define the operating requirements for each tier. Cover frequency and retention first. Then address encryption-in-transit standards and immutability requirements. Backup encryption must match or exceed production data protection. For Salesforce teams, this section turns abstract policy into a schedule administrators can execute. Storage-level decisions, including encryption at rest and geographic placement, are covered in component 5.

5. Storage architecture and the 3-2-1 rule

Use the 3-2-1 standard to structure storage decisions. That means three copies of important data, two media types, and one offsite copy. Define encryption-at-rest standards and storage geography requirements here.

For Salesforce recovery planning, that supports keeping at least one offline copy outside normal network reach. All stored copies should remain encrypted.

6. Roles and responsibilities matrix

Document the incident-level authorities that determine who acts during a recovery event. Specify who can authorize a restoration, who can confiscate or disconnect assets, and who can shut down systems. These authorities must be explicit so incident response does not stall.

7. Testing and validation procedures

Define how often recovery tests occur and what each test must prove. Include test restores for dependent components such as configuration files and encryption keys. For Salesforce teams, a successful export is not enough if related metadata or access dependencies fail during restore. Component 8 defines the metrics used to measure whether each test meets its targets.

8. Recovery performance metrics

Measure whether recovery work meets the defined RTO and RPO. Track these metrics:

• Elapsed restore time
• Data loss window
• Validation failures
• Repeat issues

This turns Salesforce recovery from a one-time drill into a managed operational process.

9. Reconstitution procedures

Document the return-to-normal process after restoration is complete. Unlike the test validation in components 7 and 8, this component covers production stabilization: confirming that live data is consistent, functionality is intact, and the system is ready for normal operations.

Also cover the return of backup data to offsite storage. Add a baseline backup of the restored system. Recovery is incomplete until production operations stabilize and recovery completion has been formally declared.

10. Required documentation appendices

Keep the appendices complete and current. These records formalize the procedures and structures defined in the preceding components. Include:

• Contact lists for personnel and vendors
• Recovery procedures (as defined in components 7 and 9)
• System diagrams
• Interconnection tables
• A Business Impact Analysis
• A test and maintenance schedule (as defined in components 7 and 8)

Moderate- and high-impact systems need additional appendices. Cover alternate storage, alternate site, and telecommunications requirements. For Salesforce programs, these records give administrators and auditors the evidence trail the main policy cannot hold alone.

Regulatory Requirements That Shape Your Policy

Regulatory requirements determine how long Salesforce data must remain recoverable and how quickly teams must restore it. They also define what evidence the policy must produce during an audit or incident review.

HIPAA (45 CFR § 164.308(a)(7))

Covered entities must establish procedures that create exact copies of electronic protected health information. Data backup and disaster recovery plans are required specifications. Testing and revision procedures are addressable, which means organizations must implement them or document an equivalent alternative. For Salesforce teams handling protected health information, backup settings and test logs must support exact retrieval.

GDPR (Articles 5(1)(f) and 32)

Organizations must have the ability to restore access to personal data in a timely manner after an incident. That term is context-dependent, so policy writers must justify specific RTOs through a recorded risk assessment. The accountability principle also requires evidence that backup capabilities meet the stated obligation. In Salesforce, that means retention and testing records must support the chosen recovery targets.

SOX (Section 802)

Electronic records related to audits and reviews must be retained for defined periods. The SEC rules extend the statutory 5-year period to 7 years. Backup systems must preserve data integrity, support retrieval, and prevent alteration across that full retention period. For Salesforce administrators, this directly affects archive duration, access controls, and proof of record integrity.

All three frameworks share one technical requirement. Backed-up data must be exactly retrievable. That is the standard a Salesforce recovery policy must satisfy.

Testing and Validating Your Recovery Plan

Recovery testing proves whether a Salesforce backup policy will work under pressure. Without restore validation, backup completion reports create false confidence.

A backup policy is only as reliable as its last restore. Backup processes rated effective in audits have still produced unreadable media during real incidents. For Salesforce teams, every policy must include restore validation, not just backup completion checks.

A three-tier testing model ties test depth to system impact levels. That model helps Salesforce teams match test depth to business risk.

1. Tabletop exercises (low-impact systems): Discussion-based sessions where personnel review roles and response procedures against specific scenarios
2. Functional exercises (moderate-impact systems): Component-level testing that validates backup capabilities, data recovery procedures, and application interdependencies without full production disruption
3. Full-scale functional exercises (high-impact systems): Complete end-to-end recovery testing, potentially including actual failover to alternate sites

All three tiers require annual execution at minimum. For Salesforce programs with frequent releases or sensitive records, additional drills help expose restore gaps before production data is at stake.

Run unscheduled reviews after organizational changes, actual incidents, or risk assessment updates. Each event can change dependencies, access patterns, or recovery priorities inside Salesforce.

Every test must measure whether RTO and RPO targets were achieved. A restore attempt alone is not enough. Document pre-exercise scope and objectives. Collect timing records during execution. Complete a post-exercise after-action report with corrective actions.

Closing the Gaps with Purpose-Built Salesforce Tools

Policy defines requirements, but tools determine how quickly teams can execute recovery and prove control. Purpose-built Salesforce tooling helps close the gaps that documentation alone cannot solve.

Flosum supports this by enabling version control, rollback capabilities, and audit trail generation for compliance reporting. Organizations with tighter recovery targets may also benefit from granular restore options and flexible storage outside standard platform limits. Enterprise tools built around Salesforce data and metadata are designed to provide these capabilities.

Protecting critical Salesforce data takes all three layers: policy, repeatable testing, and tooling built for the platform's data model. Request a demo with Flosum to see purpose-built version control, rollback, and audit trail capabilities in action.