Auditors look for evidence that no one person can complete high-risk actions without checks and balances. That includes toxic access combinations, real-time control enforcement, and records showing conflicts were detected and resolved. Teams also need to show that approval workflows prevent conflicting access from being granted in the first place.
What auditors are testing in a separation of duties review
Auditors are not looking for a policy statement alone. They want to see that the control is designed to stop one person from initiating, approving, and completing the same sensitive transaction, and that the organisation can prove the restriction is enforced in real workflows rather than only described on paper.
They also expect evidence that the SoD model is defined around the actual business process, because the relevant conflicts vary by system. In practice, that means the review needs to show which roles or permissions are incompatible, how exceptions are handled, and how conflicts are prevented or detected before they create exposure.
For a practical baseline on how SoD fits into access governance, IAM and IGA Basics is the best starting point.
What counts as strong evidence for SoD controls
Auditors usually look for three kinds of proof: a documented SoD matrix or ruleset, operational evidence from access requests and approvals, and records that show conflicting access was either blocked, remediated, or formally approved under an exception process. The strongest evidence ties the rule to a live system control, not just a spreadsheet.
They will often sample access grants, role changes, and high-risk transactions to confirm that no single user can both request and approve incompatible actions. Where an organisation relies on mitigating controls, auditors typically want to see compensating review, monitoring, or additional approval steps that are specific enough to reduce the conflict rather than merely acknowledge it.
If the process includes toxic combinations, conflict detection, or exception handling, the most relevant reference is Segregation of Duties (SoD) Guide.
How auditors judge enforcement, not just intent
Auditors generally care more about control enforcement than policy language. That means they check whether the approval path actually prevents a conflicting access grant, whether privileged users can bypass the control, and whether the system leaves a trace when a conflict is attempted or overridden.
They also look for operational consistency across joiner, mover, and leaver activity, because SoD breaks down quickly when role changes are not re-evaluated after promotions, temporary assignments, or emergency access. A mature review usually demonstrates that access recertification, role design, and transaction-level controls all point to the same SoD outcome.
For broader control expectations around access restriction, logging, and periodic review, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful benchmark.
Risk and Threat Considerations
SoD failures create fraud, error, and override risk because a single user can hide a bad transaction, approve their own change, or cover a control weakness without immediate challenge. The risk becomes materially higher when the same role can touch request, approval, execution, and review steps in a system with financial, production, or regulated impact.
Failure mechanism: Control failure usually appears as excessive role overlap, weak exception handling, or manual workarounds that let users operate outside the intended approval chain. Once that happens, the control may exist in policy while the transaction path still permits end-to-end compromise of trust.
Impact: The practical impact is loss of integrity in sensitive processes, higher fraud exposure, weaker auditability, and a greater chance that toxic access remains undetected until after a loss or failed audit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | SoD is an IAM governance control over incompatible access and approvals. |
| Recommendation — Define incompatible access roles and enforce SoD checks in your IAM governance workflow. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses segregation of incompatible duties and conflict prevention. |
| AC-6 — Least Privilege | Limits role overlap so SoD conflicts are less likely to arise or persist. | |
| AU-6 — Audit Review, Analysis, and Reporting | Auditors need logs and review evidence showing conflicts were detected and handled. | |
| Recommendation — Implement AC-5 to prevent users from performing conflicting high-risk actions end to end. Apply AC-6 to remove unnecessary permissions that create toxic access combinations. Use AU-6 to review SoD exceptions, conflict alerts, and override activity. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is part of access control design and enforcement in an ISMS. |
| A.5.18 — Access rights | Audits commonly examine whether access rights create incompatible duties. | |
| Recommendation — Map SoD rules into access control policies and enforce them consistently. Review access rights regularly and remove combinations that create conflicts. | ||
Practitioner Guidance
What to verify: Test the control against actual high-risk workflows, not just role names. A SoD rule is only credible if the system stops the conflicting action at the point of request, approval, or execution, and if exceptions are time-bound and reviewable.
What good looks like: The organisation can show a current conflict matrix, automated or enforced approvals, exception logs with named owners, and periodic reviews that remove conflicts instead of repeatedly tolerating them.
Common mistake: Treating SoD as an access review exercise only. Auditors usually flag controls that discover conflicts after the fact but do not prevent the conflicting access from being granted in the first place.
Practitioner takeaway: The strongest SoD control is one that prevents conflicting access at design time, enforces it in the workflow, and leaves evidence that exceptions are rare, owned, and resolved.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
