SAP has proven itself to be an impeccable program. Many organizations are switching to SAP and SAP enabled solutions. However, the move to SAP/4HANA isn’t something that can be knocked out in a day. It’s something to be taken seriously and its implementation requires significant effort. In particular, security is something that should be considered properly during the implementation process. The new environment you are moving to should be clean and secure from the first day forward.

Here are a few of the common security challenges that organizations are bound to face with the switch to SAP/4HANA.

Critical Access and SoD Risks

While SAP has won many awards for its groundbreaking software design, there is no such thing as one-size-fits-all. You need to realize that every single organization is different. The tools provided by SAP need to be tailored to individual businesses. Hence, the standard tools are unlikely to provide the level of security needed by every single organization. The Segregation of Duties (SoD) risks are very likely to be present during the shift to SAP/4HANA. This is a given, since the much wider access to apps when the move is finally made and finalized.

If the roles aren’t segregated into several other technical roles, the underlying risks aren’t addressed. If that’s the case, then the new SAP/4HANA environment is exposed to risks from day one.

The standard advice from SAP is to adapt their current roles to the 170 new roles that are provided by SAP. This approach isn’t for every organization. There are two risks that it overtly neglects which are SoD and sensitive access.

SAP can’t possibly know the individual circumstances and needs of every single organization. Like most big software houses, they deliver for the bulk consumers. Another complication that throws a wrench into the mix is SAP Fiori. The interface of the program is designed to simplify the look and feel of the activities of SAP. SAP professionals don’t focus on this layer because they assume there’s no need to. The lack of application of security controls to this layer can mean direct conflict with the core of SAP/4HANA

Identification and Remediation of SAP/4HANA Access Risks

The building of certain roles in SAP/4HANA is very similar to ECC. There’s very little context-of-access risk during the build process. Hence, the right tools that can be used to identify the risks aren’t present. They’re usually provided after an audit takes place and a lot of damage can be done in that period.

Consider the fact that as soon as the move is made and the system is up and running, users will be given the reins. This will leave your entire system vulnerable to hacking and theft, and your users as well. You’re potentially creating hundreds of problems for yourself that may require a lot of remediation and a lot of money. You need to ensure that the roles for the outset of SAP/4HANA are clear for the project.

SAP ECC Access to Benchmark SAP/4HANA Design

Process owners for different functions across the SAP/4HANA environment won’t all have a proper understanding of the access. They would’ve most likely been given this access by other users from the previous ECC systems. It’s impossible for them to understand the clarity of their roles immediately.

This means that certain SoD risks hidden in the ECC environment can be shifted to the new environment. Remedying this in the beginning would be the best course of action. However, most shifts are bereft of it. This leaves your system open to a lot of unnecessary threats.

Lack of Role Design and Controls Knowledge

SAP’s standard roles will be recommended to any organization that is making the shift to SAP/4HANA. However, it’s true that a lot of organizations are provided access to the Fiori. This is in the hope that the controls at the back-end will restrict access when it is mandated. This is very unlikely to be a strong defense or an appropriate level of security for your organization. It can result not only in damages and theft, but also in a bad user experience.

A lot of past ERP implementations were never allowed the importance of security. Security was restricted to being an afterthought. This often meant that a lot of costly security remediation had to be made afterwards. The same story can repeat today.

It’s very important to remember that when your users will actually begin using the new system, they will expect security. At which point, the security and controls of the program will become vital to your organization. Considering the fact that the data is your organization’s most critical asset, it’s ill-advised to not protect it.

Redesigning Business Processes

The move from SAP ECC to SAP/4HANA represents opportunities to redesign business processes. This is something that most organizations will have to take up at some level. Implementing this will impact the way that certain roles are designed.

Simple lifting and shifting is never sufficient. It requires that you completely redesign the roles that your processes are bound to take. Neglecting redesign at this stage will lead to changes that will be made further down the line; a problem  to be avoided at all costs.

In a few cases, the new business processes have to be mandated through technical changes. Those changes, which will eventually be made to the underlying solutions, can introduce Fiori-based fact sheets applications. These reside on the database of HANA and will be documented. Technical changes can be made to models based on the gathered data, however, which can include the moving of certain tables or the replacement of some key transactional data. Some fundamental activities may be amended this way.

However complicated they may seem, these security challenges can easily be tackled through the tools of customization and optimization.