Performing SoD Review

Before you learn how to carry out a Segregation of Duties (SoD) review check in the following lesson, look at the overview of the steps again. We start with the first step, Scheduling of Data Generation.

In every day work, risk owners, approvers of access requests, security administrators, or access risk specialists analyze access risks when assigning access to users and running access analysis reports, dashboards. But the content of access risks and technical roles can change, which can lead to new access risks for a user. To ensure that the access risks profile of a user is still acceptable, you must monitor access risks of users on periodic basis. SAP Access Control provides an SoD review process for this purpose.

During an SoD review, managers or risk owners review users who have access risks and determine whether assigned access is still required.

Administrators schedule a job to generate data for an SoD review in the Background Scheduler app. First, as an administrator, you specify the name of a schedule and choose the schedule activity that corresponds to SoD review data generating. If required, specify a recurring plan.

On the second step, you define analysis criteria to define the area to review. For example, you can define a set of users, risks, and specify whether to exclude expired and locked users or not. If you choose to define a review area by specifying a risk as in the screenshot, then reviewers get requests for all users with this risk. If a risk owner is the reviewer, risk owners receive a request to review and approve the access. If a manager is a reviewer, managers of all users with this risk get review requests for corresponding users. After schedule creation, SoD review requests are available for administrators review.

If necessary, administrators can change reviewers and coordinators through the Change Reviewers button in the Request Review app. If an SoD review request isn't relevant anymore, administrators can cancel the request. SAP Access Control has a configuration to make the administrator review step optional. Thus, if an administrator review is not required according to your data and processes, you can skip this step and plan workflow update for an SoD review requests.

To send requests to reviewers after the request review phase, as an administrator, you plan the Update Workflow for an SoD request job.

After execution of Update Workflow for SoD request job, approvers receive SoD review requests. A manager or risk owner can be an approver for SoD review requests. The application creates a review workflow for the specified approver type. Managers receive review requests sorted by a user, and risk owners receive review requests sorted by a risk. Reviewers access SoD risks review requests in the Work Inbox app.

As a reviewer, you can mitigate the risk, propose removal of roles, initiate actual removal of roles, or reject a user, if you are not responsible for the user anymore. On the preceding screenshot, you can see an example where the Actual removal option is available for the reviewer. You can configure one of two following options of access removal:

• Actual Removal. Roles will be removed from the user automatically after choosing this option for user access and approving a SoD review request.
• Propose Removal. In this option reviewers can only propose the removal of roles associated with a SoD risk violation. After approving a SoD review request, the workflow goes to the security administrator who can check if removal doesn't cause inconsistency in business process before deciding whether to remove the role or not. After security administrator approval, access will be automatically removed from the user.

After reviewing and taking one of the mentioned actions, you approve the request by choosing Submit. Also, you can forward the whole request to another approver.

For the rejection of a user by a reviewer, administrators take the same set of actions as in the User Access Review scenario:

• Check all user rejection cases in the Manage Rejection app and mark some of them for request generation and cancel generation of other rejections.
• Schedule Generates new request for SoD rejected request job in the Background Scheduler app to generate new requests for marked rejections.
• After generating, administrators can check reviewers in the Request Review app and change reviewers to prevent repetitive rejections.
• Finally, administrators schedule Update Workflow for SoD request job to send new requests to reviewers.

The SoD Review History Report provides the history of actions performed on SoD review tasks. In the columns, you can find a request number, risk details, and the decision that was made for user access. For example, an action like Remove, as shown on the preceding screenshot. By choosing the request, you can access all details of the request in a separate window.

The User Review Status Report report lists the request status for SoD review and User Access Review. In the report, you can view various information. This includes details about the reviewers and coordinators for each request. You can also see which requests have been approved or canceled, and which are still unprocessed. It also shows how many items within each request have been processed, left unprocessed, or rejected. If you choose the request, you see all request details in a separate window.