Join our Newsletter — 33% off our NHI Course
Home FAQ Governance, Ownership & Risk What are the signs that Segregation of Duties…
Governance, Ownership & Risk

What are the signs that Segregation of Duties is failing in an organisation?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 19, 2026 Domain: Governance, Ownership & Risk

Common signs include one user holding both initiation and approval rights, repeated exceptions to workflow rules, weak audit trails, and access that does not match job responsibilities. If transaction review is slow or inconsistent, conflicts can remain hidden. These symptoms usually point to poor access governance, incomplete role design, or reporting that does not reliably surface violations.

Where segregation of duties breaks down in practice

segregation of duties fails first as a control design problem, then as a monitoring problem. The clearest warning signs are not just obvious conflicts, but the quiet normalisation of exceptions, workarounds, and shared access that lets one person complete an entire sensitive process end to end.

That often happens when role design is incomplete, approval paths are too broad, or the business has grown faster than access governance. In a healthy control environment, duties are separated at the transaction, workflow, and review layers, so the same individual cannot initiate, approve, and conceal the same action.

  • One person can create and approve the same transaction.
  • Exceptions are repeatedly granted for the same users or teams.
  • Audit trails exist, but they are too weak to show who did what and when.
  • Access reviews do not consistently expose job conflicts or incompatible entitlements.

Why weak review and reporting are usually the real failure point

When SoD is failing, the technical symptom is often easier to see than the governance failure behind it. Slow, inconsistent, or manual review processes allow conflicts to persist long after they should have been resolved, especially when approvers trust the process more than the evidence.

That is why ISO/IEC 27002:2022 Information Security Controls is useful context here: effective control design depends on both separation and review. In practice, the question is whether the organisation can reliably detect incompatible access, not whether a policy says conflicts should not exist. Strong review evidence should show timely recertification, clear ownership of exceptions, and traceable approvals that can be tested.

Access governance failures also tend to appear when job responsibilities change but entitlements do not. A user may move teams, gain project responsibilities, or inherit temporary access, and the old approval path remains in place long after the original business need has gone. That produces a control that looks compliant on paper while silently losing its preventive effect.

Practitioner guidance for spotting SoD failure early

What to verify: Test whether the control is being enforced at the point of request, at approval, and at periodic review. If those three layers do not agree, the organisation has a real SoD weakness rather than a documentation issue.

  • Check whether the same role can both originate and approve high-risk transactions.
  • Look for recurring exceptions that have become routine rather than temporary.
  • Compare live access against current job responsibilities, not legacy role names.
  • Review whether audit logs can reconstruct the full approval path without manual guesswork.

What to prioritise: Focus first on high-impact processes where a single conflict can conceal fraud, error, or unauthorised change. Controls are most fragile where teams rely on informal checks, shared inboxes, or delegated approvals that were never revalidated after process change.

Practitioner takeaway: SoD is failing when exceptions become the normal operating model and nobody can prove that conflicting powers are still being separated in real time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA — Identity Management, Authentication, and Access ControlSoD failure is an access governance issue requiring controlled entitlement separation.
GV.RM — Risk Management StrategySoD gaps create governance risk that must be measured and owned at program level.
Recommendation — Enforce role separation and periodic access reviews for conflicting duties. Track SoD exceptions as governance risk and escalate repeated conflicts.
CIS Controls v86 — Access Control ManagementSoD breakdown often shows up as excessive or conflicting access rights.
8 — Audit Log ManagementWeak audit trails make SoD violations hard to detect or investigate.
Recommendation — Review privileged and conflicting access to remove incompatible entitlements. Centralize logs so approvals and transaction actions remain reconstructable.
ISO/IEC 42001:2023A.2 — AI PolicyGovernance patterns for rule enforcement and oversight are directly relevant to control accountability.
Recommendation — Define ownership for control exceptions and monitor policy overrides.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 19, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org