SOX and Financial Reporting Compliance for Salesforce

Share this article...

What is SOX Compliance?

In 2002, in the wake of the Enron and WorldCom accounting scandals, Congress passed the Sarbanes-Oxley Act in order to regulate and reform the financial reporting standards for public companies and their boards and accounting firms.

For many companies, Salesforce is used to generate financial reports and so many Salesforce teams are interested in ensuring they are on the right side of the law affectionately known as SOX Compliance. It’s kind of a big deal: non-compliance can carry a penalty of up to $1M and ten years in prison for corporate officers even if an inaccurate report is incorrectly filed by mistake.  


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.

Who Needs to Worry about SOX Compliance for Salesforce?

Though many of the concepts listed above around auditability and delegation of duties are now considered to be best practices, SOX Compliance is really only strictly relevant to companies that are publicly traded. If your company wants to IPO someday then it never hurts to get ready for SOX compliance early.

Auditability with Source Control

Despite its many great qualities, Salesforce can be an opaque system. It’s not the best at providing historical data or auditing. You only get six months of audit trail and the amount of information available is fairly limited. It will tell you who changed what file but doesn’t give detailed information about how your code or configuration metadata changed.

One option for maintaining auditability is making sure to download the Salesforce audit trail every few months. This will allow you to provide some information to auditors. A better solution though is to set up source control for Salesforce by using a tool like Bitbucket or GitHub or a Salesforce specific source control like Blue Canvas. Training your team to use source control for change tracking will give you unprecedented auditability over your code and configuration metadata. This provides great benefits beyond SOX compliance as well – if you ever release bugs or need to rollback, it can be helpful to have a functioning source of truth.

Maybe the most important way to ensure that you are SOX compliant is to automate wherever you can. When manual steps are required, it can be too easy to miss key changes, causing massive headaches for your team during audit season. This is especially important for Salesforce where you have so many different constituents making changes. You may have admins and business analysts who make relevant changes to metadata that touches financial reporting and you want to make sure those changes are captured without having to train them on an error-prone manual process.

Delegation of Duties

The other requirement in SOX compliance is to ensure that the developer who makes changes is not the person who deploys those changes into production. This is hard for many companies who embrace Salesforce’s clicks not code philosophy. Often there are still changes being made live in production without any kind of change tracking or version control.

To ensure compliance, you can use Salesforce’s permissions system to ensure that only select people have access to production environments. All changes should go through a review pipeline that starts at the sandbox level. Changes should be code reviewed and approved by someone who did not write the code.

Change sets do allow you to do some permission-based deploying that can help. However, the changeset UI is severely limited and it really slows your team down. And even then, it’s quite frankly not a world class way of doing software development. If you want to hire world-class people you need a better option.

A proper release management tool for Salesforce can help here. Your release management tool should allow you to delegate deployment permissions between various environments and ensure that your organization’s change management and software development lifecycle is SOX compliant.

Work with An Auditor to Determine Relevant Metadata Types

Unfortunately, there is no standard list of what kinds of Salesforce changes are in scope for SOX Compliance. Instead, you’ll have to work directly with your auditor to look at your Salesforce environment and determine which metadata types should be tracked. With Blue Canvas you can customize which metadata types are controlled by your version control system to set you up for SOX compliance. In some organizations, you may need to only track types like Apex classes. In others, you’ll need to incorporate more declarative changes.

We have found that teams that actively take the time to sit down with their auditor and get clarity about the scope of changes that need tracking are much happier come audit season. They tend to be better able to focus on what matters and are able to decrease the time it takes to complete the audit and ensure better results. Making this investment up front saves time and money in the long run.

One thought on “SOX and Financial Reporting Compliance for Salesforce

  1. Avatar

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

Leave a Reply