How should teams check segregation of duties in SAP without spreadsheets?

Why This Matters for Security Teams

segregation of duties in SAP is not a spreadsheet problem; it is an authorization problem. Once teams reduce analysis to exported user lists, they miss how SAP evaluates access through cumulative roles, org levels, derived roles, and transactional combinations. That creates blind spots where toxic combinations are hidden until audit or incident response exposes them. A control that cannot be reproduced from source authorization logic is not reliable evidence.

For security leaders, the risk is not only policy violation. SoD failures can enable fraud, unauthorized master data changes, payment manipulation, and silent privilege accumulation across business processes. The control needs to be grounded in repeatable logic and preserved snapshots, which is why structured governance patterns matter in broader identity programs as well, including the guidance in the Ultimate Guide to NHIs and the control objectives in NIST Cybersecurity Framework 2.0. In practice, many security teams encounter SoD violations only after a business exception, audit challenge, or payment anomaly has already occurred, rather than through intentional control testing.

How It Works in Practice

The practical approach is to evaluate effective access, not just assigned access. In SAP, that means checking what a user can actually do after roles are combined, derived, and filtered by organizational levels. A meaningful SoD review should model the authorization object values, transaction combinations, and any custom logic that changes access at runtime. Current guidance suggests treating the analysis as a control workflow with versioned inputs, not a one-time report.

A repeatable method usually includes:

• Build a current snapshot of users, roles, profiles, and derived roles from the SAP authorization model.
• Evaluate cumulative access across all assigned and inherited entitlements.
• Map access to a defined SoD rule set, including critical transactions and sensitive functions.
• Preserve the exact rule version, data extraction time, and analysis output for audit replay.
• Track remediation decisions so accepted exceptions remain visible and time-bound.

This is where control design becomes more important than tooling. Teams should define whether they are checking preventive access before assignment, detective monitoring after assignment, or both. The most defensible programs also tie SoD review to access recertification and privileged role governance, because toxic combinations often appear when business roles are expanded over time. The Ultimate Guide to NHIs is useful here as a reminder that identity control quality depends on visibility and lifecycle discipline, not just policy statements. These controls tend to break down when SAP custom roles, indirect assignment paths, or incomplete org-level mapping cause the analysis engine to understate effective access.

Common Variations and Edge Cases

Tighter SoD enforcement often increases exception handling and business friction, requiring organisations to balance control strength against operational continuity. That tradeoff is real in SAP landscapes where shared service teams, emergency access, and legacy custom transactions are common. Best practice is evolving, and there is no universal standard for how every organization should treat compensating controls, but the analysis itself still needs to be deterministic.

Edge cases usually appear in three places. First, derived roles can mask the true access path if the review only looks at the parent assignment. Second, org-level restrictions may make a transaction look safe when it still becomes toxic in a different plant, company code, or purchasing group. Third, emergency access should not be excluded from SoD logic just because it is temporary; it needs separate evidence and expiry handling. Teams that rely on exports often miss these nuances because flat files do not preserve SAP’s authorization inheritance or runtime evaluation rules.

For governance alignment, security teams should pair SAP SoD checks with control expectations from the NIST Cybersecurity Framework 2.0 and use the same reproducibility standard across recurring reviews. The practical goal is not a perfect spreadsheet, but a defensible control record that shows what was checked, against which logic, and with what result.

Related resources from NHI Mgmt Group

• How can IAM teams reduce segregation-of-duties exceptions without slowing the business?
• How should security teams enforce segregation of duties in SAP environments?
• Why do segregation of duties failures still happen in mature finance programmes?
• What breaks when segregation of duties relies on annual spreadsheet reviews?