In  GRC10 – ARM  Access Request approver have the choice to do Risk analysis at “Action Level”, “Permission Level”, “Critical Action”, “Critical Permission” and “Critical Role/Profile”.  But In 5.3, Approver didn't have choice to decide while using from CUP.


When approver open access request in AC10 under Risk Violation tab Permission Level is always selected .Selection is fine as this is configured this way (Parameter in SPRO 1023 -Default Report Type for Risk Analysis).  But the approver also has an option to deselect "Permission Level".


If you want to ensure that approver always keep "Permission Level" as an option, in other words option should be grayed out with permanent tick mark. This is to make sure that CUP enforce "Permission Level" check, otherwise if approver deselect then they can always skip the risk analysis by clicking different report types. Also possibility at times all the approver doesn't understand the meaning of each option.  Both accidental / intentional ways skipping Risk Analysis is possible.


As you can see Permission level is always selected but editable. Approver can deselect and submit the request with no violation. This way unmitigated risks can be submitted.


We have achieved this by deploying SAP NOTE 1796838 - UAM Risk analysis at permission level set to non editable and following below steps.



1. Go to transaction se80.

Select Package as ‘GRAC_ACCESS_REQUEST’.

Click on Web Dynpro -> Web Dynpro Application



2  .Drill down to application ‘GRAC_OIF_REQUEST_APPROVAL’. Right click on it and click Test.


3. Now, the following screen will appear.



Go to the URL of the above screen and add the following string to it.

Go to Transaction  SE16 and Enter table name as GRACREQ, enter any request number in REQ_ID field.

Click execute button and copy the value of field REQ_ID


Below is String to add in URL-


&SAP-CONFIG-MODE=X&OBJECT_ID=ACCREQ/<REQ_ID  checked from above step>


Below is example for string to add in above screen dump URL..




Observe that the dump will now get removed and an access request will be opened.

4. Go to the Risk Violation Tab and right click on the Type check boxes and choose ‘Settings for Current Configuration’



5. Now, the following pop up window will appear.



In this, you can go to each of the type of result options and click on ‘read only access’ check box.



6 For example, If you click on Permission Level and set Read-Only Access as ‘Yes’, permission level will appear as non editable on approval screens for all requests.


Click on ‘Save and Close’.

Please see that the Permission level check box is now disabled.




Hope this will help you if you meet such a kind of requirement. and prevent from submit unmitigated Risk.



Dilip Jaiswal.

GRC - IDM Consultant.


In this Customizing activity, you can configure the LaunchPad settings for Governance, Risk, and Compliance (GRC) application menu items. The GRC application uses one repository and seven LaunchPads, one for each work center, as listed below:


    Operation = GRC AC PC RM IA Repository

  Work Centers 

  • My Home
    Role = GRCHOME
    Instance = GRC_SUITE_HOME
    Operation = GRC Suite Home Workset
  • Master Data
    Role = GRCMASDAT
    Operation = GRC Suite Master Data IA
  • Rule Setup
    Operation = GRC Suite Rule Setup Workset
  • Assessment
    Operation = GRC Suite Assessment Workset
  • Access Management
    Operation = GRC Suite Access Management Workset
  • Reports and Analytics
    Instance = GRC_SUITE_REPORTS
    Operation = GRC Suite Reports Workset
  • Application Administration
    Operation = GRC Suite App Administration


Note  If SAP provides updates to the content, then such changes update the standard SAP delivered repository and LaunchPads; the changes do not directly update any customized versions.  To view the changes to the SAP delivered versions and to update your customized version go to Extra->Show SAP Version.


You have created the new menu item using the Customizing activity Maintain Authorizations for Application Links.


To create new menu items, do the following:

1. Choose a component for the menu items.

2. Choose New Application.

3. In the field Link Text , enter the menu item name.

4. Select Application Categoryand choose WDA Webdynpro ABAP.

5. In the field Namespace, enter the required SAP namespace.

6. Enter the applications. (This can possibly result in the need for development of the new applications.)

7. Enter the System Alias based on the component of the menu item. You can use the following aliases:


    • SAP-GRC for items applicable to both Process Control and Risk Management, and for all (Access Control, Process Control, Risk Management)
    • SAP-GRC-AC for Access Control only
    • SAP-GRC-PC for Process Control only
    • SAP-GRC-RM for Risk Management only

8. Enter the required Application Parameters.

9. In the field Add Information, enter MENUITEMID=<The MENUITEMID,as maintained using the Customizing activity Maintain Authorizations for Application Links.

10. Save your entries.

To link the menu items to a particular LaunchPad, do the following:

1. Double-click the LaunchPad you want to link, for example Master Data.

2. Navigate to the folder to locate the new menu item.

3. Choose Link to a Repository Application.

4. Choose the repository GRC AC PC RM IA Repository, and drag the menu items to the folder.

5. Save your entries.

To create new menu folders, do the following:

1. Double-click the LaunchPad of the work centers in which you want to locate the menu folders.

2. Choose the New Folder pushbutton.

3. Enter the folder name and folder description.

4. Change the icon of the folder. (This step is optional)


In this Customizing activity, you maintain menu authorization of all Governance, Risk, and Compliance (GRC) applications. The autorizations are then used in SAP NetWeaver Portal (portal) or in the NetWever Business Client (NWBC).

Menu items represent individual navigation links. The text is used for reference and to provide an indication about the purpose of the application. Each menu item must belong to at least one or more of the application components listed below:

  • FN, which is the common component used for all GRC
  • Process Control (PC)
  • Risk Management (RM)
  • Access Control (AC)

The application displays the group items and menu items in accordance with the authorizations granted by the user role.  For example, if the user role is not authorized to view any objects and entities in a group, the application will also not display the related menu item.

Note: If you are upgrading from Process Control 3.0, you can use the delivered BC Set for this Customizing activity. For more information, see the SAP GRC Process Control  10.0 Upgrade Guide.


You have maintained each menu item ID in Web Dynpro  and in Launchpad Customizing.


To customize the authorizations, perform the following steps:

   1. Choose the New Entries pushbutton and enter a menu item ID. This is the referenced text for the application item.

   2. Choose the required Authorization Mode from the following:

   3. Choose the Entity Evaluation. You can specify if the item can be enabled by providing authorization only for one entity or object, or if it is necessary to provide authorization for all entities and objects. If no entity or object is defined for the item, then the item is always displayed.

   4. Choose the Authorization Class.

   5. Choose the Logical Operation to provide  an additional authorization check.

You can use an exit class for the ABAP code-based authorization check for a menu item. To do this, follow the requirements listed below:


  • Use the interface IF_GRFN_MENU_ITEM_AUTH.
  • The interface contains the method IS_AUTHORIZED. The method has the following  parameters:

Importing Parameters

    • IO_SESSION type, referring to class CL_GRFN_API_SESSION

  Exporting Parameters 



  The results from the exit class can be combined with the entity-level and if required with PFCG authorization by specifying the type of operation (NO, AND, OR). You can make the required selection and save your data.

   6. If you want the authorization to be evaluated by all regulations, then select the Regulation Relevence checkbox.   That is if one of the regulations is authorized, the menu item is shown.

   7. Choose Used in Application Components.

   8. Choose the New Entries pushbuttonand select the menu items that you created.

   9. Select one of the application components used in the application. In field Application Component, select whether you want to customize the entire GRC, or select the required components from the following: PC, RM, and AC.

  10. If the authorization for the application is evaluated by Entity-Level Authorization or Entity-Level and PFCG Authorization, then do the following:

a) Choose Authorized Entities.

b) Choose the New Entries pushbutton and select one of the menu items you created.

c) Select an entity from the dropdown list to be used with the selected menu item.

d) Save your entry.

Proceed in the same manner with all other menu items.

Eskom Configuration: Not used

SPRO Location




This organizational activity describes how you can activate or modify the delivered Business Configuration (BC) sets.

SAP provides a set of recommended BC sets as a baseline. For example, there exists a BC set for the frequency timeframes, where you define and maintain the time period of your system


To activate BC sets:

1. To see the activities that have a BC set, choose Existing BC Sets.
The system displays the BC sets on the right hand side of each activity.

2. Place the cursor on a BC set and choose Additional Information ->BC Sets ->Display BC Sets for Activity. The Business Configuration Sets: Display screen appears.

3. To highlight the individual BC set, choose Goto ->Activation Transaction.
The Business Configuration Sets: Activation screen appears.

Note: You must activate each BC Set separately.

4. Choose Activate BC Set or press F7.
The BC Set is activated.


Eskom Configuration:  The above does not work.


Note: BC Sets activate the default contents on the Configuration Tables

  These BC sets can be activated via transaction code SCPR20



Select each of the BC Set ID as per the table below:




In this Customizing activity, you establish the settings for transporting the organizational objects created during the set-up of your organizational structure.

This setting suppresses the SAPGUI error and warning messages received from the HR Organization objects as a result of the changes performed, for example, by changing the name of a control in the Process Control application. Examples of objects include risks, controls, processes, and so on. If you do not configure this setting, then there is a possibility system dump appears on the user interface.

Note: You must specify the transport settings for the objects in the organizational plan created for Organizational Management. This is esential because the tool used for the organizational structure set-up in Risk Management (RM) and Process Control (PC) is the same as that for setting up the organizational plan in the clien system.

Standard settings

In the standard system, the automatic transport connection is active. As a result, the Value Abbreviation field is empty for the abbreviation CORR.


To deactivate the automatic transport connection, enter the value X for the abbreviation CORR. You must do this if  you want to maintain the settings for the organizational structure in the user interface.

Eskom Configuration: This option not used, default.



In this Customizing activity, you activate the applications that can be used in your client system.

In the default delivery system, there are three application components that can be activated:

  • GRC-PC for Process Control
  • GRC-RM for Risk Management
  • GRM-AC for Access Control


To activate an application component, proceed as follows:

  1. 1. Choose New Entries.




  2. Select an application component from the dropdown list.

  3. In the column Active, select the checkbox if you want to activate the application. If you are using both Process Control and Risk Management, you must set the indicator for both components.

  4. Save the entries.

The purpose of Emergency Access Management is to allow users to take responsibility for tasks outside their normal job function. This component allows temporary access for users when assigned with solving a problem, giving them provisionally broad, but regulated access which is monitored and recorded in the application.

SAP GRC 10.0 provides two different types of firefighting which can be used either centralized or decentralized. Following a short description of both types which can be configured in IMG using parameter 4000 (Application Type). Only one type can be configured at a given time.


ID-Based Firefighting

With ID-Based Firefighter each Firefighter ID has its own user master record with roles assigned directly to the Firefighter ID. The End-user (Firefighter) executes a transaction code and checks out an ID. It is possible for multiple users to check-out each Firefighter ID (which is authorized to the end-user) but only one user can have a Firefighter ID checked out at any time. A reason code and the expected activity must be documented prior to gaining Firefighter access. Relevant changes in SAP are captured in the change history under the Firefighter ID. It is important to highlight that everything is documented with the Firefighter ID and not the user’s normal user ID.


Role-Based Firefighting

Each role which is defined as Firefighter Role can be assigned directly to a user. This can be done through Access Request Management (ARM) if in place or directly in SU01. To use the Firefighter a user doesn’t have to check out a separate ID. Transactions and change histories are logged with the user’s own ID, which is an advantage in relation with the ID-based Firefighter. The end-user is not aware when he is utilizing emergency / firefighter access as he does not have to check out an ID and uses his own ID all the time.


Concept of ID-Based Firefighting



Concept of Role-Based Firefighting



Steps to set up ID-Based Firefighting

  1. Create Firefighter ID
    • Create a user account in transaction SU01 with user type S (Service) to be used as a firefighter. This can also be done in Access Request Management if in place.
    • Assign the Firefighter ID role which is defined in configuration parameter 4010 (Firefighter ID role name) to recognize the service user as a Firefighter ID.
    • Assign necessary roles for firefighter access.
  2. Define Firefighter Owner
    • Assign an Owner to the Firefighter ID
  3. Assign Firefighter Controller
    • Assign a Controller to the Firefighter ID. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter ID Controllers can also be Firefighter ID Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter ID.
    • The user can access the Firefighter IDs (can be more than one) within the validity dates.


Steps to set up Role-Based Firefighting

  1. Define Firefighter Role
    • Enable a specific role for Firefighting directly in the Business Role Management.
  2. Define Firefighter Role Owner
    • Assign an Owner to the Firefighter Role.
  3. Create Firefighter Role Controller
    • Assign a Controller to the Firefighter Role. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter Role Controllers can also be Firefighter Role Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter Role.
    • The user can access the Firefighter Roles (can be more than one) within the validity dates.


Please share your thoughts of both firefighting concepts and participate in upcoming discussions.

Best regards,


Access Control: - Create Access Request Using Web Service in GRC10

In this blog I would like to share my experience how Web service can be tested and create Access Request from GRC system when you are integrating with IDM system.


Suppose you have integrated GRC10 with IDM 7.2 and wanted to submit access request from IDM to GRC. Being a GRC consultant you can test Web Service used to create Access Request from GRC side. It helps to check Web Service is working and you are able to submit request and its following MSMP workflow created in GRC10 by you. Once this is tested from GRC side it’s easier to use same inputs from IDM side and submit Access Request to GRC.



Web Service used to create access request from GRC is GRAC_USER_ACCES_WS (User Access Request Service) .


Follow below steps to execute Web Service.


Execute Tcode SE80 and double click on Repository Information System


Expand Enterprise Services under Repository Information System and double click on Service Definitions .


In Application Component enter GRC-AC and Execute.

Now you will be able to see all Web Service used for IDM- GRC Integration

Here double click on highlight Web Service GRAC_USER_ACCES_WS (User Access Request Service ) .


And execute GRAC_USER_ACCES_WS (User Access Request Service) from below screen


Below pop up will come. Select Generate Request Template and execute.5.png

Below output will come. From here click on XML editor and provide required details in XML tags. And execute. This will create access request in response if you have provided all the details correct. If details are not correct then you will receive Error in response .


In above Web Service there are 5 Sections as below.


  1. CustomFieldsVal
  2. Parameter
  3. RequestHeaderData
  4. User Info
  5. Requested Line Item


Mandatory fields and User information are determined based on End user Personalization (EUP) in SPRO.  ReqInitSystem in Request Header data is mandatory filed and you need to provide IDM connector information in this.



Fill details in Header data , Line Item and User Info based on your configuration


Header DATA-


<Reqtype>String 12</Reqtype>
<Priority>String 13</Priority>
<ReqDueDate>String 14</ReqDueDate>
<ReqInitSystem>String 15</ReqInitSystem>
<Requestorid>String 16</Requestorid>
<Email>String 17</Email>
<RequestReason>String 18</RequestReason>
<Funcarea>String 19</Funcarea>
<Bproc>String 20</Bproc>


Line Item Details-


<ItemName>String 21</ItemName>
<Connector>String 22</Connector>
<ProvItemType>String 23</ProvItemType>
<ProvType>String 24</ProvType>
<AssignmentType>String 25</AssignmentType>
<ProvStatus>String 26</ProvStatus>
<ValidFrom>String 27</ValidFrom>
<ValidTo>String 28</ValidTo>
<FfOwner>String 29</FfOwner>
<Comments>String 30</Comments>
<ProvAction>String 31</ProvAction>
<RoleType>String 32</RoleType>




User Info


<Userid>String 49</Userid>
<Title>String 50</Title>
<Fname>String 51</Fname>
<Lname>String 52</Lname>
<SncName>String 53</SncName>
<UnsecSnc>String 54</UnsecSnc>
<Accno>String 55</Accno>
<UserGroup>String 56</UserGroup>
<ValidFrom>String 57</ValidFrom>
<ValidTo>String 58</ValidTo>
<Empposition>String 59</Empposition>
<Empjob>String 60</Empjob>
<Personnelno>String 61</Personnelno>
<Personnelarea>String 62</Personnelarea>
<CommMethod>String 63</CommMethod>
<Fax>String 64</Fax>
<Email>String 65</Email>
<Telnumber>String 66</Telnumber>
<Department>String 67</Department>
<Company>String 68</Company>
<Location>String 69</Location>
<Costcenter>String 70</Costcenter>
<Printer>String 71</Printer>
<Orgunit>String 72</Orgunit>
<Emptype>String 73</Emptype>
<Manager>String 74</Manager>
<ManagerEmail>String 75</ManagerEmail>
<ManagerFirstname>String 76</ManagerFirstname>
<ManagerLastname>String 77</ManagerLastname>
<StartMenu>String 78</StartMenu>
<LogonLang>String 79</LogonLang>
<DecNotation>String 80</DecNotation>
<DateFormat>String 81</DateFormat>
<Alias>String 82</Alias>
<UserType>String 83</UserType>




Kind Of Error / SUCCESS message you can get in response.




<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid request initiation system</MsgStatement>


  <RequestId />

  <RequestNo />




<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>

  <   MsgNo>4</MsgNo>


  <MsgStatement>Invalid request type</MsgStatement>


  <RequestId />

  <RequestNo />





<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid priority type</MsgStatement>


  <RequestId />

  <RequestNo />






<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Invalid Provision Action in line no 1</MsgStatement>


  <RequestId />

  <RequestNo />


5. When you provide al the required detail correct. SUCCESS response will be received.


<?xml version="1.0" encoding="utf-8" ?>

- <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

- <MsgReturn>



  <MsgStatement>Request created successfully</MsgStatement>







6. One strange issue I have seen. If you are creating access request with user missing with GRAC_SYS auth object then you can get “Connector not configured Error”



Same type of error message you can get in IDM- VDS logs when Access Request is submitted via IDM.


Hope this will help you to understand Access Request creation using Web Service and test Web Service.



Dilip Jaiswal

Purpose of the Document:

In GRC 10.0 SAP has introduced the Centralized Emergency Access Management process unlike its older version GRC 5.3 which got mixed reviews from GRC users.

Initially a user has submitted his idea in SAP IDEA PLACE asking SAP to provide De-centralized logon in GRC 10.0 in the same way they have been using in GRC 5.3 and this has been supported by lot of GRC consultants.


Finally SAP has enabled De-centralized firefighting feature in GRC 10.0 from GRC SP10. Depending on the client's needs, the option "log on centrally" (current version 10 behavior) or "log on locally" (5.3 behavior) can be configured in GRC 10 and GRC 10.1

Also system has the ability where both centralized and de-centralized approach can be configured but user can either login centrally or locally as there can be only one firefighter session at a time.

De-centralized EAM configuration – SP13 – ID based Firefighting

Step 1: Creating Connector and Assigning Integration Scenarios

Creating Connector:

  • Create new connector using SM59 Tcode or going through below mentioned path.

SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Create Connectors


  • Create ABAP connector with the options as shown below.

  • Under Logon & Security maintain the details as shown below. User RFC_USER is a system user and is available in ECD system with S_RFC access.

  • Once you have maintained all these values. Save the connector and then click on Connection Test. If it is successful, you will get below screen.

Maintain Connectors and Connection Types

  • Now click on Maintain connectors and Connection Types going to below path as this is required for assigning the connection type to our connector which is created in the above step.


  • You will get the below screen where you can see different types of connection types available in the GRC system.


  • Maintain the entries for your connector as mentioned below. Source connector is not required. Change the setting “Max No. of BG...“parameters to “3“ (i.e. this connector will use a maximum of 3 background jobs for synch jobs)

  • Now our connector needs to be assigned connector group. This is similar to logical system in GRC 5.3 where we group similar systems under one logical system. You can create your own connector group or else, when you activate BC sets for SOD rules automatically connector groups gets created in the system which were used in the SOD rules. Then you can assign your connector to the connector group as shown below.


  • Once you have these connector groups, then assign the connector group to group type as shown below.



  • Next step is to assign connectors to connector group as shown below.

Maintain Connection Settings

  • Connectors must be assigned to the all integration scenarios (AM, ROLMG, SUPMG, AUTH, PROV) available as it is a good practice according to SAP (under Common Component Settings -> Integration Framework -> Maintain Connector Settings). In the same way mentioned below repeat for ROLMG, SUPMG and PROV scenarios.

Maintain Connector Settings


  • Now go to below mentioned path for maintaining connectors with application types and enabling PSS.




Maintain Mapping for actions and Connector Groups

  • For POC purpose we are connecting GRC 10 system to ECC system and hence only one Connector group is there in active status.

  • From the same screen we can define default connector to be used for different actions as shown below.



For example if you are creating LDAP connector then the mapping between AC and LDAP fields are maintained in assign group field mapping. Once all the above mentioned steps are performed, then the next step would be to schedule the synchronization jobs in the order advised by SAP.


Step 2: Creating FF Users, FF Owners, FF Controllers in GRC 10


  • FF Users executes Tcode /n/GRCPI/GRIA_EAM from Plug-in system and login with firefighter Id’s assigned to them. So users no need to exist in GRC system any more.


  • Following role must be assigned to the Firefighter user.

SAP_GRAC_SUPER_USER_MGMT_USER for the centralization as well as Decentralization.

  • FF Id’s will be created in plug-in system and assign the role SAP_GRAC_SPM_FFID or its “Y” or “Z” equivalent to make it recognizable as FF Id.


  • FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.

       NWBC -> Setup -> SuperUser Assignment and NWBC -> Setup -> SuperUser Maintenance

  •     FF Controller should also exist in the plug-in system with valid Email ID as FF login notifications will be sent to controller’s Mail Id maintained in plug-in system.


  •    FF log notifications are sent to FF controller’s mailed maintained in GRC system. Hence FF controller should exist in both GRC and Plug-in systems.


Step 3: Synchronization Jobs in GRC 10

In GRC 10 synchronization jobs can be run from SPRO->IMG, navigating to Governance, Risk & Compliance>Access Control>Synchronization Jobs

Authorization Synch
Synchronizes PFCG Authorization data

Repository Object Synch
Synchronizes Profiles, Roles, and Users master data

Action Usage Synch
Synchronizes action usage data

Role Usage Synch
Synchronize role usage data

Firefighter Log Synch

Synchronizes the firefighter logs from plug-in system to GRC system


Firefighter Workflow Synch

Initiates FF log report review workflow based up on your workflow settings which sends the FF log report to FF controller for review.


EAM Master Data Synch

This is the new job introduced as part of De-centralized firefighting. Synchronizes the EAM data from GRC box to Plug-in system. Once you have created all required users execute this job to synchronize the data from GRC to plug-in system.

These reports can also be maintained as scheduled background jobs.



Step 4: Configuration Parameters

SAP has introduced a new configuration parameter 4015 which has to be maintained as “YES” in order to enable De-centralized firefighting as shown below.

Configuration Parameters – GRC system

Configuration Parameters – Plug-in system


In GRC System:



In Plug-In system:



Step 5: Assigning FF Ids to Users

Unable to find FF Id’s in NWBC.

  1. Please check whether configuration parameters are maintained as mentioned in step 3.
  2. Please check whether all synchronization jobs are executed as mentioned in step 2.
  3. Please check whether the user who is searching for FF ID’s in NWBC has required access.
  4. Please check the below mentioned configuration also.


Assign Owner, and Controller:

Without assigning an owner and a controller, you might not be able to assign the FF ID to a Firefighter. From NWBC –> Setup –> Super User Assignment, assign Owner, and NWBC –> Setup –> Super user Maintenance, assign Controller.

Now you can assign the Firefighter Id to Firefighters either directly or through GRC access request.

   5. In plug-in system you will find all the FF roles required for user, controller etc. You need to create Y or Z copy of them and should assign them to the users.



Step 6: FF ID is assigned to the FF User

  • FF user has been assigned with the FF Id.


  • Now FF Users executes the Tcode /n/GRCPI/GRIA_EAM in plug-in system and can see the FF Id assigned to his User ID. When FF users tries to login with the FF Id assigned user will get the below error.


  • We already has RFC connector SECCLNT100 created in GRC system to connect from GRC to SEC and vice-versa. This error was resolved after creating RFC connection locally by the same name SECCLNT100 as system is expecting a local RFC connection with the same name.


  • Once this issue is fixed, users are able to login as Firefighters from plug-in systems and complete their tasks.


Step 7: Fire fighter Login and Log notifications

Configurations required for the Login Notification:

  1. In the GRC Box, maintain configuration parameters as mentioned above in Step 4.
  2. Make sure that 'EAM master sync job' is complete.
  3. Into the Plug-in system, maintain configuration parameters as mentioned above in Step 4.
  4. In the Plug-in system, FFID controller must exist with a valid email Id, as email notification is sent from the Plug-in system.
  5. Login notification mail will be sent from Firefighter User SU01 Mail Id itself in de-centralized model. Make sure that email Id of the firefighter User is also maintained properly.
  6. FF User time zone and system time zone should be the same in plug-in system.


Login Notification sent from Plug-in system:

Configurations required for the Log report Notification

Unlike Login notification, Log Report notification is sent from the GRC Box. Almost, all of the steps are same as in case of centralization.

  1. Make sure that the configuration parameter 4002 is maintained into the GRC BOX.
    1. If the 4007 is set to 'Yes' then schedule only job 'GRAC_SPM_LOG_SYNC_UPDATE'. This job will send the Log Report notification as well.
    2. If the 4007 is set to 'NO' then schedule job GRAC_SPM_LOG_SYNC_UPDATE for synchronization. It will not send the Log Report Notification. For the Log Report, another job is required to be scheduled which is 'GRAC_SPM_WORKFLOW_SYNC'.
  2. Controller of the FFID is configured with the valid Email Id.
  3. In the NWBC -> Access Management -> Controller -> make sure that 'Notification By' column is selected to 'Email'.
  4. Make sure that 'EAM master sync job' is complete.
  5. There is no setting which is required to be maintained into Plug-in system in this case.


Log Notification sent from GRC system




Firefighter Login Issues - Plug-in system

Login as firefighter using Tcode /n/GRCPI/GRIA_EAM

User will enter the reason code and activity details and click OK.

User will be presented with a login screen.



User should be assigned to the below roles and make sure user also has access to S_USER_GRP object with Activity 03,05


EAM for Webdynpro and Web based applications

Firefighter functionality is primarily designed for use with ABAP systems. Lot of us had a requirement to implement EAM for webdynpro or web based applications, but there are lot of limitations for using EAM for webdynpro and web based applications.

To understand about EAM functionality with Webdynpro applications,  please check out the below blog post.

Emergency Access Management (EAM) for Webdynpro applications or Web-based applications - GRC 10.0


Wrong Firefighter ID Status - De-centralized EAM:

When firefighter tries to logon to the system via transaction /n/GRAC_SPM, error comes:


"<Firefighter ID> is logged on using <some other firefighter id> firefighter id."

Please check below SAP notes to resolve the issue.


1895204 - Error message: <Firefighter ID> is logged on using <some other firefighter id> firefighter ID


1702370 - Wrong Firefighter Id Status

Many thanks to Amanjit and Colleen for their guidance.


In case there is a business need to have single approval for Manager & Role Owner where both happens to be the same person, below is the solution:



This can be achieved using Multiple DBLookups....in this case 4 DBLookups:


1. Get Request ID

2. Get Role ID

3. Get the Manager ID

4. Get the Role Approver ID



Following are the steps:


Step 1: Get Request ID


Request ID is in GRACREQ (Request Header) where REQNO = Request.ReqNo (select from context parameter) . This will be used as expression in Manager ID Table to get the Manager for this Request only and not any other request.




Step 2: Get Role ID


Request ID is in GRACROLE (Role) where Role_Name=Request.Role_Name (select from context parameter) . This will be used as expression in Role ID Table to get the Role for this Request only and not any other request.





Step 3: Get Manager ID


Now create DBLookup for Manager ID. Manager ID is in GRACREQOWNER Table with Req_ID=Get_REQ_ID (Request No from Step 1) and UserType="MAN". Put that ID in a variable lets say User ID.






Step 4: Get Role Approver ID


Role Approver ID is in GRACROLEAPPRVR Table where Role_ID=Get_Role_ID (Role ID from Step 2).We can put that in Approver Variable.






Step 5: Create Condition in Decision Table


Create simple condition that if DBLOOKUP-MGR=DBLOOKUP-ROW (Manager = Role Owner) then True otherwise False.






Hope this helps.


Best Regards.



Hi experts,


While creating Risks and Opportunities, the system provides for selection of Risk Category. There is an option to assign an Activity also to the Risk being created.


I feel the need for another field to select, ie. the Activity Category. There are huge number of activities which are created as sub-processes in Business Process hiearchy and in other categories like Projects, Company Assets and Planning objects, to site a few. It is a good feature that the system allows sub-categories also.

While creating Activity, activity is  assigned to an Organisation and to an Activity Category. This category should be avaiable for selection in Risk creation and the system should filter the activities according to the Activity Category/Sub-Category chosen.


Hope others also feel the same way.



Hi All,


I need all your help to get me some documents in regard to GRC process control,I went through all the links which was given by all our friends,I am bit confused what to read and what not to read or sequence ,which documents need to go through step by step,can some body guide me on this..





After having worked on GRC Process Controls (PC) 2.5, 3.0 and also with some hands on with 10.0, it’s great to have the opportunity to look at the latest SAP offerings within GRC PC 10.1. Ramp up testing is always great learning experience and I am lucky to have experienced this one.


I’m sure there is curiosity around the new version and therefore I thought I’d share some of my observations.

Although the look and feel seems similar to 10.0, we do have some new features for Process Controls with version 10.1.


1.  Assessments -> Planner


New survey categories introduced within the Planner “Disclosure Survey” which can be conducted at Organization, Sub process and Control level.




2.  Assessments -> Questions Library


Two new Question categories have been introduced:

  • Workshop Survey
  • Disclosure Survey


3.   Assessments -> Survey Library


Two new Survey categories have been introduced:

  • Workshop Survey
  • Disclosure Survey



4.  Assessments -> Reports


There have been 3 introductions within the list of PC evaluation reports.

Assessment Survey Details report provides detailed information in addition to the overview Assessment Survey Results report. Some of these details include Question, Answer, Assessment Processor, Comments, Case ID, etc thus providing a deep dive into the assessment details. Earlier versions had drill down capability to fetch such information about assessments. But with detailed reports mass processing becomes much easier.




With the introduction of Disclosure Surveys, 2 new reports related to this survey category have been introduced:

Disclosure Survey Details as the name suggests, provides a deep dive into the survey results.




Disclosure Survey Status as the name suggests, provides information about the status of the survey.



5.   Side Panel


With PC 10.1 we see the introduction of Side Panels. These provide additional overview information which helps us connect between for example: Organizations and assessments in one go. Although these may require additional configuration.


6.    SPRO changes


Import and export of business rules functionality is new within GRC 10.1. This functionality will enable SAP delivered business rules (configurable / programmed) to be imported into the GRC system and exported to other systems too by converting them to a downloadable format (like XML).


In addition to the above, with 10.1 SAP has also included features like Role-based Entry pages, Google like search and End to End Evaluations using offline Adobe forms which can be configured based on client's requirements.

I'm sure there is still more that I will discover as I spend more time with GRC PC 10.1. I will keep you posted on more findings and experiences!

With this application, you can use the data that you have replicated from your SAP GRC system to SAP HANA, and monitor, analyze, and, in some cases, act on role-centric reports. SAP Role Analytics is an example of how you can create analytical reports and add functionality that allows you to take action on the analytical data.

The application has these reports:

·         Unused Roles

You can take action to de-provision unused roles.

·         Actively Used Roles

·         Orphaned Roles

You can access the application using an HTML5 supported web browser .The application counts the actively used, unused, and orphaned roles on the GRC system, combines it with the business process information, and displays this data in pie chart format. The default date range for the count is the current year. You can adjust the data by changing the date range, or by selecting filters for role type, landscape, criticality level, and sensitivity.

The default report is Unused Roles. You can choose to display the information in different formats: pie chart, bar chart, table. You can drill down by choosing any of the selectable elements in the charts and tables.





From the available options, select “Orphaned Roles.”


From the Sensitivity filter, when selecting “Confidential,” “Restricted,” and “Classified, the filter shows the selected 3 of the possible 10 choices under Sensitivity. Then automatically result gests refreshed graphically based on the selection criteria (pie chart).




From the result set, we can switch the pie chart to bar chart.




By double-clicking on the specific bar say the business process Quality Management roles bar in the graph, it will drill down the list of roles.





          2) UNUSED ROLES



Double click on the “Basis” section of the chart, bringing up a table of the roles and user counts involved.ra9.png


The filters can be applied to check the roles for the specific land scape say SAP R/3





From the list, we can go through each of the roles in the SAP R3 systems that aren’t being used. Even more convenient, we can select to de-provision the role from the affected users. The de-provisioning request is sent directly to the backend Access Control system and the appropriate workflow is used with just one click!

We can continue to use the SAP Access Control Role Analytics application to quickly and easily resolve the remaining unused role issue and addresses Internal Audit’s concerns.

As of Monday, November 11, 2013, SAP Fraud Management is released to customers in Release 1.1, Support Package 01. SAP Fraud Management, powered by SAP HANA, combines an intelligent and efficient infrastructure for detecting fraud and supporting investigation with the speed and power of the SAP HANA database. With SAP Fraud Management, you can detect fraud in big data environments with unprecedented speed and responsiveness, and you can bind real-time online checks for fraud by SAP Fraud Management into your purchasing, claims management, and other business processes.


With Release 1.1 SP01 of SAP Fraud Management, additional content is available for strengthening your compliance efforts with anti-corruption laws and regulations such as the US Foreign Corrupt Practices Act of 1977 or the United Kingdom’s Anti-Bribery Act of 2010.  This content is downloadable and installable from this wiki page: Extended Anti-Corruption Content with SAP Fraud Management Release 1.1 SP01 - Governance, Risk an...


The anti-corruption content includes the following rules for detecting potential fraud, together with the required customizing and detailed information:
ScenarioDetection Technology
Irregularities in AccountingAccounting documents posted on non-working days
Irregularities in PurchasingPerson or organization on a Politically Exposed Persons (PEP) list found in purchase order item
Purchase order overpaid
Purchase invoice receipt greater than goods received receipt
Partner or vendor in a purchase order item comes from a high-risk country
Changes made to a saved purchase order exceed threshold
One-Time AccountsMultiple postings made to a one-time account
Regular vendor postings made to a one-time account
Irregularities in Connection with VendorsInvoice reference number used more than once for the same vendor
Invoice without reference to purchase order
Split invoices exceed purchasing limit
Suspicious keywords found in invoice item texts
Divergent vendor and payment countries
New Business Conflicts of Interest Turnover of new vendor in first year after initial transaction exceeds limit
Turnover of new vendor between first and second years after initial transaction exceeds limit
Turnover of new vendor in excess of threshold approved by a single employee
Irregularities in Vendor Master RecordsVendor master record without bank account details
Flip-flop payee: Alternate payee in vendor master record changed suspiciously (within company code and across company codes)
Flip-flop business: Bank data in vendor master record changed suspiciously


The downloadable anti-corruption content is provided without cost and without service or warranty.


Filter Blog

By author:
By date:
By tag: