Teams often treat SoD as a one-time access rule instead of an ongoing control discipline. The common mistake is focusing only on initial role assignment and ignoring conflicting duties that emerge through exceptions, role changes, or process drift. Effective programmes combine conflict detection, remediation, lookback analysis, and monitoring to keep controls aligned with actual work.
What auditors mean when they test segregation of duties
segregation of duties is meant to prevent one person from creating, approving, and executing a transaction or control outcome without independent review. In auditing, that idea is broader than a simple role matrix: it covers design, operating effectiveness, exceptions, compensating controls, and whether the conflict still exists after organisational change. For teams that manage access well but audit poorly, the gap is usually not the policy itself, but the failure to prove that conflicting power stayed separated over time.
That is why auditors care less about whether a conflict once existed on paper and more about whether the control consistently prevented unchecked action. The SOC 2 Trust Services Criteria (AICPA) is useful here because it reflects the evidence-based mindset auditors apply when they assess control design and ongoing operation. In practice, many teams discover their SoD gaps only after a role change, emergency exception, or audit sample exposes a conflict that should have been detected earlier.
How SoD controls fail in real audit environments
Teams usually get into trouble when they treat SoD as an access provisioning task rather than a control lifecycle. The control can be technically correct at go-live and still fail in operation if changes are not revalidated, emergency access is not time-bound, and compensating controls are not strong enough to justify the exception. Auditors look for evidence that the organisation can identify conflicting combinations, investigate them, and show what happened next. A clean role model is not enough if the real process allows the same person to initiate, approve, and conceal an action through workflow gaps.
In practice, strong SoD programmes depend on three things:
- conflict rules that match actual business processes, not just generic finance or IT templates
- continuous monitoring so new entitlements, temporary access, and inherited permissions are reviewed after change
- documented remediation or approved compensating controls when a conflict cannot be removed immediately
That operating model maps well to control-oriented guidance such as the NIST Cybersecurity Framework 2.0, especially where governance and monitoring must stay aligned with real-world access patterns. It also aligns with the control discipline described in NIST SP 800-53 Rev 5 Security and Privacy Controls, where separation and review are not one-time design choices but parts of an operational assurance model.
The practical failure point is usually not lack of policy, but lack of traceable evidence that conflicts were found, assessed, and resolved before they became audit exceptions.
Where SoD assumptions break down during exceptions and change
Tighter SoD enforcement often increases workflow overhead, requiring organisations to balance audit assurance against process speed. That tradeoff becomes visible when urgent access, delegated approval, mergers, system migrations, or role redesigns create temporary paths around normal controls.
Teams often underestimate three edge cases. First, emergency access can become standing access if expiry is not enforced and reviewed. Second, role mining can miss hidden combinations when duties are split across multiple systems rather than one application. Third, compensating controls are frequently described too broadly; if no one can show how they specifically reduce the conflict risk, auditors may treat them as weak or ineffective. There is also an ongoing industry debate about how much SoD can be automated versus where human review must remain, and the consensus is not absolute. Automated detection is useful, but final acceptance of a conflict usually needs business and audit judgment, especially when a control depends on context rather than a fixed rule.
The question for practitioners is not whether a conflict exists in theory, but whether the control still works when the business process changes faster than the role model. If the answer depends on manual memory, informal approvals, or stale exceptions, the control has already started to drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV — Oversight | SoD requires ongoing governance oversight and control monitoring. |
| Recommendation — Use GV.OV to keep SoD conflicts under continuous governance review. | ||
| CIS Controls v8 | 5 — Account Management | SoD depends on accurate account and entitlement assignment. |
| 6 — Access Control Management | SoD is enforced through least-privilege access and separation rules. | |
| Recommendation — Apply Control 5 to review accounts and remove conflicting access paths. Use Control 6 to enforce separation rules and restrict conflicting privileges. | ||
| NIST SP 800-63 | 4 — Identity Proofing and Enrollment | Identity assurance affects who can receive privileged access in controlled processes. |
| Recommendation — Apply IAL/assurance checks to reduce unauthorized privileged access assignments. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | SoD can be bypassed when attackers or insiders add conflicting privileges. |
| Recommendation — Map account changes to T1098 and detect privilege additions that defeat SoD. | ||
Practitioner Guidance
What to prioritise: Focus first on the conflict types that can create irreversible or hard-to-detect outcomes, such as approve-and-post, create-and-reconcile, or request-and-approve patterns. Those are the combinations auditors are most likely to view as materially risky because they concentrate both authority and concealment potential.
What to verify: Verify that your SoD testing covers actual transactions, temporary access, inherited access, and post-change reviews, not just user-role lists. The evidence should show when a conflict was detected, who reviewed it, what exception logic was used, and how long the condition existed.
Common mistake: Treating a clean provisioning report as proof that the control works. SoD fails when organisations measure assignment accuracy but ignore process reality, especially where manual overrides, job changes, and cross-system permissions reintroduce conflict after the initial check.
Practitioner takeaway: SoD is only credible in audit when the organisation can prove it continuously detects, explains, and resolves conflicts in the way work is actually performed, not just in the access model on paper.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
