Using Preventive Controls to Strengthen Security and Compliance of Your SAP Ecosystem
SAP systems play a critical role in enabling core business operations, spanning finance, procurement, HR, and supply chain processes. As organizations expand their SAP landscapes through S/4HANA transformations and increasingly integrate with cloud and third-party applications, the complexity of managing access, compliance, and security has grown significantly.
In many environments, organizations continue to rely on traditional, detective-style controls such as periodic access reviews and retrospective Segregation of Duties (SoD) analysis. While these controls remain important for governance, they are inherently reactive and often identify issues only after access has been granted or business transactions have already taken place. This creates a growing need to rethink how security and compliance can be enforced earlier in the lifecycle of access and activity within SAP systems.
In this episode of the NextLabs Expert Series, Tiede-Jan de Jong, Associate Director of SAP Security & Controls at Accenture, discusses the role of preventive controls in strengthening SAP security and compliance. The conversation explores how organizations can address SoD risks earlier in the access lifecycle, common challenges that hinder effective prevention, and the impact of emerging technologies such as S/4HANA, automation, and AI on modern SAP security strategies.
About the Speaker
Tiede-Jan de Jong is the Secure Digital Core Lead at Accenture Netherlands, with over 20 years of experience in SAP Security, Governance, Risk & Compliance (GRC), and Identity & Access Management. He leads a team of security professionals focused on helping organizations secure their SAP landscapes, support S/4HANA transformations, and implement effective security and controls frameworks. Tiede-Jan is a recognized thought leader in the SAP security community, a frequent speaker at industry events.
Read his perspective below, watch the Q&A video, or listen to the podcasts on Spotify.
Why are preventive controls such a critical part of strengthening security and compliance in the SAP environment?
Preventive controls are critical because they stop risk before it materializes rather than identifying it after the fact.
In SAP, once access is granted or a transaction is executed, the impact is often immediate. Financial postings, master data changes, or payments are not always easy to reverse. If a payment has already been made, for example, it can be difficult to undo the consequences.
Traditionally, many organizations rely on detective controls. These controls are typically manual, often human-based, and can be time-consuming and error-prone. They also depend on periodic access reviews, sampling, and interpretation, which can introduce inconsistencies and increase risk.
Preventive controls reduce this dependency by embedding control logic directly into SAP. By enforcing controls before actions occur, organizations can strengthen compliance and reduce the likelihood of security and access-related issues occurring in the first place.
Segregation of Duties (SoD) is a major compliance concern in SAP systems. How can preventive controls help organizations address SoD risks before they become a problem?
Typically, we categorize controls into can-do controls and SoD did-do controls.
Can-do controls and solutions are used to perform Segregation of Duties (SoD) analysis to identify whether a user could, in theory, execute a transaction or use a Fiori app. They can then show whether users have access to two or more conflicting activities.
SoD did-do controls, on the other hand, are data-driven controls. They look back retrospectively and are used to determine whether a user actually breached an SoD conflict.
The data queries used for these analyses are typically based on information captured in tables, change documents, and other logs. This information can be used to determine whether a user, for example, posted an invoice against a purchase order that he or she created.
Preventive controls provide an additional category. They build on the first two approaches, but the key difference is that they block conflicting activities before they occur.
This can happen at the front end when somebody requests a role. An SoD analysis can be performed during the request process, allowing conflicts to be identified and prevented before access is granted. Preventive controls can also operate in real time within the system, blocking certain actions from occurring altogether.
What are some of the common challenges organizations face in trying to anticipate and prevent SoD conflicts during access provisioning or role design?
Organizations face multiple challenges. Often, when people are changing roles in development and promoting them through to the production environment, it is not always the case—often not even the case—that these roles are analyzed for segregation of duties conflicts.
Also, in large programs like S/4HANA transformations, we see that roles are built and tested first, while the SoD matrix is defined afterwards. That is a bit behind the fact.
Another challenge is that business processes today span multiple systems. SoD risk analysis is often focused on single systems. For example, if a business process starts in Ariba and then continues in S/4HANA, it is not always straightforward for organizations to evaluate conflicting activities across those systems.
Even for user provisioning, especially in hybrid landscapes, it is not always the case that SoD conflicts are analyzed before provisioning is done. For S/4HANA or ECC, this is often more standard. But as soon as you add cloud applications or non-SAP systems, it is not automatically done.
As a result, SoD conflicts are often detected late. They are handled manually if handled at all, and this is an area where, with some improvements, a more preventive approach could help.
How can organizations implement preventive controls to stop SoD violations at the source before access is granted?
So preventive SoD controls should be embedded directly into role design or during user access provisioning, as explained earlier. This includes defining SoD rules that are aligned to end-to-end business processes, not just purely based on Fiori app or transaction code.
We should perform real-time SoD checks during role build and user provisioning, and use workflows to block risky access requests and ensure the right approvals are in place. Prevention should also be extended across SAP and non-SAP systems.
Additionally, if an attribute-based access control (ABAC) solution is used, SoD conflicts can be prevented through that technology. ABAC allows controls to consider factors such as roles, system activities, data, and process states to ensure that conflicts are prevented from occurring, rather than detected after the fact.
For companies looking to enhance their SAP security posture, what is a first step toward using preventive controls more effectively?
The first step is to identify which SoD conflicts are inherent to the business process and which are accidental. Some conflicts exist because of organizational realities or process design and cannot simply be eliminated through technology. That’s how the business operates.
If the process itself requires conflicting activities, trying to prevent them using preventive controls will definitely fail because the business always comes first. It needs to process business transactions.
So, I would say let’s start by identifying which SoD conflicts are structural and which are not accidental. Work with the business, and through change management, see whether you can adjust processes, responsibilities, or approvals.
Then decide which critical SoD conflicts must be prevented, and which require a potential process change. Once we have set this foundation, it makes sense to introduce preventive SoD controls, because prevention works best when the business also supports the model.
With developments like SAP S/4HANA and AI-driven monitoring, how should organizations adapt their preventive controls to future-proof their SAP security posture?
It’s starting to be a totally different ball game. We have S/4HANA, we have AI, RPA. So, SoDs are no longer limited to conflicting human activity.
Through automation, the control landscape is shifting as AI and RPA increasingly automate process steps. You also need to look at batch users, technical users, and workflow users, and these should become part of the SoD equation.
As organizations increasingly adopt automation, AI agents, APIs, and robotic process automation, non-human identities become just as important as human users in the SoD model. Preventive controls must therefore govern both human and machine-driven activities across the business process lifecycle.
You should also consider that conflicts may now exist in workflow agents, assignments, master data assigned to workflows, decision tables versus transactions, and Fiori apps. It’s just not between conflicting codes anymore.
SoD now spans the entire process, including where automation starts and where it ends. That is a very important statement. Preventive control models must therefore extend beyond traditional role-based conflicts to cover workflows, approvals, background users, system users, workflow users, batch users, RFC users, and other automated actors involved in business processes.
So, look across human and non-human actors, not only roles.
To conclude, preventive controls shift SAP security from reviewing what went wrong to designing processes where risks cannot happen in the first place.
Thank you.
Thank you, Tiede-Jan, for sharing your expertise.
Discover more from NextLabs’ Expert Series, featuring industry experts in educational and thought-provoking conversations on Data-Centric Security, Zero Trust Architecture, Safeguarding AI, and more.
To comment on this post
Login to NextLabs Community
NextLabs seeks to provide helpful resources and easy to digest information on data-centric security related topics. To discuss and share insights on this resource with peers in the data security field, join the NextLabs community.
Don't have a NextLabs ID? Create an account.