Compliance
January 3, 2024

Segregation of duties in Salesforce CPQ change delivery: a must-have for compliance

SoD is key to strong internal controls over financial reporting in Salesforce

In many countries, internal controls over financial reporting (ICFR) are a requirement for public companies. And even for organizations that aren’t public, segregation of duties (SoD) is a best practice. In Salesforce CPQ development, it prevents any one person from having too much control over changes to financial data.

There are significant risks associated with noncompliance with SoD requirements. Moreover, if you’re compliant but you can’t prove you are, you’re also in hot water. That’s why segregation of duties in Salesforce CPQ isn’t just a “nice to have”—it’s an imperative.

Segregation of duties is critical in CPQ change delivery

When you’re making changes in Salesforce that impact financial information, separation of duties helps prevent errors and fraud. It forms a layer of checks and balances that protects your financial data against exposure and unauthorized changes.

The main purpose of SoD is to reduce the risk of investors falling prey to fraudulent financial reporting. It also minimizes inconsistencies that could cause all sorts of financial issues.

With SoD, you don’t let one person handle every aspect of the change management process in an app like Salesforce CPQ. Instead, you assign the tasks of making changes, testing them, and deploying them to separate teams or individuals. This builds validation and oversight into your development process.

SoD as a regulatory requirement

Many countries have laws and regulations that underline the importance of SoD for ICFR:

  • United States: Sarbanes-Oxley Act of 2002 (SOX)
  • Canada: Bill 198, also known as C-SOX
  • United Kingdom: UK SOx (in effect late 2024)`
  • Australia: ASX guidelines
  • France: Financial Security Law of France (LSF)

Besides these, there are numerous other industry-specific and regional regulations that require you to put a system of internal controls in place. And that involves implementing SoD in the Salesforce development process.

SoD as a best practice

Beyond regulations, leading industry bodies such as the AICPA and the IIA in the U.S. emphasize the importance of SoD. They consider it to be both an operational and a strategic necessity. Their endorsement of SoD underlines a universal business truth: It’s often much less expensive to prevent a problem than it is to solve one.

Even if you’re not a public company, enforcing SoD demonstrates your trustworthiness and reliability. It’s more than just a way to comply with regulations—it’s also an investment in long-term business resilience.

Risks of noncompliance with SoD requirements

When you don’t enforce SoD when making changes that could impact financial data, it can endanger the security and integrity of your Salesforce instance. This brings with it the following risks:

  1. Errors and bugs: Let’s say the same person makes, tests, approves, and deploys all the changes in Salesforce CPQ. The chance of a bug making it into production is much higher than if a second person did the approvals. SoD minimizes the risk of unintentional errors that could cause misrepresentations in financial data and lead to inaccurate reporting.
  2. Fraud: If a team member has access to every stage of the release process, they could intentionally make changes that benefit themselves. In other words, they could use their access privileges to engage in fraudulent activities.
  3. Legal and financial penalties: If an audit committee determines you failed to comply with SoD requirements, the penalties can be steep. Companies can face legal repercussions and hefty fines, while your CEO and CFO may be held personally liable.
  4. Loss of customer and investor trust: The public fallout from a compliance violation can be significant. Customers and investors may lose confidence in your organization—and once trust is lost, it’s hard to earn it back again.

Risks of not documenting SoD

Compliance isn’t just about meeting all regulatory requirements—it’s also about proving that you do so. And this can be a real challenge when it comes to Salesforce application lifecycle management or app development.

Let’s face it: Endlessly toggling back and forth between your VCS and Jira to cobble together an audit trail is nobody’s idea of fun. And yet too many Salesforce teams wind up having to do this when a SOX auditor or independent auditor asks for a report. It takes hours, if not days, to match, copy, and paste Jira issues to deployments. That’s if you get everything right the first time.

But this ultra-tedious back and forth doesn’t just eat up time. It also slows down productivity because whoever’s putting the audit trail together can’t perform their core duties.

That said, not being able to prove compliance with SoD requirements is almost as risky as noncompliance itself. Why? Well, if you can’t provide validation for the changes you’ve made to financial data, an auditor could consider them questionable. And nobody wants to be under that microscope because in the worst case scenario, it can lead to the same fallout as noncompliance.

How to prove segregation of duties

Here’s where Prodly Compliance Center saves the day. Our powerful automation keeps a meticulous and detailed log of every modification so you always know what was changed, why, how, when, and by whom.

Imagine being faced with an audit. Normally, you’d have to slog through reams of digital logs to get the information the auditor needs. But with Compliance Center, all you have to do is generate an audit report. You can even filter the report so it only shows the changes you need to see! It’s super quick and easy, and the comprehensive report accurately lists the details of every single change. Think of all the time you can save—and the sleepless nights you can avoid.

The value of SoD in Salesforce CPQ change delivery

Segregation of duties isn’t just about compliance. It’s also about building trust and transparency. When you enforce SoD, you’re showing your customers and investors that you’re committed to protecting their interests and operating in a transparent manner.

FAQs

Will implementing segregation of duties slow down the development process in Salesforce?

Introducing SoD adds an additional layer to your process, but if you have a streamlined process, the additional time will be negligible. In the long run, SoD means fewer errors and reduced risk—so a slightly longer process is a small price to pay for these benefits.

Will I need more staff or resources to enforce SoD?

Not necessarily. Instead of increasing headcount, you could reallocate responsibilities to different team members.

How can I stay updated on the regulatory requirements of different countries?

You can check for updates on regulatory websites, join industry-specific groups, or consult with your financial advisor.

In many countries, internal controls over financial reporting (ICFR) are a requirement for public companies. And even for organizations that aren’t public, segregation of duties (SoD) is a best practice. In Salesforce CPQ development, it prevents any one person from having too much control over changes to financial data.

There are significant risks associated with noncompliance with SoD requirements. Moreover, if you’re compliant but you can’t prove you are, you’re also in hot water. That’s why segregation of duties in Salesforce CPQ isn’t just a “nice to have”—it’s an imperative.

Segregation of duties is critical in CPQ change delivery

When you’re making changes in Salesforce that impact financial information, separation of duties helps prevent errors and fraud. It forms a layer of checks and balances that protects your financial data against exposure and unauthorized changes.

The main purpose of SoD is to reduce the risk of investors falling prey to fraudulent financial reporting. It also minimizes inconsistencies that could cause all sorts of financial issues.

With SoD, you don’t let one person handle every aspect of the change management process in an app like Salesforce CPQ. Instead, you assign the tasks of making changes, testing them, and deploying them to separate teams or individuals. This builds validation and oversight into your development process.

SoD as a regulatory requirement

Many countries have laws and regulations that underline the importance of SoD for ICFR:

  • United States: Sarbanes-Oxley Act of 2002 (SOX)
  • Canada: Bill 198, also known as C-SOX
  • United Kingdom: UK SOx (in effect late 2024)`
  • Australia: ASX guidelines
  • France: Financial Security Law of France (LSF)

Besides these, there are numerous other industry-specific and regional regulations that require you to put a system of internal controls in place. And that involves implementing SoD in the Salesforce development process.

SoD as a best practice

Beyond regulations, leading industry bodies such as the AICPA and the IIA in the U.S. emphasize the importance of SoD. They consider it to be both an operational and a strategic necessity. Their endorsement of SoD underlines a universal business truth: It’s often much less expensive to prevent a problem than it is to solve one.

Even if you’re not a public company, enforcing SoD demonstrates your trustworthiness and reliability. It’s more than just a way to comply with regulations—it’s also an investment in long-term business resilience.

Risks of noncompliance with SoD requirements

When you don’t enforce SoD when making changes that could impact financial data, it can endanger the security and integrity of your Salesforce instance. This brings with it the following risks:

  1. Errors and bugs: Let’s say the same person makes, tests, approves, and deploys all the changes in Salesforce CPQ. The chance of a bug making it into production is much higher than if a second person did the approvals. SoD minimizes the risk of unintentional errors that could cause misrepresentations in financial data and lead to inaccurate reporting.
  2. Fraud: If a team member has access to every stage of the release process, they could intentionally make changes that benefit themselves. In other words, they could use their access privileges to engage in fraudulent activities.
  3. Legal and financial penalties: If an audit committee determines you failed to comply with SoD requirements, the penalties can be steep. Companies can face legal repercussions and hefty fines, while your CEO and CFO may be held personally liable.
  4. Loss of customer and investor trust: The public fallout from a compliance violation can be significant. Customers and investors may lose confidence in your organization—and once trust is lost, it’s hard to earn it back again.

Risks of not documenting SoD

Compliance isn’t just about meeting all regulatory requirements—it’s also about proving that you do so. And this can be a real challenge when it comes to Salesforce application lifecycle management or app development.

Let’s face it: Endlessly toggling back and forth between your VCS and Jira to cobble together an audit trail is nobody’s idea of fun. And yet too many Salesforce teams wind up having to do this when a SOX auditor or independent auditor asks for a report. It takes hours, if not days, to match, copy, and paste Jira issues to deployments. That’s if you get everything right the first time.

But this ultra-tedious back and forth doesn’t just eat up time. It also slows down productivity because whoever’s putting the audit trail together can’t perform their core duties.

That said, not being able to prove compliance with SoD requirements is almost as risky as noncompliance itself. Why? Well, if you can’t provide validation for the changes you’ve made to financial data, an auditor could consider them questionable. And nobody wants to be under that microscope because in the worst case scenario, it can lead to the same fallout as noncompliance.

How to prove segregation of duties

Here’s where Prodly Compliance Center saves the day. Our powerful automation keeps a meticulous and detailed log of every modification so you always know what was changed, why, how, when, and by whom.

Imagine being faced with an audit. Normally, you’d have to slog through reams of digital logs to get the information the auditor needs. But with Compliance Center, all you have to do is generate an audit report. You can even filter the report so it only shows the changes you need to see! It’s super quick and easy, and the comprehensive report accurately lists the details of every single change. Think of all the time you can save—and the sleepless nights you can avoid.

The value of SoD in Salesforce CPQ change delivery

Segregation of duties isn’t just about compliance. It’s also about building trust and transparency. When you enforce SoD, you’re showing your customers and investors that you’re committed to protecting their interests and operating in a transparent manner.

FAQs

Will implementing segregation of duties slow down the development process in Salesforce?

Introducing SoD adds an additional layer to your process, but if you have a streamlined process, the additional time will be negligible. In the long run, SoD means fewer errors and reduced risk—so a slightly longer process is a small price to pay for these benefits.

Will I need more staff or resources to enforce SoD?

Not necessarily. Instead of increasing headcount, you could reallocate responsibilities to different team members.

How can I stay updated on the regulatory requirements of different countries?

You can check for updates on regulatory websites, join industry-specific groups, or consult with your financial advisor.