An SoD programme is working when conflicting access is prevented at provisioning, surfaced during certification, and removed quickly when role changes occur. If violations keep appearing in review cycles or after offboarding, the control is reporting risk rather than reducing it.
What a working SoD programme actually looks like in operations
A working Segregation of Duties programme is visible in the control path, not just in policy language. The key test is whether toxic combinations are blocked before access is granted, whether they are exposed when teams certify access, and whether they are removed fast enough when roles, projects, or employment status change.
That means the programme is doing three things at once: preventing avoidable conflict at provisioning time, finding residual conflict during review, and closing the gap between detection and remediation. If one of those layers is missing, the programme may still be producing reports, but it is not reliably reducing exposure.
A practical way to judge health is to compare the rate of newly created conflicts with the rate of resolved conflicts. If provisioning keeps reintroducing the same toxic combinations, the issue is usually upstream in role design, request workflows, or exception handling rather than in the review process itself.
Where SoD programmes usually break down
The most common failure is treating SoD as a periodic audit activity instead of a living access control. That produces a familiar pattern: conflicts are discovered late, approved as temporary exceptions, and then left in place because no one owns cleanup after the certification closes.
Another common break point is offboarding and role transition. If a person moves from one job family to another and retains incompatible access, the programme is allowing privilege accumulation to outrun governance. In practice, that is often a sign that access removal is slower, less automated, or less enforced than access grant.
A Segregation of Duties Guide is useful here because it frames SoD as a ruleset and remediation discipline, not just a compliance checklist. The right benchmark is whether the programme prevents conflicting access, detects it at review, and gives teams a clear path to mitigation or removal.
How teams measure whether it is working
Good SoD measurement focuses on control effectiveness, not just volume of reviews completed. Teams should look for whether violations are trending down, whether exceptions have expiry dates, whether remediation happens inside the expected service window, and whether the same conflicts reappear in subsequent certifications.
Another useful indicator is the proportion of violations caught before access is used versus after the fact. If conflicts are only found during quarterly certification, the control is mostly detective. If they are blocked or flagged at request time and then cleaned up during review, the programme is much closer to preventive.
The most honest measure is the repeat-violation rate. When the same role, entitlement, or business unit keeps generating the same conflict, the issue is no longer an isolated access problem, it is a design problem in the role model, approval chain, or exception process.
Risk and Threat Considerations
SoD failure creates a direct path to fraud, error, and unauthorized activity because conflicting access concentrates too much authority in one place. The risk grows when exceptions become permanent, when reviews are rubber-stamped, or when offboarding leaves residual access behind.
Failure mechanism: Toxic combinations are introduced at provisioning, survive certification without challenge, and persist after role changes because no one is accountable for timely removal.
Impact: The organisation gets false assurance from the programme while retaining the exact access patterns SoD is meant to prevent, which increases exposure to misuse, hidden conflict, and delayed detection.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly governs conflicting access and duty separation in access controls. |
| AC-6 — Least Privilege | Supports SoD by constraining access to what each role needs. | |
| Recommendation — Enforce AC-5 to separate conflicting duties and limit concentrated access paths. Apply AC-6 to reduce entitlement overlap and shrink the blast radius of role changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control governance underpins SoD rule enforcement and review. |
| Recommendation — Use A.5.15 to govern access approval, review, and revocation for conflicting entitlements. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD depends on provisioning, review, and removal of conflicting accounts and entitlements. |
| Recommendation — Use CIS-5 to manage account creation, review, and removal of conflicting access. | ||
Practitioner Guidance
What to verify: Confirm that SoD rules are enforced at request or provisioning time, not only in review reports. If the first place a conflict appears is a quarterly certification screen, the programme is already behind the risk.
What to measure: Track blocked requests, open exceptions, mean time to remove conflicts, and repeat violations by role or business unit. These metrics tell you whether the programme is suppressing risk or simply documenting it.
Common mistake: Treating approved exceptions as a permanent operating state. Every exception should have an owner, expiry, and remediation path, otherwise the SoD model becomes a record of tolerated failure.
Practitioner takeaway: A working SoD programme reduces exposure only when prevention, review, and cleanup all operate together, with rapid removal after changes as the decisive test of control health.
Related resources from NHI Mgmt Group
- How do teams know whether an AI assessment programme is actually working?
- How do security teams know whether a discovery programme is actually working?
- How do security teams know whether an image redaction programme is actually working?
- How do security teams know whether least privilege is actually working?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org