SOX segregation of duties is becoming an identity control problem

At a glance

What this is: This is an independent analysis of SOX separation of duties as an identity governance control, with SafePaaS arguing that preventive SoD checks, audit evidence, and change tracking belong in the access lifecycle.

Why it matters: It matters because IAM, IGA, PAM, and application governance teams need the same control logic to stop toxic access combinations before they reach production or audit.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read SafePaaS's analysis of SOX separation of duties and ITGC controls

Context

SOX separation of duties is the practice of splitting access and authority so one person cannot initiate, approve, and conceal the same critical transaction. In practice, that means the control sits at the intersection of identity, entitlement design, and workflow governance, not just audit documentation.

The governance gap appears when organisations treat SoD as a spreadsheet exercise after access is already live. SafePaaS frames the problem as operational enforcement across ERP, SaaS, and change-management workflows, which is where identity governance teams have to decide whether toxic combinations are blocked up front or only surfaced during review.

Key questions

Q: How should security teams enforce separation of duties in modern enterprise systems?

A: Enforce separation of duties at the point where access is requested or changed, not after the fact. The control should evaluate role combinations, transaction rights, and approval boundaries across the full application estate, then block or escalate any toxic pairing before it becomes active. That approach turns SoD into a preventive identity control rather than a retrospective audit exercise.

Q: Why do access reviews alone fail to manage SoD risk?

A: Access reviews are too late to stop a toxic entitlement from being used. They can confirm that a conflict exists, but they cannot prevent the business impact once the user already has conflicting rights. Organisations need preventive policy checks, lifecycle controls, and change tracking so the risky combination never becomes operational in the first place.

Q: What do security teams get wrong about separation of duties?

A: They often treat SoD as a compliance checklist instead of a live governance rule. That leads to spreadsheet-based reviews, fragmented application rules, and inconsistent exception handling. Real SoD requires central policy logic, workflow enforcement, and evidence that the control was applied when the entitlement was created or changed.

Q: How do organisations prove SoD is working during audit preparation?

A: They should be able to show real-time conflict dashboards, change logs for identity-sensitive configuration, and a complete approval trail for access grants and exceptions. The strongest evidence is not a policy statement but a reconstructed control path that shows who approved what, when it changed, and whether the conflict was blocked or remediated.

Technical breakdown

Why SoD must be enforced at provisioning time

Separation of duties is most effective when the control evaluates a requested entitlement before it becomes active. That is the difference between preventive and detective governance. If the same user can request a conflicting role set and receive it immediately, the organisation has not enforced SoD, it has only documented it. In identity terms, the policy matrix has to understand role combinations, transaction paths, and approval boundaries across systems, not just within one application. This is why central rule engines and access request workflows matter: they convert SoD from a retrospective audit artifact into an access decision.

Practical implication: embed SoD checks in access request and provisioning workflows so conflicting entitlements never reach production.

How change tracking supports audit-ready identity controls

Change management is part of identity governance because configuration changes can create or remove toxic access paths. A tamper-evident change log gives auditors evidence that master data, security models, and application configuration were reviewed, approved, and deployed through defined steps. That matters especially in ERP and SaaS environments, where a small master-data change can affect who can create suppliers, approve invoices, or alter credit terms. The technical point is not just logging, but linking each change to a ticket, reviewer, and deployment trail so the control can be reconstructed later.

Practical implication: keep a complete change trail for identity-sensitive configuration so audit evidence is available without manual reconstruction.

Why cross-application policy consistency matters

SoD breaks down when entitlement rules differ across platforms or when shadow SaaS apps sit outside the governance model. A role that is safe in one application may become toxic when combined with rights in another. That is why policy harmonisation across Oracle, SAP, and cloud environments is a governance requirement, not an integration convenience. The same logic applies to PAM and identity providers: if elevated access, approval rights, and transaction permissions are controlled in separate silos, the conflict can remain invisible until after loss or fraud occurs.

Practical implication: maintain one policy logic for toxic combinations across the application estate, including SaaS and privileged access pathways.

NHI Mgmt Group analysis

SOX separation of duties is an identity governance control, not just an audit control. The article is right to frame SoD as a way to prevent one user from both perpetrating and concealing a transaction. That is the same governance logic identity teams use when they look for privilege combinations that collapse oversight. The field takeaway is that SoD belongs inside IAM, IGA, and application access design, not only in audit workpapers.

Preventive SoD is stronger than detective SoD because the harm often happens at grant time. If toxic access is allowed into production and only discovered in a later review, the control has already lost its most valuable moment. SafePaaS is describing a familiar identity lesson: access review cannot compensate for poor entitlement design. Practitioners should treat access request workflows as control points, not administrative plumbing.

Change management is part of access governance because identity risk is often created by configuration drift. When a supplier record, approval matrix, or security model changes, the resulting access path can become toxic without any user action. That makes SoD a lifecycle problem as much as a policy problem. The implication is that governance teams need evidence linking each identity-sensitive change to its approval path and business justification.

Shadow SaaS and cross-system access are where SoD controls become brittle. A clean role model in one application does not prevent conflict if another system grants the complementary authority. This is why identity programme owners should think in terms of end-to-end transactional authority rather than isolated application roles. The practitioner conclusion is straightforward: SoD must be enforced across the full control plane, not one platform at a time.

Rotational duties expose whether SoD is real or merely documented. If sensitive roles never change hands, organisations can miss hidden conflicts and long-lived privilege patterns. Rotations, exception workflows, and automated conflict checks together reveal whether the operating model can resist role creep. The practical conclusion is that SoD maturity shows up in entitlement movement, not in policy language.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader control baseline, see NHI Lifecycle Management Guide for how lifecycle enforcement changes governance outcomes.

What this signals

SoD is moving from audit language into identity architecture. That shift matters because transaction-level segregation only works when entitlement design, approval routing, and change tracking are governed together. Teams that still manage SoD as a periodic review will keep finding conflicts after they matter, not before.

A practical way to sharpen the control model is to treat toxic combinations as an access graph problem rather than a policy spreadsheet problem. Once conflicting privileges span ERP, SaaS, and privileged access, the control boundary is no longer one application, it is the whole entitlement chain.

For teams building out their identity programme, the signal is clear: the strongest SoD evidence will come from lifecycle controls, not isolated audit artefacts. Pairing access request enforcement with the NIST Cybersecurity Framework 2.0 gives practitioners a cleaner way to align governance, detection, and recovery across systems.

For practitioners

• Embed SoD checks at access request time Block or escalate conflicting entitlements before provisioning, and route every exception to an independent control owner for review.
• Tie identity-sensitive changes to auditable tickets Link master data, approval matrix, and security model changes to a ticket, reviewer, and deployment record so audit evidence can be reconstructed quickly.
• Harmonise toxic-role rules across applications Maintain one policy matrix for ERP, SaaS, identity provider, and PAM entitlements so the same toxic combination cannot slip through a different platform.
• Use rotational duties to test for hidden conflicts Periodically reassign sensitive responsibilities and compare the resulting access graph for role creep, overlapping approvals, and dormant conflicts.

Key takeaways

• SOX separation of duties becomes effective only when it is enforced as an identity control at grant time, not managed as a post-hoc audit checklist.
• The practical risk is entitlement drift across applications, because a role that is safe in one system can become toxic when combined with rights in another.
• Practitioners should focus on provisioning checks, auditable change trails, and cross-platform policy consistency to keep SoD real under operational pressure.

Key terms

• Separation of duties: A control that divides critical responsibilities so one identity cannot both initiate and approve the same sensitive action. In identity programmes, it is enforced through role design, workflow routing, and access constraints that prevent a single user from controlling the full transaction path.
• Toxic access combination: A set of entitlements that becomes risky only when held together, such as creating a vendor and approving payment to that vendor. The combination may look harmless in isolation, but the merged authority creates fraud, error, or concealment risk across the application lifecycle.
• Identity-sensitive change: A configuration or master-data update that alters who can do what in an application or process. These changes matter because they can create new privilege paths, invalidate existing controls, or shift approval authority without changing the user population itself.
• Audit trail: A record of actions, approvals, and changes that lets an organisation reconstruct how a control decision was made. For SoD and access governance, it is strongest when it links entitlement changes to a ticket, reviewer, timestamp, and final outcome.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by SafePaaS: SOX separation of duties, ITGC controls, and audit readiness. Read the original.