Why do segregation of duty issues keep reappearing in SOX programmes?

Why This Matters for Security Teams

Segregation of duty failures keep resurfacing in SOX programmes because the control is often managed as a periodic review, while the actual risk is created by identity drift between reviews. When access changes are not synchronized with role changes, temporary project access, emergency access, and inherited entitlements can outlive the business need. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, and the same visibility gap often affects human access paths that feed SOX conflicts.

That matters because SOX control owners need to prove that incompatible duties are prevented, not merely detected later. If an approver can also create vendors, if a developer retains production access after moving to finance, or if a leaver remains active in downstream systems, the certification evidence will look fine until a walkthrough or audit samples the wrong account. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity governance must be continuous rather than episodic. In practice, many security teams encounter SoD conflicts only after an auditor or fraud review has already surfaced them, rather than through intentional lifecycle control.

How It Works in Practice

Effective SOX segregation of duty management starts with defining incompatible entitlement combinations by process, not by system alone. Finance, procurement, payroll, and ERP controls should be mapped to business actions such as creating, approving, reconciling, and posting transactions. That map then has to connect to identity lifecycle events: hire, transfer, temporary assignment, return from leave, contractor renewal, and offboarding. If the access model does not ingest those events quickly, an apparently clean certification cycle can still leave conflicting access in place.

Practitioners usually improve outcomes by combining preventive and detective controls:

• Use RBAC to limit default access, but treat it as a baseline rather than the full control.
• Trigger access removal or reapproval when a user changes role or department.
• Use workflow approvals for exceptions, with time-bound expiry and documented compensating controls.
• Reconcile joiner-mover-leaver events against entitlement records before the next certification window.
• Track privileged roles separately, because SoD conflicts are harder to spot when admin rights sit outside normal business roles.

The strongest programmes also tie evidence to operating procedures. NHI Management Group’s Ultimate Guide to NHIs shows how lifecycle gaps, poor visibility, and stale access create persistent risk conditions that look similar across human and non-human identities. The Top 10 NHI Issues page is also useful for understanding how stale entitlements compound when ownership is unclear. In SOX terms, the control should prove that access is removed or re-approved when duties change, not merely that a reviewer signed off on an unchanged report. These controls tend to break down in fragmented ERP and IAM environments because entitlement ownership, approval logic, and HR event timing are not governed by the same workflow.

Common Variations and Edge Cases

Tighter SoD controls often increase operational friction, requiring organisations to balance fraud prevention against business continuity. That tradeoff becomes visible in month-end close, merger integrations, emergency access, and shared services models, where one person may legitimately need multiple responsibilities for a short period. Current guidance suggests documenting these exceptions explicitly rather than pretending they do not exist, because undocumented exceptions become audit findings later.

There is also no universal standard for every SoD matrix. Some companies enforce SoD at the application layer, while others rely on ERP rules, downstream workflow checks, or periodic reviews. The right model depends on how much control the system can enforce natively and how quickly entitlements can be changed after an HR event. If the environment includes outsourced finance teams, shared service centres, or overlapping admin and business roles, the control boundary often becomes a governance problem as much as an access problem.

For audit readiness, the practical test is simple: can the organisation show that incompatible access is prevented, detected quickly, and removed before it becomes repeatable risk? If the answer depends on manual spreadsheets and quarterly cleanup, the same SoD issue will keep reappearing. When role design is weak and access revocation is delayed, certification becomes a rear-view mirror instead of a control.

Related resources from NHI Mgmt Group

• Why do access reviews matter so much in SOX programmes?
• Why do access creep and privilege abuse keep showing up in IAM programmes?
• Why do segregation of duties controls matter so much in SOX readiness?
• Why do excessive permissions keep showing up in IAM programmes?