Best Practices when Implementing Business Role Management for SAP GRC

When implemented effectively, Business Roles can also be integrated into wider Identity Access Management strategies, and align with the IdAM goal of ensuring the right access is assigned to the right users through simplification and automation, based on HR actions for Joiners, Movers and Leavers.

In a recent blog, we outlined the best practices for the initial analysis of Business Role Management implementation in SAP GRC. This blog tackles best practices for the next steps in this implementation, focusing on both deployment and hypercare.

Deployment

The deployment phase of business role management implementation is where existing roles are removed from all users and replaced by the Business Roles that have been created. Switching out roles can be a very time-consuming activity for systems with a large user base – ensure that system downtime or out-of-hours work is agreed with the business well beforehand and consider phasing the deployment if more time is required.

– User to role mapping

An essential document that should be produced as part of every business role implementation is the user to role mapping. Clear mapping will not only help during the deployment, but will remain useful during hypercare and well beyond.

In projects where there is a large user base and multiple Business Role assignments to be carried out, it is likely for misassignments to be made. The user to role mapping can be used as a validation document to check that access has been given correctly before go-live.

Further into the future, this document can also be referred to during user to role attestations as part of audit cycles. Questions regarding why a user has a particular role can be answered more easily, especially if there is a change request reference and business sign off attached to the document.

– New users, leavers and movers

Another point to consider is the possibility of new users, leavers and movers over the period of the project. This poses the risk of accidentally leaving out users that are new joiners, the assignment of the wrong access if the user has changed roles and confusion when finding users no longer exist because they have left the organisation.

Before the deployment, take user snapshots in each system and take note of any new users or leavers and any other user changes since the start of the business role implementation. Allow several days to talk to the business and get approvals for the changed users and request an access freeze until deployment so that nothing else changes in the meantime.

– The connector concept

Finally, the connector concept is extremely important with business roles – connections between the SAP GRC system and legacy systems must be maintained appropriately. Connectors provide the link between GRC and other systems so that they can talk to each other and GRC can be used for central provisioning.

The workflow relies on the system’s ability to identify the single role to business role mapping based on matching role naming with the design that has been fed into the system master data.

If legacy system connectors are still maintained within SAP GRC, the workflow could meet a remote function call error if the required single roles also exist in those legacy systems under the same names. Therefore, if connectors for legacy systems within the landscape exists, it is important that they are disconnected from the roles in the front end.

Hypercare

The hypercare period is critical as business role implementation introduces significant changes from both the risk management and access provisioning perspectives.

A robust procedure should be designed so that, if access has been provisioned incorrectly during the deployment, there are plans to swiftly rectify this, allowing users to continue with their business-critical processes.

This could be done by planning to revert to previous user access temporarily or assigning a new role whilst the business role is being corrected. Considering that this procedure should ideally be carried out as quickly as possible, it is a good idea to sort out firefighter access to the support team beforehand for the whole hypercare period. Responsiveness to the users’ issues and a clear level of ownership is key to the success

Conclusion

Business Role and Access Management is a powerful tool, and several factors must work together for the successful implementation and future use of the product. It is vital that business needs are presented as the key driver to implementing this technological change, where collaboration should aim to strike a balance with technical capability and security requirements through a risk-based approach.

Deploying the solution must take consideration of the numerous dependencies that come with access changes, especially in a live system, and proper tracking to ensure assignment accuracy.

Hypercare should be focused on an efficient and effective remediation strategy in the event that access is not adequate. Understanding the key aspects of each phase will help to ensure that the business fully reaps the benefits of increased automation and security that Business Role Management offers.