Topic starter
24/06/2026 11:23 pm
TL;DR: SAP segregation of duties checks break down when role lists miss the authorization paths that create real business power, as SafePaaS explains. SAP governance needs preventive logic tied to access paths, or conflicts stay hidden until review time.
Editorial analysis by NHI Mgmt Group, based on content published by SafePaaS: “How Experienced SAP Teams Check Segregation of Duties”.
Key questions
Q: Why do SAP SoD conflicts appear even when individual roles look clean?
A: Conflicts often emerge from accumulated access rather than from a single role.
Q: How should organisations prevent toxic SAP access before it reaches production?
A: Use preventive SoD checks during provisioning and role design, then simulate the effect of the requested access against approved rules before changes are granted.
Q: What breaks when SAP SoD checks are done with spreadsheets only?
A: Spreadsheets miss how SAP combines roles, organisational values, derived access, and cross-system privileges into effective execution power.
Practitioner guidance
- Map SoD rules to SAP authorization logic Define conflicts using authorization objects, organisational values, derived roles, and execution paths instead of relying on transaction-code pairs alone.
- Run snapshot-based SoD checks Evaluate each access snapshot against approved rules after role redesigns, transports, and access reviews so findings stay aligned to the current landscape.
- Add preventive checks before provisioning Simulate role assignments and access requests before production change so toxic combinations are blocked before they reach the business.
Bottom line: SAP SoD fails when manual methods track role lists but not the authorization paths that actually create business power.
Glossary terms: Segregation of Duties, Derived role, Organisational Value, Preventive SoD Check
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
25/06/2026 8:14 am
Spreadsheet SoD is a control artefact, not a governance model: manual matrices can record findings, but they cannot keep pace with SAP access that changes through derived roles, org-level values, and cross-system combinations. That makes the apparent control weaker than the business thinks it is. The practitioner implication is that SoD governance must be tied to SAP authorization logic, not document management.
A question worth separating out:
Q: What evidence do auditors expect from SAP SoD governance?
A: Auditors expect repeatable analysis, clear rule definitions, review history, and traceable decisions across users, roles, and time. They want to see that SoD is governed continuously, not reconstructed from ad hoc exports when an audit starts.
👉 Read our full editorial: SAP segregation of duties checks need governance, not spreadsheets