Skip to Content
Technical Articles

GRC AC Configuration Approach

Hello folks,I am writing this blog after my first GRC AC 12.0 implementation project for new newbies like me. 

Through this blog I have tried to explain which all approaches can be considered in implementation projects for moving changes across the landscape. This will help in making decision from the initial stage of the project .

Considering that all configurations are attached to RFC names, there needs to be way to be able to handle changes effectively across the landscape.

Approach 1:

Create all the connections to the satellite systems (DEV,QAS,PRD) in GRC Dev and move to prod.  (Recommended approach) – Create DEV GRC as PRD GRC. Also, the Quality and Production satellite SM59 connections would be left empty to ensure nothing is provisioned from DEV GRC to QA or PRD satellite systems.


Firstly, changes can be tracked and will be consistent across the landscape. Satellite Connectors and configuration related to connections remains intact after system refresh from PRD. Change Management process will be followed effectively. Lastly, no Audit Concerns.


Approach 1

Approach 2:

Create the connections to the satellite systems in respective GRC systems. Modify all the connector related settings directly in PRD GRC systems whenever a new satellite connector needs to be connected to the GRC system


Less time consuming.

The only advantage here is that you get to use the usual RFC that can/may be useful for core team members to identify the RFCs by name.

Audit concerns for making direct changes to the client. After system refresh (from GRC prod) all connector related configuration needs to be updated. Change Management process needs to be appended/created for making changes to the GRC system


Approach 3:

Create RFC with generic name Eg: ECC_GRC.


Firstly, easiest to configure. Only hostname of respective satellite connector needs to be updated after system refresh. Change Management process will be followed effectively. Lastly, no audit Concerns.


  1. This approach can only be applied where customer is using separate GRC systems(GRC DEV, GRC Quality, GRC Production) for connecting respective satellite systems. This approach is a failure where there is one GRC production system for connecting the complete landscape i.e (ECC Dev,  ECC quality, ECC prod) or if customer is having common GRC system for DEV and quality system for cost cutting
  2. You might have a Sandbox, Master Configuration and Unit Test client on your Development box. Your connector can only connect to one of them.


Personally, I found approach 1 as best as it generally works in all scenarios. However one needs to consider the approach depending on the GRC landscape.

I ‘d like everyone to provide suggestions/feedback and add all possible approaches to this blog that can be used during implementation projects.

You must be Logged on to comment or reply to a post.
  • Hi Kanika


    great to see blogs like this appearing back in the community


    do you have any impact considerations for target systems pointing to multiple GRC boxes? E.g. if you use Business Roles for provisioning and have GRC Prod and GRC QA connected to QA system what would that mean? Is there anything you might need to do or not do with the connectors


    I like production having all connectors for vertical system management. Production can manage access and risk to non production landscapes