CUP - Mitigation Controls in a Detour Workflow

Hello everybody,
I have a problem with a detour workflow in CUP.
I choose the detour condition: "SoD violation".
So in theory, if there is no conflicts the workflow don't take the detour path.
We supposed that the user request has an SoD conflict.
In the stage(s) before the detour, if we assign a mitigation control that mitigate the risk, the detour is still taken.
I think the workflow swich systematically to the detour if the request had a conflict, even if the risks were deleted by an Mitigation Controls assignment.
Does anyone have a solution to avoid the detour path if we mitigate the risks?
Thank you in advance!!

Ben,
   This is how CUP works. There is no configuration which allows you to ignore SOD violaton even if there is mitigation. You will have to live with this for now.
Regards,
Alpesh

Similar Messages

  • Creating Mitigation Control from CUP

    Hi Guys,
    Is this feature implemented in Access Control???? Or Stills as enhancement

    Hi Alpesh
    In order to your answer... Can you help me to identify what I doing wrong when I want to approve a mitigate control in CUP.
    Path 1 : Approve request
    Stage 1: Request
    Stage 2: Security
    Stage 3: Role Owner
    Detour Path:
    Type: CUP
    Stage: Role Owner
    Condition: SoD Review
    Detour Path: Path 2
    Path 2:
    Stage 1: Approval -- > CAD : Mitigation Monitor
    The request is send to the Mitigation Monitor but when we try to approve request show the next error:
    2010-03-30 14:10:26,390 [SAPEngine_Application_Thread[impl:3]_25] ERROR  Mitigation control TEST_5.1 could not be saved for user PRUEBAGRC_6
    com.virsa.ae.core.BOException: Exception from the service : Mitigation record doesn't exist
         at com.virsa.ae.accessrequests.bo.MitigationControlBO.insertMitigationControl(MitigationControlBO.java:207)
         at com.virsa.ae.accessrequests.bo.MitigationControlBO.saveMitigationControls(MitigationControlBO.java:321)
         at com.virsa.ae.accessrequests.bo.RequestBO.callAEExitService(RequestBO.java:6993)
         at com.virsa.ae.accessrequests.bo.RequestBO.callExitService(RequestBO.java:6748)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:6600)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:6393)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.confirmRequestApproval(RequestViewAction.java:949)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.execute(RequestViewAction.java:104)
         at com.virsa.ae.commons.utils.framework.NavigationEngine.execute(NavigationEngine.java:295)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:431)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:461)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:461)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(Native Method)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:102)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:172)
    Caused by: com.virsa.ae.service.ServiceException: Exception from the service : Mitigation record doesn't exist
         at com.virsa.ae.service.sap.MitigationControlWS52DAO.checkForSuccess(MitigationControlWS52DAO.java:832)
         at com.virsa.ae.service.sap.MitigationControlWS52DAO.executeUpdateUserMitigation(MitigationControlWS52DAO.java:287)
         at com.virsa.ae.service.sap.MitigationControlWS52DAO.insertUserMitigation(MitigationControlWS52DAO.java:309)
         at com.virsa.ae.accessrequests.bo.MitigationControlBO.insertMitigationControl(MitigationControlBO.java:195)
    Can you help me please?? All URI are OK.
    Thanks !!!!
    Edited by: Karen_sans on Mar 31, 2010 7:45 PM

  • Error when trying to approve a mitigation control in CUP

    Hi,
    I have created a Mitigation Control in RAR and set-up the necessary workflow. The request ends up in CUP and the approver is able to see the request when he/she logs in, however the approver cannot approve or reject the request.
    The following error messages appear:
    - Approve: Error processing your request, Request no: 2 in stage : MITIGATION
    - Reject: Error rejecting request no: 2
    I have check the workflow many times now and I have also checked the mitigation URL's.
    Any idea what the problem can be?
    Thanks.

    Thank you for your response. No the approver is not part of the DL. I just added the approver to the workflow (CAD).
    Please find log details below:
    2010-03-18 16:09:32,729 [SAPEngine_Application_Thread[impl:3]_8] ERROR Service call exception; nested exception is:
         com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
    java.rmi.RemoteException: Service call exception; nested exception is:
         com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
         at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:87)
         at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:96)
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callCCExitService(RequestExitServiceHelper.java:263)
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callExitServiceForApprovedRequest(RequestExitServiceHelper.java:51)
         at com.virsa.ae.accessrequests.bo.RequestBO.callExitService(RequestBO.java:5335)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:5174)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:4967)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.confirmRequestApproval(RequestViewAction.java:928)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.execute(RequestViewAction.java:103)
         at com.virsa.ae.commons.utils.framework.NavigationEngine.execute(NavigationEngine.java:271)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:425)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:455)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:455)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(AccessController.java:219)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
    Caused by:
    com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
         at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.handleResponseMessage(MimeHttpBinding.java:998)
         at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.call(MimeHttpBinding.java:1449)
         at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:80)
         ... 33 more

  • GRC CUP 5.3 SP16.3 Mitigation Controls automation removal

    Does anyone know that if you create any user requests to remove roles from a user, that if any mitigation controls were assigned to the users for those roles, the mitigating control ids can also be automatically removed from RAR during auto provisioning of the request?
    Right now, GRC CUP, if configured properly, during auto provisioning, will assign the mitigation controls automatically to the userid in RAR to mitigate the risks when the request is processed if the new access will give any SOD violations.  But if you remove the roles from a user and he/she had any mitigation ids assigned in RAR, can the request also automatically remove the mitigated control id associated with it if the user will no longer have that risk?  I have not seen the request automatically remove the mitigated id from RAR when the role was removed from the user id during auto provisioning. But I'm not sure if this requires additional workflow configuration or not.
    Will greatly appreciate if any1 is aware of this issue and how to resolve it. Or is the only solution to manually remove it from RAR..but this can be tiresome..bc then you have to run the report every week or month in RAR to remove the excessive controls assigned if the users do not have the risks anymore..comparing reports from current to previous month, etc.
    Thanks,
    A.

    Hi Alley,
    It is not possible to automate the removal of mitigation controls through a workflow in CUP. The only solution is to review on a regular basis and remove them manually from RAR
    We also has the same issue and performing manual review at regular intervals of the user & role assigned mitigation controls
    Best Regards,
    Srihari.K

  • Mitigation control workflow for AC10

    We are configuring the Mitigation control workflow during the implementation of AC 10.
    I would like to know whether its mandatory to have the workflow for Mitigation approver and monitor. As per the implementation team there is no requirement for them as this is not covered during the rampup.  But I think this should be mandatory to have the mitigation approval worflow so all the mitigation risk should be approved before mitigating. Otherwise, security admin can mitigate any risk and complete the request.
    Please advice.

    Hi,
    Yes. It will be a manual process. In some of the organizations, risks identification and mitigation will be performed manually by the Business process owners, which means in reality there will not be any risks that pop-up in CUP or RAR since they are already mitigated for the user.
    If you don't want to enable the mitigation process in the workflow, you have to do it and record the evidences manually.
    Hope this answers.
    Regards,
    Raghu

  • Mitigation control errors out in CUP approval

    We are on GRC 5.3 SP8 and I am trying to create a mitigating control in RAR.  Once it goes for approval into CUP, it erroru2019s out when I try to approve it.  Here is the message:
    2010-05-25 10:57:43,367 [SAPEngine_Application_Thread[impl:3]_9] ERROR com.virsa.ae.commons.utils.StringEncrypter$EncryptionException: Invalid PKCS#5 padding length: 32
    com.virsa.ae.service.ServiceException: com.virsa.ae.commons.utils.StringEncrypter$EncryptionException: Invalid PKCS#5 padding length: 32
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.getCCDocument(RequestExitServiceHelper.java:315)
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callCCExitService(RequestExitServiceHelper.java:263)
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callExitServiceForApprovedRequest(RequestExitServiceHelper.java:51)
         at com.virsa.ae.accessrequests.bo.RequestBO.callExitService(RequestBO.java:5391)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:5230)
         at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:5023)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.confirmRequestApproval(RequestViewAction.java:946)
         at com.virsa.ae.accessrequests.actions.RequestViewAction.execute(RequestViewAction.java:103)
         at com.virsa.ae.commons.utils.framework.NavigationEngine.execute(NavigationEngine.java:295)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:431)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:461)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
         at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
         at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:461)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(AccessController.java:219)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
    Caused by:
    com.virsa.ae.commons.utils.StringEncrypter$EncryptionException: Invalid PKCS#5 padding length: 32
         at com.virsa.ae.commons.utils.StringEncrypter.decrypt(StringEncrypter.java:200)
         at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.getCCDocument(RequestExitServiceHelper.java:305)
         ... 32 more
    Thanks,
    Peggy

    Hello Peggy,
      Did you recently upgraded your NW Java Support package? If yes, then kindly check the SAP Note "1417651 - Unable to retrieve connector & application configuration"
    The problem is coming due to change in NW encryption algorithm and impacted GRC as well. This is fixed in SP10 of GRC.
    Regards, Varun

  • CUP-5.3-SP13-Mitigation Controls by rol/users

    Hi all!
    Since RAR consider mitigations contros both by rol and users, If I have the role ZROL1 mitigated for the ID risk P001* then, would be able CUP to consider this mitigation control even when CUP is managing users?
    I mean, if ZROL1 has a mitigation control, would appear at the request the ID risk whenever I add this role to a user?
    Many thanks in advance! any help would be welcomed.
    Margarita.

    Hi Margarita,
    If you want it will consider the role level mitigation controls. So in the request risk violation will not be shown.
    For this u need check the option, consider mitigation control in CUP. Configuration-> Risk anlsysis.
    Also in RAR following things needs to be done.
    RAR Configuration->Risk analysis-> Defaults values.
    Exclude mitigated Risk as yes.
    RAR Configuration-> Risk Analysis ->Additional options
    Include Role/Profile Mitigating Controls in User Analysis  as yes.
    If above values are defined as No. than Risk Voilation will be shown in the request.
    Kind Regards,
    Srinivasan

  • Disable mitigation control workflow

    Hi community,
    one pretty simple question: I would like to be disable the mitigation control workflow, meaning, I would like to be able to directly save mitigation controls, without sending this through an approval process. I cannot find the associated activity in the spro. Can you please assist me on this?
    The way I saw this some time ago was that, if one disabled the mitigation control workflow, the Save button was visible in the mitigation control maintenance screen. When the workflow was enabled, the Submit button was visible (which, of course, makes sense). Now, I would like to be able to do this change.
    I did also look into transaction GRFNMW_CONFIGURE_WD - nothing suspicious here.
    Any help is highly appreciated. Thanks in advance!
    EM

    Hi EM,
    Please set 1061 and 1062 to NO as per your requirement for mitigation assignment and mitigation maintenance.
    BR,
    Mangesh

  • GRC AC V10 - Mitigation Control Approval Workflow

    Hi guys,
    can me explain somebody the difference between the processID SAP_GRAC_CONTROL_ASGN und SAP_GRAC_CONTROL_MAINT?
    And as well can somebody provide me the initiator rule ID for both so that we can have a detailed look into the brfplus rule.
    We only want to mitigate controls via an controlowner approval and not a process for the creation of new controls.
    That means an asisgnment approval workflow for mitigation controls.
    Thanks a lot.

    Hello Alexa,
    Did you ever employ SAP_GRAC_CONTROL_ASGN ? Were you able to identify the included agents ?
    I am interested in identifying approvers for mitigating controls who can be included in the workflow but are not risk owners. Would you have any suggestions for this type of agent ?
    Any information would be appreciated.
    Thanks,
    Jamie

  • Multiple mitigation controls assignment through CUP

    Dear All,
    We have implemented CUP 5.3 and under SP9.
    We have multiple controls addressing same risk where in we are supposed to assign multiple controls to the users. When the manager is assigning multple controls, the old one is getting replaced with the new one for the same risk.
    Is there any configuration change to be made to assign multiple mitigation controls to the same user for the same risk using CUP.
    Thanks and Best Regards,
    Srihari.K

    Ben,
       This is how CUP works. There is no configuration which allows you to ignore SOD violaton even if there is mitigation. You will have to live with this for now.
    Regards,
    Alpesh

  • Detect obsolete mitigating control assignments?

    Hello,
    What report/s would you use to detect obsolete mitigating control assignments?
    The scenario is: A user has been assigned a mitigating control, let's say during the CUP workflow, to mitigate a certain risk that came with a certain role. Later, that role is removed from the user. Now the user is in the scope of a mitigating control. However, the user is not even subject to the risk in question anymore.
    Which way (periodically?) could you detect these cases and clean up the mitigating control assignments?
    Thanks and regards
    Patrick

    Hey,
    My experience of cleaning up controls has not been very straight forward.
    I have had to perform various risk analysis reports and look up a list of user accounts that have been marked as "Expired" etc.
    It can be slightly more difficult  if, like many organisations, you decide to assign a control with a infinite validity period (i.e. 12.12.9999).
    The Business and Internal Control team need to be very proactive about regularly monitoring the controls and reviewing the assignments. This is one reason why I strongly recommend that controls are only assigned for a set period (i.e. 365 days/1 year), so a compulsory review takes place by the control owners/business on a regular basis. This makes the controls much more affective, robust and fit for purpose.
    Happy to hear other's opinions and ideas.

  • CUP mitigation wokflow

    Hi Everyone,
    We have configured in RAR, the workflow to send request for approval of Mitigation Owner using CUP Workflow. For Mitigation Control Using RAR  work fine, but unfortunately when we mitigated the Risks through the CUP request,  the workflow of Mitigation Control was not started.
    Workflow: USER > MANAGER > ROLE OWNER.
    Workflow with risk: USER>MANAGER> MITIGATION OWNER> ROLE OWNER (We have problem to send the request for Mitigation Owner).
    Let me know if you need any other information.
    Best Regards,
    Vitor Cozer

    Hi Vitor,
    I also faced the same issue and called SAP.They said GRC doesn't have option to trigger any additional workflow for mitigation from CUP (Request type /New change).
    If you have sorted out this issue,can you please tell,  then what strategy are you following currently.
    Thanks
    Mukesh

  • Validity period mitigating control

    Hi,
    I checked this forum but didn't find any helpful thread for my question. We are using GRC version 5.3. Is there any SAP report or tables available that would show history of mitigating controls per user? In running the Compliance Calibrator for a user, SOD issues were present that we didn't expect because we thought existing mitigating controls were applied and that we were  regularly monitoring this user for the associated risks. We thought that the problem might be that the validity period might have expired, but our corporate security group currently doesn't even show the mitigating control for the user. I wanted to look at the history of the mitigating control for the user to see if I could validate their claim.
    Thanks,
    John

    Hi,
    First of all, there's a special forum for GRC: "Governance, Risk and Compliance".
    Check under RAR-> configuration tab:
    Default expiration time for mitigating controls (in days) 
    When assigning a mitigating control to a risk, you must specify the validity period of the controlIf the End Date is left blank, the value in this option is used to calculate the end date of the validity period; the default value is 365 (days)
    Check also under CUP->configuration->mitigation.
    You'll be able to find the documentation for this configuration parameters in the corresponding Config Guide.
    Regarding Mitigation controls per user, I guess you can just check RAR -> Mitigation tab.
    Cheers,
    Diego.

  • Delete mitigation control

    Hello
    I am testing our access request workflows and applied a try to delete mitigation control.
    The workflow is work fine, but the mitigation control still exist.
    The same problem when i try to delete a mitigation user, the workflow work fine and the mitigation user still exist.
    Mi GRC is SP 13.
    Regards-

    Hi,
    Perform the tasks listed in:
    1.Run transaction SM30
    2. Display the view GRFNPARENT in change mode
    3. Add new line
    4. Entity = SUBPROCESS
    5. Parent = ORGUNIT
    Still the problem persists.
    Regards.

  • Mitigation of risk at detour path

    Dear experts,
    I have a scenario wherein I am using detour path for SOD violation.I want that SOD violation path goes to person depending on type of risk present in access request.
    The path with HR risk should go to person X where as non-HR(ECC) risk to person Y who will do the mitigation. There are only two(one from HR and other ECC) person to do mitigation.
    They are responsible for only mitigation and mitigation control id approver/monitor are different.
    How could this be achieved.Please share your thought.
    Thanks,
    Mamoon

    Hi Mamoon,
    Please check the below link. This could be helpful for you.
    AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls
    Regards,
    Madhu.

Maybe you are looking for