Lesson 4 of 5
Segregation of duties
10 min
Segregation of duties (SoD) means no single person can complete a sensitive process alone, end to end, without a second person involved. The classic example: if one person can create a supplier, change its bank details, post an invoice and run the payment, they can pay themselves. Each step may be legitimate on its own; the combination is the risk.
Common conflict pairs
| Process | Function A | Function B | Risk if one person has both |
|---|---|---|---|
| Procure to pay | Maintain supplier master (including bank details) | Process supplier invoices or payments | Fictitious supplier or diverted payments |
| Procure to pay | Create or change purchase orders | Post goods receipts | Receipt of goods never delivered; inflated purchases |
| Procure to pay | Post supplier invoices | Run the payment program | Payment of invoices without independent review |
| Order to cash | Maintain customer credit limits | Create sales orders | Orders released to customers who should be blocked |
| Order to cash | Create billing documents or credit memos | Post incoming payments or clear customer items | Credits issued to cover diverted cash |
| Record to report | Post manual journal entries | Approve or release those entries | Unreviewed adjustments to the books |
How conflicts are found
Conflicts are defined in a rule set: a list of functions (bundles of actions and permissions, such as "maintain supplier master") and the risks that arise when certain functions are combined. Companies with SAP Access Control use its delivered rule set, tailored to their processes, and run access risk analysis on roles and users. Without such a tool, the security team analyzes role contents against a documented SoD matrix. Either way, the rule set is a business document: the process owners and internal control decide which combinations are unacceptable.
- Rule set agreedProcess owners and internal control approve conflicting function pairs
- Role design analyzedEach role checked for conflicts on its own
- User assignment analyzedCombinations of roles per user checked
- Conflicts resolvedRedesign roles or split assignments where possible
- Remaining risks mitigatedAccepted conflicts covered by a documented mitigating control and owner
- TestedBusiness tests confirm a single user cannot complete the conflicting pair
What the business tester verifies
The analysis tool or matrix says a conflict should not exist. The business test proves it in the system. For each high-risk pair, take a user who holds the roles intended for one side and try to perform the other side. Contoso's accounts payable accountant posts an invoice from Lakeside Components, then tries to change Lakeside's bank details and to run the payment program. Both attempts must fail.
| SoD test | User and roles | Step 1 (allowed) | Step 2 (must fail) |
|---|---|---|---|
| SOD-P2P-01 | AP accountant test user | Post supplier invoice for Lakeside Components | Change Lakeside's bank account |
| SOD-P2P-02 | Purchaser test user | Create PO for 500 CMC-RTR-200 | Post goods receipt for that PO |
| SOD-O2C-01 | Credit controller test user | Raise credit limit for a test fleet customer | Create a sales order for that customer |
Critical actions on their own
Some actions are risky even without a second function: changing posting periods, maintaining payment program settings, mass-changing master data. Rule sets usually list these as critical actions or critical permissions that only a few named people may hold. Test them like SoD pairs: a user without the critical role attempts the action and must be refused.
When a conflict is accepted
Small teams cannot always separate duties. In a plant with two people in purchasing and receiving, someone may need both. Then the risk is accepted and covered by a mitigating control: a documented, regular, independent check, such as a weekly review of goods receipts posted by the same user who created the PO, signed by a manager. The control needs an owner, a frequency and evidence. Testing it means checking that the report or review it relies on actually shows what it claims.
What would you do?
During UAT, Contoso's AP accountant test user posts an invoice from Lakeside Components and then successfully changes Lakeside's bank details. The analysis report showed no conflict for the role. What do you conclude?
- SoD prevents one person completing a sensitive process alone.
- Common conflicts: supplier master vs payments, PO vs goods receipt, invoice vs payment run, credit limits vs sales orders.
- Rule sets define conflicts; tools such as SAP Access Control analyze roles and users.
- Business tests prove a user can do one side and is refused on the other.
- Accepted conflicts need a documented mitigating control with owner, frequency and evidence.
Check your understanding · not graded
Lesson check
1. Which pair is a classic SoD conflict?
2. What is a mitigating control?
3. Who should decide which function combinations are unacceptable?
4. The analysis report is clean but the business SoD test shows the conflict is possible. What wins?