Lesson 3 of 5
SoD by design
11 min
Listen to this lesson
Segregation of duties (SoD) is usually enforced at the end: users are assigned roles, a risk analysis runs, and conflicts are mitigated or removed one by one. That works, but it is expensive, and it repeats every time a role changes. SoD by design moves the check to the start. Role designs are validated against the rule set before anything is built, task roles are kept conflict-free on their own, and the remaining conflicts come only from deliberate combinations of jobs, where they can be decided once.
The rule set is the specification
In SAP Access Control, a rule set contains access risks grouped by business process. Each access risk combines functions that, held by one user or role, allow an irregularity. A function is a business task defined by actions and permissions. Actions are transaction codes, Web Dynpro applications, SAP Fiori UI5 apps or OData services; permissions are authorization objects, fields and values, aligned with SU24. Risk types include segregation of duties (two or more conflicting functions), critical action and critical permission (a single action or permission that is a risk by itself). New or changed risks and functions must be generated into rules, for example with program GRAC_GENERATE_RULE, before analysis uses them.
Make the rule set S/4HANA-ready first
A rule set written for ECC describes conflicts in ECC terms. If a function lists only classic transactions, a user who performs the same task through a Fiori app or its OData service will not be detected. Before role design starts, Nadia's team updates the functions: Fiori apps and their services are added as actions, transactions retired by the conversion are removed, business partner maintenance is reflected in the vendor and customer master functions, and new company code 1910 is included in scope for Wave 2. Process owners and internal control approve the changes, and change history is kept, because the rule set is a control document that auditors will read.
- Update the rule setAdd Fiori apps and OData services as actions; remove retired transactions; regenerate rules
- Design task rolesEach task role built from catalogs per the design rules
- SimulateRisk analysis on the designed roles before they are built in CMD
- Resolve at designSplit tasks or change catalogs until no task role conflicts on its own
- Combine into jobsSimulate business roles; decide every remaining conflict with the process owner
- Build and recheckRoles built in CMD; analysis repeated on the real roles before transport
Deciding conflicts that remain
Some jobs genuinely combine conflicting tasks, especially in small teams. Contoso Parts Distribution in company code 1810 has two people in accounts payable, and after Wave 2 the Monterrey team in 1910 will be small too. For those, the design authority does not remove the conflict silently; it decides with the process owner whether to split the job, accept it with a mitigating control from the control catalog, or redesign the process. Access Control supports risk simulation, so the effect of each option can be seen before it is applied.
- Is the conflict inside a single task role?Yes → redesign the task role; never accept it · No → next question
- Can the job be split between two people?Yes → split the business role · No → next question
- Is there an effective control that detects misuse?Yes → accept with a mitigating control, owner and test of the control · No → escalate to the process owner and internal control
| Risk (example) | Conflicting functions | Design response at Contoso |
|---|---|---|
| Supplier and payment | Maintain supplier bank details / Run payment proposal | Split: master data team and Ana's payments team hold separate business roles |
| Purchasing and receiving | Create purchase order / Post goods receipt | Split by role in 1710 and 1720; accepted with mitigation in a small plant, with a monthly review |
| Sales pricing and billing | Change pricing conditions / Release billing documents | Split; pricing moved to a pricing role owned by the order-to-cash process owner |
| Critical action | Change the posting period settings | Only in a finance controller role, reviewed quarterly |
How a few typical risks are handled in Contoso's design.
Keep it designed after go-live
SoD by design only lasts if changes go through the same gate. Contoso runs risk analysis on every role change before transport and on every access request before approval, through the access request workflow. A role change that introduces a conflict into a task role is rejected at the gate, not discovered at the next audit.
What would you do?
During simulation, the new accounts payable clerk business role for 1710 shows a conflict: it combines "post supplier invoices" and "maintain supplier master". The process owner says Ana's team has always done both. What should Nadia do?
- SoD by design validates role designs against the rule set before build.
- A rule set holds risks, functions, actions and permissions; actions include Fiori apps and OData services.
- Update the rule set for SAP S/4HANA first, or Fiori access goes undetected.
- No conflict inside a task role; remaining job conflicts are split, mitigated with an owned control, or redesigned.
- Keep the gate after go-live: analyze every role change and access request.
Check your understanding · not graded
Lesson check
1. Which items can be actions in an SAP Access Control function?
2. What must happen after a risk or function is changed?
3. Why update an ECC rule set before designing SAP S/4HANA roles?
4. What is the rule for conflicts inside a single task role?