Lesson 5 of 6
Segregation of duties as negative tests
8 min
Listen to this lesson
Segregation of duties (SoD) means no single person should control every step of a sensitive transaction. If one person can create a supplier and pay it, a fictitious supplier can be paid without anyone else noticing. SoD is a control auditors test every year. Role testing is where you prove it before go-live.
Classic conflicts
| Function A | Function B | Risk | Contoso negative test |
|---|---|---|---|
| Maintain supplier master (including bank details) | Post supplier invoices or run payments | Pay a fictitious or altered supplier | AP clerk tries to change Lakeside Components' bank details |
| Create purchase orders | Post goods receipts | Receive goods that were never ordered properly, or hide theft | Chicago buyer tries to post a goods receipt for her own PO |
| Create purchase orders | Post supplier invoices | Order and pay without independent check | Buyer tries to post a supplier invoice |
| Maintain customer credit limits | Create sales orders | Release your own orders by raising the limit | Sales clerk tries to change Great Lakes Fleet Services' credit limit |
| Post journal entries | Open and close posting periods | Post into closed periods unnoticed | GL accountant tries to reopen a closed period |
Common SoD conflicts and the negative tests they produce. Your organization's rule set is the authority.
Where the rule set comes from
Organizations define SoD risks in a rule set: each risk is a pair (or more) of functions, and each function is a list of actions and permissions. Organizations that run SAP Access Control use its Access Risk Analysis to check users and roles against the rule set, simulate a change before it is made, and record mitigating controls where a conflict is accepted. Others use their own rule sets and reports. Either way, the test team should get the list of risks that apply to the roles in scope.
SoD is about combinations, so it also depends on assignments, not just role design. Two roles can each be clean on their own and still create a conflict when one user holds both. That is why the analysis must run on the planned user assignments as well as on the roles, and why the negative tests should use test users with the full production combination.
| Assignment | What the user can do | SoD result |
|---|---|---|
| Supplier invoice processing only | Post invoices for Lakeside Components | Clean |
| Supplier maintenance only | Create suppliers and change bank details | Clean |
| Both roles on one user | Change a supplier's bank details, then post and pay its invoices | Conflict: pay a fictitious or altered supplier |
Access risk analysis tells you whether a role design contains a conflict on paper. A negative test proves that the generated roles in the system actually stop the user. The two complement each other: analysis covers every combination quickly, and tests prove the highest-risk pairs work as designed.
| Aspect | Access risk analysis | SoD negative test |
|---|---|---|
| Question answered | Does the role design contain a conflict on paper? | Do the generated roles in the system actually stop the user? |
| Coverage | Every role and assignment, quickly | The highest-risk pairs only |
| Catches | Conflicting combinations in the rule set | Build errors, missed checks, apps reachable by URL |
| Evidence for sign-off | Analysis result for go-live assignments | Captured denial for each tested pair |
- Rule setList SoD risks that apply to roles in scope
- AnalyzeRun access risk analysis on roles and planned assignments
- Remediate or mitigateChange roles, or document an accepted risk with a mitigating control
- Negative testTest users try both halves of each high-risk pair
- EvidenceDenials captured, and mitigating controls tested where risk is accepted
Running an SoD negative test
- Pick a test user with the planned production roles, for example T_AP_CLERK_01.
- Confirm the positive half works: the clerk posts a supplier invoice for Lakeside Components.
- Attempt the conflicting half directly: open the business partner, switch to change mode and try to edit the bank details.
- Expected result: the change is refused with an authorization message, or the bank data fields are display-only.
- Capture the evidence: user, roles, the attempted action and the denial message or SU53 result.
What would you do?
Dan, Contoso's finance process owner, accepts that two small-site AP clerks will hold both supplier invoice posting and supplier maintenance because of staffing. Access risk analysis flags the conflict. What should the test plan include?
- SoD prevents one person from controlling every step of a sensitive transaction.
- Get the rule set; use access risk analysis to check designs and negative tests to prove the system.
- An SoD negative test attempts both halves with a production-like user and captures the denial.
- Accepted conflicts need a named, tested mitigating control.
Check your understanding · not graded
Lesson check
1. Which pair is a classic SoD conflict?
2. What does access risk analysis add to negative testing?
3. What is required when a business accepts an SoD conflict for some users?
4. In an SoD negative test, what is the expected result for the conflicting action?