SAP segregation of duties checks need governance, not spreadsheets

At a glance

What this is: This is an analysis of how SAP segregation of duties checks should be governed in ECC and S/4HANA, with the key finding that spreadsheet-driven review does not scale with real authorization complexity.

Why it matters: It matters because SAP teams must control toxic access across roles, org levels, Fiori paths, and connected systems without turning every audit into a manual reconciliation exercise.

👉 Read SafePaaS's analysis of SAP segregation of duties governance

Context

Segregation of duties in SAP is the control that keeps one identity from being able to complete incompatible business actions end to end. In ECC and S/4HANA, that is harder than it sounds because access is shaped by role design, organizational values, derived roles, background execution, and multiple front-end and back-end paths.

The governance gap is not the idea of SoD. It is the method used to check it. When teams rely on static exports and spreadsheet matrices, they lose sight of how SAP actually grants effective access, how conflicts accumulate over time, and how auditors expect evidence to remain consistent and repeatable.

Key questions

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. That means evaluating cumulative access across roles, org levels, and derived roles, then preserving snapshot evidence so findings can be reproduced during audit. The goal is to make SoD a control process, not a quarterly data exercise.

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. Removing one visible conflict does not fix the underlying access model. Sustainable reduction requires preventive checks before provisioning and redesign, plus ongoing review of how access is actually granted.

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. Fiori, OData, CDS views, background jobs, and APIs can all carry the same business risk through different routes. A credible SoD programme has to inspect those routes, not just screen transactions.

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.

Technical breakdown

Why SAP SoD conflicts emerge from authorization logic, not single roles

In SAP, SoD risk rarely lives in one role assignment. It emerges when authorization objects, organizational levels, derived roles, temporary access, and copied templates combine into effective business power that is broader than any single line item suggests. That means transaction-level review misses the real control plane. Security teams have to evaluate how role composition and org-level values change what a user can actually do, not just what a template appears to allow on paper.

Practical implication: build SoD rules around SAP authorization logic and cumulative entitlements, not transaction lists alone.

How Fiori, OData, and background jobs hide effective access

S/4HANA and Fiori simplify the user interface, but they do not simplify the authorization model. Users can exercise access through catalogs, groups, OData services, CDS views, background jobs, and APIs, which means screen-based analysis undercounts real execution paths. The technical mistake is assuming the visible app equals the real privilege boundary. In practice, SoD analysis must inspect backend authorizations and alternate execution channels, or it will certify a narrow view of a much wider risk surface.

Practical implication: include backend paths and non-transactional execution routes in every SoD review.

Why repeatable snapshot-based SoD checks hold up in audit

A defensible SoD programme is not a yearly report. It is a repeatable control tied to snapshots, role redesigns, transports, and access reviews so that findings can be reproduced later. That matters because auditors look for consistency, traceability, and proof that the control operated over time, not just a single exported result. Preventive simulation before provisioning is especially important because it catches toxic access before it reaches production, when remediation is harder and more disruptive.

Practical implication: run SoD analysis at provisioning, redesign, and review points, and preserve snapshot evidence for audit.

NHI Mgmt Group analysis

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.

Self-contained SoD findings are a false comfort in integrated SAP estates. A user can look clean inside ECC or S/4HANA and still create process risk when their access is combined with adjacent systems, APIs, or downstream business tooling. This is where isolated review breaks down. Identity governance has to follow the process, not the system boundary, or it will miss the real risk path. Practitioners should evaluate SoD across the full business process chain, not only within the SAP tenant under review.

Preventive SoD checks are the difference between governable access and inherited audit debt. If toxic access is discovered only after assignment, the organisation has already accepted a risk it may struggle to justify. The stronger pattern is to simulate role impact before provisioning and before redesigns reach production, because that is where control design still has leverage. Practitioners should shift SoD from retrospective evidence collection to pre-commitment control validation.

Business-process framing is what makes SAP SoD usable outside the security team. Conflicts tied only to transactions or authorization objects are difficult for process owners to interpret and therefore slow to remediate. When SoD findings are expressed in procure-to-pay, record-to-report, or similar process terms, accountability becomes clearer and remediation becomes business-owned rather than security-owned. Practitioners should map technical violations to business processes so the control can be acted on, not just reported.

Cross-system SoD governance is now part of SAP access control, whether teams planned for it or not. SAP access that appears acceptable in isolation can still create an incompatible process outcome when combined with access elsewhere. That means the old assumption that the ERP can be governed as a closed system no longer holds. Practitioners should extend SoD thinking to the connected landscape before audit findings expose the gap.

From our research:

• 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.
• That same governance pressure is why teams should also compare access review practice with Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when SAP roles, service accounts, and other identities converge in one process.

What this signals

SoD in SAP is shifting from periodic review to continuous governance. Teams that keep treating conflicts as a quarterly audit task will keep inheriting stale evidence and reactive remediation. The practical signal is to align review cadence with role change events, transport cycles, and provisioning workflows so the control reflects how SAP landscapes actually move.

Role complexity is now an identity lifecycle problem, not just a security configuration problem. When derived roles, temporary access, and long-lived exceptions accumulate, the control failure is less about one bad assignment than about ungoverned lifecycle drift. Teams that connect SAP SoD to the Lifecycle Processes for Managing NHIs will be better placed to govern access changes over time.

Cross-system evidence will increasingly decide whether SoD is trusted or challenged. If SAP looks compliant in isolation but the process still fails across connected systems, auditors will push harder on traceability. That is where the 52 NHI Breaches Analysis helps reinforce the broader lesson: unmanaged access paths tend to surface first as governance blind spots, then as control failures.

For practitioners

• 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.
• Tie every violation to a business process Map each conflict to end-to-end processes such as procure-to-pay or record-to-report so process owners can understand and remediate the issue quickly.
• Preserve snapshot evidence for audits Keep repeatable analysis outputs tied to access reviews, transports, and redesign cycles so the control can be re-run and explained over time.

Key takeaways

• SAP SoD breaks down when teams try to govern cumulative access with spreadsheet logic that cannot keep pace with role sprawl and derived entitlements.
• The control is only defensible when it evaluates real authorization paths, including Fiori, OData, background jobs, and cross-system access combinations.
• Preventive simulation, business-process mapping, and snapshot evidence are the practical levers that turn SoD into a repeatable governance control.

Key terms

• Segregation Of Duties: Segregation of duties is the practice of preventing one identity from holding incompatible permissions that could complete a sensitive business process alone. In SAP, it depends on effective access across roles, values, and execution paths, not just on visible transaction access.
• Derived Role: A derived role is a SAP role that inherits a template’s structure while changing organizational values or scope. It can look harmless at the template level but still create a real conflict once those values expand what the user can execute.
• Preventive SoD Check: A preventive SoD check evaluates access before it is granted or redesigned so toxic combinations are stopped early. It is stronger than after-the-fact review because it turns SoD into an approval control rather than a cleanup exercise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SafePaaS: Without Losing Control or Living in Spreadsheets, how to check segregation of duties in SAP. Read the original.