SoD and RBAC
Segregation of duties and role-based access are how an ERP prevents one person completing a whole risky transaction alone. The design work is business analysis, not technical configuration.
If you change this
It implies 2 topics across 3 modules, including Security & Identity and Human Capital Management and Financial Accounting which you might not expect.
See the path ahead →Why it matters
The conflicts that matter are business conflicts: creating a supplier and paying one, raising a purchase order and receipting it, changing a bank account and releasing a payment run. Technology enforces them; it cannot identify them.
- It is preventive: The only control that stops the transaction rather than detecting it afterwards.
- It is testable: Auditors will run the conflict report themselves.
- Small teams strain it: Where separation is impossible, compensating controls must be designed deliberately.
The workflow
- 01
Risk identification
The transactions that matter, and which combinations create exposure.
- 02
Conflict matrix
Documented in business language, owned by finance and risk.
- 03
Role design
Roles built so a single role never contains a conflict.
- 04
Assignment rules
Which roles can be held together, and which cannot.
- 05
Detection
Conflict reporting run regularly, not only at audit.
- 06
Mitigation
Where a conflict is unavoidable, a documented compensating control.
In a small finance team some conflicts cannot be separated. That is a legitimate position only if it is identified, documented and compensated — usually by independent review of the specific transaction. Silence is not a mitigation.
What you need in place
- A conflict matrix in business language: Owned by the business, not by IT.
- Roles designed against it: Conflicts prevented at design, not detected later.
- Regular conflict reporting: With an owner for resolution.
- Documented mitigations: Where separation is impossible.
- Change control on roles: A role change can introduce a conflict silently.
Questions to ask
01Matrix
Do we have a conflict matrix, and who owns it?
If IT owns it, it describes system objects rather than business risk.
02Detection
How often is conflict reporting run?
Annually, at audit, is how conflicts persist for a year.
03Mitigation
Where separation is impossible, what compensates?
It should be specific, documented and evidenced.
04Role change
Can a role change introduce a conflict without review?
Usually yes, which is the gap.
05Privileged
Do administrators bypass the matrix entirely?
Almost always. Decide whether that is acceptable.
Metrics and KPIs to track
Open conflicts
Users with unmitigated conflicting access.
Mitigation coverage
Accepted conflicts with a documented compensating control.
Detection frequency
Conflict reporting run per period.
New conflicts introduced
Per role change cycle.
Alongside this