Five Steps to a Secure & Successful SAP S/4 HANA Migration

Migration to S/4HANA brings myriad considerations for the SAP-driven enterprise, with the issue of security right at the top of the agenda. Security is inherently linked to an improved and consistent user experience (UX) on offer through Fiori and so can be one of the key success factors for migration to S/4.

Far from just an upgrade, the move to S/4 has a significant impact on security and role design for end users – and any organisation attempting to tackle HANA’s security challenges must take a methodical approach to keep the business fully protected. Security cannot also be decoupled from the frontend UX, so it will be critical to include this in success criteria for any SAP S/4 HANA project.

In this blog, we’ll look at the process behind a successful S/4 migration from a security perspective, broken down into five key stages.

Ideal for SAP customers taking a ‘Brownfield’ approach (migrating from ECC 6 to S/4), this five-step guide also provides a useful reference for brand new ‘Greenfield’ implementations.

This very practical guide has been created to help SAP customers understand the new security considerations that come with implementing SAP S/4 HANA. Read ‘Safety first: Security for SAP S/4 HANA’ by clicking here.

Step 1: Understand your SAP ECC usage data

For those opting for a Brownfield migration approach from SAP ECC, the first stage is to analyse and understand your ECC usage data for any of the business processes that are not going to be fully redesigned as part of the implementation.

Where business processes are being redesigned or opting for a fresh Greenfield implementation, the SAP ECC usage data is still be valuable to help inform on new process designs from a security perspective.

By benchmarking the usage data from your ECC system for business processes that are not being redesigned, you can then begin to map that usage to how it might need to look in S/4 HANA.

By establishing this benchmark you are creating a framework on which to build your new S/4 environment. In short, you’ll be able to look at your previous usage data and design the new environment to meet the same needs.

Step 2: Assess ECC Usage Data and align to any retained Business Processes

Utilising previous ECC usage data does have a variety of complexities to overcome before it can become a valuable informing tool on future business process designs for S/4.

Firstly, there are fundamental changes to the list of available transaction codes in S/4  when compared against the transaction codes in ECC. Some ECC transactions have been marked as obsolete or replaced in S/4 HANA, in addition to some functional areas being consolidated, so attempting to rely on ECC’s existing transaction code role assignments to determine access in SAP S/4 HANA is not a viable option, therefore a transaction code remapping exercise is required at a first step.

Secondly, some of the retained business process designs will need to be revised due to the functional changes within S/4 , in addition to the transaction code changes. This requires close alignment with Business Analysts and SAP Security teams to understand functional changes to business processes that will consequently require revisions to role designs.

Thirdly, the security design concept within ECC does not accommodate for changes within the new exposed Fiori user interface, within S/4 HANA. Although access through SAPGUI can still be retained, this does not improve the overall UX for end users. Changes will be needed to roles to accommodate for the Fiori App assignments.

Step 3: Assess the fit with SAP’s standard S/4 HANA roles

The second step for a Brownfield customer (and the first for a Greenfield implementation) is to look at the S/4 roles delivered as standard by SAP.

With only 170 standard roles in S/4 – compared with around 4,000 roles in ECC 6 – it’s clear that S/4 HANA’s standard roles are not sufficiently segregated to minimise risk. You’ll therefore need to undertake the exercise of splitting out those roles to meet your access requirements.

Where possible, try to understand where the segregation of duties lie across those standard roles, and create derivations from the standard list.

Failure to do this from the start can mean introducing significant access risks to your new-look SAP landscape.

Step 4: Perform a risk gap analysis and create mitigating controls

Even once roles have been split out for greater segregation, it’s likely that some risks will have to be tolerated – often because roles cannot be split down to the apposite level of granularity without impairing day-to-day operations.

It’s therefore vital to identify where risks exist within certain roles – and to address the risk by putting controls in place.

This is often the case in supporting roles (for instance within the finance function), where high-level access is afforded to users who may only actually need it in the event of others being away from the business.

This can afford the user largely unnecessary access across the entire finance function, providing the potential for considerable business disruption – but these risks may need to be accepted in order to maintain continuity when primary users are away.

Where such conflicts are identified, mitigating or compensating controls must be designed and implemented accordingly.

Step 5: Evaluate the impact of SAP Fiori

A key final consideration in the security element of S/4 HANA migration is the impact of SAP Fiori – SAP’s new primary user interface for S/4.

Due to the architecture of the new technology, security of the user interface itself must now be taken into account when designing back-end roles.

SAP delivers standard Fiori content and Fiori catalogues. Catalogues essentially provide access to the Fiori applications, requiring security teams to map the catalogues to the appropriate roles.

As a result, security teams are having to take on double the amount of role maintenance; transaction codes, authorisation objects and Fiori Apps.

Many service integrators do not tackle this challenge effectively and default to recommending the implementation of the SAP standard business roles rather than adopt a security-by-design approach.

While this might sound good in theory (and indeed may work adequately in the short term), problems will soon be encountered as users start to move around the business. The problem is that the standard roles provide a wide range of access across too many FioriApps, which would otherwise be segregated if an organisation’s Security team followed best practice SAP security design concepts.

That’s because unless you’re continuously maintaining the back-end roles, individuals who change position or role within the organisation may find themselves gradually exposed to more and more Fiori apps – without intended authorisation.

It’s the price you pay for leaving the Fiori floodgates quite literally open.

To guard against this scenario, teams must therefore not only appropriately assign the Fiori catalogues and apps to back-end roles as part of the migration process – but put processes in place to ensure back-end roles are properly maintained going forward.

Summary

The user experience is a key success criteria driving organisations to migrate to SAP S/4 HANA, however this comes with considerable implications for security, role design and user access. With the potential costs of data loss, theft and business disruption at an all-time high, those implications demand some serious thought.

Naturally, any move to S/4 will bring its own unique challenges . But by following the five pragmatic and practical steps above, you can ensure the robustness of your SAP set-up – allowing you to explore the business benefits of HANA, without exposing the organisation to increased risk.

This very practical guide has been created to help SAP customers understand the new security considerations that come with implementing SAP S/4 HANA. Read ‘Safety first: Security for SAP S/4 HANA’ by clicking here.