Spreadsheets miss how SAP combines roles, organisational values, derived access, and cross-system privileges into effective execution power. They also age quickly, so the control becomes a retrospective report rather than a live governance process. The result is inconsistent evidence, missed conflicts, and poor audit defensibility.
Why spreadsheets fail as the system of record for SAP SoD
SoD analysis is not just a list of incompatible job titles. In SAP, effective privilege comes from the interaction of roles, organisational values, derived authorisations, profile changes, and cross-system access. A spreadsheet can record a snapshot, but it cannot reliably calculate the effective access path that SAP actually executes, so it misses conflicts that only appear once those elements are combined.
That gap matters because segregation checks are supposed to answer a practical question: can one person, role, or account complete a sensitive business process end to end without a compensating control? If the tool cannot evaluate the full execution path, it cannot distinguish harmless role names from real toxic combinations.
Why stale spreadsheets turn SoD into after-the-fact reporting
Spreadsheet-based review quickly becomes retrospective. By the time a file is exported, edited, reconciled, and re-circulated, role assignments and authorisations may already have changed. The control then measures what was true at extraction time, not what is true in the system now, which weakens both monitoring and remediation.
That timing problem creates operational drift. Teams start using the spreadsheet as evidence of review activity rather than as a live control that prevents or flags risky access before it is used. When access governance is delayed, conflicts can sit open long enough to affect procurement, finance, maintenance, or emergency access processes.
What effective SAP SoD needs instead
Effective SoD in SAP requires an access view that understands business roles, derived permissions, and the actual combinations that lead to execution power. It also needs rules that stay aligned to current master data and role design so that conflict detection reflects the system, not the worksheet.
That is why a proper SoD process usually pairs rule logic with continuous inventory and review. The review output should be evidence of a live governance process, not a manually curated register. Where access or privilege structures are already well established, the control should trace those structures directly rather than relying on indirect human interpretation.
For practitioners building or validating the rule set, NHIMG’s Segregation of Duties (SoD) Guide is the clearest companion for turning conflict detection into a repeatable control, and SAP-specific access weaknesses are easier to reason about when you also understand how credentials and repository access can expose downstream execution paths, as shown in SAP Kubernetes secrets exposure 2023.
Risk and Threat Considerations
Spreadsheet-only SoD checks create a blind spot that can hide real business abuse paths. The risk is not merely incomplete documentation, it is that a user may retain a combination of access rights that enables posting, approval, vendor setup, or payment activity without the conflict ever being detected in time.
Failure mechanism: Manual exports cannot reliably model SAP’s effective access logic, so derived permissions, organisational values, and cross-system privileges are missed or misread. Conflicts then survive because the control is reviewing names on a sheet instead of executable authority in the platform.
Impact: Conflicts can be approved on bad evidence, audit trails become hard to defend, and remediation becomes inconsistent across business units. The longer the spreadsheet lags behind the system, the more likely the organisation is to inherit unresolved toxic access and false confidence in control coverage.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD checks directly map to separation of duties controls for conflicting access. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Spreadsheet-based review weakens timely monitoring and evidence quality for access conflicts. | |
| Recommendation — Enforce AC-5 with rules that detect and prevent incompatible SAP access combinations. Use AU-6 to review SoD conflicts from current system evidence, not static exports. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is an access-control governance issue because it limits who can do what. |
| Recommendation — Apply A.5.15 to define and enforce access rules that prevent toxic combinations. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question concerns operational access governance and conflict management. |
| Recommendation — Use CIS-6 to maintain current access rules and remove conflicting entitlements. | ||
| SOC 2 (AICPA) | CC6.2 — Implements logical access security software and infrastructure | SoD evidence supports logical access controls and audit defensibility. |
| Recommendation — Document and operate logical access restrictions that prove conflicts are detected and handled. | ||
Practitioner Guidance
What to verify: Confirm that your SoD ruleset evaluates effective access, not just assigned roles. If the control cannot explain how a person acquires execution power through derived or inherited privileges, it is not fit for audit-grade assurance.
What good looks like: Conflict detection should run from current SAP authorisation data, produce repeatable outputs, and show why each flagged combination is risky. Reviewers should be able to trace the conflict back to the actual access path and the compensating control, if one exists.
Common mistake: Treating the spreadsheet as the control itself instead of a reporting artifact. Once that happens, teams start managing the workbook, not the access risk.
Practitioner takeaway: Use spreadsheets only as a presentation layer, because SoD is a control over executable authority and must stay synchronized with the live SAP access model to remain defensible.
Related resources from NHI Mgmt Group
- What breaks when SoD controls are tied to legacy SAP customisations?
- What breaks when SAP authorisation checks fail in RFC paths?
- What breaks when SAP platforms expose privileged interfaces with weak input and authorization checks?
- What breaks when data contract checks are done manually in analytics pipelines?