Nine out of ten posts on LinkedIn talk about Digital transformation and Cloud innovations today. While there is a lot of focus on digital transformation initiatives and products, the majority of organizations are still lacking the foundation for taking the giant leap into embracing the big change of SAP GRC for S/4 HANA.

Many SAP customers have started or are yet to start their arduous journeys towards S/4 HANA transformation. While S/4 HANA is a natural evolution from ECC, more focus should be on evaluating GRC for S/4 HANA than just upgrading, given the complexity of legacy systems, custom codes, and security roles.

This article highlights the importance of transforming application security in S/4 HANA, considering increased complexity, vulnerabilities, and the need for secure access to HANA databases and Fiori apps. S/4 HANA Security transformation considerations and evaluations can be summarized with a set of some basic questions and pointers:

• Is SAP GRC for S/4 HANA upgrade and enhancement part of the implementation roadmap?
• How will the existing roles and authorization objects change based on new Tcodes and table structures in S/4 HANA? What is the overall effort?
• Are there new access risks or changes to the existing access risks?
• S/4 HANA setup needs inherent access to associated Fiori apps and HANA database views/tables. How will these additional systems be provisioned “in-tandem” to ensure complete and consistent provisioning?
• How will elevated access be managed in S/4 HANA, HANA database and Fiori systems?
• Will roles exist as a system-specific composite or single role (as they used to be) or templatized in a role group with roles spawning in S/4 application, Fiori and HANA database in tandem?

Migrating to S/4 HANA requires integrating the new architecture with SAP GRC and Access Control, enabling user provisioning and risk analysis for HANA and Fiori systems. End users will need additional security roles to access these systems. Enabling provisioning functionality to these systems is imperative to ensure consistent end-user experience. The GRC workflows and configuration need to include additional systems in the automated user provisioning.

A real-life example can be quoted here. A “Buyer” (Purchaser) in a supply chain setup is a critical position and may require access to many business functions like sourcing, contracts, maintain/create catalogs etc. He may also have the reporting access to certain reports and dashboards. The access map for a Buyer in an SAP S/4 HANA environment may look like below:

The user who performs the Buyer role gets access to front-end Fiori apps. The associated backend application roles need to be assigned in the S/4 HANA system to this user ID. The user will need simultaneous access to specific HANA database tables, Fiori roles, and core applications for seamless functionality.

 With the S/4 HANA transformation so the existing GRC needs to be upgraded to 10.1 versions and the following needs to be considered:

1. New systems, namely Gateway (hosts Fiori) and HANA Database/s need to be added as a managed system in GRC
2. Configuration to add these systems in MSMP/BRF+ workflows to enable auto role provisioning
3. Ruleset to be considered for upgrade with new Tcodes and Authorization objects
4. Roles re-design to accommodate changes to Business processes owing to change in S/4 t code and table structures

A key decision in migrating to S/4 HANA is whether to keep existing roles and add Fiori content or create new roles. Whichever path is chosen, there will be a unique set of advantages and disadvantages to be considered.

Retaining the current role design can help maintain audit compliance, but requires replacing obsolete transactions and mapping Fiori service authorizations. Starting from scratch means Fiori Catalogs can be used to pull through the authorizations required for each app to work.

This saves effort but needs Fiori launchpad expertise and role reassessment to avoid Segregation of Duties risks.

S/4 HANA emphasizes simplicity by introducing a simple data model, consolidated business processes, and straightforward architecture.

The goal of S/4 HANA migration is simplification and performance improvement, but also careful analysis of the existing SAP landscape, security design, GRC systems, and customizations is essential. Migration should be a strategic decision, not just a simple upgrade.