Sep 5

This document elaborates the SoD Management Process that is a key part to reduce Segregation of Duty (SoD) conflicts in a company. In fact SoD is a key contributor for fraud activities within an organization and hence to achieve seamless compliance (e.g. SOX) it is absolutely necessary to follow a straight process.


The SoD Management Process has six single steps that need to be completed one after one. Each step has its own outcome that you have to achieve before proceeding with the next.


Steps Description

Gather a list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation.


Helpful documents:

Risk Lifecycle


Build the rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set to analyze the user and/or role assignments.


Helpful documents:

Business Risks / Rule Set

Rule set - Rules & Rule Types


Analyze the SoD output. This can be performed with the help of SAP GRC Access Control. In case of manual analysis, for each user, analyze if he/she has the access to perform any of the conflicting functions defined in step 1. The outcome is basically to provide the business insight to alternatives for correcting or eliminating discovered risks.


Helpful documents:

Online vs. Offline Risk Analysis


In this step, evaluate if the conflicting tasks can be performed by an alternate person. If so, role changes and/or user reassignments can be performed to segregate duties properly. The outcome must be a very low number of remaining risks that need mitigation.


Helpful documents:

Remediating Access Control SoD Risks


If it would not be possible to remediate the existing conflicts, consider formulating an appropriate control to mitigate the risk. This would typically entail working with the business to setup additional monitoring procedures that ensure to compensate the risk. The outcome must be no remaining risks.


Helpful documents:

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

Creation of Mitigation Controls in GRC 10.0

Mitigating Control Lifecycle


Finally, establish a new continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning on the system. Also make sure that all role changes must be analyzed and remediated before implementing. The outcome, and also final result, your system remains clean.

Helpful documents:

Approve/Reject Own Requests

Risk Terminator - GRC 10

Best regards,

Posted by Alessandro Banzer

Twitter Facebook

0 Trackbacks

  1. No Trackbacks


Display comments as(Linear | Threaded)
  1. No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.