GRC AC Configuration Approach

[kanika]

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 a 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.

Advantages:

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

Advantage:

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.

Disadvantages:

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.

Advantages:

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.

Disadvantage:

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.

CONCLUSION:

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.

[I048902]

Very Good Article)

[Colleen]

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

[former_member669096]

nice blog 🙂 good to see implementations blog also in community.

[kanika]

Hi Colleen,

Apologies for the delay in response.

Thanks for bringing up that point.

In my scenario customer was using IDM with GRC where he was only interacting to GRC prod for creating roles in S\4 hana development system and then was transporting the roles in quality and production.

They were using a naming convention for creating testing roles via BRM  in GRC development system i.e roles starting with name NP_<ROLENAME>. However, once BRM configuration was tested . Finally they were using only GRC production to create roles in development with naming conv PRD<ROLENAME>.  They have defined this in their process to use such naming convention and to use GRC prod only for BRM.

By defining such process at org level and educating the same to GRC core team, I don't see any issues or challenges even if backend is connected to multiple GRC system.

Regards

Kanika Gupta

[dave_w00d]

I know its been a couple years since this posted. I found your blog because I'm trying to determine how to add my non-prod boxes to GRC.

You also have to consider your sync jobs and manage those. We currently have 34 production systems attached to our prod GRC system. Managing and scheduling those sync jobs was tough.

So now I'd like to add all the DEV and QA boxes to GRC and as you can imagine adding 100+ to our production box probably won't work.

So I have couple options. Add a new client to my GRC production box. Or make one of my non-prod GRC boxes the main non-prod provisioning system?

Anyone have thoughts?

[vandana_maini]

Hi Dave,

What is the reason for moving your user provisioning to GRC? Is it the Audit requirement or the internal process to move the provisioning to GRC.

If this is Audit requirement, then you might have to consider using GRC Prod and increase the sizing for the GRC box. But if this is an internal process enhancement, then it would be best for you to consider using GRC QA box as one of the provisioning systems as this would not consume additional resources on the PRD system (Even a different client would consume resources)

I hope this helps.

Regards,
Vandana

[dave_w00d]

Thanks Vandana.

That does help. This is not a audit requirement we just need a solution for our non-prod boxes and since GRC is used and accepted by our end users it just makes sense for us.

Is there any note or recommendation from SAP? I've searched everywhere and can't find anything.

[vandana_maini]

Hi Dave, I do not believe so.