Common signs include role reviews that focus on module names, conflicts that only appear after an audit, and toxic combinations that span finance, procurement, HR, or Basis. If a review cannot explain the full transaction path and who approves each step, it is probably blind to the highest-risk exposure.
Why the review looks tidy while the real conflict slips through
The biggest warning sign is a review that reads like a naming exercise instead of a control test. If the reviewer can tell you the module involved but cannot explain the transaction path, approval path, and where a conflict is actually exercised, the review is measuring structure, not risk. That is how high-risk combinations survive inside otherwise “clean” role sets.
A second signal is timing. If conflicts are only discovered after audit fieldwork, the review process is probably not using the same business path that creates the exposure. In SAP environments, the real issue is often not one permission in isolation but a chain that crosses request, create, approve, post, release, and reconcile steps.
A third signal is when toxic combinations cut across business functions rather than sitting neatly inside one module. A reviewer who thinks only in finance, or only in procurement, will miss combinations that span Segregation of Duties (SoD) Guide scenarios involving finance, procurement, HR, or Basis, because the conflict is created by the end-to-end process, not by the module label alone.
What a real SAP SoD conflict actually depends on
A meaningful SoD review has to model who can start a transaction, who can change it, who can approve it, and who can complete or reverse it. If any one of those steps is hidden, compressed into a generic role description, or treated as “someone else’s module,” the review becomes blind to privilege combinations that are only obvious when the full path is reconstructed.
The same problem shows up when a review treats compensating controls as a checkbox rather than a demonstrated control path. A reviewer may see that a user has access to multiple activities and assume the risk is acceptable, but if the approval evidence, monitoring, or exception handling does not match the actual flow, the conflict still exists in practice.
That is why a proper review should test for toxic combinations across operational reality, not just authorisations on paper. If the role can support posting plus approval, vendor maintenance plus payment release, or request plus final approval, the conflict is material even if the individual permissions look ordinary in isolation.
For broader control design, the pattern aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls around access control, auditability, and separation of duties, because the control objective is to prevent one actor from carrying a process from initiation to unsafe completion.
Why blind spots persist even in mature SAP governance
One common blind spot is over-reliance on role names, role owners, or job titles. Those are useful clues, but they are not proof of safe segregation. Another is stale rule content, where the sod matrix has not kept pace with process redesign, custom transactions, emergency access, or cross-functional role bundling added for operational convenience.
Reviews also go wrong when they ignore third-party and technical access paths. Basis, background jobs, interface users, and service-style accounts can create the same practical conflict as a human role holder if they can initiate and complete sensitive actions. If the review stops at named business users, it misses the paths that actually execute the transaction chain.
In cloud-connected or heavily integrated SAP landscapes, hidden exposure often comes from automation or unreviewed exceptions rather than the core dialog role itself. That is why reviews should be checked against the actual transaction sequence and not just against the access catalogue. Where implementation complexity is high, the control model should remain anchored to the concrete conflict path, not the comfort of a tidy role report, and Segregation of Duties (SoD) Guide is a practical reference for building that view.
Risk and Threat Considerations
When SAP SoD reviews miss the real conflict, the failure is usually not cosmetic, it is exposure to fraud, unauthorised change, or unchallenged approval chains. The highest risk is where a single actor can move a transaction from initiation to outcome without an effective second set of eyes.
Failure mechanism: The review model relies on module labels, role names, or partial permissions instead of reconstructing the full transaction path and approval path. That lets conflicting privileges survive in cross-functional or technical roles, especially where exceptions, emergency access, or automation are involved.
Impact: High-risk transactions can be created, approved, posted, or reversed without meaningful segregation, which increases fraud potential, audit findings, and the chance that compensating controls will fail when tested. In practice, the conflict is often visible only after an investigation, when the damage is already done.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD reviews are directly about separating conflicting transaction powers. |
| AU-6 — Audit Review, Analysis, and Reporting | Review quality depends on evidence that exposes hidden approval and transaction paths. | |
| Recommendation — Enforce AC-5 to split initiating, approving, and posting authorities across different roles. Use AU-6 to detect conflicts that only appear when logs and process paths are reconciled. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD review quality is an access-control governance issue, not just a role-admin task. |
| A.5.18 — Access rights | SoD failures often persist because rights are not reviewed against actual business transactions. | |
| Recommendation — Define access rules that prevent one role from holding conflicting process powers. Review access rights against real transaction paths and remove conflicting entitlements. | ||
Practitioner Guidance
What to verify: Test the full end-to-end path, not just the role catalog. A review is only credible if it can show who initiates, who approves, who completes, and who can override each step for the exact business process being assessed.
Common mistake: Treating SAP module ownership as a proxy for SoD. That shortcut misses cross-module toxic combinations and creates false confidence when access is distributed across finance, procurement, HR, or Basis.
Practitioner takeaway: The right question is not “does this user sit in a risky module,” but “can this user carry the transaction to completion without a real control break.” If the answer is unclear, the review is not finding the real conflict.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- When do NHI access reviews create more value than a one-time cleanup?
- What are the signs that a static or dynamic scanner is missing real application risk?
- What are the signs that an LLM evaluation program is missing real-world failure modes?