Finding the Segregation of Duties (SOD) Conflicts in Microsoft Dynamics GP 10—Why the User Level Is Key

Recently, I was working on a SOX (Sarbanes-Oxley) compliance project for a large corporation that used Microsoft Dynamics GP in a subsidiary location. The internal audit team tasked with segregation of duties (SOD) analysis was not familiar with how security worked in Dynamics GP. As the project progressed, I kept a log of their key questions surrounding SOD and Microsoft Dynamics GP.

We are using the roles and tasks delivered by Microsoft. Will we have any SOD issues?

The team identified that any role or task name that contained an asterisk was standard delivered from Microsoft. They also confirmed that only roles and tasks with asterisks were being used. With that in mind, the team figured that there was no need to analyze the segregation of duties. There are two issues with this logic.

First, the tasks are modifiable. Any task, including those delivered by Microsoft, may be modified and there are no restrictions on naming conventions. An administrator has the ability to create a new task, name it INQ_FIN_010*, and assign global access to it. Without an audit trail showing that the tasks had not been changed, we could not be sure that the standard tasks had not been modified.

Second, it appears Microsoft focused on business productivity when building the standard roles in GP 10. The standard roles have SOD conflicts out of the box. There are "Inquiry" roles and tasks, designed to give a user read-only or Inquiry access, that contain access to GL master data and the permissions to AP manual checks. Using the roles and tasks delivered out of the box will help you go live and process transactions in GP, but they should be scrutinized for SOD issues.

Are we ...