What is segregation of duties?

Simply put, it is the separation between two or more tasks such that they cannot be performed by the same person.

Segregation of duties (or ‘SoD’ as it is commonly abbreviated to) is typically applied to tasks which, if performed by the same person, allow for fraud or error to be committed and then concealed.

A simple example: Andy counts how many cans of tuna are available in the pantry and notes this down. William then verifies the number of cans and signs his name to indicate that he has performed his review.

The counting and review processes should not be performed by the same person, otherwise he/she could record an incorrect number and it would not be detected during the review process.

Segregation of duties in SAP

Segregation of duties is relevant for tasks in and outside of the system. When a system such as SAP is used, SoD can be implemented through carefully designed user access rights.

Here are some examples of SoD in the system:

  • A user should not be able to change vendor master data and make invoice payments. Why? How could fraud/error occur? The user could change the vendor’s bank details to their own bank account and make payment to the vendor. The result is that the payment is fraudulently received by the user.
  • A user should not have access to create a purchase order and approve the purchase order. Why? The user could create a fictitious purchase order and approve it themselves.
  • A user should not have access to create sales orders and unblock customers. Why? A scenario could arise whereby a sales order is raised against a blocked customer. In order to allow the sales order to be posted, the user unblocks the customer without a proper risk review. This could lead to goods being delivered to an unwanted customer or payment not being received.
Photo by Olena Sergienko on Unsplash

These examples show that a real business risk can arise if some conflicting tasks can be performed by one and the same person.

Using the first example above, segregation of duties should be established between the tasks of changing vendor master data and making invoice payments. However, sometimes you may see users who are granted access to do both in the system. Why would that be so?

In some cases, segregation of duties cannot be established because there are not enough employees to allow tasks to be segregated. Other times, tasks are assigned accidentally.

When SoD cannot be achieved

Using the above example again, a payment clerk may require access to view vendor details in order to help verify necessary details against the invoice. However, access to change vendor details is not required. Therefore, in this case, a simple remediation would be to remove the user’s access to change vendor details and give them display-only access instead. Other conflicts may require mitigating controls to be put in place.

Segregation of duties controls should be implemented on a preventative basis, such that any access rights given to users are free of SoD conflicts.