An auditor pulls a sample of ten users and finds three who can create a vendor, post the invoice, and release the payment without a second approver. This is not a hypothetical audit finding; it is one of the most common gaps discovered during SOX and internal control reviews across SAP landscapes.
Segregation of duties SAP controls are frequently assumed to be enforced simply because a GRC tool is installed, when in practice the ruleset is outdated, the risk analysis job has not run recently, or mitigating controls were approved years ago and never reassessed. IT managers, SAP security leads, and compliance officers running S/4HANA, SAP GRC Access Control, or SAP Cloud Identity Access Governance need a clear way to verify whether SoD is actually working rather than just configured. This article explains why enforcement gaps happen and how to close them with a structured, technically grounded approach.
Why This Problem Happens
Segregation of duties in SAP is often treated as a one-time project delivered during implementation rather than an ongoing control that requires continuous validation. A ruleset gets loaded, risk analysis runs once during go-live, remediation happens for the highest-risk conflicts, and the program is declared complete. Over the following months, role changes, emergency access grants, and new Fiori apps introduced through system upgrades quietly reintroduce conflicts that nobody is actively monitoring, because the periodic access review cycle was never operationalized as a recurring job.
S/4HANA migrations make this worse in a specific and predictable way. Moving from ECC to S/4HANA changes the underlying role model, introduces Fiori-based authorization concepts, and adds embedded analytics that did not exist in the legacy landscape. Legacy roles carrying hidden conflicts often migrate directly into the new environment without being redesigned, which means an organization can complete a technically successful S/4HANA migration while carrying forward every SoD violation that existed before the project started.
Cloud modules such as Ariba, SuccessFactors, and Fieldglass add a second dimension to this problem, since cross-system conflicts between an on-premise S/4HANA role and a cloud procurement role are not visible unless the ruleset explicitly covers cross-application risk.
A third reason enforcement gaps persist is a technical one specific to SAP GRC Access Control and SAP Cloud Identity Access Governance. Risk analysis in SAP Cloud Identity Access Governance depends on business function groups being correctly mapped to connected target systems, and without this mapping the Access Analysis Service cannot calculate risk scores at all, even though the system may report as configured.
Organizations running the bridge scenario between on-premise Access Control and cloud IAG also depend on a working Risk Definition Sync Job to keep rulesets aligned, and when that synchronization job fails silently, cloud risk results simply stop reflecting the current on-premise ruleset without triggering any visible alert.
Solution: Validating and Enforcing Segregation of Duties in SAP
Enforcing segregation of duties in SAP requires treating it as a control lifecycle with four connected stages: ruleset accuracy, access risk analysis, remediation or mitigation, and continuous monitoring. Each stage depends on the one before it, and a weakness in any single stage undermines the entire program even if the other three appear healthy on a dashboard.
The SoD Control Lifecycle
| Stage | Purpose | Key Risk If Skipped |
|---|---|---|
| Ruleset Accuracy | Ensure the SoD ruleset reflects actual business processes, not just SAP-delivered defaults | Risk analysis reports “clean” while real conflicts go undetected |
| Access Risk Analysis | Run checks at user, role, and request level | Historical access conflicts are missed if only request-time checks are used |
| Remediation / Mitigation | Redesign roles or apply compensating controls for unavoidable conflicts | Mitigating controls pile up without ever reducing actual risk exposure |
| Continuous Monitoring | Recurring risk analysis jobs and periodic access reviews | Clean state silently degrades as roles, org changes, and new modules are rolled out |
Validate the Ruleset Before Trusting Any Risk Report
The starting point for genuine enforcement is confirming that the SoD ruleset actually reflects the current business process landscape rather than the default SAP-delivered content. SAP ships standard rulesets for landscapes including R3, S4HANA on-premise, S4HANA Cloud, BASIS, HR, Ariba, SuccessFactors, and IBP, and these standard rules cover common conflicts but rarely reflect an organization’s specific process design, custom transaction codes, or industry-specific risk tolerance.
A manufacturing company running goods movement and inventory adjustment processes through custom transactions needs those transactions explicitly added to the ruleset, or the risk analysis will report a clean result while a real conflict sits undetected in production.
Custom rulesets should be built by exporting the standard ruleset, adding organization-specific risk definitions under a distinct business function group naming convention, and re-importing the file rather than editing standard content directly. SAP recommends keeping each risk definition limited to two or at most three functions, since risk definitions with more functions create performance strain during large-scale access analysis runs across thousands of users.
Because there is no built-in transport mechanism for moving a ruleset between non-production and production IAG systems, organizations need a documented manual process for promoting ruleset changes, or configuration drift between environments becomes its own audit finding.
Run Access Risk Analysis at User, Role, and Request Level
Once the ruleset is accurate, risk analysis needs to run consistently at three levels rather than only at the point a user requests new access. User-level analysis identifies conflicts that already exist in production, role-level analysis identifies conflicts baked into a role’s authorization objects before that role is ever assigned to anyone, and request-level analysis prevents new conflicts from being introduced during the provisioning workflow itself. Organizations that only check risk at request time, and never re-run analysis against existing user assignments, consistently miss the largest and oldest source of SoD violations: historical access that predates the current control framework.
For organizations running SAP Access Control 12.0 alongside SAP Cloud Identity Access Governance in a bridge configuration, a specific configuration parameter controls where risk analysis actually executes for access requests.
When this parameter directs analysis to run through Cloud Identity Access Governance, request-level checks in Access Control itself stop evaluating risk locally, which means a misconfigured integration can leave request approvers believing risk analysis occurred when it did not. Validating this integration point directly, rather than assuming it, is one of the highest-value checks a security team can perform in a hybrid GRC landscape.
Redesign Roles Instead of Only Adding Mitigating Controls
Mitigating controls, such as a compensating review or an exception report, have a legitimate place in a mature SoD program, but they should be the exception applied to unavoidable conflicts rather than the default response to every violation discovered. A more durable fix is redesigning the underlying role by splitting a composite role that bundles creation and approval authorizations into two separate roles aligned to the principle of least privilege. This reduces the population of users who need a mitigating control in the first place, which lowers both audit overhead and the ongoing burden on process owners who must review compensating controls on a recurring schedule.
Role redesign work should be prioritized using a risk-based approach that addresses high-impact conflicts capable of causing material financial loss or regulatory exposure first, rather than working through the full violation list in whatever order it was generated. A conflict allowing one user to create a vendor and release payment to that same vendor carries materially higher fraud exposure than a conflict involving two low-value reporting transactions, and treating both with equal urgency wastes remediation capacity that should go toward the highest-risk exposure first.
Best Practices for Sustainable SoD Enforcement
Sustainable enforcement depends on embedding SoD checks directly into the user access lifecycle rather than treating them as a separate compliance activity performed after access has already been granted. This means running automated risk analysis at the provisioning stage, at every role change, and at de-provisioning, so that no new conflicting access reaches a user by default and so that a departing employee’s remaining access is captured rather than left active during an offboarding gap.
Periodic access reviews should be scheduled on a quarterly or semi-annual cadence and owned by business process owners rather than only by the SAP security team, since process owners understand whether a flagged combination of access reflects genuine business need or leftover access from a prior role. Documenting the outcome of every review, including access that was retained with a justified mitigating control, gives auditors a clear trail showing the control operated continuously rather than only at the moment of the audit request.
Common Mistakes in SAP SoD Programs
The most common mistake is running access risk analysis once during implementation and treating the resulting clean report as a permanent state rather than a snapshot. Role changes, organizational restructuring, and new module rollouts introduce conflicts continuously, and without a recurring analysis job scheduled through the Job Scheduler in Access Control or Cloud Identity Access Governance, the organization has no visibility into how quickly that clean state degrades.
| Mistake | Why It Happens | Consequence |
|---|---|---|
| Treating risk analysis as a one-time project | No recurring job scheduled after go-live | Conflicts reintroduced by role changes go undetected |
| Approving mitigating controls with no review cycle | No expiration/reassessment date set | Compensating controls remain long after justification disappears |
| Assuming cross-system risk is covered | Both Access Control and IAG are “in place” but not verified | Cross-app conflicts (e.g., S/4HANA ↔ Ariba) go undetected without explicit ruleset coverage and a working Sync Job |
Conclusion
Segregation of duties SAP controls only function when they are treated as a continuous lifecycle rather than a one-time implementation deliverable. An accurate, business-specific ruleset, risk analysis running consistently at user, role, and request level, role redesign prioritized by real financial exposure, and a documented periodic review process together determine whether SoD is genuinely enforced or only appears enforced on a dashboard. S/4HANA migrations and hybrid landscapes combining on-premise Access Control with Cloud Identity Access Governance add specific technical dependencies, from business function group mapping to Risk Definition Sync Jobs, that must be verified directly rather than assumed to be working.
As SAP landscapes continue extending across cloud modules and Fiori-based authorization models, the gap between configured SoD tools and actually enforced controls will keep widening for organizations that treat this as a completed project. Building the validation habits outlined here into a recurring operational rhythm is what keeps an SAP environment audit-ready between review cycles, not just during them.
FAQs
1. What does segregation of duties SAP actually mean in practice? Segregation of duties SAP refers to structuring authorizations so no single user can complete an entire sensitive process end to end, such as creating a vendor and also approving payment to that vendor, without independent review from another user.
2. Does installing SAP GRC Access Control automatically enforce SoD? No, installing the tool only provides the capability. Enforcement depends on an accurate ruleset, scheduled risk analysis at user and role level, active remediation of conflicts, and periodic review, none of which happen automatically without configuration and ongoing ownership.
3. How does S/4HANA migration affect existing SoD controls? Legacy roles with hidden conflicts commonly migrate unchanged into S/4HANA’s new Fiori-based role model, meaning a technically successful migration project can still carry forward every segregation of duties violation that existed in the prior ECC environment.
4. What is the difference between SAP Access Control and SAP Cloud Identity Access Governance for SoD? SAP Access Control is the on-premise GRC solution with full role maintenance and workflow capability, while SAP Cloud Identity Access Governance is a cloud-native risk analysis service that manages business roles and can operate standalone or as a bridge extending risk analysis to cloud applications.
5. How often should SAP SoD risk analysis be run? Risk analysis should run at every provisioning event, role change, and de-provisioning action, supplemented by a scheduled recurring job covering the full user population, since relying only on point-in-time checks at access request misses conflicts already present in production.
6. What is a mitigating control in the context of SAP SoD? A mitigating control is a compensating measure, such as a management review or exception report, applied when a conflict cannot be eliminated through role redesign, and it should carry a defined reassessment date rather than remaining in place indefinitely.
7. Can cross-system conflicts between S/4HANA and Ariba or SuccessFactors be detected automatically? Only when the ruleset explicitly includes cross-application risk definitions and the integration between on-premise Access Control and Cloud Identity Access Governance, including the Risk Definition Sync Job, is functioning correctly and verified rather than assumed.
8. Who should own periodic SAP access reviews for SoD compliance? Business process owners should lead periodic reviews because they understand whether flagged access reflects genuine current responsibilities, while the SAP security team supports the review with accurate risk analysis data and documentation.
References
Source: SAP Cloud Identity Access Governance – Preparing the Setup of Access Analysis Service (SAP Learning) — https://learning.sap.com/courses/sap-cloud-identity-access-governance-implementation-and-configuration/preparing-the-setup-of-access-analysis-service
Source: SAP Cloud Identity Access Governance – Setting up the Access Analysis Service (SAP Learning) — https://learning.sap.com/courses/sap-cloud-identity-access-governance-implementation-and-configuration/setting-up-the-access-analysis-service
Source: SAP IAG Access Analysis (SAP Community) — https://groups.community.sap.com/t5/technology-blogs-by-sap/sap-iag-access-analysis/bc-p/13548154
Source: GRC Risk Analysis for Cloud Systems (SAP Blogs) — https://blogs.sap.com/2021/02/25/grc-risk-analysis-for-cloud-systems/
