SAP SoD Segregation of Duties Basics: Identify and Resolve Access Conflicts

01What SAP SoD means

SAP segregation of duties (SoD) separates sensitive steps among different people so that one person cannot initiate, approve, and complete a high-risk business process alone. A practical SoD control connects a business risk to the transactions, applications, or permissions that create it, then checks which users or roles combine those capabilities.

SoD is a preventive and detective control. Preventive design keeps conflicting access from being assigned together. Detective review identifies conflicts that already exist, assesses their business context, and records a remediation or mitigation decision. For broader context, see SAP Security and GRC overview.

02How an SAP SoD conflict is formed

An SAP SoD conflict exists when the same user can perform two or more activities that should be independently controlled. The conflict can come from direct user assignments, composite roles, derived roles, business catalogs, connected systems, or emergency access.

A rule normally contains a risk, a function, and the permissions or transactions associated with that function. For example, a purchasing conflict may combine supplier master maintenance with purchase order approval. A finance conflict may combine vendor master changes with payment execution. The exact risk depends on the organization’s process, system configuration, and control policy.

A simple SAP segregation of duties example

Consider a procure-to-pay process:

1. A user creates or changes supplier master data.
2. The same user creates a purchase order.
3. The same user approves the purchase order.
4. The same user posts and pays the invoice.

Each step may be legitimate in isolation. The combined access creates a risk because one person can influence the supplier, commit company funds, and complete the payment path. A review should examine the actual process and assigned access rather than treating every rule match as proof of misconduct.

03What to review during access analysis

Start with the user and role inventory for every in-scope system. Include active users, technical users where relevant, composite and single roles, connected applications, and emergency access assignments. Record the analysis date, system, client or environment, rule set, and reviewer.

Then validate how the conflict is created. Trace the matched function to the assigned role and authorization data, confirm whether the user can execute the activity in production, and check whether the access is temporary, time-limited, or inherited through another role. The SAP Access Control overview provides useful context for risk analysis and access governance.

A useful review record contains:

• User and business owner
• System and environment
• Risk identifier and rule description
• Conflicting functions
• Roles or permissions creating the match
• Business justification
• Remediation or mitigation decision
• Control owner and review frequency
• Due date, status, and evidence location

04How to handle a detected conflict

Use a consistent decision sequence. First, confirm that the user needs both functions. If one function is unnecessary, remove the role or permission and retest the user. If both functions are required, determine whether the organization accepts the risk with a documented compensating control.

A compensating control should have a named owner, a defined review frequency, clear evidence, and a scope that addresses the actual risk. Examples include an independent review of supplier changes, payment approvals, or exception reports. A generic statement that a manager monitors the user is insufficient unless the review activity, timing, population, and retained evidence are defined.

For temporary elevated access, use a controlled emergency access process with approval, time limits, activity logging, and post-use review. See SAP Emergency Access Management and Firefighter when emergency access is part of the operating model.

05Remediation workflow

A practical remediation workflow is:

1. Detect: Run the risk analysis against the current user and role assignments.
2. Validate: Confirm the matched access and its business relevance.
3. Prioritize: Rank the issue by financial impact, fraud exposure, regulatory significance, and scope.
4. Decide: Remove access, redesign the role, restrict the activity, or approve a compensating control.
5. Implement: Change the assignment or activate the documented mitigation.
6. Retest: Run the analysis again and verify the result in the target system.
7. Close: Attach approvals, evidence, dates, and ownership to the record.

Retesting is essential after role redesign. A removed role may be restored through a composite role, a derived role, or a later access request. Treat the post-change analysis as the evidence that the intended result was achieved.

06Monitoring and periodic review

SoD control is an ongoing operating process rather than a one-time cleanup. Schedule reviews based on risk and business change. High-risk conflicts generally need more frequent review than low-impact informational matches.

Track key control metrics such as open conflicts, overdue remediation, repeated exceptions, newly introduced conflicts, conflicts by business owner, and mitigation reviews completed on time. Investigate trends: a growing number of conflicts in one role family may indicate poor role design or an overly broad rule.

Access review evidence should show who performed the review, what population was assessed, which decisions were made, and when the decisions were approved. For related access certification operations, see SAP user access review basics.

07Audit evidence and logging

SoD analysis shows that access creates a risk; it does not by itself prove that a user performed the risky activity. Use application records, change documents, workflow history, and security audit data to investigate actual use. Retain evidence according to the organization’s retention policy and control requirements.

Separate access evidence from activity evidence. Role assignments, risk analysis results, and approvals demonstrate what a user could do. Transaction logs, workflow records, and business documents demonstrate what happened. The SAP Security Audit Log basics article covers the audit-log perspective.

08Common SAP SoD troubleshooting

When a conflict result looks unexpected, troubleshoot in this order:

1. Confirm the user, system, client, and analysis date.
2. Identify the exact functions matched by the rule.
3. Trace each function to the assigned role or permission.
4. Check composite, derived, and inherited assignments.
5. Confirm whether the access is active and usable in the target environment.
6. Review exclusions, organizational restrictions, and approved mitigations.
7. Re-run the analysis after every access change.

A false positive often reflects a rule that is broader than the business process or an organizational restriction that the analysis does not evaluate as expected. Document the reason for the decision and obtain approval through the established governance process rather than silently excluding the result.

09Operating principles for SAP SoD

Effective SoD management combines role design, risk analysis, business ownership, remediation, and evidence. Keep the rule set aligned with real processes, assign each risk to an accountable owner, and make exceptions time-bound.

The strongest control environment treats SoD as part of the access lifecycle: design roles with conflicts in mind, analyze access before approval, monitor changes after assignment, review emergency access, and periodically recertify both access and mitigations.