How to create CRM 7 WEB UI based risks in GRC

[former_member530411]

Hi,

This question has been asked earlier but there was no answer to it. We have a scenario where we have CRM system in frontend and then the backend system is ISU ( IS - Utilities ) .

How do we create the risk in GRC 10.1 system where we don't know how to determine the WEB UI components which could be based on UIU_COMP auth object which has values for each screen.

Is there a way to create a risk for a process that starts in CRM and ends in ISU.

Thanks ,

Ritesh Soni

[Colleen]

Hi Ritesh

Two options (and both would need prototyping to check validity

1. See if possible to configure CRM and ISU like a Hub scenario for Fiori (set the ISU connective as a subsequent connector to CRM). I'm not confident on this as it may be a Fiori use case only

2. Define the conflicting functions differently as a cross-system risk based on single function in CRM and ISU

For option 2....

Risk = Function A + Function B

CRM/ISSUE situations seems to be

FUNCTION A = Action A in CRM and Permissions A in ISU

FUNCTION B = Action B in CRM and Permission B in ISU

Risk = Action A in CRM + Action B in CRM + Permission A in ISU + Permission B in ISU

Therefore, when defining the SOD Conflict try doing a cross-system risk with

Function A = Action A + Action B in CRM

Function B = Permission A + Permissions B in ISU

Regards

Colleen

[former_member530411]

Hi,

Thanks for the information. Can we do this for a critical action ?

Critical action will only span across 1 system.

[Colleen]

A risk set as critical action means it is a single function risk definition

In the case of a "critical action" in your use case, you would be defining it as a cross-system SOD Risk. You would have a two functions - 1 in ISU and 1 in CRM to form together for the risk

This approach, assuming it works for you, would need to recognise a different in language - the risk definition versus the technical definition

You Critical Action and your segregation of duties would all be configured as cross-system SoD Risks. You might want to use naming conventions to differentiate which is a Critical Action (and will mean inherent conflict in a role or user) versus SoD.

Regards

Colleen