This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Access Control is an enterprise software application that enables organizations to control access and prevent fraud across the enterprise, while minimizing the time and cost of compliance. The application streamlines compliance processes, including access risk analysis and remediation, business role management, access request management, superuser maintenance, and periodic compliance certifications. It delivers immediate visibility of the current risk situation with real-time data. This guide explains the Segregation of Duties Review concept and the technical configuration to attain that functionality.
Authors: Harleen Kaur, SAP Customer Solution Adoption
Created on: August 10, 2011
Version: 1.6
Performing Segregation of Duties Reviews in Access Control 10.0
The Segregation of Duties Review (SoD Review) feature automates and documents the periodic
decentralized review of risk violations by business managers or risk owners.
In the SoD Review process, the system checks periodically for any risk and violations associated with
users and functions they are associated with.
This feature can be used during the initial “clean-up” of risk violations as well as a long-term strategy to
review and affirm previous mitigation assignments.
Requests are generated automatically based on the company’s internal control policy.
The SoD Review provides a workflow-based review and approval process.
1.1 About this Guide
In this how-to-guide, the configuration as well as the implementation of the SoD Review process is
illustrated in detail. This guide is a stand-alone document.
Note:
This guide provides business use cases as examples for how you can use SAP software for your company. These examples are intended to serve only as models and might not necessarily run the way they are described in your customer-specific landscape.
This guide discusses SoD Review for GRC Access Control 10.0. Any attempt to use this guide for other product versions is not supported.
For an overview of the Access Control 10.0 documentation, refer to the SAP BusinessObjects Access
Control 10.0 Master Guide on the SAP Service Marketplace at service.sap.com/instguides.
1.2 Audience for this Guide
This guide is intended for the following people involved in performing SoD Review:
The key features of the SoD Review in Access Control (AC) 10.0 are:
Decentralized review of segregation of duties violations
Reaffirmation of mitigating control assignments
Workflow requests for Access Review and approval
Audit trail and reports for supporting internal and external audits
The key benefits of the SoD Review are:
A streamlined internal control process with collaboration among business managers, internal
control, and information technology teams
Improved efficiency and visibility of the internal control process
2.1 Exploring the SoD Review Process
The high-level process for SoD reviews is as follows:
1. The SoD background jobs generate SoD review requests. 2. The system sends e-mail notifications to reviewers. 3. The reviewer reviews the request and chooses from the following options:
a. Reject request items. b. Mitigate function risks by assigning controls. c. Remove access for items that violate your company policies.
There are other optional steps involved in the SoD Review process such as performing Admin Review
before sending requests to Reviewers. This guide explains all the steps in detail.
GRC Access Control 10.0 Segregation of Duties Review
SAP GRC 10.0 includes the following roles that can appear in SoD Requests:
Administrator – Administrators perform SoD Review-specific administration tasks such as performing an Admin Review before generating a workflow for the request.
Reviewer - Reviewers are approvers at the Reviewer stage. A Reviewer can be a User’s Manager or the Risk Owner.
User’s Manager – User’s Manager is the direct manager of a particular user, as defined in the User Details Data Source.
Risk Owner – Risk Owner is the owner specified in your Risk Analysis and Remediation (RAR) master data.
Coordinator – Coordinators are users assigned to one or more Reviewers. Coordinators monitor the SoD Review process and coordinate activities to ensure that the process is completed in a timely manner.
3. Prerequisites
Before running the SoD Review data job, ensure that the Batch Risk Analysis job is executed and
completed with the Management Report and that Risk Owners are assigned to risks.
Also make sure to run the following synchronization and action usage jobs as preconditions for
performing SoD Reviews in GRC 10.0. (It is recommended to run the jobs in the sequence they are listed
in the table below.)
Job Description
GRAC_ROLEREP_PROFILE_SYNC Synchronizes all profiles in the repository
GRAC_ROLEREP_ROLE_SYNC Synchronizes all roles in the repository
GRAC_ROLEREP_USER_SYNC Synchronizes all users, and roles used by these users
This section discusses how to maintain the configuration settings related to SoD Review, and then
generate data for SoD Review.
4.1 Managing IMG Configuration Settings
Before creating a SoD Review Request, there are some configuration options that need to be
maintained in IMG.
1) Log on to the GRC 10.0 system using SAP GUI and execute transaction SPRO.
2) Select the SAP Reference IMG option and navigate to Governance, Risk and Compliance
Access Control Maintain Configuration Settings.
3) Choose Configuration Options for Risk Analysis.
4) Set the configuration parameter for the Enable Offline Risk Analysis option to YES.
5) Choose Configuration Options for SoD Review Request.
6) The configuration parameters for SoD Review request are explained below:
Field Possible Values Descriptions
Request Type Any request type Choose the Default Request Type for SoD.
Priority Any priority Choose the Default Priority for SoD.
Reviewers Risk Owner/Manager Select the role to perform the Review.
Admin Review Yes /NO
Choose whether to require an Administrator
Review before the request is forwarded to
Reviewer(s)
Admin Review provides an opportunity for the administrator to review the request data for completeness and consistency prior to sending the request(s) to Reviewers.
Removal of Roles Yes/No Whether actual removal of role is allowed.
GRC Access Control 10.0 Segregation of Duties Review
a. Request Type: This is the request type that will be associated with SoD Review workflow requests. Request types can be reference points for initializing a workflow and determining the actions to be performed.
b. Request Priority: You can set a priority for a request to determine how quickly a request is to be approved. The request priority is also one of the workflow request attributes.
c. Reviewers: This term refers to the approver at the Reviewer stage. For the SoD Review, the Reviewer may be the user’s Direct Manager or the Risk owner as maintained in the RAR master data.
d. Admin Review: This configuration option provides an opportunity for the administration to review the request data for completeness and consistency prior to sending the request to Reviewers.
If any manager or risk owner information is incorrect or missing, the administrator can modify the
data prior to generating workflow tasks and notifications. The administrator can also cancel the
requests.
An Admin can perform SoD Review-specific administrator tasks, such as cancelling SoD Review
requests and regenerating requests for rejected users.
If this Configuration Option is set to:
Yes: The administrator reviews the SoD Review requests prior to the generation of workflow
tasks. The administrator can change the Reviewer and approval roles or cancel any unwanted
SoD Review requests.
No: The administrator does not have an opportunity to Review SoD Review requests prior to
sending the workflow notifications to Reviewers.
If there are users with no manager identified in the User Detail Data Source and the Reviewer is
defined as the User’s Manager, then Admin Review is required. This allows the administrator to
maintain the missing data prior to sending workflow tasks to Reviewers.
e. Removal of Roles: In AC 10.0, Reviewers can actually remove a role if any risk is associated
with any transaction(s) given to user(s) due to some role.
4.2 Managing Coordinators
This section describes how to manage Coordinators for requests.
The procedure is as follows:
1. Log on to the frontend GRC Access Control 10.0 system. 2. Navigate to Access Management Compliance Certification Reviews Manage
Coordinators. The Manage Coordinators screen appears.
GRC Access Control 10.0 Segregation of Duties Review
3. To change a coordinator-to-reviewer mapping, choose the Open pushbutton. The Change Mapping screen appears.
4. Modify the settings, as required, and choose the Save pushbutton.
5. To delete a coordinator-to-reviewer mapping, select the mapping you want to delete, and choose the Delete pushbutton. A confirmation dialog box appears. Choose Yes.
6. To create a new coordinator-to-reviewer mapping, choose the Create pushbutton. The Create Mapping screen appears.
GRC Access Control 10.0 Segregation of Duties Review
7. In the Coordinator ID field, type or select the appropriate value. 8. In the Reviewer ID field, type or select the appropriate value. 9. Choose the Save pushbutton. 10. Choose the Close pushbutton. The mapping appears in the table on the Manage Coordinators
screen.
4.3 Specifying the Service Level Agreement
(Escalation)
You can define the service level agreement for SoD Review requests.
1. Log on to the backend GRC Access Control 10.0 system. 2. Enter transaction SPRO. 3. Choose the SAP Reference IMG pushbutton. 4. Navigate to Governance, Risk and Compliance Access Control User Provisioning
Maintain Service Level Agreements. The Service Level Agreement Overview screen appears. 5. Create a new Service Level Agreement using SAP_GRAC_SoD_RISK_REVIEW as the Process
ID.
4.4 Generating Data for Requests
This section describes how to generate data for SoD Review requests by creating a schedule using the
Background Scheduler.
1) Log on to AC 10.0 using the Net Weaver Business Client.
GRC Access Control 10.0 Segregation of Duties Review
12) Select the NEXT pushbutton and the MAINTAIN AGENTS screen appears. You can define
agents for workflow stages, either for notification or approval.
13) The possible agent types are:
Directly Mapped Users A group of users created within the workflow configuration PFCG Roles All users who have specified PFCG role assignments PFCG User Group All users who are part of the specified PFCG group GRC API Rules All users returned by the configured rule for agents
GRC Access Control 10.0 Segregation of Duties Review
14) Once the agents are maintained, choose the NEXT pushbutton to maintain the VARIABLES AND
TEMPLATES.
15) In this screen, you can maintain custom notification templates as well as their variables and
reminders.
16) Choose the NEXT pushbutton to go to the MAINTAIN PATHS screen. a. In this screen, you can maintain workflow approval paths and their stages. All stages for
a selected path are shown in the Maintain Stages table.
GRC Access Control 10.0 Segregation of Duties Review
b. Select a path and choose the ADD or MODIFY pushbuttons to define the path stages. c. In the Maintain Stages table, choose the MODIFY TASK SETTINGS pushbutton to
change the stage settings.
i. In the Approval Type column, select All Approvers or Any One Approver from the dropdown list. This determines if all approvers or any one approver is required to approve the stage.
ii. If you choose Yes for Escalation, specify the escalation setting by entering the idle time in minutes. Idle time is the amount of time by which, if the stage is not approved or rejected, the task is either sent to the specified agent or the workflow moves to the next stage.
15) Choose the NEXT pushbutton to go to the Maintain Route Mappping screen. In this step you can maintain route mappings between the initiator rules result and the actual path for the result.
GRC Access Control 10.0 Segregation of Duties Review
16) Choose the NEXT pushbutton to go to the GENERATE VERSIONS screen.
In this step you can save, simulate, and generate new versions from the changed workflow for the SoD Review process.
Choose SAVE, to only save a configuration without generating a new version or without simulating validation of changes made to the configuration.
Choose SAVE/SIMULATE to save a configuration and to simulate changes to a configuration. In this case, the application displays all entities modified since the previous version was generated.
Choose ACTIVATE to activate the new version of a configuration for a selected process. After taking this step, any new workflow instances of the process will use the newly generated version.
17) Changes to the Workflow will not be reflected in any requests generated prior to the change. Only those requests generated after the changes will reflect the changes.
GRC Access Control 10.0 Segregation of Duties Review