Topic starter
24/06/2026 11:23 pm
TL;DR: Manual SAP segregation of duties checks break down when PFCG roles, derived roles, organizational values, and cross-system access combine to create conflicts that spreadsheets cannot keep current, according to SafePaaS. Sustainable governance depends on rule logic tied to SAP authorization paths, preventive checks before provisioning, and repeatable evidence for audit.
Editorial analysis by NHI Mgmt Group, based on content published by SafePaaS: “How Experienced SAP Teams Check Segregation of Duties”.
Key questions
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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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