Security & GRCintermediate

Segregation of Duties Fundamentals: Risks, Functions and Conflicting Access (Part 2)

Key takeaway

Model SoD as a business-control problem where one person should not hold conflicting capabilities that allow them to initiate and complete a fraud or error without independent oversight.

Explanation

📌 KEY POINTS
✅ The risk isn't that either capability is bad alone — it's the COMBINATION that removes independent checks.
⚠️ "TCode A + TCode B" is an implementation detail, not a risk description — start from the business process and fraud/error scenario.
💡 SoD isn't only Finance — procurement, master data, inventory, payroll, security admin, and IT operations all carry incompatible-responsibility risk.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE CORE IDEA

Separate incompatible business capabilities so no one person completes a high-risk process end to end without independent control
Classic example: creating a supplier AND executing payment to that supplier

━━━━━━━━━━━━━━━━━━━━
▶ 2. HOW GRC MODELS IT

Business functions represent the capabilities
An SoD risk links conflicting functions
Technical actions/permissions map system access to those functions
Risk analysis asks: can a user/role/profile/proposed assignment perform both sides?

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. DEFINE THE RISK PROPERLY

From a business process and fraud/error scenario — not from a T-code pairing
The risk owner should be able to explain what can go wrong, which assertion is affected, and whether it must be eliminated or can be mitigated

━━━━━━━━━━━━━━━━━━━━
▶ 4. IT'S EVERYWHERE, NOT JUST FINANCE

Procurement, master data, inventory, payroll, security administration, IT operations
Preventive analysis before provisioning; detective monitoring confirms controls keep working after changes

✅ CHECKPOINT: explain why "TCode A + TCode B" is the wrong way to describe an SoD risk.

Real project scenario

A user had access to maintain supplier bank details and process payments. Neither role looked powerful in isolation. During audit the combination was identified as a fraud path. The organization removed bank-maintenance access from the operational role and created an independently approved emergency path for rare exceptions.

Common mistakes

Describing risks only as transaction pairs.
Assuming all same-process access is conflicting.
Ignoring organizational-level restrictions.
Treating every risk as equal severity.
Running SoD only once during implementation.

Best practices

Write risks in business-language scenarios.
Include organizational restrictions when relevant.
Separate preventive and detective controls.
Assign accountable risk owners.
Reassess risk after role/process changes.

Interview angle

Define SoD in business terms, then explain function-to-function conflict and how technical authorizations map to those functions. Strong answers distinguish the risk scenario from the technical rule.

Practice this lesson

Quick check

1. Scenario — A user had access to maintain supplier bank details and process payments. Which response best addresses the design or operating risk in Segregation of Duties Fundamentals: Risks, Functions and Conflicting Access?

2. A review finds this recurring pattern around Segregation of Duties Fundamentals: Risks, Functions and Conflicting Access: "Having the conflicted user perform their own mitigating review." Which principle should the team adopt?

3. Scenario — A small country office required one employee to create suppliers and enter invoices because staffing was limited. Which response best addresses the design or operating risk in SoD Remediation vs Mitigation Controls: Choosing the Right Response?

Interview questions

1. A project encounters this situation while working on Segregation of Duties Fundamentals: Risks, Functions and Conflicting Access: A user had access to maintain supplier bank details and process payments. Walk through how you would analyze the requirement or issue, what you would validate, and how you would test the solution before release.

Answer it in your own words first, then compare.

2. Using this SAP project situation — Analyze a user with vendor-maintenance and payment-processing access — explain Segregation of Duties Fundamentals for SAP. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.