Segregation of duties (SoD) rarely fails as a single catastrophic event; it degrades quietly over time, surfacing during period-end close, in unexplained variances, and in increasingly complex audit discussions year after year.
In many organizations operating under controls aligned to the Sarbanes-Oxley Act (SOX), SoD is one of the few control domains that spans security, finance, IT, and internal audit. This article examines SoD as it actually operates today: across ERP and critical business systems, under external audit pressure, and in environments where spreadsheets and legacy identity governance tools (IGA) begin to reach their limits.
What Segregation of Duties Looks Like in Practice
On a whiteboard, SoD appears simple; in real enterprise systems and role models, it rarely is. At a policy level, no single individual should be able to initiate, approve, and record the same financial or operational transaction without independent oversight — but shared services models and cross-functional ownership structures make consistent enforcement difficult.
Typical examples include:
- A user who can both create or maintain suppliers and approve related invoices.
- A finance analyst who can create journal entries and post them to the general ledger.
- A payroll specialist who can update employee master data and approve payroll runs.
- A buyer who can create purchase orders, receive goods, and approve invoices (three-way conflict scenario).
Effective SoD design does not start with a rule library; it starts with understanding how business processes actually operate end-to-end.
Related reading:
- SOX Separation of Duties (SoD) Best Practices
- Why Segregation of Duties is Critical for SOX Controls
- The Three Aspects of Segregation of Duties in Access Governance
The SoD Conflicts Organizations Encounter Most Often
Common patterns include:
Master Data Creation + Transaction Execution
- Create or maintain supplier + approve payment
- Maintain customer credit limits + approve credit memos
- Maintain chart of accounts + post journals
Transaction Initiation + Approval
- Enter purchase requisition + approve purchase order
- Enter employee master data + approve salary adjustments
- Initiate wire transfers + approve them
Recording + Reconciliation Activities
- Post journals + perform reconciliations for the same accounts
- Maintain fixed asset records + approve disposals
For most organizations, the real question is not “Do we have these conflicts?” but “How many do we have, and where are they concentrated?”
Why SoD Becomes More Complex in Multi-System, Multi-Country Environments
SoD is relatively manageable in a single system with a small user base; it becomes significantly more complex as the footprint grows. Risk emerges in the gaps between systems and processes rather than within a single application.
- A user can create or maintain vendors in one system and approve payments in another.
- Shared services staff hold roles that span multiple business units and regions.
- Identity data is distributed across several directories and HR systems, so no single control owner has a complete view of what each identity can do across systems.
That is precisely where spreadsheets and single-system tools tend to fall short.
Why Manual SoD Reviews Struggle to Keep Up
Manual SoD reviews rarely fail due to negligence; they fail because the process cannot scale. A typical process looks like this:
- IT or the ERP team extracts user-role data from one or more systems.
- Internal Audit or SOX teams map those roles to SoD risks in a workbook.
- Business owners are asked to review access and attest that it is appropriate.
- Exceptions are tracked manually, often through email and ad-hoc tracking tools.
As complexity grows, the limitations become clear: volume, inconsistency across regions, evidence gaps, and timing delays. At this point, manual SoD becomes a recurring audit remediation cycle rather than a reliable control.
What Effective SoD Control Looks Like
Strong SoD means being able to answer a few straightforward questions at any time, without launching a multi-week project. You should be able to state:
- Which combinations of access are defined as toxic or conflicting for each key process.
- Which users — human and non-human — hold those combinations today, across systems.
- Which conflicts are being remediated, which are mitigated, and who owns each one.
- How preventive controls operate during provisioning and access changes, not only in periodic reviews.
How SafePaaS Helps Automate and Operationalize SoD
Modern SoD platforms support this transition through:
- Central rulebooks aligned to your processes — prebuilt SoD rule libraries covering finance, supply chain, HR, and IT scenarios.
- Continuous access risk analysis across systems to identify toxic combinations, not only inside one application.
- Preventive controls at provisioning — SoD simulation at the point of access request, so conflicts can be blocked before they reach production.
- Guided remediation workflows with full audit trail: remove access, separate duties, or apply mitigating controls.
- Audit-ready evidence on demand — dashboards and reports aligned with how external auditors test SoD and ITGC.
Further reading:
New SoD Risks Introduced by AI Agents
AI and automation do not eliminate SoD risk — they relocate it. As AI agents, RPA, and service accounts take on more work in finance, HR, and operations, they increasingly operate with privileged or persistent access in enterprise environments. Two recurring issues are:
- These identities are often created and managed outside standard identity lifecycle processes.
- Their access is expanded incrementally over time, with limited review of the overall permission set.
Modern SoD approaches increasingly include non-human identities in analysis — subject to the same rules, policies, and monitoring as human users.
Where to Start Without Boiling the Ocean
A practical starting point:
- Define a focused scope — Begin with in-scope financial processes (P2P, O2C, R2R, HR/payroll) and your main ERP(s).
- Align on a SoD rule set — Use proven rule patterns as a baseline, then refine based on how your processes actually operate.
- Baseline your current risk — Run an initial SoD analysis to understand where conflicts are concentrated.
- Define prevent vs. detect — High-risk combinations should be blocked; lower-risk duties can rely on well-designed mitigating controls.
- Plan for continuous monitoring — Embed SoD checks into access provisioning and change processes, not just annual reviews.
A platform such as SafePaaS can turn what appears to be a large undertaking into a phased, controlled program.
