How do organisations know if SOD controls are actually working?

Look for two signals: risky requests being blocked before access is granted, and existing violations being found and remediated on a recurring schedule. If violations only appear after incidents or audits, the control is reactive. Effective SOD programmes show both low conflict rates and fast exception handling.

Why This Matters for Security Teams

Segregation of duties only matters if it changes actual decision-making, not if it merely documents separation on paper. In identity and access workflows, that means controls must block toxic combinations before access is granted and surface standing violations before they become incidents. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a governance and enforcement problem, not a checkbox exercise. When SOD is weak, privileged requests can be approved by the same people who benefit from them, and exceptions become permanent.

That matters even more for non-human identities, where service accounts, API keys, and automation pipelines can bypass human review if they are not explicitly governed. NHI Mgmt Group’s Ultimate Guide to NHIs — Standards notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that makes SOD failures hard to see until damage is already underway. The practical question is not whether a policy exists, but whether conflicting access is prevented, detected, and remediated on a predictable cycle. In practice, many security teams discover broken SOD only after an audit trail is reconstructed from an incident.

How It Works in Practice

Working SOD controls operate at two layers: preventive control during request approval and detective control during recurring access review. Preventive SOD checks should compare the requestor, approver, target system, and entitlement against a conflict matrix before access is granted. Detective SOD checks should continuously scan current access against the same matrix so standing violations are found even if they predate the latest request.

The strongest programmes treat SOD as policy logic, not manual memory. That usually means defining forbidden combinations in a policy engine, integrating the policy with IAM or PAM workflows, and recording every exception with an expiry date and compensating control. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of enforced review discipline, while the NHI Mgmt Group Ultimate Guide to NHIs — Standards is useful for framing how these controls extend to service accounts, tokens, and secrets.

• Block toxic combinations at approval time, rather than approving first and reviewing later.
• Re-scan standing access on a fixed schedule, especially for privileged and shared identities.
• Track exception ageing, because an open-ended exception is usually a failed control.
• Measure the ratio of conflicts detected to requests processed, plus time to remediation.

For NHI-heavy environments, that logic should also cover machine credentials, because a service account with broad permissions can create the same separation failure as a human admin. Controls tend to break down when approvals are buried inside CI/CD pipelines or ticketing workflows, because the same automation that speeds delivery also makes conflict review easy to bypass.

Common Variations and Edge Cases

Tighter SOD controls often increase workflow friction, requiring organisations to balance approval speed against assurance. That tradeoff is real, especially in engineering and cloud operations where legitimate dual control can slow releases. Current guidance suggests focusing the strictest SOD rules on high-impact actions first, rather than applying the same friction everywhere.

Edge cases matter. In smaller teams, there may not be enough staff to separate every duty cleanly, so compensating controls become necessary. In cloud and DevOps settings, one person may legitimately author the workflow, deploy it, and observe it, which means SOD must be expressed as policy over specific actions rather than job titles. That is why NIST-aligned control design and the broader inventory discipline in the Ultimate Guide to NHIs — Standards are both important.

Another common failure mode is treating exception review as proof of control health. A programme can look busy while still failing, if exceptions are never expired and recurring violations are not trending downward. The control is working only when conflicts are caught early, exceptions are short-lived, and the same violations do not keep reappearing across access reviews.

Related resources from NHI Mgmt Group

• How do organisations know if zero trust controls are actually working?
• How do organisations know whether NHI controls are actually working?
• How do organisations know whether mobile asset controls are actually working?
• How do security teams know if SoD controls are actually working?