GRC

Risk Analysis and Remediation

Intro to portal

• URL• http://10.0.0.14:51000/irj/portal• Creating a user– Go to the User Administration tab to create the user– The first few users, we copied from an existing user.

• Creating roles in portal is a developmental responsibility – assigning roles to groups or individual users is a security/authorization personnel responsibility

AOTD

• Create an URL iview – www.<something>.com• Create a Page• Create a Workset as an entry point• Create a Role as an entry point• Assign the iview to the page• Assign the page to the workset• Assign the workset to the role• Assign the role to your user id

GRC application

• http://10.0.0.14:51000/webdynpro/dispatcher/sap.com/grc~acappcomp/AC

AOTDBrowse through this powerpointLogin to the GRC applicationReview the 4 sub-applications that exist in the product GRC Access ControlWhat each of these sub-applications can performADM955 – Access ControlADM940/950/960 – So far what we have covered.

3 phase approach

Phase 1 Phase 2 Phase 3

Phas

e 1 Risk

RecognitionRule Building and Validation

Phas

e 2 Analysis

RemediationMitigation Ph

ase

3 Continuous Compliance

Roles and ResponsibilitiesRoles Responsibilities

Business Process Owners

• Identify risks and/or approve risks for monitoring• Approve remediation involving user access• Design controls for mitigating conflicts• Communicate access assignments or role changes• Perform proactive continuous compliance

Senior officers • Approve/reject risks between business areas• Approve mitigating controls for selected risks

Security Administrators and Technical Liaisons

• Own the GRC technology foundation tools and security process• Design and maintain rules to identify risk conditions• Customize the SAP GRC technology foundation roles to enforce roles and

responsibilities• Analyze and remediate SoD conflicts at role level

Auditors and Regulators

• Perform risk assessment on a regular basis• Provide specific requirements for audit purposes• Perform periodic testing of rules and mitigating controls• Act as a liaison between external auditors

SoD Rule Keeper • Must not be involved in day-to-day security administration• Maintains controls over rules to ensure integrity• May act as a liaison between Basis and the SAP GRC methodology

foundation support center

Exercise• Enter an invoice in Financials . Accounts Payable (Company Code 1000)

(Transaction FB60).

• Save the document• Print the vendor balance confirmation (Transaction F.18) The company

must print and send balance confirmations as part of its annual audit process. Print the balance confirmation for vendors. Report variant GRC010 is available for ease of use.

• What is the risk of this process?• There is a potential for fraud if the same person can created an invoice

then print the vendor balance confirmation.

Field Name Value

Vendor 3101

Invoice Date Today’s date

Amount 1,100

Calculate Tax Select

Input tax 1I (Input tax 10%)

G/L Account 417001

Amount in doc. Currency 1,100

Rule Building Terminology• Business Process: The business area categories in which you would like to

report risk analysis results in Risk Analysis and Remediation• Function: A grouping of one or more related actions or permissions for a

specific business area• Risk: An opportunity for physical loss, fraud, process disruption, or

productivity loss that occurs when individuals exploit a specific condition; functions are the main components of risks

• Action: An activity that is performed in the system in order to fulfill a specific function, for example, Create Purchase Order or Create Material Master Record

• Permission: Authorizations that allow a user to perform a particular activity in a system

• System: Refers to a system in which risk analysis is performed, for example, SAP ERP, Oracle, SAP CRM, PeopleSoft, or Hyperion

Rule StructureRule Set A“Global”

Business Process“Purchase-to-Pay”

Risk A – User is able to maintain vendor master

data and initiate payment runs

Function 1 – Vendor master maintenance

Function 2 – Process Vendor

invoices

Business Process“Finance”

Risk B – user is able to create a fictitious GL

account and generate journal activity or hide

activity via postings

Function 3 – Maintain GL master

records

Function 4 – Post Journal Entries

Business Process “n”

Risk C – User is able to …

Function “t” - …

Rule Building

Create a Business Process• Example

Procure-to-Pay, Order-to-Cash, Finance and Controlling

Define a rule set ID and description• Example –

Global rule set “A”

Create functions for the business process• Assign actions

and permissions to the function

Create a risk for the business process• Assign

conflicting functions

• Assign to a rule set

Risk ID

Function 1 ID

Function 1 Function 2 ID

Function 2 Description of Risk Risk Level

F001 GL02 Maintain G/L records

GL01 Post Journal Entry

Create a fictitious GL account and generate journal activity or hide activity via postings

High

SO03 SD05 Sales Order Agreements or Contracts

SD01 Customer Master Maintenance

Create a fictitious customer and initiate fraudulent sales document

High

FS01 Create Master RecordFS02 Change Master RecordFSP1 Create Master Record in Chart/AcctsFSP2 Change Master Record in Chart/Accts

F-21 Enter Transfer PostingF-42 Enter Transfer PostingF-47 Down Payment RequestFB01 Post DocumentFB05 Post with Clearing

GL02GL01SOD Risk: F001

Exercise -2 • Log on to SAP GRC Access Control (rule architect) and create a new rule set.

• Log on to SAP GRC Access Control (rule architect) and create your own business process for purchase-to-pay as above

• Create functions with the following information.

• Create a risk with the 2 functions above and the following info

• Generate the rules for the risk that you just created.

Function ID Func1_XX (where XX is your group number)

Description Func1_XX

Business Process PP<XX>

Analysis Scope Single

Actions XK01

Function ID Func2_XX (where XX is your group number)

Description Func2_XX

Business Process PP<XX>

Analysis Scope Single

Actions ME21N

Risk ID RK<XX >(where XX is your group number)

Description Risk_XX

Risk Type Seggregation of Duties

Risk Level Medium

Business Process PP<XX>

Status Enable

Rule Set ID RS<XX> (where XX is your group number)

Description XX Rule Set

Business Process ID PP<XX> (where XX is your group number)

Description XX Procure to Pay

Change History• To view change log information for functions, choose Rule Architect →

Change History → Functions. In the displayed Functions-Change History Results screen, select your settings and choose Execute to run a search to view the change log results.

• The Functions Change History Results log includes:– Changed On: The date and time– Changed by: The user ID– Function (ID)– Change Type: This is either Insert Function or Delete Functions– System– Action– Item– Value– Status

Comparison of rule sets

• The rule sets can be compared in two ways:– A comparison of just the risks in the designated rule sets– A comparison of risks and actions/permissions

• To perform a comparison of rule sets, choose Rule Architect → Rule Sets → Compare.

• A comparison of risks is always performed, and these results are displayed initially.

• The Summary button on the risk comparison screen drills down to an action rule comparison. The Detail button in the action rule comparison drills down to a permission rule comparison.

SOD Phase 2 - Analysis

• The purpose of this phase is to provide business process analysts and business process owners with alternatives for correcting or eliminating risks by:

• Performing a security analysis to confirm risks for:– Simple roles– Composite roles– Users

• Reviewing the role to determine how certain personnel might be restricted from performing undesired activities by checking:– Objects– Fields– Values

Analysis – Exercise 1

• Enter the following information.Role: Z*GRC*O2C*Rule Set: GlobalReport Type: Permission LevelReport Format: Summary

• Choose Background.• Enter Job Name: “xx” Risk Analysis GRC-O2C• Choose Immediate Start.• Choose Schedule.

Remediation Exercise as a follow-up to Analysis Exercise-1

• Log on to SAP BusinessObjects Access Control and perform a simulation on role level. Simulate the removal of the single role Z*GRC*MISC* from the composite role Z*GRC*O2C. Compare the results with the first part of this exercise.

Mitigation

• Mitigation controls are required when it is not possible to segregate duties within the business process. For example, in a small office, one person has to take over two roles within the business process, which causes a missing SoD conflict.

• Examples of mitigation controls:– Release strategies and authorization limits– Review of user logs– Review of exception reports– Detailed variance analysis– Establish insurance to cover impact of a security incident

Types of Mitigation controls• Preventative controls– Minimize the likelihood or impact of a risk before

it actually occurs.• Detective controls– Alert when a risk takes place and enable the

responsible person to initiate corrective measures.Preventative Detective

Configuration Reports

Custom Objects Budget Review

User Exits and Enhancements Plan vs Actual Reviews

Security Technical logs

Workflow Alerts

Setting up mitigation controls

• Definition of responsibilities• Define administrators and select applicable role.

– Approver• Approve the control and identify appropriate mitigation monitors.• Ensure monitors are executing applicable controls within the period

frequency stated in a mitigation control.

– Monitor• Perform the actions identified in the control to monitor users and identify

inappropriate actions.

– Risk-owner• Responsible for monitoring the use of actions and permissions associated

with a risk

• Create business units and assign monitors to each.

Control creation• Specify control ID. Sample naming convention:

– Character 1 . Business area designation– Character 2 . User or role group letter– Characters 3 to 10 . Sequential number

• Enter description.– Definition: Who / what / how often / why (control objective)

• Assign business unit.• Assign approver from available approvers for the entered business

unit.• Assign associated risk IDs as pre-selection.• Document control monitoring:

– Assign one or more monitors.– Assign one or more mitigation reports (optional).

• Select the system from which you will run the reports.• Enter associated action.• Assign a monitor to each report.• The frequency must be established in number of days, for example, enter 30 for

monthly reports.

Alerts

• As a temporary mitigation control• To display users accessing multiple conflicting

actions• To display users accessing critical actions• To ensure effectiveness of mitigation control

by showing delays in starting mitigation reports

Alert Setup• Enablement and scheduling:

– Enter an application server location to store executed action information:

– Choose Configuration→ Miscellaneous.• Schedule background jobs for alert generation:

– Action log– Conflicting action– Critical action– Mitigation monitoring

• Schedule background jobs for alert notification:– Risk owner assigned to the associated risk is notified by e-mail

(maintained in Mitigation tab)– Monitors can also review the list of alerts through the Alert module

Mitigation ExerciseCreate an approver for the new mitigation control.1. Create an approver for the new mitigation control.a) Log on to SAP BusinessObjects Access Control with user GRC300-##.b) Select the Mitigation tab and choose Administrators → Create.c) Enter the following information.Administrator ID: ##-ApproverFull Name: Approved Approver ##Email: Enter a fictitious mail addressRole: Approver2. Create a monitor for the new mitigation control.a) Log on to SAP BusinessObjects Access Control.b) Select the Mitigation tab and choose Administrators → Create .c) Enter the following information.Administrator ID: ##-MonitorFull Name: Watching Monitor ##Email: Enter a fictitious mail addressRole: Monitor

Mitigation Exercise Contd.

3. Define a business unit as container for the mitigation controls.a) Log on to SAP BusinessObjects Access Control.b) Select the Mitigation tab and choose Business Units → Create.c) Enter the following information.Business Unit ID: PP##Description: ## Purchase-to-PayApprover ID: Enter the approver ID that you created inthe previous stepMonitor ID: Enter the monitor ID that you created inthe previous step

Mitigation Exercise 2SAP offers a dual-control principle to protect sensitive fields in the vendor master record from direct manipulations performed by one user. This preventative mitigation control can be used to mitigate the risk of fraudulent manipulation of bank accounts. After the security measure is activated in customizing by the IT department, the mitigation control needs to be implemented in SAP BusinessObjects Access Control.1. Implement the mitigation control in SAP BusinessObjects Access Control.a) Log on to SAP BusinessObjects Access Control.b) Select the Mitigation tab and choose Mitigation Controls → Create.c) Mitigation Control ID: MCVEN##To ensure the effectiveness of the control, the monitor needs to check the critical vendor on a weekly basis to investigate the result of S_ALR_87012090 (Display / Confirm critical vendor changes).d) Description: A vendor master data field marked in customizing table T055F as sensitive can only be changed after it is confirmed by a second party. Before approval takes place, a payment run block is activated for that account, and the confirmation status .To be confirmed. is set. Consequently, the likelihood of fraudulent manipulation is lower because an extra confirmation is required.e) Business Unit: PP##Management Approver: ##-ApproverRisk ID: Choose all risks ##NN you built in exercise, Rule Building and Validation, containing .vendor master data maintenance. as one of the conflicting functionsMonitor ID: ##-MonitorSystem: Select the appropriate systemAction: S_ALR_87012090Frequency: To run the report once a week (every seven days), enter 7.

Mitigation Exercise 2 Contd.After the security measure is activated in customizing by the IT department, implement the mitigation control in SAP BusinessObjects Access Control.a) Select the Informer tab and choose Risk Analysis → Role Level. Enter the following data.Role: GRC300-CR_PURCHASE_TO_PAY-##Rule Set: GlobalReport Type: Permission LevelReport Format: Management Summaryb) In the resulting report, select the risk you want to mitigate with the control and choose Execute.Hint: It should contain “vendor master data maintenance” as one of the conflicting functions. To see more details, toggle to the Summary report.c) Select the risk description and select Mitigate the Risk in the Options area.d) Choose Continue. In the Risk Mitigation screen, and enter the following data.Mitigation Control: MCVEN##Monitor ID: ##-MonitorStatus: Enablee) Check if the role name and the risk ID are correct.f) Choose Save.Result: The mitigation control is now assigned to risks.

Mitigation Exercise 2 Contd.Check the assignment of the mitigation control by performing a new risk analysis on GRC300-CR_PURCHASE_TO_PAY-##.a) Select the Informer tab and choose Risk Analysis.b) Enter the following data.Role LevelRole: GRC300-CR_PURCHASE_TO_PAY-##Rule Set: GlobalReport Type: Permission LevelReport Format: Management Summaryc) Choose More Options.d) Set Ignore Mitigation to YES to make the mitigated risks invisible in the result screen of the analysis.e) Choose Execute.In the results screen, all mitigated risks have vanished and the composite role is much cleaner than before our remediation and mitigation activities started.

Remediation relevant reportingDemonstrate the Action Usage by Users report.a) Log on on to Risk Analysis and Remediation via the SAP BusinessObjectsAccess Control launch pad.b) Choose Informer → Miscellaneous.c) Select the Action Usage by Users report.d) In the selection criteria, enter the following data.System T90CLNT090Date Use defaultAction SU01Report Type Alle) Choose Execute.f) Look at the results of the search.

Mitigations control report

Demonstrate the Invalid Mitigation Controls report.a) Log on to Risk Analysis and Remediation via the SAP BusinessObjectsAccess Control launch pad.b) Choose Informer Risk → Analysis → User Level.c) In the selection criteria, enter the following data.System T90CLNT090Risk ID 9901*Report Type Invalid MitigationControlsd) Choose Execute . If you see a runtime warning, choose OK.e) Look at the results of the report.

SOD Violations from custom programs

Demonstrate the SoD Violations from Custom Programs report.1. Demonstrate the SoD Violations from Custom Programs report.a) Log on to Risk Analysis and Remediation via the SAP BusinessObjectsAccess Control launch pad.b) Choose Informer → Audit Reports → Miscellaneous.

CUP – Verification of install

CUP Auth. System

Integrate RAR and CUP. Retrieve the URL for Risk Analysis Web service configuration.a. From the SAP NetWeaver Web Application Server start page, choose Web Service Navigator.b. Expand VirsaCCRiskAnalysisService Web service.c. Choose Document.d. Right click on the URL address under the WSDL heading to copy as a shortcut.. Choose Compliant User Provisioning, choose the Configuration tab, and chooseRisk Analysis.. In the Select Analysis and Remediation Version pane, choose 5.3 Web Servicefrom the Version menu.. In the URL field, enter the risk analysis URL. You can paste in the copied shortcut you obtained in the first step.. Enter a User Name and a Password.Note: This user must have the Admin role for Risk Analysis and Remediation.. Choose Save.

Define connectors for SAP

Define SAP connectors for CUPChoose CUP, select the Configuration tab, and choose Connectors → Create Connectors. In the Connector Type menu, choose SAP. In the Name field, enter a name for the connector. Note: The connector names are important when integrating with other Access Control Components and Central User Administration (CUA).Make sure that the connector name for Access Control is the same as the one configured for CUA. In the Short Description field, enter a brief description of the connector.In the Description field, enter a long-text description of the connector.In the Application field, enter the name of the application or application server.In the Application Server Host field, enter the host name of the application server. In the System Number field, enter the number in the SAP system log.In the Client field, enter the SAP client number. In the User ID field, enter the user ID you are configuring to have access to the back-end system. In the Password field, enter the specified password for the SAP user ID.In the System Language field, enter the language for the system.In the Message Server Name field, enter the name of the message server, which s used for load balancing.In the Message Server Group field, enter the logon group name to which the message server belongs.In the Message Server Host field, enter the host name of your message server.In the SAP Version menu, select the appropriate SAP version. CUP supports SAP 4.6C, SAP 4.7, and SAP ECC 6.0.Select the SLD Connector checkbox to enable the Standard Landscape Directory.In the Connector Category menu, select the category to which the connector belongs. Possible values are Production, Non-Production, or Other. This is used to classify servers into categories on the access request forms.In Role menu, select whether or not role information comes from ERM or the SAP back end.Choose Create.Choose Test Connection to ensure that the connection is valid.

CUP Lifecycle

How does CUP workflow work

CUP Workflow components

Workflow example

Approver Determination

Approval Stage Customization

• There are three configuration areas:– Notification Configuration– Additional Configuration– Additional Security Configuration (Approval Reaffirm)

• If the user, requestor, and approver are the same, each receives multiple e-mail notifications. When sending an e-mail notification to the user and the requestor if the user is the requestor, the system sends two e-mail notifications. If the requestor and the manager are the same user, that person receives two e-mails.

Notification configuration• The Notification Configuration screen configures e-mail notifications for a

stage to determine whether and to whom the system sends notifications about the actions taken at this stage. There are four possible actions:

1. Approved: The system sends the e-mail notification configured on the Approved tab when the approver approves the request.

2. Rejected: The system sends the e-mail notification configured on the Rejected tab when the approver rejects or denies the request.

3. Escalation: The system sends the e-mail notification configured on the Escalation tab when the approver fails to respond to the request within the allotted wait time and an escalation has occurred.

4. Next Approver: The system sends the e-mail notification to the approver(s) of the stage when the request enters this stage. The next approver is the approver of the current stage.

Additional Configuration• Risk Analysis Mandatory: Select Yes or No to determine whether the approver is required to perform a risk

analysis before approving the request.• Change Request Content: An approver has the authority to change the content of the request. If set to Yes,

the Add Roles field becomes available for selection. Select Yes or No to allow roles to be added during this stage. If set to Yes, the Path Evaluation For New Roles field becomes available for selection. This setting determines how the roles are evaluated to see if they are on the correct path (this is necessary only if you configure your initiators by roles).

• All Roles in Evaluation Path: All roles are re-evaluated against the initiators. New Roles Only: These new roles are analyzed against the initiators to determine if another parallel workflow mist be created for the newly added roles.

• If the Change Request Content configuration option is set to Yes but Add Roles is set to No, the approver can remove roles from the request but not

• add additional roles.• If the Change Request Content configuration option is set to No, the approver cannot change the roles on

the request. They cannot reject or remove roles, nor can they add additional roles to the request.• Approval Level: The approver has the authority to approve the request at the Request, Role, or System and

Role levels.• Reject Level: The approver has the authority to reject the request at the Request, Role, or System and Role

levels.• Approval Type: Select whether any one approver can approve at this stage. Or whether all approvers must

approve at this stage. for the request to move on to the next stage.• Email Group: This feature is no longer used. It remains on the screen for backward compatibility.• Comments Mandatory: Select whether the approver is required to enter comments when approving or

rejecting the request. If you set this option to Yes, checkboxes appear to allow the user to specify when comments are required (on approvals, request rejections, or both).

Additional Configuration Contd.• Request Rejection: If you set this option to Yes, approver is allowed to reject entire request. Reject button

appears next to Approve button, so approver can reject the entire request without individually rejecting each role. If No, the approvers can reject roles on the request without the ability to reject the entire request.

• Re-Route: Approver has authority to re-route the request to a previous stage as an alternative to rejecting the request entirely. Re-routing does not apply if the approver chooses to approve the request.

• Confirm Approval: Approver must answer an additional question if he or she wants to confirm approval action.• Confirm Rejection: Approver must answer an additional question if he/she wants to confirm rejection action.• Reject by Email and Approve by Email: Approver can reject or approve the request by e-mail.• If you set this option to Yes, there could be two additional links on e-mail when approver gets e-mail

notification for this stage stating that there is a request waiting for action. If Approve by Email is set to Yes, one link will be the Approve Request action. If Reject by Email is set to Yes, another link will be present for Reject Request. These buttons will transfer the approver to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password.

• Reject by Email: The approver can reject the request by e-mail. This setting is not an option if actions are required, for example, if risk analysis or comments are required.

• Approve by Email: Options will allow the approver to approve the request by e-mail. This setting will not be an option if actions are required, for instance, if risk analysis or comments are required.

• Forward: The approver has the authority to forward the request to someone else for approval.• Approve request despite risks: If you set this option to Yes, the approver is allowed to approve this stage, even

if there are SoD violations that have not been mitigated.• If you set this option to No, approver at this stage must remediate(remove) or mitigate violation before he/she

can approve the request. The approver is required to enter comments when approving or denying the request.• Forward Type: Options are Any One Approver or All Approvals: If you select the Forward option, you can

specify whether: Any one of the approvers that the request is forwarded to can approve and the request can continue OR All approvers listed on the Forward are required to approve before the request can continue on.

CUP Workflow Configuration Exercise• Set up a basic workflow with one stage to make a change to a user, run an SoD check, then have

the change auto-provisioned to an SAP system.• Log on to the back-end system assigned by your instructor, into client 800 with your user ID, and

create the following roles:• a. Z_##_FB50 and assign transaction FB50 with full authorizations i. Description: Post Journal Entry• b. Z_##_OB52 and assign transaction OB52 with full authorizations i. Description: Open and Close

Accounting Period• Log on to SAP BusinessObjects Access Control Compliant User Provisioning through http

://10.0.0.14:51000/webdynpro/dispatcher/sap.com/grc~acappcomp/AC• Choose Configuration → Role → Import and import the roles you created using the Selected Roles

option.• Log on to the UME using your User ID and create the following users in the UME:

– Manager(XX) with Role: AE Approver– RoleOwner(XX) with Role: AE Approver– Security(XX) with Role: AE Security– Sox(XX) with Role: AE Approver

• Log on to SAP BusinessObjects Access Control Compliant User Provisioning through http://10.0.0.14:51000/webdynpro/dispatcher/sap.com/grc~acappcomp/AC

• Choose Configuration → Roles → Attributes and create a functional area.– Name: ##FI– Short Description: ##FI– Description: ##FI Functional Area

CUP Workflow exercise contd.• Choose Configuration → Roles → Role Search and select the roles imported into Compliant

User Provisioning in step 4 above. Verify/assign the following:– Z_##_FB50

• Business Process Finance• Critical Level High• Role Approver Tab RoleOwner (XX)

– Z_##_OB52• Business Process Finance• Critical Level High• Role Approver Tab RoleOwner(XX)

• Go to the workflow configuration and create an initiator. Choose Configuration → Workflow → Initiator.

• Choose Create and enter the following data.– Name ##_Initiator, Short Description ##_Initiator– Workflow Type Compliant User Provisioning, Attribute Functional Area, Value ##FI

• Choose Save to save the initiator.• Create three stages. Choose Configuration → Workflow → Stage.• Choose Create and enter the following data.

– Name ##_Manager, Short Description ##_Manager– Workflow Type Compliant User Provisioning, Approver Determinator Manager– Name ##_RoleOwner, Short Description ##_RoleOwner– Workflow Type Compliant User Provisioning, Approver Determinator Role– Name ##_ Security , Short Description ##_ Security– Workflow Type Compliant User Provisioning, Approver Determinator Security

CUP Workflow exercise contd.• For the notification configuration, select the Next Approver tab and fill in the

information for approval.• Select the following options for the Additional Configuration section.

– Risk Analysis Mandatory Yes– Change Request Content No– Add Role Should not be able to change. Why?– Change Request Content set to No.– Path Revaluation for New Roles Should not be able to change. Why?– Change Request Content set to No.– Approval Level set to Request– Rejection Level set to Request– Approval Type Any one Approver– Comments Mandatory Yes or no– Request rejected No– Re-route No– Confirm Approval No– Confirm Rejection No– Reject by Email No– Approve By Email No– Forward Allowed No– Approve Request Despite Risks Yes

• Choose Save to save each stage.

CUP Workflow exercise contd.• Create a path. Choose Configuration → Workflow → Path.• Choose Create, then enter the following data.

– Name ##_Path– Short Description ##_Path– Workflow Type Compliant User Provisioning– Number of Stages 3– Initiator ##_Initiator– Be sure to make the path Active.

• Select the three stages that you created in this exercise.• Choose Save to save the path.• Create a Custom Approver Determinator for detour. Choose Configuration → Workflow

→ Custom Approver Determinators and create a custom approver determinator.– Name ##_SOD_CAD– Short Description ##_SOD_CAD– CAD Type Attribute– Workflow Type Compliant User Provisioning– Attribute Functional Area

• Choose Save.• Choose the Approvers button and choose Add.

– Functional Area ##FI– Approver Sox## User

CUP Workflow exercise contd.• Define a stage for SoD violation. Choose Configuration → Workflow → Stage and enter the following data.

– Name ##_ SOD_Stage, Short Description ##_ SOD_Stage– Workflow Type Compliant User Provisioning– Approver Determinator ##_SOD_CAD

• Define a detour path. Choose Configuration → Workflow → Path and create the following path.– Name ##_Detour, Short Description ##_Detour– Workflow Type Compliant User Provisioning– Number of Stages ```2– Initiator None– Be sure to make the path Active– Detour checkbox Select Yes– Stage 1 ##_SOD_STAGE– Stage 2 ##_Security

• Choose Save.• Define a detour for SoD violations. Choose Configuration → Workflow →

– Detour/Fork and create a detour.– Workflow Type Compliant User Provisioning– Path ##_Path– Stage ##_RoleOwner– Action Save– Condition SOD Violations– Value Yes– Detour Path ##_Detour

• Test your workflow by creating several requests and verify that the path and detour you created work properly.• Hint: Create multiple AE requests to create users for the back-end system. Assign each user to one or both of

the roles you created.