(Without Losing Control — or Living in Spreadsheets)
For SAP customers who have been running ECC or S/4HANA for years, segregation of duties (SoD) is not an abstract compliance concept. It is a daily reality shaped by PFCG roles, derived role structures, organizational values, custom transactions, and access decisions made years ago that no one wants to touch today.
The real challenge is no longer whether SoD is important.
The challenge is how to check segregation of duties in SAP in a way that reflects how SAP actually grants access, scales with complex landscapes, and holds up under audit scrutiny — without consuming the security team every quarter.
What “Checking SoD” in SAP Really Means
In theory, SoD is about separating incompatible activities.
In practice, checking SoD in SAP means answering three very specific questions:
Who has incompatible access in the SAP authorization model — not just conflicting transactions?
This requires understanding how authorization objects, organizational levels, and derived roles combine to create real execution power.
Where do those conflicts originate?
In most SAP systems, SoD risks do not come from a single role. They emerge from cumulative access across multiple roles, copied templates, temporary assignments, emergency access, or org-level values that quietly widen scope.
How often are those conflicts identified, reviewed, and addressed in a defensible way?
Auditors are not just interested in findings — they want evidence of consistency, governance, and control over time.
This is where classic segregation-of-duties theory meets the technical reality of SAP ECC and S/4HANA security.
Why Manual Segregation of Duties Checks Break Down in SAP
Many SAP teams still rely on a familiar approach:
- SUIM and standard SAP reports
- User and role extracts
- Excel-based SoD matrices maintained by audit or security teams
This approach can work in small or relatively static systems. But in mature SAP environments, it quickly becomes unmanageable.
Over time, SAP landscapes accumulate complexity:
- Role explosion from years of copied and modified PFCG roles
- Derived roles where organizational values introduce SoD conflicts that are invisible at the template level
- Custom Z-transactions that were never mapped into SoD rules
- SU24 data that was never fully maintained post go-live
- Emergency and firefighter access that quietly becomes long-term access
As a result, manual SoD analysis becomes:
- Time-consuming to produce
- Difficult to keep current
- Nearly impossible to explain clearly to auditors or business owners
By the time the analysis is complete, the SAP security model has already changed.
ECC and S/4HANA: Different UI, Same SoD Problem
S/4HANA did not eliminate segregation-of-duties risk. It redistributed it.
While Fiori simplified user interaction, the underlying authorization framework remains complex — and in many cases more opaque. Access can now be exercised through:
- Fiori catalogs and groups
- OData services
- CDS views
- Background jobs and APIs
Experienced SAP security teams know that analyzing only what users see on the screen is never enough. Real SoD analysis must account for backend authorizations and multiple access paths that bypass traditional transaction usage.
What Sustainable SoD Checks Look Like in SAP
Organizations that have moved beyond spreadsheet-driven SoD checks tend to adopt a few hard-earned practices.
They define SoD rules based on SAP authorization logic, not just transaction codes.
This allows risks to be identified even when transactions are hidden, executed in the background, or replaced by Fiori apps.
They run snapshot-driven, repeatable SoD analysis.
SoD checks are aligned with security snapshots, role redesigns, transports, and access reviews — not treated as a once-a-year audit exercise.
They introduce preventive checks before access is granted.
Instead of discovering toxic access after the fact, they simulate role assignments and access requests to identify conflicts before changes reach production.
They interpret findings in business terms.
SoD risks are mapped to end-to-end processes such as procure-to-pay or record-to-report, making conversations with process owners and auditors far more effective.
These practices acknowledge how SAP actually behaves — and how audits actually work.
Where Native SAP Tools and Point Solutions Fall Short
SAP provides reporting and analysis capabilities, and many organizations supplement them with point solutions. Even so, experienced teams often encounter the same limitations:
- Fragmented rule definitions across ECC, S/4HANA, and connected systems
- Excessive noise caused by organizational values and false positives
- Limited visibility into how SoD risks are reviewed, accepted, or remediated over time
- Gaps across systems, where SAP access looks clean in isolation but creates risk when combined with access elsewhere
These gaps become particularly visible during audits, when evidence must be consistent, traceable, and repeatable.
How SafePaaS Supports Real-World SAP SoD Governance
SafePaaS is designed to work with SAP’s complexity — not abstract it away.
For SAP teams with years of accumulated security history, SafePaaS provides a structured way to govern SoD without re-engineering the ERP itself.
Centralized SoD rule governance
SoD rules are maintained in a single, controlled library aligned to SAP authorization logic, and applied consistently across environments.
Automated analysis of SAP users and roles
Security snapshots are evaluated against approved rules to identify:
- User-level violations
- Role-level risks
- The underlying access paths that create conflicts
This removes the need for manual data joins and spreadsheet logic.
Preventive SoD checks during provisioning and role design
Before access is granted, SafePaaS simulates the impact of role assignments and redesigns, allowing teams to prevent toxic access instead of remediating it later.
Cross-system SoD visibility
When business processes span SAP and non-SAP systems, SafePaaS evaluates combined access risk, closing gaps that often surface during SOX and internal audits.
What This Changes for Audit and Compliance
When segregation of duties in SAP is governed through SafePaaS, audit preparation becomes a by-product of normal operations — not a separate project.
Teams can:
- Produce up-to-date SoD analysis backed by snapshot evidence
- Show how conflicts were reviewed, approved, or remediated
- Demonstrate preventive controls, not just detective findings
- Trace decisions across users, roles, rules, and time
Auditor conversations shift from “Where did this spreadsheet come from?” to “How is this control designed and governed?”
The Perspective of a Long-Time SAP Security Practitioner
After two decades in SAP security, one lesson is clear:
Spreadsheets don’t fail because teams are careless — they fail because SAP access models are too complex to govern manually at scale.
Segregation of duties does not need to be a quarterly fire drill.
With the right structure, it becomes a repeatable, defensible control embedded into how SAP access is designed, granted, and reviewed.
SafePaaS gives experienced SAP teams a way to manage SoD realistically — without oversimplifying SAP, and without overwhelming the people responsible for securing it.
