Business Scenario

In one of the GRC projects I have worked for, the client's requirement is to send the User Access Review Workflow to User for review at First Stage and then to Manager for review. Since there is no standard User agent provided by SAP we developed a custom user agent by making use of BRF+ functionality


BRF+ Agent Design


As per User Access Review process, first UAR request generation job is scheduled which will generate the requests and then UAR Workflow update job is scheduled which will push all UAR requests into workflow and then they go to corresponding workflow path and stages


Since "User Agent" is requested by the client, now "User" also becomes one of the GRC Approvers and hence "User" should exist in Target system and GRC System as well


Once the requests are generated by "UAR Request Generation" job, these requests will be stored in GRC table "GRACREVITEM - Review Request Related Items"


In our UAR User Agent design we used DBLOOKUP functionality to the table GRACREVITEM to get the result as UserID based on the UAR Request ID.


NOTE: This Agent design works for UAR workflows having MANAGER as REVIEWER


BRF+ Agent Configuration

You have to generate the BRF Rule via Transaction SPRO in GRC system. Follow the below steps in your GRC system.

Run the transaction SPRO, Go to IMG => Governance, Risk and Compliance =>Access Control =>Workflow for Access Control  => Define Workflow related MSMP rules.


Directly execute Tcode GRFNMW_DEV_RULES

  • Fill generation criteria (Process ID, Rule type, etc.)
  • Specify Generation options
  • Generate rule shell (Execute button)


Click Execute or Press F8. This now generates a successful message for BRFPlus Rule with name and ID. You can run BRF+ Tcode and can check the newly created BRF+ application there.



Functions Signature Update

In BRF+ function, change the mode to “Event Mode” and activate the function as shown below.

  • Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
  • In “Signature” tab of BRF Function, change the result data object to GRFN_MW_T_AGENT_ID


Create Ruleset in BRF+ Application

Create Ruleset in your BRF+ application by clicking on “Create Ruleset” button under “ASSIGNED RULESETS” tab of function. Ruleset is a combination of business rules that can only be assigned to a function in the BRFPlus framework.

Create Rule within Ruleset - Create Expression of Type “Loop”

  1. Click on “Insert Rule” button to create new rule
  2. From within rule, click on “Add” -> “Process Expression” -> “Create” to create a new expression
  3. Create expression of type “Loop” and provide suitable name and description.
  4. Loop gets created as shown below. Processing Mode and Loop Mode maintain as mentioned below.


Create Rules within Loop Expression

First Rule

a. Request ID field which we use in this particular agent rule is sent with prefix as "ACCREQ/REQ_ID". Before doing DBLOOKUP the prefix has to be removed and only "REQ_ID" should be sent to DBLOOKUP. To achieve this, I used "FORMULA" expression with SUBSTRING function.


b. Once the Request ID field is trimmed, then this Request ID field is used in DBLOOKUP and gets the UserID. The second rule is to create DBLOOKUP for tables GRACREVITEM



C. Each LineItem in BRF+ need to be assigned to context parameter ITEMNUM as we didn't initialize the LineItem key.


Second Rule

Second rule is used to assign value to context as shown below. This rule will be included in your loop for inserting the values into Agent ID table after processing each LineItem.


Finally Loop expression will have all required rules as shown below.



Once above rules creation is done, activate your expressions REMOVE STRING, DBLOOKUP, LOOP, FUNCTION and then check by simulating your function by adding Line Items rows and enter any Request_ID from table GRACREVITEM and check if your agent is returning correct results.


After verification this BRF+ agent can be used in MSMP UAR workflow and your UAR requests can be routed to User's for Approval/Notifications

Looking forward for all your feedback


Thanks for reading.


Best Regards,

Madhu Babu Sai

Sandeep Poojary

Being GRC Expert

Posted by Sandeep Poojary Apr 22, 2015

Hello Friends--

For past so many years i have been taking GRC interviews and  some important aspect i would like to share for all those who are willing to pursue the career in GRC --

There are 2 aspects to look into this :

On the Functional Point of view :

1 - Firstly understand why an Organisation needs SAP GRC, and what are the benefits of implementing the complete Kit.
2 - Understand the various compliance structure around the Globe and how they are mapped to the organisations internal process.
3- Design a Standard Roadmap for various sectors of the Industry and align it to the organizational need.

On the Technical Point :

1 - Those who are from SAP Security background, who understand SAP Authorizations, believe me, GRC will be a smooth ride, you just need to understand what are the different functionality in SAP GRC and need to know when and how to use this functionality.-- Technically its a cake walk.

2 - Those with Support experience of SAP GRC - In your job, the work is restricted to certain tabs of GRC, but with the help of social media you can explore lot of learning. Utilise your time in understanding various functionality, learn the subject well, when you get an opportunity learn in the demo servers, Implementation is not the only means of having expertise in GRC, its ones commitment and learning skills which will help in understanding the concepts.

3 - Those who want to learn SAP GRC - Please go through the GRC training material, and seek help in the social media, i am sure our fellow colleagues will come forward and help in training.

Whenever you prepare for an interview, make sure you have known the subject well, even without experience, what the recruiters will look for is how good are you with the concepts and how well you can explain those functionalities. It clicksss..

And yes, i am waiting for all those who are willing to be an GRC expert to work along

All the Best--


Sandeep Poojary


In GRC Access control as part of Workflow approvals and reviews Managers, Role Owners, FF ID Owners and Controllers, Function/Risk/Mitigation Approvers, Monitors, Users, Requestors etc. receive various Email notifications. Based on the client’s requirements these Email notifications are enhanced and maintained. This blog is to discuss about various customizing options available for GRC notifications as well as notification variables and their limitations and scope

For beginners below document gives details on how to customize email notifications templates in GRC

AC 10.0 - How to Customize Notification Templates for AC Workflow

Email Notification Templates - HTML Tags

1. HREF (For Email ID and URLs)

Business Scenario:

Notification variables which gets converted to URLs in the notification emails will have a very big URL with Path ID, Stage ID etc. Basically when the URL is not maintained as HREF using HTML tags, in most of the cases Emails get routed to JUNK folder in mailbox because of various special characters in the URL. Hence it is suggested to use HREF tag and make these GRC URLs as links which will avoid routing to JUNK folder issue as well as avoids end users directly seeing all technical details of the URL. Below are some of the variables which gets converted to URLs in notification Emails.

LINK_APPROVE_REJECT    Link to Approve/Reject by Email

LINK_GET_APPROVERS    Link to get Approvers

LINK_GET_REQ_STATUS    Link to get Request Status

Example: How the above variables look in notification emails with and without HTML tags



b. Click <A HREF = %LINK_APPROVE_REJECT% > here </A> to approve/reject the request



2. To Include GRC Help-desk Email


Business Scenario:

When end users receive email notifications for GRC related requests then most of the times we observed that users will have queries with the Emails or about their GRC requests and wanted to contact concerned GRC Admin/Help-desk for clarifications. In order to make it easy for end users to contact HELP-DESK, we can include Email ID in notification emails.

Example: How to include Email link in notifications

Please contact GRC Admin at <A href=""> GRC Helpdesk </A>



Reason behind sharing details about BOLD, UNDERLINE and ITALICIZE tags is because these doesn't work with traditional HTML tags like <B> <U> and <I> in notification templates.

Example: <strong> <span style="text-decoration: underline;"> Quick Reference for approvers: </span> </strong>



<span style="font-style: italic;">

Select the approval status as "REJECT" beside the role that you wish to reject.



How to insert Company Logo in Email Notification Templates

First you need to store the Logo which you want to use in Email notifications in GRC MIME repository

Go to SE80 Tcode and click on MIME REPOSITORY. Import the Logo which you wanted to use into MIME objects repository as shown below:



Mime 2.png


Mime 3.png


Once the above activities are completed, the next step is to use the LOGO in Email notification Templates.


Note: URL for logo is no transportable and need to be individually changed in each system when notification template is transported.


Use the image source tag as shown below:


<img src = "http://my_server.my_domain/sap/public/bc/ur/MyLogo.png">


Example: <img src = "http://myserver_mydomain/sap/public/bc/ur/MyLogo.png">



How to create New Message Class for Notification Templates

How to create new Message Class for any workflow in GRC ?


Very common requirement is customers request to have specific Email notifications at each stage individually and for such scenarios it might require creation of Custom message classes to be used at various stages in workflow and you can follow below process for creating new message classes


Example: For EAM Log Review Workflow there are no FORWARD and RETURN Message Class available.


Execute Tcode SM30


Open table GRFNVNOTIFYMSG and click on Maintain button and then click on "NEW ENTRIES" and maintain as below and once done click on SAVE button



Execute Tcode SM30


Open table GRFNVNOTIFYMSGC and click on Maintain button and then click on "NEW ENTRIES" and maintain as below and once done click on SAVE button



Once the above mentioned activities are completed, now the newly created Message Class can be added to your MSMP Variables & Templates Notification Templates section as shown below



Notification Variables in GRC

Each workflow process comes with a number of notification variables that are available to all notification templates that belong to it. They are displayed on the bottom of the screen in step 4, ”Variables & Templates”, in the customizing activity Maintain MSMP Workflows.

Few queries regarding Notification Variables customization especially %PROVISIONING% and %PROVISIONING_WITHOUT_PASSWORD%

For ARQ provisioning there are 2 variables which are sent along with END OF REQUEST notification( with Roles and Password details) PROVISIONING and PROVISIONING_WITHOUT_PASSWORD


These variables are standard variables which are calculated run-time.. if you are not happy with the formatting, please raise a CSS message and let SAP developer fix that for you.. there is no customizing available for it..


Other option can be to have your own custom variable created, but again that require development


2012041 - Is it possible to suppress the role details in the variable %PROVISIONING%

1854408 - Potential information disclosure relating to user password

How to create custom notification variables in GRC

In the MSMP configuration, Select the process ID and goto Step 4 Variables & Templates kindly add a Z variable.


Now in the backend GRC system goto transaction SE37 and enter the function module GRAC_NOTIF_VAR_RULE_AR. and copy this function module and

create a custom Z Function Module and add the logic for the Z variable in the function module.


Once done activate the Function Module


Open the MSMP configuration and goto Step 2. Maintain Rules. Add this newly create Z function module as a Notification Variables Rule. Also maintain this Z Function Module in the Notification Rule under Global Rules in Step 2.


Save and Activate the MSMP workflow configuration.


Now you can use the custom Z variable in the document objects.

How to modify URL shown in GRC notification variables to enable SSO

First setup Single Sing On (SSO) between Enterprise Portal and GRC system.

Once done, create a Portal iView in Content Adminstration -> Portal Content Management using standard GRC Access Control iView Template.

In the template, Application Name, Configuration Name, System, Location etc fields are maintained and once the template is maintained then PERMISSIONS need to be maintained for iView.

Once the above steps for creation of portal iview are completed, modify the URL used in the notification variables by creating a Custom Notification Variable Function module and replace the URL with Portal iView which you can work with ABAPer and Portal guys to get the details.

Once all above steps are done even the approvers can access all Approval Links in Email notifications via SSO without entering UserID and Password

Note:Deactivate password for all users in GRC System including approvers UserIDs

Looking forward for all your inputs in improving this blog with all other additional details



Thanks for reading.



Best Regards,

Madhu Babu Sai



As a foreword I would like to use popular Rolling Stones’ song adopted to the topic of the article.

When I'm customizin' my GRC

And that support comes in the message

It's tellin' me more and more

About some useless information

Supposed to fire my imagination

I can't get no, oh no, no, no

Hey hey hey, that's what I say


Here on SCN and on SAP promo materials everybody can read about the powerful tool – BRF+ and very flexible workflow of the new GRC. So, I will not be arguing with those promises, but I would like to share my experience. Now we are reimplementing GRC, we just try to make the same settings in GRC 10 that we have in GRC 5.3. During the reimplementation we have faced with the non-resolving issues and I hope that this article “fire your imagination”.

The first issue

Really we don’t have so many issue, but they stuck our project. The first thing is CUA setting. I don’t know for what purpose SAP made “Maintain CUA Settings” in SPRO. In fact, it doesn’t work. Why have I decided so?

I have CUA with 3 systems (SSDCLNT001 – CUA central system, SSDCLNT200 – CUA managed system, GRDCLNT200 – CUA managed system), it configured in (I call it) Mix mode. Mix means that we use many parameters (such as name, user type, format…) set as global, and the others (such as roles, profiles, user parameters…) set as local.

We were surprised when had known that this configuration is not supported by the new GRC.

Quote from the message

Hi Artem,

I had discussions with our architect and other technical experts on

this. Currently it is not possible to consider the mixed settings and

hence would request you to maintain them as globally in the SCUM

settings in order to resolve your issue.

Of course, during the correspondence, we tried to use “Maintain CUA Settings”, but I was advised to not use it at all. Even if use global or local settings. Here is the question for experts: what is the purpose of this setting?! More over if I set here CUA-manager system and CUA-managed system and not activate “CUA Global System”, I get the dump: OBJECTS_OBJREF_NOT_ASSIGNED_NO CX_SY_REF_IS_INITIAL CL_WDR_INTERNAL_WINDOW========CP

The second issue

BRF+ is really great thing and MSMP too! But… it is not flexible for logically standard scenario. When we started to implement new GRC I see that systems go as independent items in the request and should be approved as roles. Finally, systems go not just as an attribute of the request (like it was in 5.3), but they have owners. However, to customize simple workflow is not possible:

1st stage - Manager selects systems and roles.

2nd stage – Systems should be approved/rejected by the owners.

3rd stage – Roles should be approved/rejected by the owners, and the roles assigned to the rejected systems should be rejected automatically.

Doesn’t it seem logically simple?

In fact, it’s not possible using the standard tools to realize this scenario. You may say: Use ABAP. But for what we need ‘flexible’ BRF and MSMP then?

I should thank Madhu Babu for his helpful blog

He does a great work, and I see that he is one the most active contributor on scn! Unfortunately, the above configuration doesn’t resolve the issue. Imagine that you are a role owner, you get a request with, say, 20 roles. You analyse them, wright some comment, in common, waste your time to process the roles. In parallel, some system owner doesn’t think that the user of the request must have the access to the system and reject system assignment. In the result, user will not get the access to the system and the roles (for which you and the other owners have wasted the time!).

I should also thank Marina Volynets, because she tried to help me find out that the issue cannot be resolved with the standard tools.

Need an idea to resolve split procedure

The third issue

BRF+ in its decision table must have approvers for each item in the request, otherwise we get “No agent found” on the workflow level. There no option in MSMP to send all line items without approvers to the next stage. Previously (in 5.3), all orphaned roles go to the next stage. Yes, it might be a breach in the security area, but why 10.x doesn’t have an option (check box, for example) to pass forward orphaned items?


From my point of view, we get a new GRC that is neither better nor worse than the previous. They are the same with slight differences.

I hope that my article will raise a wave of indignation and experts provide their view on the issues. Maybe someone points me that I'm wrong or points me on the idea place… If someone has issues to add to the article, you are welcome!


Best regards,


Hi Team


During GRC Access Control Implementation ,the most of the concerns of the business is towards the access risks present in the landscape and how is it addressable from GRC AC perspective. I have tried to cover all aspects of the implementation of ARQ Workflow .As the per the business we had some requirements which i guess many of our colleagues will have during Access Request Workflow Implementation.



1) Risk analysis should happen automatically on access request submission

2) Role Owner should approve all the assignment of roles to user and in case of SOD voilations it request should route to SOD Owner stage

3) SOD owner should address all the SOD access risks and mitigate it and finally approve the request.The request should not be approved without mitigating SOD risks.They need HARD STOP on approval.

4) For access removal there should not be any approval but the request needs to be validated by Security Admin before its implementation.



For requirement 1, We need to enable to below parameter in SPRO in GRC system.

SPRO->Governance Risk and Compliance->Access Control->Maintain Configuration Parameters


Risk   Analysis - Access request1071YESEnable risk analysis on form   submission
Risk Analysis10232(Permission level)Default report type for risk analysis

For requirement 2 ,the Workflow(Account Creation/modification) needs to be created in MSMP with stage approval on GRAC_ROLEOWNER stage with routing rule enabled for rule id  GRAC_MSMP_DETOUR_SODVIOL and therafter maintain route mapping


For requirement 3,We need to enable to below parameter in SPRO in GRC system.

SPRO->Governance Risk and Compliance->Access Control->Maintain Configuration Parameters


Risk   Analysis - Access request1073YESEnable SoD violations detour on   risks from existing roles

Now,maintain the SOD routing in MSMP


For requirement 4

Create a Delete Request Path in MSMP with any stage for Security Admin(Agent id: GRAC_Security) so that when user or his/her manager raises delete request it gets validated by security admin and after validation security admin should submit the access request for it.


The Delete request will lock the user in backend(System  can be chosen by requestor) and also it can set the validity dates. For roles removal, Requestor needs to select all the roles by clicking on existing assignment and chose remove actionfor the Roles.


The actions to be maintained for Delete Request-

1) Change and Lock user

2) Remove


Issues: 1) SOD owner was able to mitigate the SOD access risks and approve the request but also SOD Owner was able to approve the request without mitigating the Risk.The HARD BLOCK is not working.


Go to below path

Governance, Risk and Compliance > Access Control > Maintain AC Applications and BRFplus Function Mapping. Within the transaction SPRO follow the path “Governance, Risk and Compliance” > “Access Control” > “Maintain AC Applications and BRFplus Function Mapping” and click the execute button.

Request Mitigation Policy application id is deleted from the screen to enable hard stop of approval of access request form in SOD owner stage with SOD access risks.


Issue 2: Access Request in Editable mode for Approver i.e.Approver has an option to deselect the risk analysis in Permission level and approve the request.This may dilute the Requirment 1.


The Webdynpro GRAC_OIF_REQUEST_APPROVAL  needs to customized to change the risk analysis in Read only mode for the approver.

In SE80, open the web dynpro in test-admin mode and copy the link which was opened and added the HIGHLIGHTED string to it. The REQ ID can be fetched from GRACREQ table


After hitting the above link, the request will open in customize mode and then we can go to go risk violations tab and right click on Permission level level and go to settings configuration and make the tabs in Read only mode and save it.


I hope the document will help everyone here.

Appreciate your feedback.


Best Regards


It may be difficult to believe that 2015 is flying by so quickly, but planning is already underway for SAP TechEd 2015 in Las Vegas.

SAP TechEd logo.png

The design team for the ASUG education sessions this year is Tammy Powlas, ASUG volunteer Kristen Dennis, and myself, along with our SAP Point of Contact Peter McNulty. Tammy posted a very informative blog in the Business Intelligence space to entice BI people to start thinking about presenting.,Plan Now for Call for ASUG Speakers for SAP TechEd Las Vegas . I am not going to repeat everything she already said so well, but I do want to encourage you to review her post and to consider presenting.


You might be thinking, I don't see a GRC track at TechEd, and if you are thinking that, you are right: there is not a track solely dedicated to GRC. However, the Security, Secure Development, and Configuration track covers SAP security products as well as standard features, capabilities and recommendations. In this track we welcome and encourage customers to present on SAP Access Control, SAP Identity Management, SAP Threat Detection, SAP Single Sign-on, security redesign projects, secure development and configuration - really, just about anything related to the security function in your SAP landscape. Lessons learned from implementations and upgrades, tips and tricks, believe me when I say that ASUG's Design Team wants to offer more than just SAP HANA all the time. Certainly, if you have a SAP HANA security success story, we welcome it, too, but think bigger. We have a lot of education slots to fill, and the feedback we have received is that customer presentations are highly desired. So put on your thinking cap now and get ready for the call to open on April 20.


Here is the expected timeline  (Source: SAP):

TechEd Timeline.png

ASUG members who are not customers are also welcome to submit an abstract; just keep in mind that customer presentations are preferred. If you are a consultant who had a successful security or GRC project, perhaps you can persuade one of the customers on the team to present and tell your mutual success story. I hope to see many abstracts submitted on security, IdM, GRC, and other related topics.

From my experience, in many companies country risk is treated separately to risks registered in their Enterprise Risk Management (ERM) framework and reported independently to the Board - most often by using political risk maps.


To me, this is an error as country risk has a direct impact on operational risks and this impact should be materialized so that the correct mitigation strategy can be decided and applied.


First, let me define what I mean by country risk. To me, it is the potential negative events arising from political, economic and societal uncertainty in a given country.

Many equate country risk to political risk but as you can see in my definition, I believe that political risk is only a component of country risk - albeit an important constituent - it does not cover its complete scope.


This concept is very mature within investment companies as it is usually one of the criteria applied when deciding whether to invest in one country or another but I think it applies more widely.


All companies face a country risk, some with a higher level than others but all companies operate at least in one country. So, even if this country is rather “stable” today, this risk should still be recorded, assessed and monitored as situations can evolve sometimes more rapidly than expected.


Direct links with your ERM framework


Consider the following situations:


  • Do you have operations? If yes, then regulatory changes decided by a government can affect you directly and subject you to new regulatory obligations;
  • Do you have production facilities? If yes, in extreme cases, you may be facing unilaterally decided nationalizations;
  • Do you have sales activities? If yes, then these can be significantly impacted by the national economic climate, especially if you are in a B2C business;
  • Do you have employees? If yes, then these can be at risk if there is a sudden outburst of unrest. On a less drastic scale, a change in labour laws can also directly influence your HR organization and even decrease your profitability;
  • Do you invest in innovation? If yes, you may have to agree to technological or knowledge transfer to be able to supply the local market with your products, increasing your competitive risk.


In another post (The Critical Role of Marketing Executives in the Risk Management Process) I had discussed the fact that reputational risk is a direct result from other risks. Well, I believe that country risk is at the opposite side of the spectrum and can be a trigger for many operational risks.


As such, even in low risk profile countries, assessing and regularly reviewing the risk level is part of a sound risk management practice.


How to assess country risk?


There isn't one common agreed measure to assess this risk category but I would like to try to suggest a simple method:


  • Likelihood of occurrence: here would be assessed the combined probability of potential evolution of the political, economic and societal conditions. Some countries have a stable political environment either because it appropriately represents the opinion of the population or because the government secures its re-elections by different means. Nevertheless, this does not mean that societal conditions can’t evolve rapidly, as precisely illustrated during the Arab Spring. Taking into account these three criteria will therefore result in a more truthful probability of occurrence;
  • Impact: here would be documented the potential direct impact of a country risk for your company and its different activities carried out in the country: manufacturing, sales, R&D, etc.;
  • Speed of Onset: here would be assessed the velocity with which the risk can occur. For instance, in countries where political representation effectively embodies public opinion, a change in the political landscape can be rather long compared to personalized regimes where a change in leader can bring a system down rapidly. This is likely to be the most difficult criteria to assess, but publicly available geopolitical analyses can be a good starting point.


Then what?


Here is why I believe political risk maps can’t be used as is by companies as country risks: not all companies will be affected in the same way by changing events. Integrating this risk category in your ERM framework means that you can not only assess a macro-impact at your company level, but that you can also document the influence of this country risks on your objectives and on other risks in the ERM framework: potential effects on your supply chain, manufacturing activities, sales process, etc.


From there, appropriate mitigation strategies for these operational risks can be defined and implemented.


The intent of this post is certainly not to say that all countries are at risk, far from it, but that internal and external influences can lead to a rapid change in the rules of the game for your organization and its activities and that this should be monitored so as to avoid being taken off guard.


What about you, do you monitor country risk?

There are frequent questions why "Custom Field" option is disables when the Details are not saved while creating an Role via BRM application.


  • The Details (First Phase) are becoming mandatory because the Role ID is required to initiated the BADI IF_GRFN_API_CUSTOMFIELD_BADI, then BADI can become active on the Fields that are desired by Custom Fields.


  • Logically the Post Exit method POPULATE_ROLE_ATT in ZFILL_ROLERELAT_CUSTFIELDS is not called when creating a role in BRM application. Because the Role ID is required for the second phase.


  • The functionality flows, first phase the basic attributes of the Role eg Role Name has to be defined and in second phase enhanced attributes would be defined like Owners/Approvers then BADI for Customer Fields is called.

Hi GRC Community


Do you get frustrated by functionality that it lacking? Do you see something in the solution and consider it an incident but are then told it’s by design? Are you creative and love to continually improve this product? Are you stuck in a situation where you have to minimise custom developments for the GRC system? Are you nodding your head in agreement? Are you the type of person who strives for continual improvement? Is that a Yes?


Then time to take a journey to the SAP ideas Place for the GRC Products. This is your opportunity to have your voice heard and get the support of the community. It is a direct connection to the SAP GRC Product Owners – a great opportunity that can be hard to come by.


pic ideas.png

Here’s the Ideas Places for GRC component:

SAP Access Control: Home

SAP Process Control: Home

SAP Risk Management: Home



Create Your Idea

  • You will need to register your account if you have not done so already
  • Assumption you have searched to make sure there is not duplicate idea
  • Make sure you create it under the appropriate category
  • Take your time to provide as much information as possible
    • Did the idea come about from a SCN thread?
    • Did you get requested to raise it in response to being told it’s not an Incident in Marketplace?
    • Do you have screen shots or uploads to better explain your example
  • Let your network know about your idea and get their support



Vote and Comment

But hey, if you’re not an Ideas person then you get still join in. If anything, you are integral to an idea being considered. Vote in Support. Vote in Disagreement (some times the ideas have flaws). Just Vote! Add your feedback in comments.


SAP GRC team will only review ideas that have at least 10 votes.



GRC Product Team Listens and Reviews

The regularly review the Ideas Space and their next review is February 20 2014 – less than 10 days away. They will only review suggestions with more than 10 votes – Ideas cost money to develop. They will not consider ideas without customer support.


GRC Product team will add comments, request further feedback or review the idea in conjunction with their road map. You might find your idea accepted and scheduled for delivery (what an achievement) or you might find the idea is dismissed if it doesn’t fit the product road map. But hey, if it's dismissed at least you'll know why.



Get involved

So dear community, we have an opportunity to provide improvement suggestions to improve GRC. It may not help you today but with a strong voice and support of the community, your idea could be there to help you next time.


There are lot of ideas created in the past two years that are still valid. They have less than 10 votes and aren’t getting considered due to lack of support. Someone may have a proposed a solution to your current challenge but their voice is not loud enough to be heard. Time to shine some light on the ideas and get behind them.



And remember to check back regularly for new ideas!


Vote on! The count down is on!





     I am striking a discussion away from the technical aspects of GRC. The reason being, it is interesting to know how all the technical build-up and maintenance actually helps the organizations. I have a very basic and limited understanding in this area, that I have put across here and would really like to get more information to understand the overall picture.


     From the purpose of SAP GRC, it is clear that it caters to regulatory compliance based on certain legal acts / laws. These are specific to industries and geographies. We usually implement SAP GRC Access Control with majorly separation / segregation of duties in mind. This primarily in turn caters to help comply with certain regulatory laws. For example, the major one we hear of - SOX (Sarbanes-Oxley) Act.


     Now, SOX Act consists of over 50 legal sections. Most of which are not specifically IT related. SAP GRC Access Control's Separation of duties caters to the SOX Act's Section 404, which deals with Internal controls. This requires the management of an organization to have enough internal controls to assess risks and prevent frauds. Similarly, having approval logs, audit logs as part of SAP GRC features caters to the SOX Act's section 802, which deals with altering documents. This requires that no documents is altered in the due course of business in an organization.


     I, having worked specifically on Access Control part of SAP GRC, usually get to only look at the side of the separation of duty policies heavily. I know that Process Control does cater to specific regulatory compliance much more than what Access Control does, that being its purpose.


     So, please share your experiences, regarding how you have used SAP GRC Access Control or Process Control to cater to which regulatory compliance and how.




The Dotcom boom of late 90’s, also saw some major corporate scams like Worldcom, Enron & Adelphi.  Some national headlines in US media (“Data theft at nuclear plant went unnoticed for six months” – June 10 , 2006 New York Times, XYZ Manufacturer violates EU pollution laws” – July 06 2006 CIO Tech Informer “US imposes record $100 Million penalty for export control violations” – March 27, 2007 Washington Post, etc.) would accentuate the changed milieu.  This necessitated a major emphasis on data security & vigorous audits (financial / system audits).  Sarbanes-Oxley (commonly called as SOX) act came into existence.  (The sections of the bill cover responsibilities of a public corporation's board of directors, adds criminal penalties for certain misconduct, and requires the Securities and Exchange Commission to create regulations to define how public corporations are to comply with the law).  There was a growing need of more transparent corporate governance, a well-designed whistle-blower policy framework & detail audit log (of who did what & when).


IT firms took these challenges into cognisance & turned it into opportunity to come up with security solutions, seamlessly integrated with organizations’ ERP softwares. ERP players like SAP acted upon it swiftly & integrated security solutions into SAP under a growing niche product suite called GRC (Governance, Risk & Compliance). SAP’s GRC 10.1 suite handles it through 3 sub-modules of 

Access Control, Process Control & Risk Management.


  • Access Control – It involves managing user roles, who will (& who can) do what in the systems. The principle of Segregation of Duties (SoD) needs be considered while providing access. A simple example of SoD is, never to provide the same user access of creating new vendors as well as issuing/printing cheques. Giving too little access to user hinders work, whereas giving too much access attracts risk, so due care needs to be taken while designing access control. It also involves super user management & emergency access management.
  • Process Control – This involves checks and balances built into the business processes to avoid/minimize occurrences of fraudulent activities. There are three different types of controls need to be designed: Preventive Controls, Detective Controls & Corrective Controls. The other way to look at building a healthy internal control environment is, following below 5 steps.  1. Documentation 2. Testing 3. Remediation 4. Analysis 5. Optimization.  (The details under each will be covered in a separate article)
  • Risk Management – It helps reduce the risk of failing to comply with the regulations for financial reporting, trade regulations, factory act/s & environmental protection. At a very high level, Risk Management involves:  Identify the risks, analyse the risks, identify risk owners & coordinate responses.


Considering the growing need of ERP-agnostic solutions, many IT consulting companies (like Infor Approva, Greenlight Corp etc) came up with GRC solutions which complement the ERP software (like SAP, Oracle, Microsoft Dynamics) or seamlessly integrate with it. 


If we talk of India, the Indian corporate world was shaken by Satyam scam, Reebok India & a recent case in India’s top IT firm. In India, Clause 49 came into existence from 31st Dec 2005, for the improvement of corporate governance of all listed companies. (Which entails - It would be necessary for Chief Executives and Chief Financial Officers to establish and maintain internal controls and implement remediation and risk mitigation towards deficiencies in internal controls, among others)


In short, the question ‘Do-I-need-to-implement-GRC’ is no more relevant. Instead it should be, “What are we going to implement under GRC and when?”

Hello GRC Community-


Every month, GRC Product Support together with our Development team will share with you information proactively to help keep you up to speed on important news. The Newsletter will be uploaded to KBA 2123844 . This is our first edition and would like to hear from you any ideas that you think will help to make the newsletter more valuable. Please contact me directly (email in my profile) and we will work to incorporate your ideas into future editions.


Thank you everyone, hope you find some of this information useful.


Ramelyn Paredes
Director and Global Functional Manager (GRC and EPM)
SAP Active Global Support

Is it 2015 already!?! Wow, how time flies. The SAP governance, risk, and compliance (GRC) team is already off to a fast start for 2015. Given this, I thought I’d use this week’s GRC Tuesday blog to reflect on 2014 as well as look forward into 2015.


2014 New Products

2014 was both a busy and successful year for those of us who watch over GRC here at SAP. I hope the same was true for you and your organization. One measure that I use to rate how busy we’ve been is the number of new products we’ve launched. In 2014, we made five entirely new products available to you, our customers, for use when dealing with a number of specific risk and compliance challenges. I invite you to learn more about each of these solutions:


2014 Awards and Recognitions

I can also measure our success by looking at the awards and other recognition that our solutions have garnered. In the last year, our GRC solutions have been rated and recognized as world-class more than a few times. One example is that Ventana honored us with their Overall Business Technology Innovation Award for our SAP Audit Management and SAP Fraud Management solutions. This award and others like it help you to understand the capabilities we’ve included, as well as just how successful our customers have been through their use.


2014 Customer Successes

But I’m even more proud of the accomplishments that our customers made using our solutions and technologies as a cornerstone of their GRC programs. Our customers’ success is the greatest measure of our own. GRC 20/20 recognized Exxaro, its implementation partner CQS, and SAP with a 2014 GRC Value Award in the domain of Internal Control Management. Exxaro is one of South Africa’s largest mining and materials companies. This award recognizes the efficiency, effectiveness, and agility of Exxaro’s controls program. Read this case study for more information. Way to go Saret and team!


2014 Internal SAP Implementation

A second 2014 GRC Value Award was given by GRC 20/20 to SAP for its implementation of an integrated GRC architecture and use of technology to support and enable a global risk assessed internal control monitoring and assurance program. Yes, of course, we use our own products, but this is not the typical “drink your own champagne” use of one’s own software products. SAP’s own risk, compliance, controls, and policy teams are world-class. These teams impressively support all of SAP’s GRC requirements and this award is proof. In fact, some that know our GRC programs well have indicated that this is the most comprehensive, successful, and global implementation of GRC in the world. Congrats to the SAP’s own GRC team!


And now some predictions for 2015…

Uh oh! They tell me that I’ve run out of time and space here. Tune in next time for my thoughts on the GRC market in 2015 and how SAP will help your organization meet its risk and compliance requirements.



Originally posted to the SAP Analytics blog

Predicate and Propositional logic was the only subject in university that I failed (if only partial points were awarded for partial proofs!). Yet, I find myself applying this form of mathematics all the time in work as part of troubleshooting and problem solving. I must admit also, I can barely do the proofs anymore (goes to show what happens when you stop practising). However, the parts of this maths discipline is around reasoning and logical deductions - the type of mathematics we all use daily without realising. Yep – problem solving! By understanding logic and the concepts, it has helped me to troubleshoot and simply requirements. And in some cases, it has help me provide solutions to questions asked in this space.


So what has this really go to do with GRC? A tad random for me to be writing about something with no direct connection to GRC. Then again, the thought for this blog came to me after assisting a few recent questions relating to MSMP and BRF+ Decision tables. Members of this community were not asking how to resolve an error (that is, they knew how to configure workflow) but more around their design of their workflow and decision table entries (they didn't know what values to specify for the steps). Logically, it became evident that logic was missing.


I won’t attempt to provide a lesson in this mathematics (I couldn't imagine anyone willing to learn from a self-proclaimed failure). However, I thought I might share a slither of my thought process and approach to designing the decision table rules in hope it can help you to determine yours.


I have used this recent question from GRC space as an example of breaking it down - GRC 10.0 BRM : Issue with Decision Table. My workings this blog are not 100% the same as to the answer I gave as I have separated the steps out. However, the answer I provided would also have covered the requirement.



Step 1 – Gather and Record your Requirements


This step does not require changes to your system. Hold back on configuring your system until your think your requirements through. Therefore, you’re working with pen and paper and figuring out your design.


Requirements gathering in its simplest form involves obtaining business statements of what is needed. In this step, avoid the use of technical jargon and write your requirements out in simple English (or whatever your native language is).


You can ask yourself questions such as:

  • Do I have different workflow scenarios depending on the request?
  • What sort of scenarios are they?
  • Will these scenarios require different approval steps?
  • Who are my different approvers (agents)?


In this example, the requirements were already provided (off to a good start to designing the table)


If I select Composite Role it has to go Approver 1 irrespective of any criticality of the role whereas for Single Role if the role criticality is HIGH it has to go to Approver 2 and If the role criticality is MEDIUM and LOW it has to go Approver 3.



Step 2 – Identity your Inputs attributes

By the time you get to step 2 you should have written down all of the scenarios that you can think off for your requirements. The next stage is to go through and find the condition values (attributes) that you can use to configure your rules.


My approach on this one is to go through your statements with a highlighter and colour the attributes that you can see exist for the request type. Depending on how visual you and are how complex your requirement, you might want to use different colours to group the attributes.


For later use (in step 3) you can also highlight the output paths. In this case, these output paths are the identified Approver groups (return results).


1 bus req highlight.png


Once you have gone through and found your condition values, you can then group them together as to identify the attributes:

  • Role Type (e.g. Composite Role, Single Role)
  • Criticality Level (e.g. High, Medium, Low, Any) – in BRF+ it will display as “Crit. Lvl”


At the end of this analysis, you now know that you have two input attributes to use. You can now build the structure of your decision table (you know the inputs from this analysis and you have the outputs due to the rule type – initiator).


2 decision table structure.png


Step 3 – Sequence and Simplify your conditions

As entry to this step, you know you the attributes to enter as the column headings. In this stage, you need to return the original business requirements and rewrite them as a pseudo-logic format based on your inputs and outputs.


3 rule break down.png

Now an example of where Logic comes in (allows you to build a logically equivalent rule) and shows an example between how I wrote suggested the solution versus how it was built is Rule 1.


4 rule example for logic.png

A Logical equivalent of this rule would be replacing the criticality is asterisk with the use of an OR operator and listing out ALL POSSIBLE VALUES for Criticality level


5 rule example for logic equiv.png

The risk of switching to the OR operator is if new Criticality Levels are built, then you have not factored them into this scenario. You then have to update the decision table. For this reason, when you requirement does not require the use of the attribute, I would specify the asterisks. However, the two rules above will return the same result (so long as there are only those 3 criticality levels).


You could approach this sequencing and simplification by drawing a decision tree. If you have completed business process flows, you may not even need to go through this process as the steps are already defined for you. Example of the decision tree, provides a visual flow of your rules which may help you validate them later when you test the rules. It is also a useful approach to use when you are analysing gaps in your requirements.


6 decision tree.png


When breaking this one down, as it was a simply scenario, I realised immediately that 3 lines were needed for the different scenarios. However, where it becomes more complex, you might need to work through a decision flow and refine it until you can see all of the scenarios.


Step 4 – Add your catch-all

Depending on how thorough your rules are, you may have no rules left to capture. This step is important to analyse the business rules that you have devised to make sure you did not miss any possible combinations. If you miss a scenario then your end user will receive an “on submission” of the workflow error.


In this step, you need to look at your business rules and compare to your IMG configuration to determine if there are any possible inputs not yet catered for. In some cases you may be able to simplify your rules by changing the OPERATOR. In other scenarios, you may need to add additional rules (another line item).


As an example, ROLE TYPE is a potential gap. The original requirements only considered two roles types – Single and Composite. However, there are other roles types to choose from (profile, derived, composite, etc). It is hard to know if this is an oversight as part of it comes back to IMG configuration for choosing which role types are in scope. For the purposes of this blog, let’s assume that all role types are required.

The second potential is PRIORITY. If you only list the explicit values – LOW, MEDIUM and HIGH – you risk missing any other configured values. You also risk future IMG configuration requiring creation of a new criticality but the BRF+ decision table is forgotten. For example, there might be a value call CRITICAL.


There are a few ways to add the catch-all


Option 1 Rewrite your rules to cater for them

In the case of the first attempt – you can go through your rules and incorporate it. The risk of this path is that you implicitly include it in an Approver Path instead of going back to your business requirements and confirming them. This option really depends on how well you captures you business requirements in the first place.


For example, in rule 2 and 3 change it to Role Type <> Composite instead of Role Type = Single. For rule 3, change the criticality to not equal high. You have now removed the gap for Role Type and Criticality.


7 catch all rewrite.png


Your risk is whether you have interpreted the requirement correctly in simplifying. For example, what if Non-Composite Roles that have Criticality level of Critical need to go to a different approver (approver4)? This rule will not provide that option. Therefore, your simplification becomes invalid.



Option 2 Add entries to the bottom for each scenario

For each gap, you need to define the requirement and capture it. For example, you have determined that there are only two role types (Single and Composite) but there is another Criticality level – Critical – and you want to route to Approver2.


8 catch all add entries.png


If you have a decision flow diagram, then you would need to update it to reflect the new rule. For each scenario, you would add a new rule to your table.



Option 3 Edit your Existing Rules to Expand

An alternative to Option 2 could involve editing the existing rules to include the missed scenarios. This would depend on the missing gap. Using the same requirement Options 2 (criticality of critical for single roles should go to Approver2) would result in editing rule 2.


9 catch all edit entry.png


Option 4 Wildcard catch all at the very end

If your decision table properties has been configured to only return a single result (which is the first rule evaluated) then you can add a wildcard catch all to the very end. This rule will only be evaluated if all other rules have failed. In this case, would configure an Approver_X (unknown) and consider routing it in MSMP to an Administrator to investigate.


10 catch up wildcard.png


Step 5 – Build and Test your decision table

Finally, you’re at the stage where you have translated your business requirements into business rules. Time to hope into BRF+ and create the decision table. Once you have completed, activate the decision table, functional and application. Finally, you can simulate your rules to verify that you receive the expected result based on your inputs (your decision tree might even help you with your test scenarios).


11 decision table complete.png

Note: configuration screen shot taken from the original thread referenced at the top




Hope this helps you think through your rules and apply a little logic. If you happen to be interested in logic as a topic (and succeed where I failed), this site is useful and includes a Teach Yourself Logic Guide.


What is your approach to breaking down BRF+ rules? Do you take a similar approach or do something different altogether? I would love to hear your thoughts in the comments below.




Surely 2014 was the year of simplicity with SAP's emphasis on simplification, simplicity, "Run simpler," or any of the variations on that theme trumpeted loudly and clearly at every SAP event and opportunity. This new emphasis seemed to be well received by customers, and why not? Who *wouldn't* want their SAP landscape to be simpler and easier to support and sustain? Security is no exception: doing more with less, squeezing a lean team harder to support more projects, more systems, and more users is just the given these days. Assuming that we start with at least a minimum number of well trained and competent SAP security staff, what does it take to simplify security to make it sustainable and bring about sustainable compliance? Here are some suggestions for your consideration.


Consistent security design

In my experience, there is not a "one size fits all" of security design except to say that sustainable results are more likely to be achieved with a consistent design. Are your security roles built using the derived role functionality, the enabler role model, or a haphazard mix of both? Is the design task-based, job-role based, or not clearly one or the other? If Business Role Management (BRM) is in use, is the model easy for the business users to understand? Is it your organization's practice that security roles have standalone integrity, or do some unknown number of them not fully functional unless some other functional role is assigned, which is not documented but "everyone in the plants knows that?" Are end user roles restricted from assignment to the SAP support team, or are exceptions frequent? Whatever approach the organization takes, taking it consistently and documenting it thoroughly will make your security much more sustainable in the long run, reducing the confusion among the people requesting access and the demands on the security resources to maintain and explain it.

Security design aligned with the business model

Whatever the basis of your security role designs, aligning the designs with the business is imperative for simplification. Otherwise, the requesters and role approvers will find themselves in an endless cycle of submitting requests to the security team for adding and removing roles from the users, and adding/ removing access from roles,  in frustrating attempts to get the access levels just right. But what if the jobs are not defined in a consistent manner? Then there is really very little the security team can do until the HR function works with the business to review the job  and task descriptions to improve the consistency.

Organizational standards

In my experience and observation, it is often the case that the organization's management wishes to have users' access restricted organizationally, often for compliance reasons. Whether the division is geographically based, product/service line based, data sensitivity based, or some other reason, sustainable security and compliance is much easier to achieve when the rules are documented, applied consistently, and enforced via automation. There is not much point in stating that users with access to one business unit should not have access to data of another business unit, when one functional area has a different idea from another of what organizational values represent each business unit, and end users are frequently granted roles from more than one functional area.


Furthermore, when the rules must be enforced manually, and approved exceptions are kept in a spreadsheet or file drawer instead of in a GRC toolset, compliance is anything but sustainable.

Governance model

So how does an organization that is lacking in any of these areas bring about the changes that are needed for sustainable security and compliance? In my experience, governance is the key. Role designs should not only be required to meet a documented standard, they should also be subject to periodic governance review. If role designs are any which way that the role owner and/or his/her business lead wish, if organizational standards are only a suggestion instead of a policy, if exceptions are numerous and monitored manually,  the security team will find themselves in an endless cycle of role and user modifications, which can take so much time and effort that value-added proactive initiatives, such as automating the user access review or some of that manual monitoring, are forever on the back burner. Without a governance model that has teeth, the security team may find themselves the scapegoats for the breaches and non compliance that are almost inevitable.


I hope that some of these suggestions spark improvement ideas that help bring about simpler and more sustainable security and compliance in your SAP landscape. Are any such initiatives already in the works for 2015 at your organization or among your clients? I welcome your comments and observations. What did I miss that you have found to be key to sustainable security and compliance?


Filter Blog

By author:
By date:
By tag: