top of page
Sesame Software

The Complete Guide to Salesforce Audit Trail Evidence

Writer: Sesame Software
Sesame Software
Oct 13
9 min read

Updated: 3 days ago

Quick answer

Salesforce audit evidence is the record that proves who changed what in your org, when they changed it, who accessed it, and what your data looked like at any point in time. Salesforce gives you several native tools for this, including Setup Audit Trail, Field History Tracking, Field Audit Trail, and Event Monitoring. Each one covers part of the picture with its own retention limits and licensing. To meet SOX, HIPAA, GDPR, and CCPA reviews, most enterprises pair those tools with a customer-controlled backup that keeps full history, including deleted records, for as long as their regulations require.


What counts as audit evidence in Salesforce


When an auditor, regulator, or legal team asks for evidence, they're usually asking one of four questions:


  • Configuration changes: Who changed a permission set, profile, flow, or field, and when?

  • Field-level data changes: What was the old value, what's the new value, who made the change, and when?

  • Access and activity: Who logged in, viewed a record, ran a report, or exported data?

  • Data state at a point in time: What did a record, or a whole object, look like on a specific date, including records that have since been deleted?


Salesforce's native tools answer the first three questions, each for a limited window. The fourth question, point-in-time data state, is where native tools fall furthest short. It's also the question auditors increasingly ask.


Salesforce audit evidence infographic with four boxes on setup, field changes, access, and record history gaps.


Salesforce's native audit tools and what each one keeps


Setup Audit Trail

Setup Audit Trail records administrative and configuration changes: permission sets, profiles, roles, custom fields, page layouts, workflow and flow changes, and security settings. It shows who made each change and when.


It's on by default in every org. The Setup screen shows the 20 most recent changes, and you can download the last 180 days as a CSV file. Anything older than 180 days is gone unless you exported it first.


Field History Tracking

Field History Tracking logs the old value, new value, user, and timestamp for fields you choose to track on standard and custom objects. You can track up to 20 fields per object.


Salesforce keeps field history for 18 months in the user interface and 24 months through the API. It records individual changes, not a full snapshot of the record. And when a record is deleted, its field history goes with it.


Field Audit Trail

Field Audit Trail extends Field History Tracking for organizations that need longer retention. More on it in the next section.


Event Monitoring

Event Monitoring captures user activity such as logins, API calls, report exports, and record views. It's the main native tool for answering "who accessed what." Detailed event log files require Salesforce Shield or the Event Monitoring add-on, which keeps log files for one year by default. Without that license, you get only a few basic event types with very short retention.


The Recycle Bin

Deleted records sit in the Recycle Bin for 15 days. It's a safety net for accidental deletes, not a compliance record. It won't support a litigation hold, a fraud investigation, or proof that a GDPR erasure was completed.


Bar chart titled Native retention vs. what audits ask for compares Salesforce retention periods with HIPAA and SOX requirements.


What is Salesforce Field Audit Trail?


Field Audit Trail is a licensed Salesforce feature that keeps field history long after the standard 18-month window. It's available in Enterprise, Performance, and Unlimited Editions when you purchase Salesforce Shield or Field Audit Trail licenses.


Here's how it works:


  • More fields. You can track up to 200 fields per object, compared with 20 under standard Field History Tracking.

  • Automatic archiving. By default, Salesforce moves field history into an archive after 18 months in production and one month in sandboxes. You can define your own retention policy per object.

  • Long-term storage. Archived changes are stored in the FieldHistoryArchive big object and kept until you delete them.


Field Audit Trail is a solid option for long-term field history, but it leaves gaps that matter for audit evidence:


  • It still tracks changes, not full record state. You can see that a field changed, but rebuilding exactly what a record looked like on a given date takes work.

  • Deleted records are still a problem. It doesn't give you an independent copy of records that were deleted from the org.

  • The evidence lives inside Salesforce. Your audit history sits in the same platform it's auditing, under Salesforce's storage and access controls. For organizations with data sovereignty or customer-controlled storage requirements, that's a gap.

  • It covers field changes only. Setup Audit Trail still ages out after 180 days, and access logs depend on your Event Monitoring license.


Where native Salesforce audit tools stop


Put the native tools side by side and the same four gaps show up:


  1. Retention windows are shorter than audit windows. 180 days of configuration history and 18 to 24 months of field history don't stretch to a multi-year audit.

  2. No point-in-time snapshots. Native tools log changes, but they don't store what a full record or object looked like on a specific date.

  3. Deleted records lose their history. Once a record leaves the Recycle Bin, its field history is gone too.

  4. The logs live in the org they monitor. A permissions mistake, a bad data load, or an aggressive retention setting can erase the trail, and auditors expect evidence stored independently of the system being audited.


What regulators expect from Salesforce audit trails


Regulations rarely name Salesforce features, but their expectations translate directly into audit evidence requirements.


SOX. Section 404 requires internal controls over financial reporting, including evidence of who changed financial data and system configuration. SEC rules adopted under Sarbanes-Oxley require audit firms to keep audit workpapers for seven years, so most public companies keep the financial-system evidence behind them at least that long. That includes change history on opportunities, contracts, and orders that feed revenue.


HIPAA. The Security Rule requires audit controls that record and examine activity in systems containing ePHI (45 CFR 164.312(b)). Required security documentation must be kept for six years (45 CFR 164.316(b)(2)), and many covered entities apply the same six-year window to access and change logs for Health Cloud and other systems holding PHI.


GDPR. The accountability principle (Article 5(2)) means you must be able to show how personal data was processed. Article 30 requires records of processing activities, and Article 17 means you need proof that an erasure request reached every copy of the data, including backups.


CCPA. You need to locate every record holding a consumer's personal information, show how it was used, and confirm deletions were complete across all storage.


Here's the bottom line: native tools give you weeks or months of evidence, while audits ask about years.


How to build a Salesforce audit evidence workflow


The strongest approach uses native tools for day-to-day monitoring and a customer-controlled backup for long-term evidence. Here's a six-step framework.


Infographic titled Six steps to audit-ready Salesforce evidence, with six numbered boxes and blue-purple workflow labels.

Step 1: Scope your regulated objects and fields. Identify the financial objects in scope for SOX, the objects holding PHI for HIPAA, and the objects with EU or California personal data for GDPR and CCPA. Map each to its required retention period.


Step 2: Turn on native monitoring. Enable Field History Tracking on the fields that matter most, and use Event Monitoring, if you're licensed, to alert on bulk exports, off-hours logins, and unusual API activity.


Step 3: Capture configuration history before it ages out. Export Setup Audit Trail on a regular schedule, well inside the 180-day window, so there's never a gap in your change management evidence. Back up metadata such as flows, profiles, and permission sets so you can show what your configuration looked like at any point.


Step 4: Capture full data history in storage you control. Back up record state, including deleted records, on a frequent schedule into a database you own. Keep it for each regulation's full retention period. This is what answers the "what did this look like on March 3?" question.


Step 5: Lock down access to the evidence. Use role-based access so only a small group of compliance and security staff can query audit records, and nobody can quietly modify or delete them. Tie access to SSO or LDAP so you can show segregation of duties.


Step 6: Export evidence and test recovery on a schedule. File job logs and reports with your audit workpapers before anyone asks for them. Run recovery tests on a calendar and document the results, because an untested control is an assumption, not evidence.


What good audit monitoring looks like day to day


When this is working, audit prep stops being a scramble. Someone checks backup job status each morning and follows up on anything that failed. Retention rules run automatically. Setup Audit Trail exports and recovery tests happen on a set calendar. When an auditor's request arrives, months or years of history, access records, and test results are already on file and ready to export.


How Sesame Software turns Salesforce history into audit evidence


Sesame Software's Salesforce backup and recovery platform fills the gaps native tools leave, and it keeps the evidence in your environment.


  • Patented History Tracking. For every object you back up, Sesame Software keeps a parallel history table that records field-level changes over time, including deleted records. There's no 20-field limit and no 18-month cutoff.

  • Point-in-time answers. See exactly what a record, field, or object hierarchy contained on any date, and restore it if you need to.

  • Storage you control. History lives in your own SQL Server, Oracle, or PostgreSQL database, on-premises or in your cloud, through a customer-hosted architecture. Sesame Software doesn't keep a copy of your data.

  • Near real-time capture. Backups run as frequently as every five minutes.

  • Metadata history. Flows, profiles, permission sets, Apex classes, layouts, and other metadata are captured alongside data, and Metadata Compare shows side-by-side what changed between two points in time.

  • Retention you set. Set retention per object to match SOX, HIPAA, or GDPR, and use GDPR Clean to purge data on schedule when retention ends or a data subject requests erasure.

  • Built-in audit logging and access control. Every backup and restore job is logged. Admin, Manager, and Reader roles, with SSO or LDAP, keep evidence access tight, and sensitive fields can be hidden from view while still being backed up.

  • No coding required. Compliance and IT teams can configure retention, pull logs, and retrieve evidence from a web interface.


Sesame Software is SOC 2 Type II certified, holds 15 patents, and brings 30+ years of enterprise data management experience to organizations like Procter & Gamble and the U.S. government.


Ready to stop scrambling when the auditor calls? Talk to a Sesame Software data expert.


How to check and enable a Salesforce audit trail

  • View Setup Audit Trail: Go to Setup, type "View Setup Audit Trail" in Quick Find, and open it. You'll see the 20 most recent changes and can download the last 180 days.

  • Enable Field History Tracking: In Setup, open Object Manager, select the object, choose Fields & Relationships, click Set History Tracking, and select up to 20 fields. Changes then appear in the record's History related list.

  • Field Audit Trail: After purchasing Shield or Field Audit Trail licenses, define a retention policy per object to control when field history is archived.

  • Event Monitoring: With Shield or the Event Monitoring add-on, access event log files through the API or the Event Monitoring Analytics app.



Salesforce Audit Trail Frequently Asked Questions


What is Salesforce Field Audit Trail?

Field Audit Trail is a licensed Salesforce feature, available with Salesforce Shield or Field Audit Trail licenses, that archives field history beyond the standard 18 months. It tracks up to 200 fields per object and stores archived changes in the FieldHistoryArchive big object until you delete them. The data stays inside Salesforce, so organizations that need customer-controlled storage or deleted-record evidence often add an independent backup.

Setup Audit Trail keeps 180 days. Field History Tracking keeps 18 months in the interface and 24 months through the API. Field Audit Trail keeps archived field history until you delete it. Event log files are kept for one year by default with Shield or the Event Monitoring add-on. The Recycle Bin holds deleted records for 15 days.

Setup Audit Trail covers configuration and administrative changes and is included in every org. Field Audit Trail covers field-level changes to records over a much longer period and requires an additional license.

Only partly. They supply useful activity data, but they lack point-in-time snapshots, independent storage, and history for deleted records, and most of their retention windows are shorter than audit windows. Pairing them with a customer-controlled backup closes those gaps.

No. Shield's Field Audit Trail is one way to extend field history. An independent backup with history tracking can keep field-level and point-in-time history for as long as you need, in storage you control, without a field limit.

Not natively. Once Setup Audit Trail entries pass 180 days, field history passes its retention window, or a record leaves the Recycle Bin, Salesforce can't bring that evidence back. The only fix is capturing it before it ages out.

Yes. An erasure request covers every copy of personal data, including backups. Your backup tool needs a governed way to delete that data and a record showing the deletion happened.


Sources


Related Resources

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


bottom of page