An effective and mature governance, risk and compliance (GRC) program has proper business requirements and the right blend of automation and technology support. Unfortunately, many organizations struggle to implement the proper technology due to the incomplete or inaccurate functional and technical design of their GRC technical requirements.
To increase the maturity of SAP GRC Access Risk Analysis (ARA) reporting, there are 5 areas that can help one build a solid technical GRC ARA foundation. These quick wins require only a light touch with the business and can be analyzed and fixed in the background. Such activities help eliminate any pain points an organization might be experiencing regarding incomplete or inaccurate access violation reporting.
To start analyzing GRC ARA master data, one should download their GRC ruleset technical tables using their normal table browser transaction codes. Tables extracted should include the Ruleset Description, Function Description, Function Action and Function Permission tables. Once the tables have been downloaded, the following 5 actions can be taken to identify and fix any gaps:
- Remove inconsistent technical configuration between GRC ARA technical tables—GRC ARA master data tables (e.g., the Function Action and Function Permission tables) are not always synchronized with one another. For example, transaction codes may be listed as active in one table but not active in another. For consistency in reporting, all active transaction codes should be active across all GRC ARA master data.
- Enhance the use of the “wildcard” (i.e., the asterisk symbol) and condition operators (AND, OR and NOT)—The usage of condition operators (e.g., “all” and “any” as well as the “AND,” “OR” and “NOT”) should be carefully designed. Wildcard “all” should be placed between parenthesis only when looking for users who are able to specifically execute all activities for a certain authorization object. In addition, when uploading a ruleset, the operator value should technically be “OR” across the ruleset, unless one is specifically looking to return users with the ability to perform all configured activities for a specific permission.
- Add SAP Standard profiles and custom sensitive profiles—GRC ARA allows management to monitor sensitive privilege profiles across the different target systems. That said, many GRC ARA users do not configure the master data tables to allow for such reporting. Standard profiles such as SAP_ALL and SAP_NEW should be configured for management reporting and monitoring.
- Eliminate redundant functions configured within one ruleset—In many cases, I see that the ruleset is configured with multiple IT and business process functions that addresses the same risk. This redundant monitoring process results in a ruleset with more than 200 risk sources that management is maintaining. This ultimately will result in an inaccurate configuration of technical details due to the multiple places where updates need to be maintained manually (i.e., GRC administrators should consider adding a new custom transaction code for different redundant functions).
- Introduce targeted access risk to cover new technologies—Many clients undergoing major transformations neglect to alter their rulesets to monitor the new technologies. Whether using the SAP-delivered ruleset or custom rulesets, the GRC access ruleset needs to be updated to monitor the critical access risk against the SAP landscape’s different technologies (e.g., SAP HANA, SLT, Ariba and SuccessFactors).
If a GRC ARA system is not optimized, the effectiveness of the GRC program diminishes quickly; the GRC system will report false positives (i.e., users reported without access) or false negatives (i.e., users with access but not reported).
Mostafa Elghazaly, CISA, CRISC, CISM, CGEIT, CDPSE is the founder of Signify Solution LLC and the creator of the improve framework, the first Agile framework for risk management functions to help compliance leaders transform to agile. He can be reached via email at mostafa@signifysolution.com and on LinkedIn.