Salesforce Audit & Compliance Features Every Admin Should Know

A practitioner’s guide to every native and Shield-powered audit feature in Salesforce — what each one captures, what it leaves out, and how they fit together to satisfy SOX, HIPAA, GDPR, and your auditors.

Security & Compliance Verified: Spring ’26 Reading time: ~16 min

Why audit and compliance matter

Every Salesforce org is a small regulatory environment. SOX wants to know who changed financial data. GDPR wants you to prove which fields hold personal data. HIPAA wants a record of who accessed a patient’s record. PCI DSS wants logs of access to cardholder data. Auditors want immutable evidence that controls are working.

Salesforce provides a layered set of features to answer these questions — some free and native, others bundled into the premium Salesforce Shield add-on. The trouble is that they overlap, they each have different retention periods, and the documentation refers to them under several names (Setup Audit Trail, Audit Trail, Field History, Field Audit Trail, Event Log Files, Event Logs, Real-Time Events…). Knowing which feature captures what — and where each one stops — is the difference between a clean audit and a frantic Friday afternoon trying to reconstruct what happened.

Two layers, two questions

Most Salesforce audit conversations collapse into two questions, and the features below answer one or the other:

Setup Audit Trail and Health Check answer Layer 1. Field History Tracking, Field Audit Trail, Login History, and Event Monitoring answer Layer 2. Real-Time Event Monitoring spans both. Data Classification gives auditors the map that tells them which layer to care about for any given field.

Setup Audit Trail: the 180-day configuration logbook

Setup Audit Trail is the single most-asked-about audit feature in Salesforce — and the one most admins underestimate. It records every administrative change made through Setup: profile and permission set edits, field metadata changes, sharing rule modifications, role hierarchy edits, login IP range changes, login flow updates, package installs, and even changes performed by background users from managed packages.

Each entry logs the change, the user who made it, the date, the source IP, and (for delegated administrators) the user who initiated the action. It’s enabled by default — there is no setup step — and accessed at Setup → Quick Find → View Setup Audit Trail.

What it captures vs. what it doesn’t

The 180-day cliff

Salesforce retains Setup Audit Trail data for 180 days (six months). The UI displays only the 20 most recent entries; the full 180-day window is accessible only by clicking Download to export a CSV. After 180 days, entries are permanently deleted — there is no native mechanism to extend retention.

The hidden risk: background user changes

Managed packages — including Salesforce’s own — make Setup changes as part of installation and upgrades. These appear in Setup Audit Trail under the package’s user account. When something breaks after an upgrade, the Audit Trail is often where the smoking gun lives. Reviewing it after every release is a high-yield habit.

Field History Tracking: change capture for record data

Where Setup Audit Trail watches configuration, Field History Tracking watches data. Enable it on an object, pick the fields you care about, and Salesforce records every change to those fields — the old value, the new value, the user, and the timestamp — in the object’s history related list and in the corresponding history object (AccountHistory, OpportunityHistory, {Object}__History for custom objects, and so on).

Setup path

1. Go to Setup → Object Manager and open the object you want to track.
2. Click Fields & Relationships, then click Set History Tracking in the upper right.
3. If this is the first time, tick Enable Field History for the object.
4. Select the fields to track — up to 20 fields per object on standard Field History Tracking.
5. Add the {Object} History related list to the page layout to expose the history to users.

What you can — and cannot — track

Most standard objects (Account, Contact, Lead, Opportunity, Case, Order, and so on) and every custom object support field history. The following field types cannot be tracked: formula fields, roll-up summary fields, auto-number fields, the long text area when over 255 characters, and system fields such as CreatedBy and LastModifiedBy (those are already captured everywhere).

Field Audit Trail: Shield’s long-term memory

For organizations that need to track more than 20 fields, retain history longer than 18 months, or both — typically those subject to SOX (seven-year retention), HIPAA (six years), or regulated financial services and healthcare workloads — Salesforce offers Field Audit Trail as part of the Shield add-on. Field Audit Trail extends Field History Tracking with custom retention policies, expanded field capacity, and archival to a Big Object called FieldHistoryArchive.

How retention policies work

Retention is governed by a HistoryRetentionPolicy object that you define per tracked object. The policy specifies how many months of history to keep on the live {Object}History object before Salesforce archives it into FieldHistoryArchive. Once Field Audit Trail is enabled, the policy is defined and deployed via the Metadata API, and modified using REST, SOAP, or Tooling API.

Standard vs. Field Audit Trail at a glance

Querying the archive

Because FieldHistoryArchive is a Big Object, it has special query rules. You can filter by FieldHistoryType, ParentId, and CreatedDate, but full table scans and aggregate functions like COUNT() are not supported. Plan SOQL queries around a known parent record ID or a bounded date range.

Login History: who’s coming through the door

Every Salesforce org logs login attempts — successful and failed — for the last six months. Login History captures the user, login time, source IP, login type (Application, API, OAuth, etc.), browser, platform, status (Success, Invalid Password, Locked Out, etc.), and the authentication method used.

Access it at Setup → Quick Find → Login History. Like Setup Audit Trail, the data can be downloaded as a CSV, and the underlying LoginHistory object is queryable via SOQL and the API.

What to actually look for

Login History is most valuable when combined with detection logic. A few patterns worth flagging:

Event Monitoring: the full activity recorder

If Setup Audit Trail records what changed in the org and Field History records what changed in the data, Event Monitoring records what users did. It captures runtime activity — logins, logouts, API calls, report exports, page loads, URI clicks, Apex executions, Visualforce hits, dashboard runs, login-as-user events, and dozens more — and writes it into the EventLogFile standard object.

Event Monitoring ships in two forms. Free Event Monitoring is included with Enterprise, Performance, Unlimited, and Developer editions but exposes a limited set of event types (Apex Unexpected Exception, CSP Violation, Hostname Redirects, and a few others). Paid Event Monitoring — sold as part of Shield or as a standalone add-on — unlocks the full catalogue of 50+ event types, hourly log generation, and retention of up to one year.

The event types that matter most for compliance

How event logs work

Event log files are CSV files generated asynchronously after the activity occurs — hourly for paid customers and every 24 hours for free customers. Each file is delivered as a record of the EventLogFile object, with the actual CSV stored as a file attachment. To consume them, query EventLogFile via SOQL, retrieve the file body, and parse it locally — or push it to Splunk, Datadog, QRadar, or your SIEM of choice.

Real-Time Event Monitoring and Transaction Security

The Event Log File model has one drawback for security teams: the delay. By the time a user has exfiltrated 50 reports, the log file describing what happened may not exist for another hour. Real-Time Event Monitoring (RTEM) closes that gap by streaming events through the Salesforce Streaming API and persisting them in Big Object storage for up to six months.

Each streamed event has a sibling Big Object. ReportEvent streams every report view; ReportEventStore persists it. ApiAnomalyEvent streams machine-learning-detected API anomalies; ApiAnomalyEventStore persists them. The same pattern applies to LoginEvent, SessionHijackingEvent, CredentialStuffingEvent, PermissionSetEvent, BulkApiResultEvent, and more.

Threat Detection and Transaction Security

Two capabilities sit on top of the streaming infrastructure:

Health Check: your security configuration score

Health Check is a free, native feature that scores your org’s security settings against a baseline. It’s the easiest “show me where we stand” tool in Salesforce, and it’s the first thing most auditors will ask you to run.

From Setup → Quick Find → Health Check, the tool produces a summary score from 0 to 100, with settings grouped into four risk categories: High-Risk, Medium-Risk, Low-Risk, and Informational. Settings include password policies, session timeouts, login IP ranges, certificate management, sharing model defaults, and dozens of other configurable controls.

Baselines

The default baseline is the Salesforce Baseline Standard, which represents Salesforce’s recommended values. You can upload up to five custom baselines — useful for organisations that need to enforce internal security policies that diverge from Salesforce defaults, or that need to maintain different baselines for different environments (production vs. sandbox).

What the score actually means

The Fix Risks button is the workhorse: it lets you push baseline-recommended values to settings without leaving the page. Each setting can also be edited individually, which is important for cases where the baseline value conflicts with a known business requirement (for example, your team genuinely needs longer session timeouts for kiosk users).

Security Center: multi-org compliance at scale

Health Check tells you the security posture of one org. Security Center tells you the security posture of all your orgs at once. It is a paid add-on (sold separately from Shield) and aggregates Health Check scores, user permission summaries, MFA adoption rates, and Setup Audit Trail data across every connected org into a single dashboard.

Why it exists

Enterprises with five, ten, or fifty Salesforce orgs (production, full sandboxes, partial sandboxes, developer orgs, separate business unit instances) face a real visibility problem: which org is exposed today? Security Center surfaces that answer without requiring an admin to log into each org and run Health Check by hand.

What it shows

Data Classification: tagging sensitive fields

Audit features tell you what changed. Data Classification tells you which changes matter. Introduced in Summer ’19 and refined since, it adds four metadata attributes to every field that admins can use to express the regulatory weight and sensitivity of the data that field holds.

The four classification attributes

These attributes live on the FieldDefinition Tooling API object, which means you can query the classification of every field in your org with a single SOQL statement:

SELECT QualifiedApiName, ComplianceGroup, SecurityClassification, BusinessOwnerId FROM FieldDefinition WHERE EntityDefinition.QualifiedApiName IN ('Account','Contact','Lead')

Why this matters for audits

When an auditor asks “show me every field in your org that holds GDPR-relevant data,” the answer should be a SOQL query — not a meeting with the data architect. Data Classification turns that question into a one-line query and feeds downstream tooling: Shield Platform Encryption uses it to suggest encryption targets, Data Detect uses it to auto-tag scan results, and a well-designed data dictionary uses it to surface compliance scope.

A layered audit strategy

No single feature satisfies every audit requirement. A defensible compliance posture stacks them — using free tooling where it covers the need, layering Shield where it doesn’t, and pushing data to external archives wherever Salesforce retention falls short of regulatory minimums.

A reference stack

Common pitfalls to avoid

Even well-tooled orgs run into the same failure modes. A few to watch for:

1. Trusting Salesforce as the system of record

Setup Audit Trail expires at 180 days. Field History Tracking expires at 18 months. Login History expires at six months. Event Log Files expire at one year on the most generous tier. None of these are systems of record for multi-year compliance. Export early, export often.

2. Confusing standard with Shield

The phrase “audit trail” gets used loosely in Salesforce documentation. Setup Audit Trail is free. Field Audit Trail is paid Shield. They are different features with different scopes. Misreading the name leads to either over-paying for a feature you don’t need or under-engineering for a requirement you can’t meet.

3. Tracking too many fields, learning nothing

The temptation on a new org is to flip every field history checkbox. Don’t. Tracked fields generate noise that buries the signal during an investigation. Classify your fields first, then track the ones that map to your compliance scope — PII, financial data, status fields tied to approvals, ownership and access fields.

4. Forgetting to add the History related list

Enabling Field History Tracking writes to the history object, but users won’t see the data unless the {Object} History related list is added to the page layout. Easy to miss; embarrassing to explain to an auditor.

5. Treating Health Check as a one-time gauge

Configuration drifts. A 95 today can be an 82 in three months as new users, profiles, and integrations land. Schedule Health Check runs and trend the score over time — that trend is far more meaningful to auditors than a single snapshot.

6. Ignoring Event Monitoring because it’s “too technical”

Event Log Files are CSVs. They open in Excel. Even without a SIEM, a weekly review of ReportExport events catches an enormous fraction of insider data exfiltration. The barrier to entry is much lower than the documentation makes it look.

Frequently asked questions

What’s the difference between Setup Audit Trail and Field History Tracking? ⌄

Setup Audit Trail logs configuration changes made in Setup — profile edits, permission set changes, field metadata updates, sharing rule changes, and similar. Field History Tracking logs data changes — when a value in a tracked field on a record is created, edited, or deleted. They are complementary: Setup Audit Trail tells you who changed the org, while Field History Tracking tells you who changed the data.

How long does Salesforce retain Setup Audit Trail data? ⌄

180 days (six months). The UI shows only the 20 most recent entries, but the full 180-day window can be exported as a CSV. After 180 days, entries are permanently deleted with no native option to extend retention. Most compliance frameworks require longer retention, so regularly exporting and archiving the CSV is a standard admin practice.

Do I need Salesforce Shield to track field changes? ⌄

No. Standard Field History Tracking is included in all editions that support it and lets you track up to 20 fields per object with 18 months of retention (24 months via API). Field Audit Trail — part of Salesforce Shield — extends this to 200 fields per object as of Spring ’26 and up to 10 years of retention. Use the standard feature for general auditing; add Field Audit Trail when regulations like SOX, HIPAA, or GDPR require multi-year retention.

What is the difference between Event Monitoring and Real-Time Event Monitoring? ⌄

Event Monitoring captures user activity in Event Log Files generated hourly or daily, written to the EventLogFile object. Real-Time Event Monitoring streams events in near real time via the Streaming API and stores them as Big Objects for up to six months. Real-Time Event Monitoring also enables Transaction Security policies (block, require MFA, or notify) and Threat Detection (ML-based anomaly identification). Both ship as part of Salesforce Shield.

Is Salesforce Health Check free? ⌄

Yes. Health Check is a native, no-cost feature in Setup that scores your org’s security settings (0 to 100) against the Salesforce Baseline Standard or up to five custom baselines. Security Center, which aggregates Health Check scores across multiple orgs, is a paid add-on.

Can I extend Login History beyond 6 months? ⌄

Not natively. Login History retains six months of data. To keep login data longer, either export the LoginHistory object regularly via API or CSV, or upgrade to Event Monitoring, which captures login data as Event Log Files retained for up to one year, or to Real-Time Event Monitoring, which streams LoginEvent records into Big Object storage.