Notifications
Clear all
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.
NHIMG editorial — based on content published by SafePaaS: Without Losing Control or Living in Spreadsheets, how to check segregation of duties in SAP
Questions worth separating out
Q: How should teams check segregation of duties in SAP without spreadsheets?
A: They should use repeatable analysis tied to SAP authorization logic, not static exports.
Q: Why do SAP SoD conflicts keep reappearing after remediation?
A: They reappear because the root cause often sits in role design, copied templates, organizational values, or access combinations across systems.
Q: What do security teams get wrong about SoD in S/4HANA?
A: They often over-focus on what users see in the interface and undercount backend execution paths.
Practitioner guidance
- Define SoD rules from SAP authorization logic Base rules on authorization objects, organizational values, and derived role behaviour so the analysis reflects actual execution power rather than transaction names.
- Include non-transactional access paths in review Assess Fiori catalogs, OData services, CDS views, background jobs, and APIs alongside classic transactions so hidden execution routes do not escape the control.
- Run preventive checks before provisioning Simulate role assignments and role redesigns before they reach production, and block combinations that would create toxic access at go-live.
What's in the full article
SafePaaS's full blog covers the operational detail this post intentionally leaves for the source:
- How SafePaaS structures centralized SoD rule governance across SAP authorization logic and security snapshots
- How preventive SoD simulation works during provisioning and role redesign before access reaches production
- How cross-system SoD visibility is handled when business processes span SAP and non-SAP environments
- How audit evidence is produced from normal operations rather than from a separate spreadsheet exercise
👉 Read SafePaaS's analysis of SAP segregation of duties governance →
SAP SoD checks in ECC and S/4HANA: where manual methods fail?
Explore further
25/06/2026 8:14 am
Spreadsheets are a symptom of SAP SoD governance that has outgrown its control model. Manual matrices can document conflicts, but they cannot reliably represent cumulative access across PFCG roles, organizational values, temporary assignments, and cross-system entitlements. That is why the issue is not just operational fatigue. The deeper problem is that the control was designed for a slower, simpler access model than modern SAP landscapes now present. Practitioners should treat spreadsheet dependence as evidence that the SoD governance model is no longer fit for scale.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which is why inventory quality and governance evidence matter before audit season arrives.
A question worth separating out:
Q: Who is accountable when SAP SoD findings are not remediated?
A: Accountability sits with both the access governance function and the business owners who accept the process risk. If a conflict is only reported as a technical issue, remediation stalls. When it is mapped to a business process and tied to an approval or exception path, ownership becomes much harder to defer.
👉 Read our full editorial: SAP segregation of duties checks need governance, not spreadsheets
