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.

Similar Messages

  • 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

  • RAR 5.3 SP10 Mitigating Control Import Utility

    All -
    I exported my mitigating controls from a RAR 5.3 SP9 system and imported them into a 5.3 SP10 system. I received a successful confirmation of the import, but when I "searched" my mitigating controls there were duplicated mitigating control numbers. It looks like the import tool duplicated the mitigating control ID for every "monitor" assigned to the mitigating control number. For example, mitigating control MC00000001 with Monitor1, Monitor2, & Monitor3 equated to 3 entries of MC00000001. If I try to delete 2 of the 3 entries, I receive a "Successfully deleted" message and get the error "Exception!!. No relavent language message available in database for :0053". When I "search" again, the mtigating control is no longer there (as expected).
    I confirmed my mitigating control import file does not have the multiple entries.
    Any ideas?
    Thanks,
    Daniel

    Venky,
    Thank you for your response. The message issue actually wasn't the one that I was asking about, but thanks for the heads up. The main issue is that RAR (5.3 SP10) is multiplying mitigating control entries for the number of monitors assigned to the mitigating control. It appears to be an issue with SP10 as it did not occur in SP9. I'm trying to see if anyone knows what the fix is.
    Thanks,
    Daniel

  • GRC AC RAR: Comprehension question Mitigating Controls

    Hello all,
    I have a small comprehension question regarding Mitigating Controls.
    Situation:
    We have identified some authorization roles that contained lots of risks and we decided that they should not be used anymore. I therefore had our admins remove those roles from all the userIDs and update the role descriptions so it is clear that these roles are obsolete and must not be used anymore. For specific reasons we are currently not able to archive those roles in order to remove them from the system (can't delete them either for unclarified data retention questions).
    What has been done:
    1. I have created the necessary userIDs for Management Approver, Monitor, etc. in tab Mitigation -> Administrators -> Create
    2. I have created the necessary business unit and assigned to userIDs created in 1. in tab Mitigation -> Business Units -> Create
    3. I have created a Mitigation Control "Obsolete Roles" in tab Mitigation -> Mitigating Controls -> Create
    4. Within the Mitigatin Control I have mitigated all associated risks in tab "Associated Risks", added a userID in tab "Monitors" and I have added all the obsolete roles using the button "Mitigate roles"
    What I want to achieve:
    - Roles should not show up in the analysis anymore -> I've checked that and it works as expected
    - I now want the userID I added in tab "Monitors" and when mitigating the roles to regularly check in the SAP system whether the mitigated roles have been assigned to any userIDs again (using PFCG or any other suitable report in the system).
    Can I achieve that by using tab "Reports" within the Mitigating Control ?
    If I provide the system in column "System", provide "PFCG" in column "Action", "Use PFCG to check is role is assigned again" in "Description", add the userID in tab "Monitor" and set Frequency to "4" this would mean that that userID needs to check whether the roles have been used again at least every 4 weeks ?
    Will the system automatically send a reminder eMail to that userID every 4 weeks or does the user have to check the RAR manually in order to see "his/her" tasks ?
    Regards,
    Benjamin

    Hi Jwalant,
    sorry for my late reply, but I have waited for a few weeks to make be sure wheather the way you described works or not.
    - The background job gets executed once a week and finishes without any error.
    - The only thing that doesn't work is that the userID that I maintained in clolumn "monitor" and for which I defined a mitigation control which has to be executed every 2-weeks (using column "report") does NOT get a mail from the system that reminds him/her to execute the mitigating control.
    Log of background job execution:
    INFO: -
    Scheduling Job =>16----
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob run
    INFO: --- Starting Job ID:16 (GENERATE_ALERT) - Z_SAP_GRC_AC_RAR_MITIGATION_CONTROL_ALERT_GENERATION
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob setStatus
    INFO: Job ID: 16 Status: Running
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob updateJobHistory
    FINEST: --- @@@@@@@@@@@ Updating the Job History -
    1@@Msg is Z_SAP_GRC_AC_RAR_MITIGATION_CONTROL_ALERT_GENERATION started :threadid: 2
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.dao.BgJobHistoryDAO insert
    INFO: -
    Background Job History: job id=16, status=1, message=Z_SAP_GRC_AC_RAR_MITIGATION_CONTROL_ALERT_GENERATION started :threadid: 2
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob alertGen
    INFO: @@@ Alert Generation Started @@@
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob alertGen
    INFO: @@@ Conflict Risk Input has 1 records @@@
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob alertGen
    INFO: @@@ Critical Risk Input has 1 records @@@
    Mar 28, 2011 4:00:00 AM com.virsa.cc.xsys.bg.BgJob alertGen
    INFO: @@@ Mitigation Monitor Control Input has 1 records @@@
    Mar 28, 2011 4:00:00 AM com.virsa.cc.comp.BackendAccessInterface alertGenerate
    INFO:  @@@@@ Backend Access Interface execution has been started @@@@@
    Mar 28, 2011 4:00:00 AM com.virsa.cc.common.util.ExceptionUtil logError
    SEVERE: null
    java.lang.NullPointerException
         at com.virsa.cc.comp.wdp.IPublicBackendAccessInterface$IStatRecInputElement.wdGetObject(IPublicBackendAccessInterface.java)
         at com.sap.tc.webdynpro.progmodel.context.NodeElement.getAttributeAsText(NodeElement.java:888)
         at com.virsa.cc.comp.BackendAccessInterface.execBAPI(BackendAccessInterface.java:401)
         at com.virsa.cc.comp.BackendAccessInterface.executeBAPI(BackendAccessInterface.java:302)
         at com.virsa.cc.comp.BackendAccessInterface.get_TcodeLog_Rec(BackendAccessInterface.java:2800)
         at com.virsa.cc.comp.BackendAccessInterface.alertGenerate(BackendAccessInterface.java:1940)
         at com.virsa.cc.comp.wdp.InternalBackendAccessInterface.alertGenerate(InternalBackendAccessInterface.java:4355)
         at com.virsa.cc.comp.wdp.InternalBackendAccessInterface$External.alertGenerate(InternalBackendAccessInterface.java:4824)
         at com.virsa.cc.xsys.bg.BgJob.alertGen(BgJob.java:1666)
         at com.virsa.cc.xsys.bg.BgJob.runJob(BgJob.java:697)
         at com.virsa.cc.xsys.bg.BgJob.run(BgJob.java:362)
    here it keeps ranting on for pages about Null Pointer Exceptions
    I'll just leave that part out
    Mar 28, 2011 4:00:29 AM com.virsa.cc.comp.BackendAccessInterface alertGenerate
    INFO:  -
    No of Records Inserted in ALTCDLOG =>16 For System =>XXX_xxx -
    Mar 28, 2011 4:00:29 AM com.virsa.cc.comp.BackendAccessInterface alertGenerate
    INFO: ==$$$===Notif Current Date=>2011-03-28==$$$==Notif Current Time=>04:00:00===$$$===
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.mgmbground.dao.AlertStats execute
    INFO: Start AlertStats.............
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.bg.BgJob alertGen
    INFO: @@@=== Alert Generation Completed Successfully!===@@@
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.bg.BgJob setStatus
    INFO: Job ID: 16 Status: Complete
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.bg.BgJob updateJobHistory
    FINEST: --- @@@@@@@@@@@ Updating the Job History -
    0@@Msg is Job Completed successfully
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.bg.dao.BgJobHistoryDAO insert
    INFO: -
    Background Job History: job id=16, status=0, message=Job Completed successfully
    Mar 28, 2011 4:00:29 AM com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob scheduleJob
    INFO: -
    Complted Job =>16----
    - Anothjer thing I noticed is that the job always adds some entries to table "ALTCDLOG" which I guess means something like "Alert T-Code Log".
    It always adds entries like:
    581 XXX_XXX userID#1 SE16 2011-03-21 07:49:44 xxx 5
    582 XXX_XXX userID#1 SM37 2011-03-21 07:55:44 xxx 5
    Where does the system get the information which T-Codes are "bad" and for which it needs to create those entries ? I have never configured anything like that in the system.
    Or is this an indicator that the authorization roles I mitigated have been used again ?
    Regards,
    Benjamin

  • CC: Entering Mitigation Controls

    Hi ,
    I am entering mitigation controls in CC and am noticing 2 issues
    1) I cannot blanket mitigate a selection of users. Blanket mitigation only seems to apply if I want to mitigate all users. Is there any way to add 10 select users to a mitigation control by selecting the 10 users, rather than having to specify risk, validity dates etc. for all 10?
    2) I have noticed in SAP documentation that * should be entered after the risk ID e,g, P005*. Why should this be entered. This does not default when setting up the mitigation control and if I forget to do it, I have to delete the mitigation entry for the user and recreate. Can anybody advise why * must be entered and if there is a way to default *
    Thanks,
    Gary

    Gary,
    1)  No there is no way to select 10 individual users without creating a line item for each one.  Unless they all get the access from the same Role.  If that was the case you could just create the mitigating control for that role and anyone that would have the conflict via that Role would not appear in your risk reports.
    2)  The reason you have to enter * in the mitigating controls is so that all risk ID's are mitigated by your rule.  For example short risk ID P033 is made up of multiple long risk ID's based on each transactional combination i.e. P03300101 for ME21,ME51, P03300201 for ME21N,ME51, P03300301 for ME22,ME51, P03300401 for ME22N,ME51.
    So to cover all possible transaction combinations with a mitigating control you need to enter it for P033*.  This would also allow you to enter a mitigating control for only long risk id P03300101 it your mitigating control only covered users with access to ME21 and ME51.
    Hope that helps.
    Matt.

  • Changing Monitor on Mitigating Controls

    HI all:
    Just wondering, is there a way to change the Monitor on an existing mitigating control once it is assigned to either a role or user??  When we try to do it, the error message says "Role is already mitigated to Control xxxx: Monitor xxxx cannot delete".
    The only workaround is to delete the exisintg entries and re-enter them with the new monitor...however this is not an efficient approach when we have many entries for one mitigating control.
    The monitors are defined properly....we just can't change the mitigating control monitor once there are assignments to roles or users.
    Any help would be appreciated.
    Margaret

    I think one of the option may be to keep the monitor ID same but change the name of the monitor for that monitor ID in the administrator tab of mitigation.
    Hope this helps
    Regards,
    Nitin

  • Reduplicative mitigation controls

    Hi There,
    In RAR of GRC 5.3, there are many reduplicative mitigation controls. I tried to delete duplications, it seems like if I delete one of them, I will delete all of them. Could you please advise how to delete reduplicative mitigation controls and just keep one of them? And I also want to know why there are many reduplicative mitigation controls in our GRC. Thanks.
    Thank you for any information or suggestion!
    Regards,
    Sophie W

    Hi Sophie,
    You can check following
    Check if mitigation to user assignment table has duplicates or it is only display error.
    Check if they are exactly same in all details or there is a difference.
    This will help you to focus in specific direction for troubleshooting.
    BR,
    Mangesh

  • Changing a monitor on a mitigating control

    1. I am using CUP 5.2 and I noticed that I am not able to change the monitor on a mitigating control. The messages reads that the administrator id is already assigned as a monitor to a business unit and cant be deleted. When I go to the business unit and try and update that monitor it is not allowing me to do that also. There are users that have been assigned to that mitigating control although their valid to date has expired. Does anyone know how I can update the monitor and keep the mitigatig control?
    2. When I am assigning a user to a mitigating control is there away to do them all at once instead of one by one?

    Hi Valarie,
    You cannot edit the monitor of a mitigation control if that mitigation control has already been assigned to users. You will either have to delete all the users and then change the Mitigation control ID or you will have to assign a new monitor to all these mitigated users and then you will be able to delete the old monitor.
    Hope this clarifies your doubt.
    Thanks
    Harleen
    SAP GRC RIG

  • Mitigating Controls got Inactivated

    Friends,
    we got some mitigating controls popped up in controls library option under management view, but those are actually active and i suspect this is happening because of not mentioning valid to date when they are created and mitigating controls gets expired after 365 days(as per our setting).
    Is there any way that these can be reactivated or do we need to delete and re-create them.
    Thanks for the help in advance.

    Hi Srinu,
    Mitigation controls will never get inactivated. It is the users who will be out of the mitigation controls after 1 year (default mitigation period).
    However, if you are referring to the Active and Inactive controls in the management view under the control library, the Inactive controls are the one which are untouched from a long time. If you mitigate another user, it will be automatically added in the active control list.
    Hope this helps!!
    Regards,
    Raghu

  • Error while uploading mitigation controls

    Dear All,
    While uploading the mitigation controls i am facing with the below error. Can you please help me in resolving this error.
    Error in table dataVIRSA_CC_MITUSER
    SQL:=>Insert into  VIRSA_CC_MITMON(MITREFNO,MONITORID) Values(?,?)
    Record::Line Number :21 : D VIRSA_CC_MITMON TESTC1 TEST1
    Below is the text file which i am uploading into the RAR for test purposes
    M     VIRSA_CC_ADMIN     USERID     NAME     EMAILID     ROLEID               
    D     VIRSA_CC_ADMIN     TEST1     TEST1     test     M          
    M     VIRSA_CC_BUSUNIT     BUSID                              
    D     VIRSA_CC_BUSUNIT     TH                              
    M     VIRSA_CC_BUSUNITT     BUSID     LANG     DESCN                    
    D     VIRSA_CC_BUSUNITT     TH     EN     Thailand                    
    M     VIRSA_CC_BUAPPVR     BUSID     APPROVERID                    
    D     VIRSA_CC_BUAPPVR     TH     TEST1                         
    M     VIRSA_CC_BUMONITOR     BUSID     MONITORID                         
    D     VIRSA_CC_BUMONITOR     TH     TEST1                         
    M     VIRSA_CC_MITREF     MITREFNO     BUSID     APPROVERID               
    D     VIRSA_CC_MITREF     TESTC1     TH     TEST1                    
    M     VIRSA_CC_MITREFT     MITREFNO     LANG     DESCN                    
    D     VIRSA_CC_MITREFT     TESTC1     EN     Test mitigation control               
    M     VIRSA_CC_MITRISK     MITREFNO     RISKID                         
    D     VIRSA_CC_MITRISK     TESTC1     F006*                         
    M     VIRSA_CC_MITMON     MITREFNO     MONITORID                         
    D     VIRSA_CC_MITMON     TESTC1     TEST1                         
    M     VIRSA_CC_MITRPT     MITREFNO     ACTIONS     VSYSKEY     MONITORID     FREQUENCY          
    M     VIRSA_CC_MITUSER     MITREFNO     RISKID     USERID     VALIDFROM     VALIDTO     MONITORID     STATUS
    M     VIRSA_CC_MITROLE     MITREFNO     RISKID     ROLEID     VALIDFROM     VALIDTO     MONITORID     STATUS
    D     VIRSA_CC_MITROLE     TESTC1     F006*     Z1.*.ASST-SC-FINC-MGR     6/9/2010     7/25/2010     TEST1     0     
    M     VIRSA_CC_MITHROBJ     MITREFNO     RISKID     HROBJ     HROBJTYP     VALIDFROM     VALIDTO     MONITORID     STATUS
    M     VIRSA_CC_MITPROF     MITREFNO     RISKID     PROFILE     VALIDFROM     VALIDTO     MONITORID     STATUS
    M     VIRSA_CC_MITUSRORG     MITREFNO     RISKID     USERID     ORGRULEID     VALIDFROM     VALIDTO     MONITORID     STATUS
    M     VIRSA_CC_DETDESC     OBJECT_TYPE     OBJECT_ID     LANG     DETAIL_DESCN     
    D     VIRSA_CC_DETDESC     MIT     TESTC1     EN     Test Mitigation control                    
    We are not mitigating users now. Only roles are getting mitigated and hence we have not provided any values to the MIT USER table.
    Thanks and Best Regard,
    Srihari.K

    Dear Varun,
    Thanks for your reply. It helped me a lot. But however i am facing the following issue while uploading the mitigation controls
    After exporting the mitigation file from RAR, we opened the text file in a spreadsheet format and added few lines to the file and saved in the same text format or in UTF-8 format also
    After uploading the same into RAR again after changes we are facing similar errors mentioned in above query.
    But when we add lines  directly in the wordpad and upload the file then it is successful.
    We have to add so many mitigation controls and roles to be assigned for which excel would be easy way to dump.
    Is there anything wrong we  are doing here in editing and converting the files.
    Thanks and Best Regards,
    Srihari.K

  • 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.

  • 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

  • Workaround for non-SAP mitigating control reminders

    Dear all,
    Our business users would like to document mitigating controls in RAR 5.3 regardless of whether they are connected with an SAP report. They would also like to receive email reminders for those controls.
    Unfortunately, the frequency of the control can only be defined per connected SAP report and reminders will only be sent for controls if the SAP report has not been executed.
    Have you been exposed with a similar requirement? It seems like a natural thing to ask from a business perspective. RAR 5.3, however, is not designed in that way.
    Have you come up with any feasible workarounds for this?
    My current approach would be to create a dummy Z-report per SAP system (such as Z_MANUAL_MITCTRL) that control monitors have to call once to confirm the execution of their control.
    Cheers and best regards
    Patrick

    Hello,
    Regarding your question, in fact this is dependant on how your UME (User Management Engine) is configured on your WAS (Web Application Server). If the UME is connected to your R/3 back-end then the user need to have a R/3 account to connect to CC, otherwise if your UME is "independant" then you just need to create an account in the UME.
    Regards,
    Jérôme.

  • Bringing mitigating controls from PC to AC in GRC 10.0

    Hi ,
    I am going through remediation process in GRC 10.0, However there are no mitigation controls setup in AC.
    my client is asking me to copy all the mitigating controls from PC to AC.
    Is this possible ? if yes, What will be the process ?
    Thank you.

    Hi Sri,
    you can achieve by downloading and uploading the mitigations.
    Go to SE38 and use the following program GRAC_DOWNLOAD_MIT_ASSIGNMENTS to download the file and make necessary changes to it and upload the file by using the following program GRAC_UPLOAD_MIT_ASSIGNMENTS.
    and put the active column in the file as X.
    Regards,
    Venugopal Ireni

  • Mass maintenance of Mitigation controls in GRC 10.0

    Dear All,
    How to do mass maintenance of mitigation in ARA of GRC 10.0. We successfully migrated the mitigation controls from 5.3 to 10.0. I need to change the monitors for many user conflicts and also add new user conflict mitigation controls. Is it possible to do a mass changes in GRC 10.0 as there is no upload functionality for mitigation controls
    Thanks and Best Regards,
    Srihari.K

    Hi Sri,
    you can achieve by downloading and uploading the mitigations.
    Go to SE38 and use the following program GRAC_DOWNLOAD_MIT_ASSIGNMENTS to download the file and make necessary changes to it and upload the file by using the following program GRAC_UPLOAD_MIT_ASSIGNMENTS.
    and put the active column in the file as X.
    Regards,
    Venugopal Ireni

Maybe you are looking for