<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

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 looking for SOD conflicts at the Role, Task or User level?

In GP 10, there are three key items in security: roles, tasks and objects. Roles, which usually equate to an individual's job, are made up of tasks. Tasks are typically a business process or the function that will be performed within GP--setting up a customer, entering journal entries, etc. Tasks are made of up objects, which include windows, reports, series posting permissions and other items found within GP.

The key object in SOD analysis is the window. It is the windows that allow users to maintain data within GP.

See the Webcast GP Security  From A to ZGiven that the task controlled the function a user could perform, the project team wanted to analyze the task for SOD issues. The logic was that if we eliminated conflicts at the task level, there would be no conflicts at the Role and therefore, user level. However, getting to zero conflicts at the task level will not eliminate SOD issues. Why? The combination of tasks in a role may create a conflict.


Task 1 contains 1 object: Account Maintenance. This task would have zero conflicts.

Task 2 contains 1 object: Transaction Entry. This task would have zero conflicts.

Role 1 has 2 tasks; task 1 and task 2. The combination of these tasks creates a conflict.

As you combine several tasks in several roles, you create several conflicts.

Since the task analysis was not an option, the project team shifted its focus to eliminating conflicts within the roles. During the initial SOD analysis of the roles, we discovered almost 650 conflicts. Unfortunately, we ran into the same issue here as we did with the tasks. Users can be assigned to multiple roles, and the combination of roles yielded conflicts.

That leaves us with doing analysis at the User/object level. It is only at the user/object level that we get a true picture of SOD conflicts in GP. Our initial analysis yielded over 1400 conflicts at the user level. So we had 16 at the task level, 650 at the role level and over 1400 at the user level. If we would have stopped our analysis before the user, we would have left over 800 risks in the system.

Now I know the issues, how can I remedy them?

The final question is a common one in GP 10. The team wanted to edit the roles and tasks to try and eliminate as many conflicts as possible. For example, they wanted to revoke Account Maintenance window access from all accounting clerks. When the administrator tried to determine where an object was associated to a task, there was no easy way to make a determination through the interface. We had to write an Excel report that displayed the Role > Task > Object access. This report made it easy to identify where a role and a task were gaining access to an object.

We also emphasized that the goal should not be to eliminate SOD conflicts from the implementation, but rather to minimize them. This is especially true in small to midsize organizations. It is very hard to achieve segregation of duties with a one-person AP department. The remaining issues must then be remediated with other internal controls.