SoD becomes hard to prove when role and entitlement data is scattered across multiple systems and exceptions are tracked inconsistently. The control depends on seeing incompatible access combinations in one place. Without that view, teams can describe the policy, but they cannot demonstrate that it is continuously enforced.
Why SoD is hard to prove in SOX programmes
Separation of duties is easy to state as policy and hard to evidence as control because the proof depends on a complete, current view of who can do what across systems, roles, and exceptions. In SOX programmes, the control fails at the reporting layer first: if incompatible access is spread across ERP, IAM, ticketing, spreadsheets, and compensating-control notes, teams cannot reliably show enforcement.
Where the proof problem starts
The core issue is not the principle of SoD itself, but the mechanics of proving that the principle is preserved over time. A SoD rule is only as strong as the inventory behind it, because the auditor needs to see role assignments, direct entitlements, inherited access, and any temporary exceptions in one coherent population.
That becomes difficult when access is granted through different paths. A user may have one entitlement through a role, another through a manual override, and a third through a break-glass or emergency process. If those paths are not normalised into one reviewable record, the organisation can believe it has controls while still being unable to demonstrate that conflicting access was actually prevented or removed.
Why exceptions and overlapping systems break the control narrative
SoD evidence is weakened by exception handling because exceptions are often tracked as human judgment rather than as control-state data. If one team records mitigations in a spreadsheet, another in a GRC tool, and a third in a ticket comment, the organisation loses the ability to reconcile whether the exception is current, approved, limited in scope, and still valid for the specific access combination under review.
Overlapping systems also create a timing problem. Access may be compliant at certification time and non-compliant later when a role changes, a new application is introduced, or a temporary entitlement never gets removed. That means the control is not only about design, but about continuous evidence that the SoD state has been maintained between review cycles.
How SOX proof usually fails in practice
Most failures are traceability failures, not policy failures. Teams can often produce policy documents, role matrices, and sign-off evidence, but struggle to answer a simple question: which users currently hold conflicting access, through which mechanism, with what mitigation, and since when?
That question is difficult when role mining, entitlement review, provisioning history, and exception approval are split across multiple owners. It is also difficult when access is interpreted differently by different systems, for example when one tool reports the role, another reports the effective permission, and a third only records the ticket that justified the grant. The result is a control that exists in theory but is fragmented in evidence.
Risk and Threat Considerations
When SoD evidence is fragmented, toxic combinations can persist long enough for fraud, misuse, or undetected policy drift to become credible. The risk is not just audit failure, but hidden excess access that lets one person complete incompatible steps in a process without challenge.
Failure mechanism: Access is granted, modified, and excepted through separate systems, so no single control owner can prove the current effective access state or reconcile whether conflicting privileges were removed.
Impact: The organisation may fail SOX testing, miss a real segregation breach, or be forced to rely on compensating controls that are weaker than the primary SoD control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | SoD proof depends on enforcing incompatible privilege combinations. |
| AU-6 — Audit Record Review, Analysis, and Reporting | SOX proof needs traceable evidence of access and exception handling. | |
| Recommendation — Map conflicting duties and verify access paths against AC-5 before certification. Correlate entitlement, approval, and exception records for review and reporting. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | SoD evidence relies on controlled granting, review, and removal of access rights. |
| A.5.3 — Segregation of duties | The question is directly about proving segregation of duties in audit settings. | |
| Recommendation — Review, recertify, and revoke access rights on a defined schedule. Document incompatible activities and enforce segregation through role design. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | SOX-style proof overlaps with control evidence over logical access and restrictions. |
| Recommendation — Demonstrate that access is approved, restricted, and periodically reviewed. | ||
Practitioner Guidance
What to verify: Test whether you can produce one reconciled view of role membership, direct entitlements, inherited access, and active exceptions for each in-scope business process. If any one of those elements lives outside the evidence chain, SoD is likely demonstrable only at policy level, not at control level.
What good looks like: The organisation can trace each critical access path back to an owner, an approval, a time-bounded exception if one exists, and a review outcome. A reviewer should be able to determine, without manual reconstruction, whether an incompatible combination is currently present.
Practitioner takeaway: In SOX, SoD becomes hard to prove when the evidence model is fragmented, so the control should be designed around provable access state, not just approved access policy.