Compliance
June 15, 2023

SOX compliance checklist for Salesforce sandboxes

How to manage your orgs to meet SOX requirements

Are you a Salesforce professional working for a public company or a business that’s preparing for an IPO? Use this SOX compliance checklist to learn how to manage your Salesforce sandboxes without violating any regulations of the Sarbanes-Oxley Act of 2002.

SOX controls checklist for Salesforce sandboxes

This checklist provides a set of guidelines for managing your orgs in a way that supports the critical requirements of SOX. In regard to sandbox management, the requirements you should care about are enforcing internal controls and ensuring data integrity.

First, let’s look at implementing and enforcing internal controls. After that, we’ll examine what you can do to ensure data integrity.

Internal controls for Salesforce environments

When it comes to internal controls for environment management, three main requirements apply: access controls, segregation of duties, and sandbox monitoring.

Access controls

Salesforce provides controls and permissions that let you determine who can access specific environments, as well as what they can do in them. Here’s what you need to know.

How to restrict access to environments in Salesforce

Developers don’t need access to the information in your production org, but they do need to be able to build and test in sandboxes. Salesforce lets you control access to environments—including production—in the release pipeline by assigning the correct permissions in a sandbox. Here’s how:

  1. Create a user in your production org.
  2. Set them to inactive.
  3. Activate them in a specific environment.

The user now has the permissions they need to develop in an environment.

Sometimes specific development and testing tasks require the Modify All Data permission. All you have to do is increase the user’s permissions in the sandbox—without giving them that same permission in production.

How to avoid manual reconfiguration after a sandbox refresh

When a sandbox refreshes, it resets your access controls so they’re identical to your production org. This means you have to reconfigure the access controls in the sandbox manually again to enforce internal controls. For every user. And while it’s busy work, it’s essential. Unfortunately, it also slows everyone down.

Prodly helps you avoid this hassle by eliminating the need to refresh sandboxes. Our sandbox seeding feature lets you instantly replicate data from production into up to five sandboxes in one go. It makes it super fast and easy to keep your sandboxes in sync with prod.

With Prodly, you get an up-to-date, production grade environment in the blink of an eye. You don’t need to reconfigure the org’s access controls. And everyone can just get to work right away.

Segregation of duties

Prodly helps you enforce segregation of duties by setting deployment permissions at the environment level. This ensures that the person making the changes isn’t the same person who approves and deploys them. It’s a highly effective measure to automatically prevent unauthorized changes from being deployed to production.

Sandbox monitoring

To comply with SOX regulations, you need to your monitor orgs for any unauthorized access, changes, or deletions. You can use Setup Audit Trail in a sandbox to record all activity for the past 180 days in an audit log.

It’s advisable to set up a schedule to review the audit logs on a regular basis. You’ll be able to pinpoint irregularities sooner and take appropriate action.

Unfortunately, many companies find that this built-in audit trail isn't robust enough for their purposes. That's why we built Compliance Center—always-on monitoring for your environments with customizable rules that let you determine the types of changes you want to monitor. With Compliance Center, you never have to worry about proving compliance during an audit. You can generate an audit report that shows precisely those changes an auditor wants to see—with a single click!

Ensure data integrity

SOX requirements include robust data security and protection measures to eliminate the risk of unauthorized individuals making financially-impacting changes. These measures also prevent bad actors from using sensitive information to commit fraud. There are several ways to include data protection in your sandbox management strategy.

Use lower-level environments

It’s best practice to have the just right amount of metadata and data for your purposes in your org—no more, no less. The more components and data you have, the higher the risk of financially-impacting components and configurations being exposed or corrupted.

Developer sandboxes and scratch orgs have the lowest capacity of all types of Salesforce environments. That’s why it’s advisable to use them as much as possible in the build and test stages of your development cycle.

Mask and redact data

A developer doesn’t need to actually see sensitive financial data, but they might need to use some to make sure their changes function correctly.

You can automatically mask sensitive data in a sandbox with Salesforce Data Mask. It’s available for Sales Cloud, Service Cloud, Salesforce’s Industry products, Work.com, platform customizations, and AppExchange applications.

Want to quickly, easily, and securely move your data? Prodly provides powerful data masking and data redaction capabilities with its sandbox seeding and deployment automation. This is much more secure than using a data loader, which involves downloading CSVs with potentially sensitive data to your desktop.

SOX compliance checklist: the key to peace of mind

This SOX compliance requirements checklist summarizes the points you need to pay attention to in your sandbox management strategy. Use it to fine tune your policies and procedures—and enjoy peace of mind knowing your sandboxes are protected against noncompliance.

FAQs

Why is SOX compliance important in Salesforce change management?

SOX regulations aim to prevent public companies from committing fraud by intentionally providing inaccurate financial reports. If an external auditor finds a company to be in violation of SOX requirements, the CEO and the company are at risk of serious legal and civil repercussions. Learn more.

What are some best practices for SOX compliance in Salesforce release management?

Best practices for a SOX-compliant release process include developing and implementing a formal change management process, documenting all changes, conducting regular audits, and more. Learn more about best practices for SOX compliance in the Salesforce release management process.

How can I streamline SOX compliance in my Salesforce release process?

One of the best ways to streamline SOX compliance in Salesforce is to use automation where possible. That way, you can set and forget according to your policies—and just go about your work. Learn more about automation for SOX compliance for your release process in Salesforce.

Are you a Salesforce professional working for a public company or a business that’s preparing for an IPO? Use this SOX compliance checklist to learn how to manage your Salesforce sandboxes without violating any regulations of the Sarbanes-Oxley Act of 2002.

SOX controls checklist for Salesforce sandboxes

This checklist provides a set of guidelines for managing your orgs in a way that supports the critical requirements of SOX. In regard to sandbox management, the requirements you should care about are enforcing internal controls and ensuring data integrity.

First, let’s look at implementing and enforcing internal controls. After that, we’ll examine what you can do to ensure data integrity.

Internal controls for Salesforce environments

When it comes to internal controls for environment management, three main requirements apply: access controls, segregation of duties, and sandbox monitoring.

Access controls

Salesforce provides controls and permissions that let you determine who can access specific environments, as well as what they can do in them. Here’s what you need to know.

How to restrict access to environments in Salesforce

Developers don’t need access to the information in your production org, but they do need to be able to build and test in sandboxes. Salesforce lets you control access to environments—including production—in the release pipeline by assigning the correct permissions in a sandbox. Here’s how:

  1. Create a user in your production org.
  2. Set them to inactive.
  3. Activate them in a specific environment.

The user now has the permissions they need to develop in an environment.

Sometimes specific development and testing tasks require the Modify All Data permission. All you have to do is increase the user’s permissions in the sandbox—without giving them that same permission in production.

How to avoid manual reconfiguration after a sandbox refresh

When a sandbox refreshes, it resets your access controls so they’re identical to your production org. This means you have to reconfigure the access controls in the sandbox manually again to enforce internal controls. For every user. And while it’s busy work, it’s essential. Unfortunately, it also slows everyone down.

Prodly helps you avoid this hassle by eliminating the need to refresh sandboxes. Our sandbox seeding feature lets you instantly replicate data from production into up to five sandboxes in one go. It makes it super fast and easy to keep your sandboxes in sync with prod.

With Prodly, you get an up-to-date, production grade environment in the blink of an eye. You don’t need to reconfigure the org’s access controls. And everyone can just get to work right away.

Segregation of duties

Prodly helps you enforce segregation of duties by setting deployment permissions at the environment level. This ensures that the person making the changes isn’t the same person who approves and deploys them. It’s a highly effective measure to automatically prevent unauthorized changes from being deployed to production.

Sandbox monitoring

To comply with SOX regulations, you need to your monitor orgs for any unauthorized access, changes, or deletions. You can use Setup Audit Trail in a sandbox to record all activity for the past 180 days in an audit log.

It’s advisable to set up a schedule to review the audit logs on a regular basis. You’ll be able to pinpoint irregularities sooner and take appropriate action.

Unfortunately, many companies find that this built-in audit trail isn't robust enough for their purposes. That's why we built Compliance Center—always-on monitoring for your environments with customizable rules that let you determine the types of changes you want to monitor. With Compliance Center, you never have to worry about proving compliance during an audit. You can generate an audit report that shows precisely those changes an auditor wants to see—with a single click!

Ensure data integrity

SOX requirements include robust data security and protection measures to eliminate the risk of unauthorized individuals making financially-impacting changes. These measures also prevent bad actors from using sensitive information to commit fraud. There are several ways to include data protection in your sandbox management strategy.

Use lower-level environments

It’s best practice to have the just right amount of metadata and data for your purposes in your org—no more, no less. The more components and data you have, the higher the risk of financially-impacting components and configurations being exposed or corrupted.

Developer sandboxes and scratch orgs have the lowest capacity of all types of Salesforce environments. That’s why it’s advisable to use them as much as possible in the build and test stages of your development cycle.

Mask and redact data

A developer doesn’t need to actually see sensitive financial data, but they might need to use some to make sure their changes function correctly.

You can automatically mask sensitive data in a sandbox with Salesforce Data Mask. It’s available for Sales Cloud, Service Cloud, Salesforce’s Industry products, Work.com, platform customizations, and AppExchange applications.

Want to quickly, easily, and securely move your data? Prodly provides powerful data masking and data redaction capabilities with its sandbox seeding and deployment automation. This is much more secure than using a data loader, which involves downloading CSVs with potentially sensitive data to your desktop.

SOX compliance checklist: the key to peace of mind

This SOX compliance requirements checklist summarizes the points you need to pay attention to in your sandbox management strategy. Use it to fine tune your policies and procedures—and enjoy peace of mind knowing your sandboxes are protected against noncompliance.

FAQs

Why is SOX compliance important in Salesforce change management?

SOX regulations aim to prevent public companies from committing fraud by intentionally providing inaccurate financial reports. If an external auditor finds a company to be in violation of SOX requirements, the CEO and the company are at risk of serious legal and civil repercussions. Learn more.

What are some best practices for SOX compliance in Salesforce release management?

Best practices for a SOX-compliant release process include developing and implementing a formal change management process, documenting all changes, conducting regular audits, and more. Learn more about best practices for SOX compliance in the Salesforce release management process.

How can I streamline SOX compliance in my Salesforce release process?

One of the best ways to streamline SOX compliance in Salesforce is to use automation where possible. That way, you can set and forget according to your policies—and just go about your work. Learn more about automation for SOX compliance for your release process in Salesforce.