Technical Articles
SAP GRC 10.0/10.1/12.0 – Mitigation Policy Configuration for Access Requests
Introduction
Request Mitigation Policy is basically a set of rules which can be used to control the GRC request approval behavior when there are risk violations in the request based on “Risk Type”, “Risk Level” of the violations reported in the access request. Additional request parameters can also be included while customizing the Mitigation Policy Rules.
SAP delivers a predefined BRF+ Application and BRF+ rule mapping that decides the Risk Mitigation policy for GRC. You can either delete this mapping or change the BRF mapping as per your requirement to enforce the approver to mitigate the risk in a request.
Requirement
Usually customers will have requirement to mitigate only specific type of risks after running risk analysis at Stage Level. We have a requirement where our customer wants SoD risks (High, Medium and Low) to be mitigated and Critical Action (High, Medium and Low), Critical Permission Risks (High, Medium and Low) not required to be mitigated.
Solution
The MSMP Workflow Stage Task Setting Configuration Parameter is tied to a BRF+ Configuration
The configuration is available through the below mentioned path.
SPRO =>Governance, Risk and Compliance =>Access Control =>Maintain AC Applications and BRFPlus Function Mapping and check the mapping for application “Request Mitigation Policy”.
Under the Application Mapping, there is the Application ID: ‘Request Mitigation Policy’. The BRF Function for this App ID is maintained by default. The BRF+ rule is created to identify which risk requires mitigation and which risk does not require. If there is no BRF+ Rule created for Mitigation Policy, then please remove the entry from IMG.
If the “Request Mitigation Policy” entry is deleted from Maintain AC Applications and BRFPlus Function Mapping then GRC will not allow approvers to approve the request until all risks are mitigated.
Hence we have customized Request Mitigation Policy rule according to our requirement. Following are the steps:
Configuration Setting 1
Stage Level setting “Approver Despite Risk” is set to “No”
Configuration Setting 2
Parameter 1072 – Mitigation of critical risk required before approving the request is set as “NO”. Even if it set as “YES” mitigation policy will overwrite these settings based on mitigation policy rules configured in BRF+
Configuration Setting 3
SPRO =>Governance, Risk and Compliance =>Access Control =>Maintain AC Applications and BRFPlus Function Mapping and check the mapping for application “Request Mitigation Policy”.
Request Mitigation Policy is maintained and associated with MSMP Process ID “SAP_GRAC_ACCESS_REQUEST”
Open BRF+ in “Expert Mode” and if you are not in Expert mode use “Personalize” button to open in Expert Mode as shown below:
BRF+ Mitigation Policy application provided by SAP is “GRAC_BRFP_MIT_POLICY”.
Open the Function of the Mitigation Policy BRF+ application and create a top expression as “Decision Table”. This decision table is the place where you define your Mitigation Policy rules.
Verify your Decision Table entries, Save and Activate the Decision Table.
Save and activate Function and Application and once completed use Function Simulation to verify the results.
After this we have created a GRC request with SoD and Critical Action risk violations and approver was prompted to mitigated only SoD risks and after mitigating SoD risks requested can be approved without mitigating Critical Action Risk Violations.
Request has SoD risk violations which are not mitigated as shown below:
Request has Critical Action risk violations which are unmitigated as shown below:
When approver tried to approve the request GRC stopped the approval with the error message as shown below:
Approver Mitigated the SoD risk violations in the request.
After mitigating the SoD risk violations approver is able to approve the request without mitigating Critical Action risk violations
Critical Action risk violations are not mitigated and approver can approve the request
Mitigation Policy can be customized as per your requirements by creating different rules in the Mitigation Policy BRF+ application.
References
2212543 – How to enforce mitigation of only a specific type of Risk ID
1614290 – Risk Analysis Mandatory for Access Request
Thanks for reading.
Looking forward for your valuable inputs in updating/improving the blog with all relevant details 🙂
Best Regards,
Madhu Babu Sai
Hi Madhu,
Excellent.. Thanks for sharing.
Regards,
Manju
Hello Madhu,
Great Work as Always....
Thanks for Sharing
When I am searching for the application GRAC_BRFP_MIT_POLICY I am getting the message No Application Found. Can you help me with this please?
Regards,
Rakesh Ram M
The Best!!!
Hello Madhu,
Thank you for the article. It's a pity, but just yesterday I played with Mit.Pol and before I hadn't seen your post. Let me share a bit of my experience, perhaps you will include it into your article.
When I followed to note 2212543, I faced with the error "Not a valid BRF plus ID". In accordance with the note 1637515 you should copy it from 000 client. This note, by a some, reason is a hardly-find note on SMP, but it really helpful. However, maybe it's valid only for my version of GRC - 10 SP22. BTW, what is your version you customized on?
I tried to configure obligatory mitigating of any kind of risks, unfortunately, the only solution that works is to remove the string with Mit.Pol. Initially I configured the rule 80E0ED08B0561DEFA4FCEAD405569CF3 and assigned it to SAP_GRAC_ACCESS_REQUEST process. It seemed that my system ignored rule at all.
Regards,
Artem
Hello Madhu,
Thank You for the article, it is really helpful.
What is the backed table which stores SOD risks in particular GRC request.
The table which shows Risk Ids involved in a GRC request.
Thank you
Hello Madhu!
Thank you for the great article!
This new APP/FUNCTION for policy (GRAC_BRFP_MIT_POLICY) has a different result from the old one (named as MITIGATE_RISK).
The old result, named OUTPUT, of the function MIT_POLICY_FUNC (ID: 80E0ED08B0561DDFA2B0452122FC44BE), of the old app GRAC_MIT_POLICY_APP (ID: 80E0ED08B0561DDFA2B039A0AB0903E8), was a Boolean element (True or False value, which can be interpreted on values 1 or 0 and not 1 or 2, as the result of data element MITIGATE_RISK on the new app/function).
Also, the old data element result has "no binding" with standard DDIC elements. The new data element result is binding to DDIC data element GRAC_BRFP_MIT_POLICY.
So, there is quite some differences between the new BRF+ app and the old BRF+ app. I am writing this because I do not understand why you are using "Functional and Event Mode" instead of just "Functional Mode". And I am wondering if this new app evaluates the policy for EACH risk line on request SoD analysis report (one-by-one).
If it would be the case, can I use the table ROLE_ATTRIBUTES to build a Loop for each line on that table and check if the roles listed are involved on the risk reported, and if the roles involved on the risk were a requested role the result would be YES, otherwise NO?
That would be helpful with my demand to only mitigate "NEW" risks on the Access Request - the risks which has "orange lines". My environment has lots of "legacy" risks which will be treated with SoD review on a "clean up project", but the client wants to speed up the approval process but without "adding" more risks to users, making mitigation mandatory only for the "NEW' risks.
As I learn here in your document, the standard app has no pre-inserted structure with the roles listed on the risk report, so I will probably need to use a Procedure Call to get the full risk report, am I right?
Regards!