SOX Compliance in Salesforce: The Steps Auditors Actually Test

Your Salesforce org falls under SOX as soon as it feeds your financial statements. If quotes, orders, contracts, or billing data live there and flow into revenue, your external auditor will treat the org as in scope.

The audit doesn't ask whether Salesforce has good security features. It asks whether your team runs specific controls the same way every time and can prove it.

Auditors test three things: whether your IT general controls (ITGC) scope is complete, whether duties are separated, and whether every production change has approval evidence dated before the deployment.

This guide walks through each one, then compares a manual approach with controls built into the release process.

How SOX reaches your Salesforce org

Section 404 of the Sarbanes-Oxley Act requires management to assess internal control over financial reporting every year, and larger filers also need an auditor's attestation. The law never mentions Salesforce. Auditors connect it to your systems through ITGCs, the controls that make an application's data and logic trustworthy.

Under AS 2201, the PCAOB standard for this audit, auditors test the controls that address risks to financial reporting, and that includes IT controls. If those controls fail, the auditor can't rely on the system's reports and has to do far more substantive testing.

ITGCs usually cover four areas: access to programs and data, program changes, program development, and computer operations. In most Salesforce orgs, access and change management produce nearly all of the audit work, and segregation of duties runs through both.

Step 1: Define your ITGC scope

Auditors start by mapping your financial processes, such as quote-to-cash, and pinning down which objects, fields, and automations affect amounts in the general ledger. Typical in-scope components include:

• Opportunity, Quote, Order, and Contract objects, plus any custom pricing or billing objects
• CPQ and billing configuration, such as price books and discount schedules
• Flows, Apex triggers, and validation rules that change financial values
• Integrations that send data to your ERP
• Reports finance uses for journal entries or reconciliations

Scope moves. A new field, flow, or managed package can pull more of the org in. Keep a living inventory of in-scope metadata, review it every quarter, and give each area a named owner. Flosum's guide to data governance roles and responsibilities in Salesforce shows one way to split that ownership. Expect auditors to ask how you know the list is complete.

Reports that finance relies on count as information produced by the entity (IPE). Auditors check that report filters can't be changed without anyone noticing and that the output ties back to source records. Field history helps here, and Flosum's guide to the Salesforce Field Audit Trail covers setup and limits.

Access controls over in-scope data

Auditors don't stop at checking that MFA is turned on. They test whether the access process works, sample by sample.

Provisioning. Each sampled new user needs an approved request from a manager or data owner, dated before the account was activated.

Deprovisioning. Auditors match HR termination dates against user records and login history. Anyone still active past your policy window, commonly one to three business days, is an exception.

Access reviews. Quarterly reviews need to show action: who was flagged and what was removed. A sign-off with no changes, quarter after quarter, reads as a review that didn't happen.

Login History and the Setup Audit Trail give you the raw data. What auditors test is whether a named person acts on it, which comes down to ownership. Flosum's post on who owns Salesforce security explains why that matters.

Step 2: Separate duties

Segregation of duties (SoD) means no one person can both make a change and deploy it, or both create a transaction and approve it. It is one of the hardest Salesforce controls to pass, because small admin teams often have one person doing everything.

Testing starts with privileged permissions: System Administrator, Modify All Data, Author Apex, and Manage Users. Auditors count who holds them and check that each person has a documented reason. Then they look for conflicts like these:

• A developer can deploy to production. Untested or unapproved logic can change financial figures.
• The approver of a change also built it. The approval adds no independent review.
• An admin can edit financial records and the approval settings. One user could change a deal and the rules that check it.
• A sales user can set a discount and approve it. Discounts skip pricing controls.
• Shared or generic admin logins. Actions can't be tied to a person.

Small teams can use compensating controls. A common one is a monthly review, by someone outside the admin team, of Setup Audit Trail changes against the approved change log. For emergency access, grant elevated rights for a fixed window and review what was done afterward. Flosum's article on applying Zero Trust to Salesforce deployments covers time-limited access in more detail.

Step 3: Keep approval evidence for every production change

Auditors pick a sample of production changes and trace each one through your process. Two things decide the result: a complete population of changes, and approval evidence that holds up.

A complete population. If your change list comes only from tickets, auditors will ask how you know nothing went around the process. The Setup Audit Trail answers that, but Salesforce only lets you download the past 180 days of setup history. Export it on a schedule so the record covers the full audit period.

Approval evidence. For each sampled change, auditors look for:

• A ticket that describes the change and its business reason
• Evidence of sandbox testing, such as a QA sign-off or Apex test results
• An approval from someone other than the developer, with a name and timestamp
• A timestamp showing the approval came before the production deployment
• A record of what was deployed, such as a deployment ID or commit, that matches the ticket

The last two cause most exceptions. An approval dated after the deployment fails, even if the change itself was fine.

Version control and pipelines. Required reviews in a version-controlled process record the author, reviewer, and timestamp on every change. See Flosum's guides to Salesforce branching strategies and Salesforce version control without Git. A pipeline that only deploys approved changes turns SoD into a system rule instead of a habit, as Flosum's complete guide to Salesforce DevOps explains.

Emergency changes. Label them, deploy with whatever approval you can get at the time, and finish a documented review within a few business days.

Don't skip computer operations

Auditors also want a backup schedule, retention that matches your policy, and proof that a restore works. Test-restore financial records at least once a year. Flosum's walkthrough on how to restore deleted records in Salesforce is a good starting point, and its breakdown of Salesforce backup pricing compares native and third-party options. Log every failed ERP sync and how it was fixed.

Manual controls vs. controls built into the release process

Spreadsheets, tickets, and email can pass a SOX audit, but they leave people to build the evidence by hand every cycle. Flosum builds approvals, separation of duties, change tracking, and backup into the release process, and runs on your choice of three deployment options: Salesforce-native, Flosum-hosted cloud, or customer-hosted. The table below maps each audit area to both approaches.

For a side-by-side look at release tools, see Flosum's technical comparison of Lifecycle Center (formerly DevOps Center), Copado, Flosum, and Gearset, or read how Flosum supports SOX compliance for Salesforce.

Want to see your own change and approval evidence in one place before the next audit? Book a meeting with Flosum.

Frequently asked questions

‍