Security & GRCadvanced

Preventive SoD: Designing Roles That Avoid Conflicts Before Provisioning (Part 5)

Key takeaway

Embed SoD prevention into role engineering by designing business tasks, separating incompatible capabilities, restricting organizational values, simulating risk, and controlling role changes before access reaches users.

Explanation

📌 KEY POINTS
✅ The cheapest SoD violation is the one never built into a role in the first place.
⚠️ Avoid "power roles" built by adding transactions whenever a ticket arrives — that's how conflicts accumulate silently.
💡 Organizational restrictions (company code, plant) only mitigate SoD if the rule set and authorization design correctly model those field values.

━━━━━━━━━━━━━━━━━━━━
▶ 1. START FROM BUSINESS TASKS

Define what a job must do, then group permissions into roles that support those tasks without combining incompatible functions

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. THE POWER-ROLE TRAP

Building roles by adding transactions ticket-by-ticket accumulates hidden conflicts

━━━━━━━━━━━━━━━━━━━━
▶ 3. ORGANIZATIONAL MITIGATION

Can separate access by company code/plant — but only works if the GRC rule set and authorization design correctly model those field values

━━━━━━━━━━━━━━━━━━━━
▶ 4. TREAT CHANGES LIKE NEW ROLES

Role changes deserve the same risk simulation as new roles — one added transaction/object can introduce a conflict for every current user
Derived/composite/business-role patterns improve maintainability but don't inherently eliminate SoD — always analyze effective technical permissions

✅ CHECKPOINT: explain why a single added authorization object can create risk for an entire existing user population.

Real project scenario

A purchasing support role grew for years until it contained vendor maintenance, PO approval and inventory adjustment. Nearly every senior buyer generated several SoD conflicts. The security team decomposed it into job-specific roles and used temporary EAM for rare high-risk support tasks. Request approval became simpler and risk count dropped materially.

Common mistakes

Building roles from historical users instead of business tasks.
Adding permissions without analyzing existing assignees.
Assuming composite/business roles are automatically SoD-safe.
Relying on org restrictions not represented in the rule set.
Creating permanent admin access for rare support needs.

Best practices

Risk-analyze every material role change.
Keep job roles task-focused.
Use emergency access for rare privileged operations.
Model org-level restrictions accurately.
Review inherited/composite permissions end to end.

Interview angle

Describe role engineering as the first preventive SoD control. Mention business-task decomposition, organizational restrictions, pre-transport simulation and impact on all current assignees.

Practice this lesson

Quick check

1. A team proposes this shortcut while working on Preventive SoD: Designing Roles That Avoid Conflicts Before Provisioning: "Counting violations without severity/context." Which alternative should you recommend?

2. Scenario — A purchasing support role grew for years until it contained vendor maintenance, PO approval and inventory adjustment. Which response best addresses the design or operating risk in Preventive SoD: Designing Roles That Avoid Conflicts Before Provisioning?

3. A review of User, Role and Profile-Level SoD Risk Analysis finds this risky pattern: "Building roles from historical users instead of business tasks.". Which corrective action is strongest?

Interview questions

1. You are the senior consultant/architect responsible for Preventive SoD: Designing Roles That Avoid Conflicts Before Provisioning. The project situation is: A purchasing support role grew for years until it contained vendor maintenance, PO approval and inventory adjustment. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?

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.