Do not pass go without a risk analysis! Mission Possible?

[Former Member]

We all have high expectations to reduce risks in our SAP environments.  The objective which we chose to take was to get clean and stay clean.  Management has further decided to track our every move from the risk analysis dashboards.  Oh, Big Brother! Are violations going up or down?  With this kind of visibility, you want to address risks prior to provisioning access.  But how do you do this when the GRC Access Control 10 application forces you to choose one default risk? What if you have rules for critical authorizations in addition to segregation of duties?  How can you be sure that the default risk type is not removed?

These are all questions that we ask ourselves as we perform a detailed analysis of our violations. We identify additional unmitigated risks that are being introduced into our GRC control environment.  We spent weeks identifying the root causes of these newly introduced risk violations.  Since our task is to get clean and stay clean, what could we do to prevent these new violations?  Prior to recent changes, the GRC 10 application only allowed a single default risk type through configuration.  The application provided flexibility to choose one of the five risk analysis options as a default, but by only having a single default parameter you may allow unmitigated risks to be introduced into your environment.  If you were proactive, you may be able to mitigate some risks prior to them being included in the management dashboard.  But is our job to perform multiple manual processes to reduce risk?  I believe there are more important tasks than to constantly monitor new violations manually.  Isn’t that what the application is for? Yes!

With recent influence activities you now have more flexibility.  If you wanted to select all five risk analysis types as defaults on an access request you could.  However, choosing all of the risk types introduces a second issue of false positives.  These are issues when a user technically has access to a transaction (Action) but does not have the required authorization object values to create the risk.  I personally would not recommend selecting all risk types but rather select those appropriate to your environment which will force mitigation of risks prior to provisioning.  The five risk types on a standard GRC Access Request are as follows:

This new option is available in SAP Note 1776542 (UAM: Multiple values for default report type not possible).  If you are on GRC support package 10 or less, you can manually implement this note.  The solution is currently scheduled to be included in GRC support package 11.  Without applying the note and performing the manual steps, you can only select one default risk type for GRC configuration parameter 1023.  After the note is implemented you have flexibility that was not previously available through configuration.  You could have provided this through careful custom coding but the ability to apply notes within a complex environment would create new support issues.  After applying the note you are allowed multiple parameter 1023 entries in the GRC configuration.

With this note our mission is almost complete.  Our next agenda item is to prevent the user from unchecking the default risk types within the request.