SoD (Segregation of Duties) is an essential and critical concept in SAP Security. The SoD concept assists in reducing the number of frauds or errors in an organization by dividing the roles and responsibilities of an individual. It is also called Separation of Duties, where more than one person is required to complete a task.
SoD involves breaking down tasks that could be completed by a single individual into multiple tasks so that any single person is not solely in control. Therefore, a SoD risk is a chance that someone has access without segregation (wider access).
A simple example of a SoD risk:
An employee can create/submit his expense and approve his expenditure.
In the above example, we must segregate the tasks to ensure no risk. If the employee can submit his expense report, he should not have access to approve his report. The authority to approve the expense lies with his manager.
How do we prevent or mitigate the SoD risk in GRC?
‘Access Risk Analysis’ is a tool within SAP Access Control that allows you to define user access risk (with the help of a set of rules) and to identify access risk (or simulate for potential risk). Mitigate the risk by assigning a mitigating control.
The primary risk management process, as suggested by most risk management frameworks, involves the steps described below:
Recognize the Risk: Identify SoD risks that allow fraud or produce significant errors.
Rule Creation: Prepare or build the rule set based on the recognized risks. This technical rule set helps to analyze the user and role assignments.
Risk Analysis: Analyze the risk with the help of SAP GRC Access Control. Using “User level Simulation” risk analysis, we can analyze the risk for a user based on Ruleset and Risk levels (Low, Medium, High, and Critical).
Remediation: With this step, we must decide if a different individual can perform the conflicting activities/actions. If so, we can proceed with role modification and/or user role reassignments to remediate the risk. If the user is not supposed to perform that task, we can remove the access, generating the risk.
Mitigation: It may not always be possible to remediate the existing conflicts. In that case, we can assign a control to mitigate the risk. This way, the corresponding control owners will always control and monitor the risk.
The final takeaway:
SoD is not just a compliance checkbox but a crucial safeguard against fraud, errors, and operational disruptions. Properly managing SoD conflicts is essential for maintaining the integrity of operations and regulatory compliance.
It is always a good practice to review the access request and perform risk analysis before provisioning access to the users. I recommend running a level simulation before modifying the role. This way, we can keep the system clean without any conflicts. SoD is not an option but a necessity in the GRC world.
View our LinkedIn, here.
