Segregation of duties (SoD) is the internal control principle under which the tasks involved in a high-risk transaction process are divided among multiple individuals — so that no single person has the ability to initiate, approve, execute, and record a transaction without the oversight of another. The principle applies most directly to financial processes where the combination of capabilities creates fraud risk: a person who can both create a vendor and approve vendor payments; a person who can both enter a sales invoice and post a credit note; a person who can both request a purchase and approve the purchase order.
The practitioner distinction: SoD is not about distrust. It is about removing the opportunity for undetected error or misconduct — protecting the individual as much as the organisation. An employee with excessive access who makes an error, or who is later accused of misconduct, is harder to defend in either the finance function or a regulatory investigation. Proper SoD protects the employee from accusations they cannot disprove because no one was checking.
In the Context of Egypt and the GCC
ERP implementations in GCC enterprises — Oracle EBS, SAP, and Microsoft Dynamics are the most common — carry default role configurations that frequently violate SoD principles if applied without review. During implementation, access is typically granted broadly to meet go-live deadlines and narrowed later through an access review. In practice, the narrowing often does not happen. Organisations operating Oracle EBS or Fusion with four-year-old role configurations may be carrying access conflicts that were introduced at go-live and have never been reviewed. ZATCA audit procedures in Saudi Arabia include user access review as part of the IT general controls assessment — meaning unresolved SoD conflicts are not only an internal risk, they are a regulatory exposure.
How This Connects to EPM and Systems
SoD in EPM environments governs who can prepare a budget, who can approve it, who can adjust actuals data, and who can override a consolidation. Oracle EPM applications support role-based access at granular levels — read, write, and approval rights can be configured at the form, entity, and scenario level. A budget administrator who can both enter budget data and approve their own submission has an EPM-level SoD conflict as material as an ERP-level one. EPM access design must be reviewed against the SoD control framework with the same rigour as ERP access.
What Goes Wrong
The failure that concentrates risk invisibly is role accumulation over time: an employee joins the finance team with appropriate, limited access. Over three years, they take on additional responsibilities and are granted additional system access for each. No single access grant created a conflict. The cumulative set does. By the time an access review is conducted — if one is ever conducted — the employee has a combination of capabilities that would never have been approved if requested together. In the absence of automated SoD conflict detection tools (Oracle Identity Governance, SAP GRC), this accumulation is invisible to the finance function until an auditor or a loss event surfaces it.
How Loop Wise Solutions Encounters This
SoD review is a standard component of our ERP and EPM assessment work. We analyse the current role-to-responsibility mapping against a defined SoD conflict matrix — the combinations of access that create unacceptable risk — and produce a remediation plan that resolves conflicts through role redesign, compensating controls, or additional oversight. In most organisations we assess across the region, the number of active SoD conflicts is higher than the finance leadership expects, and the resolution requires both system reconfiguration and process change.
