How should security teams enforce segregation of duties in SAP environments?

How to make SoD enforceable in SAP, not just reportable

Segregation of duties works in SAP only when the conflict logic is built into role design and access request handling. Define which combinations are toxic, encode them as rules, and make the request path check them before assignment. That prevents risky access from being created in the first place, instead of relying on after-the-fact audit review.

That also means the rule set has to reflect how SAP access is actually used, including composite roles, transaction-level permissions, emergency access and cross-application dependencies. A static policy that ignores those paths will miss the combinations that matter operationally.

For an implementation reference on the control model, the IAM and IGA Basics guide explains how authorization, entitlement governance and access reviews fit together when SoD is being enforced rather than merely documented.

Why SAP role design is the real SoD control point

In SAP, SoD usually fails when teams treat role engineering as a packaging exercise instead of a control design exercise. If one role bundle can accumulate purchase, approval, vendor maintenance and payment functions, the conflict is already present even if the underlying transactions are individually “approved”. The control objective is to keep incompatible business powers separated across roles, users and escalation paths.

That is why approval workflow matters as much as the role matrix. If a conflict can be overridden without a compensating control, the business has created an exception process that can bypass SoD whenever pressure is high. A good design distinguishes ordinary access from emergency or temporary access and makes the exception visible, time-bound and reviewable.

For SAP-specific access patterns, SAP Identity and Access Security Guide is the most direct internal reference for role design, firefighter IDs, SAP GRC and SoD handling.

How to keep SoD effective over time

SoD is not a one-time configuration. It degrades when roles drift, new transactions are added, emergency access is copied into steady-state access, or business processes change faster than the control catalog. Periodic review should therefore test both the role content and the underlying business process that the role enables.

Good practice is to review toxic combinations at three points: when access is requested, when roles are changed, and on a recurring certification cycle. That gives teams a chance to stop new conflicts, detect conflicts introduced by role redesign, and catch exceptions that have outlived their business need. For environments with large role estates, the review also needs ownership, because no SoD model stays current if every exception is someone else’s problem.

The broader principle is covered well in the Core Security Principles Guide, which frames separation of duties as a control that should fail closed rather than rely on downstream detection.

Risk and Threat Considerations

SoD failures in SAP usually create business-process abuse rather than a purely technical security issue. When one identity can both create and approve a transaction, or maintain a master record and release payment, the environment is vulnerable to fraud, unauthorized change and concealment of wrongdoing. The risk increases when emergency access is broadly available or when compensating controls are informal.

Failure mechanism: Toxic combinations slip through because the rule set is incomplete, the workflow does not enforce the rule, or a compensating control is treated as a permanent substitute for real separation. Role drift and emergency access reuse are common ways the control quietly collapses.

Impact: Organisations can lose the ability to trust SAP approvals, postings and master data changes. That raises fraud exposure, weakens audit evidence and makes it harder to prove that conflicting duties were actually separated.

Practitioner Guidance

What to verify: Verify that the SoD catalogue is machine-readable, mapped to real SAP roles and transaction combinations, and enforced in the request path rather than only in reporting. If a conflict is only found after access is granted, the control is detection, not prevention.

Decision rule: If a conflict is operationally unavoidable, require a documented compensating control with an owner, expiry date and review cadence. If those three elements are missing, treat the exception as an open risk, not an approved mitigation.

What practitioners underestimate: The hardest part is not identifying conflicts, it is maintaining the rule set as SAP roles, business processes and emergency access patterns evolve. A stale SoD matrix gives false comfort because it looks complete while no longer matching how access is actually used.

Practitioner takeaway: Enforce SoD in SAP by making conflicts impossible to grant silently, and make every exception temporary, attributable and reviewable.

Related resources from NHI Mgmt Group

• Guide: Segregation of Duties (SoD) Guide
• How should security teams enforce segregation of duties in IAM workflows?
• How should security teams implement segregation of duties automation in hybrid environments?
• How should security teams implement segregation of duties in multi-cloud environments?
• How should security teams enforce segregation of duties in IAM?