Three Essential Security Considerations for Your SAP S/4 Implementation

Reading time: 6 mins

Meet the Experts

Key Takeaways

⇨ Organizations move to SAP S/4 is to take advantage of the innovations

⇨ Partner with system integrators to achieve efficient SAP S/4 implementations

⇨ Consider security needs five or 10 years hence

SAP S/4 implementations can and do bring improved operational efficiency to organizations, but only if they get their implementations right. Given the speed of innovation, new cyber threats, and a changing regulatory landscape, managing risk is a central challenge to SAP S/4 implementations. With SAP S/4, what was once the organization’s core ERP has become both broader in scope and more heterogeneous.

As a result, implementation efforts must include careful consideration of security, compliance, and controls issues to fully integrate the design and deployment of S/4 with the larger ecosystem. It is critical that the implementation team shares a common vision for these matters for both cloud and on-premise systems to properly secure the environment end-to-end.

When an organization decides to implement SAP S/4, it may actually be implementing several integrated SAP products. It will certainly implement thousands of new and custom transactions. If the organization is replacing an earlier version of SAP, it will combine some of its current installation’s features and functions as it goes. SAP S/4’s new Fiori user interface adds a new, more intuitive layer to SAP.

Taken together, SAP S/4 implementations involve many changes to the user experience: it is a dramatic degree of change that requires a broad set of skills from a cross-functional implementation team. Likewise, the newness of the Fiori interface calls for careful consideration of security as a matter of risk management, but also to ensure user adoption.

Lastly, many teams prize speed of implementation above all else, but that interest must be balanced with a deliberate approach to security, compliance, risk management, and controls. These efforts must proceed in parallel with implementation from the outset of the project.

Security, the Business, IT and Everyone Else

There are hackers who would love to access any organization’s premier system of record. It is therefore essential to consider security for SAP S/4 in every step of its implementation process and establish the tools to monitor and manage the security of new systems once they are in operation.

Some organizations might make the mistake of seeing their SAP S/4 implementation as a pure IT project and assign participants only from IT with limited participation from the business. What is needed, however, is shared responsibility among IT, financial controls, compliance, audit, risk, security, and the business to contribute to a comprehensive security design that accurately mirrors business operations. Organizations do best when they consider the design of cohesive controls to be as essential to the project as delivering business value.

Security tools include not only technology, but also involving the right processes, governance, and people in the implementation and ensuring that everyone understands their roles in risk management efforts. SAP S/4 implementation projects must have the right risk mitigation measures in place as the system goes live. This calls for embracing the fundamental principles of security by design and ensuring that risk management efforts are informed by a clear understanding of the organization’s risk appetite.

Security is always the company’s responsibility. The company, not the cloud solution provider, must govern access to systems: defining the security model, managing identities, and authorizing access. Whether the organization plans to make use of managed business services or use its own staff, security must be a key focus of the development life cycle.

Planning the SAP S/4 implementation effort calls for including the right skills from the beginning. These include not only IT and the business, but also financial controls, compliance, audit, risk, and security. All of that expertise is essential to ensure that the project incorporates security considerations from the beginning, such as:

  • Implementing the security features SAP S/4 offers
  • Developing code that is secure from a vulnerability perspective
  • Following a DevSecOps approach that integrates security reviews into the development life cycle

Security, Fiori, and User Adoption

One reason organizations move to SAP S/4 is to take advantage of the innovations it delivers. Those innovations are meaningless unless trained, confident users make full use of new features. What users learn first is likely what they will continue to use, so fostering user adoption of new features early on is critical.

With SAP S/4 comes Fiori, a user-friendly, tile-based front end. Fiori delivers more functionality to users than SAP’s prior user interface. Why is this a security matter? SAP S/4 security defines the initial layout each user has. What is defined in the security model drives user experience with the system: what they see, the actions they are allowed, how they navigate, and how their jobs are shaped.

User adoption succeeds when users feel well-equipped, trained, and confident. Security is the lever by which the implementation team can promote use of Fiori’s new features to realize the full potential of the interface. Conversely, granting incorrect access can do more than merely frustrate new users. Granting access to the wrong functions or data exposes the organization to a range of risks, including compliance failures.

With Fiori comes a need for new skills to secure the environment—a need that many established SAP professionals are not yet equipped to provide. Traditional SAP security revolved around securing transactions and authorization objects and used to be fairly self-contained as far the technical implementation was concerned.

However, with Fiori in the picture, the challenge for most organizations is in keeping up with the new skills required to secure the Fiori layer, collaboration with Basis and development teams to drive the user experience, and the interaction and understanding from the business in driving the business role definitions to be used with the Fiori layer.

Every organization considering a S/4 HANA implementation faces these challenges. If not addressed, they lead to technical debt that is very hard to overcome without significant effort. They can lead to low user adoption as well as compliance failures, as risk owners do not understand what is expected from them.

Security versus Speedy Implementation

Organizations will want their SAP S/4 implementations to take advantage of new applications and features, and to derive full benefit from the efficiencies and innovation they offer. Another equally important objective must proceed in parallel with delivery of business value: the SAP S/4 implementation must also take a long view of security and risk. From initial planning, SAP S/4 implementation projects do well to consider security needs five or 10 years hence. Project teams can build in flexibility by getting foundational security elements right.

Many organizations choose to partner with system integrators to achieve efficient SAP S/4 implementations. For many organizations, system integration services are essential, but they come with this caveat: a system integrator’s objective may be to implement SAP S/4 as rapidly as possible with security being an afterthought or at least not a priority during the implementation.

This imperative comes at the cost of not fully integrating the security in testing, putting a poor security model in place, and underutilizing new features by duplicating a prior implementation’s configuration. This results in deemphasizing security considerations throughout the life of the project which is not sustainable for the business post go-live.

It is not unheard of for SAP S/4 implementations to be rushed all the way through to go-live, only to have an auditor observe excessive accesses, insufficient segregation of duties, or other security or compliance flaws. When observations like these come late in the project, they can be impossible to remediate. Correcting such errors may call for full-blown redesign—with all the retesting that redesign implies and incurring a separate change management effort to get the users onboard with the new security model.

Considering Security from SAP S/4 Project Inception

When organizations choose to implement SAP S/4, they take on a system design and user interface that are significantly different from prior versions of SAP. The degree of change that SAP S/4 brings to organizations warrants careful consideration from security, compliance, and risk management points of view. Integrating these viewpoints throughout project efforts ensure that system controls are sufficient. Prioritizing security also aids with user adoption of all the innovation SAP S/4 has to offer.

It is therefore well worth it to consider security and compliance from the project’s inception and ensure that compliance, risk, and security skills and interests are represented from SAP S/4 project planning onward. For some organizations, this may mean seeking external expertise to represent these perspectives for the project.

Contributions from Mithilesh Kotwal and Kyle Wechsler

To learn more about our SAP consulting services, contact us.

More Resources

See All Related Content