Lesson 5 of 5
Preventive design
10 min
Listen to this lesson
Finding conflicts after users have their access is detective work, and every finding needs a decision, a change and a retest. Preventing them means checking at every point where access is designed or granted: when a role is designed, when it is built or changed, when it is assigned, and when it is tested. Shifting SoD left is cheaper for the same reason that finding defects early is cheaper.
- DesignCheck the role designMap catalogs and transactions to functions on paper; no role combines conflicting functions.
- BuildRole-level analysis before transportEvery new or changed role is analyzed in CMD before it leaves.
- Map usersUser-level simulationThe planned user-to-role mapping is simulated before assignment.
- TestNegative SoD testsTest users prove a conflicting second function is refused.
- RunRequest-time checksEvery access request is analyzed before approval.
Design roles around conflict boundaries
The easiest conflict to fix is one that never exists. When Nadia designs Contoso's business roles, she uses the rule set's functions as boundaries: a role may contain several functions, but never two that form a risk. Task-based roles (maintain suppliers; post invoices; run payments) are easier to keep clean than broad job roles, because a job that legitimately needs two conflicting tasks shows up at assignment time, where it can be decided, rather than being baked into a role.
Make SoD part of testing
Priya adds SoD to role testing in two ways. First, negative tests: for each high risk, a test user holding one side of the conflict tries the other side and must be refused. For P001, Ana's AP clerk test user tries to change a supplier's bank details and must fail. Second, a clean analysis as an exit criterion: the role test cycle cannot exit until a user-level analysis of the planned production mapping shows no unmitigated high or critical risks.
| Test | Example | Pass criterion |
|---|---|---|
| Negative SoD test | AP clerk test user tries to change supplier bank details | Refused; SU53 shows the expected missing permission |
| Rule set validation | A deliberately conflicting test role is analyzed | The analysis reports the expected risk |
| Mapping simulation | Planned production user-to-role mapping simulated | No unmitigated high or critical risks |
| Mitigation check | Accepted conflicts in 1810 | Each has an approved, assigned control with an owner |
SoD tests in Contoso's role test cycle.
- Role design workshopProcess owner and Nadia map tasks to functions and mark conflicting pairs.
- Build in CMDNadia's team builds roles from catalogs and transactions; Kenji's developers supply SU24 checks for custom code.
- Role-level analysisAny conflict inside a role sends it back to design.
- Mapping simulationThe planned user-to-role mapping is simulated; conflicts go to risk owners.
- Role test cyclePositive tests, negative SoD tests, and a final clean analysis as the exit gate.
Notice that the analysis runs twice before any business user sees the roles: once on each role and once on the mapping. Both are cheap. The expensive path is the one Contoso followed in ECC, where conflicts were found by auditors years after the roles went live and had to be removed from people who had come to depend on them.
Keep it clean after go-live
Prevention continues in operations. Access requests should run risk analysis before approval, so a conflict is seen by the approver rather than discovered months later. Role changes are analyzed before transport. Periodic access reviews catch drift. The course on SAP Access Control covers these processes in detail.
What would you do?
Priya's role test cycle is almost done. All positive tests passed. The user-level simulation of the production mapping shows six unmitigated high risks, all for users in Contoso Parts Distribution. Grace wants to exit the cycle on schedule. What should Priya recommend?
- Prevent conflicts at design, build, mapping, test and request time.
- Use rule set functions as role boundaries; task roles are easier to keep clean.
- Negative SoD tests prove one side of a conflict cannot perform the other.
- Make a clean user-level analysis an exit criterion for role testing.
- After go-live, request-time analysis and periodic reviews keep access clean.
Check your understanding · not graded
Lesson check
1. What is a negative SoD test?
2. Why are task-based roles easier to keep SoD-free than broad job roles?
3. Which exit criterion fits SoD in a role test cycle?
4. How do you prove the rule set itself works before relying on clean results?