The SoD management process aims to remove the risk of errors and fraud or minimize them. Since a single user will not have access to several stages of an individual business process, it is necessary to manage such risks.
A business process must be separated, distributed, and allocated to different individuals to achieve the separation of duties. All of this is done in three distinct stages, and SAP GRC Access Control is an ideal tool to carry out this process.
You identify a high-level list of relevant SOD conflicts that allow fraud or generate important errors in this first step. The consequence of this move is that, by remediation or mitigation, your organization has decided as to what constitutes an unreasonable risk they want to report on and handle. This move takes place beyond the system and requires a basic understanding of business processes and their vulnerabilities.
Rule Building and Validation
In the second step, based on the recognized risks from step 1, you create the technical rule set that helps users, positions, or profiles to assess and classify risks. In the ARA module of SAP GRC Access Control, the technical rule set is constructed.
Analyzing the results of the risk analysis is the first step in phase 2. You may perform a risk analysis against users, tasks, accounts, and even HR artifacts (positions, work, etc.) using the ARA module. The risk analysis outcome will decide whether a single user, a single role, a single profile, or a job/position can perform any of the conflicting functions described in step 1. You will use the findings as a security administrator to give the organization insight into options for fixing or removing discovered risks.
This is one of the steps in the process that is most significant. The aim is to resolve the occurrence of the dispute at the level of the user. When allocated to a user, the occurrence of a SoD dispute occurs most frequently. Evaluate, therefore, if the conflicting tasks can be assigned to another person.
In this process, role changes and role reassignment are important because it is only then that access violations can be severely remedied. The result of this move is a decreased number of conflicts so that only a few conflicts need to be mitigated.
The remaining risks must be mitigated if remediation is not feasible. To be effective, mitigation requires a systematic explanation and intervention. In most situations, mitigation is accomplished by the implementation of new screening measures to ensure risk compensation after an action occurs. In certain situations, preventive steps are carried out after an incident happens. Therefore, it is advised to make as little use of mitigation as possible.
Continuous Compliance In this last stage, it is necessary to create a continuous process in which, before provisioning, every access request is checked against the SoD conflict matrix. Furthermore, make sure that all role changes are subject to risk analysis and remedied before they are made available to end-users. This process ensures that the system is free of violations.