SOX and Financial Reporting Compliance for Salesforce

Share this article...


The Sarbanes–Oxley Act was passed almost 20 years ago, and while the letter of the law hasn’t changed, how it’s applied and what’s in scope has. On one hand, this isn’t surprising — SOX is on one level a set of regulations about technology, and as technology changes, the regulatory framework it exists in has to adapt accordingly. On the other hand, this creates uncertainty for the teams working with that technology in regulated environments.

This is something we see all the time in our work with Salesforce Admins and IT leadership at pre-IPO and public companies. As the platform evolves, there remains considerable confusion around whether or not, and to what extent, Salesforce is in scope.

In this post, we’ll look at five trends we’re seeing that are driving auditor focus on your Salesforce Org and how this can impact you. First, a little context will be helpful.

What Is SOX?

The Sarbanes–Oxley Act of 2002, also known as the Corporate and Auditing Accountability, Responsibility and Transparency Act, was the United States’ major legislative response to a series of high-profile accounting scandals (Enron, WorldCom, etc.) in the early 2000s.

SOX established a set of broad standards for financial governance and accountability in public companies and, in a more limited capacity, some private corporations. It created new, stricter requirements for recordkeeping and disclosures, and imposed harsher penalties for fraud and other violations.

Among other things, SOX Section 404 introduced new requirements for data and information security, access management, and change controls around any software that can impact financial records, data and critical business processes.

Why Salesforce? And Why Now?

For obvious reasons, accounting/ERP platforms like NetSuite have always been in scope for SOX. What we’re seeing now is that auditors are starting to focus on Salesforce, too.

Why? In our experience, this boils down to five main trends:

1. Revenue Cloud and Related Apps

Salesforce’s incredible growth over the past few years has created a robust ecosystem of apps to support new use cases. And more apps means a greater possibility that a change in one of those apps could impact financial data.

We see this most prominently in Revenue Cloud, where the Billing and CPQ apps store rules around products, pricing, discounts, approval workflows, etc. as configuration data (many other third-party apps do this too.) Auditors will want to see how you control for changes to that data; they’ll want to see that you’re aware, for example, if an Admin changes a pricing or advanced approval rule without authorization.

2. Platform Growth

Trend number two is basically an extension of number one. One of Salesforce’s biggest selling points is that it’s highly configurable. So it should be no surprise that, for many organizations, it’s much more than a CRM. We’ve seen Salesforce used for everything from project management to professional services, and it has become increasingly verticalized for specialized applications such as healthcare, life sciences and manufacturing.

The bottom line is that the broader the platform is — and the more business-critical data is stored on it — the more likely it is to have a downstream impact on financial reporting.

3. Automated ERP Integrations

The growth of iPaaS tools is also contributing to auditors’ increased focus on Salesforce. Now, much more of the opportunity-to-cash process is taking place on the platform; in many cases, that data is automatically being sent to the general ledger in an ERP, ready to be posted.

Manual integration between CRM and ERP systems requires a degree of human oversight that may be enough to satisfy auditors — in other words, if someone is exporting and importing data themselves, they can theoretically confirm whether or not it’s accurate. But if, as is increasingly common, the process is automated via an integration platform like Mulesoft, a control is no longer in place, and auditors will want to see that changes are being properly managed where the data is originating.

4. End-to-End Processes

Most public companies are tightly restricting who can access their production Orgs, and have formal approval processes for changes. However, auditors are more concerned about the changes you don’t know about — those that skipped the CI/CD process (continuous integration/continuous delivery), or had an unexpected (potentially malicious) impact on financials or system reliability.

A great example of this is changing a picklist. What seems like a simple change can potentially cause data to be processed incorrectly by dependent code, or cause a relevant record to be skipped entirely. A more sinister example is an ‘easter egg’ snuck into code that touches sensitive records or PII.

It is vital to have tools and systems to prove to your auditors that all changes impacting critical processes were approved prior to release, and that the implications of the changes were understood. If you aren’t very careful and systematic, these concerns could potentially bring all changes into scope for SOX, raising the compliance workload and reducing dev team efficiency.

5. Auditor Awareness

When it comes to SOX, ultimately, you have to worry about what your auditors tell you to worry about. And as internal and external auditors become more familiar with the Salesforce platform — what you can do with it, what it connects to, and how it’s managed — they are going to start asking more questions.

In our experience, more than anything, it’s the increasingly tech-savvy, Salesforce-aware audit community that is the biggest driver of the increased focus on SOX.

SOX Compliance in Salesforce

For Salesforce developers, admins and IT managers, SOX compliance for Salesforce boils down to a few key concepts: auditability and delegation of duties in deployments.

Auditability is about bringing visibility into who is changing what and when in Salesforce. This gives auditors the ability to track and trace changes made in your Salesforce org that might be considered to have an impact on financial reporting.

The delegation of duties is about ensuring that the developers who write code are different from the people who deploy the code. This is meant to safeguard an organization from having unchecked code get into Salesforce that could affect the financial reports that come out of it.

Auditors are most concerned with three things: access controls, metadata and configuration data. What’s critical, though, is that not all of it is in scope for SOX, auditors only care about what’s tied to critical business processes or data and objects connected to revenue recognition.

So what can you do?

Auditability with Source Control

The options for maintaining auditability for configuration in Salesforce are somewhat limited. You can download the Salesforce audit trail every few months but a better option would be to set up a source control tool for Salesforce. This could be something like Bitbucket, GitHub or a Salesforce specific tool. Source control management systems enable you to maintain a single source of truth, merge code without conflicts and facilitate collaboration and automation.

Delegation of Duties

Part of SOX compliance is ensuring that the developer that makes changes is not the same person that deploys those changes to production. This can be hard to achieve for smaller teams, those without tracking or version control, and let’s not even get started on those making changes live in production!

Options include:

  • Limit access to your production org
  • All changes must go through a change review process starting in a sandbox
  • Code must be reviewed and approved by someone who did not write the code
  • Consider investing in a change release management tool for Salesforce

Work with An Auditor

Work directly with your auditor to look at your Salesforce environment and determine what is and what is not in scope. In some organizations, you may need to only track types like Apex classes. In others, you’ll need to incorporate a longer list including declarative, access changes, and data.

Teams that actively take the time to sit down with their auditor and get clarity about the scope of changes that need tracking, have a much easier time come audit season. Working with your auditor can ensure you focus on the areas that matter and reduce the time it takes to complete the audit.


The Salesforce platform puts SOX compliance within reach, but we are finding that Salesforce teams are increasingly looking for tools to help save them time and tighten up the process. Check out this short post on the pros and cons of prepping for SOX using Setup Audit Trail and Field History Tracking that goes into this in more detail.

Salesforce teams need to find ways to treat these changes with more rigor while continuing to innovate at speed elsewhere on the platform. And that’s exactly what our product, Strongpoint, does. If you’d like to learn how it can automate this difficult work and reduce audit prep time by up to 90%, check out our website!

2 thoughts on “SOX and Financial Reporting Compliance for Salesforce

  1. Alex
    thanks for sharing this, do you know any Salesforce customers who have achieved SOX compliance using platform services described above? any customer stories?

    1. Hi Kapil!

      You might want to check us out – our products have helped hundreds of companies achieve SOX compliance:

      We build automatic tools on top of the documentation layer that speed up critical steps in clean-up, change management and governance processes so that your team can get more done more efficiently. Working with our customers, we’ve found our full suite of tools can cut prep time by 50% or more, and eliminate around 90% of the costs.

Add Comment