cancel
Showing results for 
Search instead for 
Did you mean: 

What is correct way to retire system from SAP GRC ?

Trinetra_Bhusha
Active Participant
0 Kudos

Hello,

We all face scenarios where existing system gets retire due to SAP licensing or new application (like ARIBA replace SRM). We want to keep all the Access Request data from SRM for Audit purpose but also would like update GRC SPRO to remove SRM specific config. I generally follow below approach please add if you think any more:

Remove system from Connector Group

Remove from all Integration Scenario

Remove from Maintain Connector settings

Remove from Default connector List

Thanks,

Trinetra

Accepted Solutions (0)

Answers (1)

Answers (1)

Colleen
Advisor
Advisor

G’day Trinetra

Interesting Question and hope others jump here. Here’s my thoughts (I’m not part of product team to see if they have a specific recommendation).

I would not remove the connector from configuration whilst there is master data, transactional and historical data associated with the connector. You may find it difficult to report and retrieve the data from the front end (e.g. how can search for the connector if it doesn’t exist in drop down).

I would see 2 phases for removal: (1) Logical Removal and (2) Physical Removal. What you’ve proposed is more of what I’d look at for step 2.

Phase 1 – Logical Removal – keep the data and reporting capabilities but remove updates (to the user it's either doesn't exist on the front end or it's limited read only use)

  • 1. IMG Configuration

a. Do not remove the actual connectors

b. Consider updated configuration parameters to remove any default or higher sort preferences

c. Consider updating data source configuration to remove it from here

d. Possible change default connectors depending on your logical group setup but if you are decommissioning SRM then I assume all connectors in the group should be removed (but do recognised it might be staged)

e. Do not touch integration framework and other mapping areas (would do this for physical removal)

  • 2. Update user authorisations remove access to connectors and/or limit to display only for key teams

a. There are some system connectors or logical systems

b. Consider template requests if they are system specific, etc

c. Goal is to prevent the connector appearing in access request, etc. You

  • 3. Copy/Extract/Archive any data that is no longer required
  • 4. Suspend periodic jobs and other housekeeping jobs for that connector such as (there are others)

a. Email reminders

b. Batch risk analysis

c. Object repository sync jobs

d. Auth sync jobs

  • 5. Dummy SM59 RFC Connection to make is inaccessible (keep the entry for config but remove user credentials and change the host name if it’s only used for GRC connections)
  • 6. Access Risk Analysis

a. Optional to delete generated rules if risk analysis reporting is no longer needed (reduces table size)

b. Optional to set all access risk or functions for the logical system to inactive so no risk analysis can occur.

c. Cancel any batch risks analysis jobs

d. Option to delete violation data, if no longer required

  • 7. Access Request Management

a. Update and remove any default rules relating to configuration or BRF+ rules

b. Update MSMP workflows if they contain the old system. Can always add a new routing rule just in case

c. Update and remove any Request Templates from the System

  • 8. Business Roles Management

a. Configure a Role type of Decommissioned and make it not productive (cannot be chosen in an access request)

b. Mass all technical roles for the connector to have role status as not productive – this will stop them appearing in an Access Request

c. Remove technical roles form business roles (again stops system trying to provision them)

d. Change or remove Role Owner

e. Activate the configuration parameter to include comments so you can reference the RFC/Change number to recognise this is historical data.

  • 9. Emergency Access Management/Firefighter

a. Remove all FF Ids, FF Users, and FF Controllers, and FF Owner assignments to the related FF Ids for the system.

b. Note – later version of audit/change documents record this action so removing users still retain the audit log

  • 10. MSMP Workflow/BRF+

a. As mentioned – review configuration to see if you need to remove or add any specific rules relating to this system

b. Cancel any in flight workflows that may have been orphaned

  • 11. Data Deletion

a. Have mentioned it throughout

b. What you delete here needs to consider business requirements for data retention policy rules in conjunction with SAP recommendations (i.e. deleting technical role data that is in a business role may cause issues).

c. As part of this you can identify the data minimisation opportunities as well – what is the mandatory data you need to retain.

  • 12. Other Integration - confirm not other upstream or downstream systems use the data (e.g. SAP IdM, SailPoint, etc). If so, work with those teams to remove the references

Phase 2 – Physical Removal – system is no longer needed and all data is retried / unlikely you need to search or report on it. Might take a while to get to this stage

Note: change document/logs, SLG1, etc won’t be touched here

  • 1. Confirm data no longer required (as per data retention policy)
  • 2. Run deletion jobs (SAP notes provide the steps) to delete the rest of the data again the connector
  • 3. Remove Connector from IMG Configuration

Anyway, quick brain dump of my approach. I’m sure there are gaps so would love to see others jump in on this thread

Cheers

Colleen

Trinetra_Bhusha
Active Participant

Hi Colleen,

Very good points and explanation and this is very helpful. I have few observations on above:

6.Access Risk Analysis: I believe we can use the GRC program “GRAC_DELETE_ACCESS_RULES” (Note 2268795)?

9. Emergency Access Management/Firefighter: You have mentioned to remove all FF Ids, FF Users, and FF Controllers, and FF Owner assignments to the related FF Ids for the system. If we do that don’t, we lose the ability run reports on EAM, Same like if remove connector we cannot run some front end reports?

Phase 2 – Physical Removal:

As per SAP note 2075597 - GRC AC - How to delete specific system from SPRO. “You can also deactivate the connector instead of deleting the connector”.

I am not sure about what they mean by “deactivating connector”, can you share your thoughts?

Trinetra