Lesson 2 of 5
Segregation of duties
8 min
Some combinations of access are dangerous even when every individual permission is reasonable. Segregation of duties (SoD) means splitting a business process so that no single person can both commit an action and conceal it. It is one of the oldest internal controls in finance, and it is the reason your role sometimes stops short of what you think you need.
Two everyday examples
Supplier master and payments. If one person can create a supplier, change its bank account and run the payment program, that person could create a fictitious supplier, or redirect a real supplier's payments to their own account, and pay it. Splitting supplier maintenance (master data team) from payment execution (treasury or accounts payable) means fraud needs two people to collude.
Purchasing and goods receipt. If the buyer who creates a purchase order can also post the goods receipt, they could confirm delivery of goods that never arrived, triggering an invoice match and payment. Contoso splits the two: purchasing group 001 creates POs for Lakeside Components, and the warehouse in plant 1710 posts receipts in storage location 171A.
| Process | Duty A | Duty B | Risk if combined |
|---|---|---|---|
| Procure to pay | Create or change supplier master (including bank details) | Run payments | Pay a fictitious supplier or divert payments |
| Procure to pay | Create purchase order | Post goods receipt | Confirm goods that never arrived |
| Order to cash | Create customer credit memo | Post incoming payments or clear customer items | Hide stolen cash behind credits |
| Record to report | Post manual journal entries | Approve or release the same entries | Unreviewed adjustments to results |
| Security | Maintain user roles | Use those roles in business transactions | Grant yourself any access you want |
How SoD is enforced
SoD lives in three places. First, in role design: the security team builds roles that do not contain conflicting duties. Second, in access requests: when someone asks for an extra role, the request is checked against a rule set of conflicts. SAP's own governance product for this, SAP Access Control, runs that kind of risk analysis; other companies use their own process. Third, in process controls inside SAP, such as dual control for sensitive supplier fields: when a defined field like the bank account is changed, the supplier can be blocked for payment until a second person confirms the change.
When a conflict cannot be avoided, for example in a small team, the company documents a mitigating control: a periodic review of the risky transactions by someone else. At Contoso, a two-person treasury team in Chicago might need overlapping access during holidays; Dan, the finance process owner, reviews a weekly list of supplier bank changes and payments to compensate.
SoD and audit findings
External and internal auditors test SoD every year. Typical findings are users who hold conflicting roles without a mitigating control, roles that were extended "temporarily" and never cut back, and generic or shared users that make it impossible to tell who did what. Each finding costs time and credibility, and repeated findings can affect the auditor's opinion on internal controls.
- RequestUser asks for an extra role, with a business reason
- Risk analysisThe request is checked against the company's conflict rules
- ApprovalManager and role owner approve, or reject, or add a mitigating control
- ProvisioningSecurity team assigns the role
- Periodic reviewRole owners recertify access, typically each quarter or year
What would you do?
During testing, a Contoso accounts payable clerk reports she cannot change a supplier's bank account to correct a typo. The supplier is waiting for a payment. What should happen?
- Segregation of duties splits a process so one person cannot both commit and conceal an error or fraud.
- Classic conflicts: supplier maintenance with payments, purchasing with goods receipt, user administration with business use.
- SoD is enforced through role design, risk analysis on access requests and controls such as dual control for sensitive fields.
- When conflicts cannot be avoided, a documented mitigating control is required.
- Test with production-like roles, including tests that prove a conflicting step is blocked.
Check your understanding · not graded
Lesson check
1. Why is "create supplier" separated from "run payments"?
2. A buyer can create purchase orders and post goods receipts for them. What is the risk?
3. What is a mitigating control?
4. Why is testing with super-user access a problem?