Start with business processes that carry financial, operational, or regulatory risk, then identify the specific duties and approvals within each workflow. The right rule is the one that reflects a real process conflict, not a theoretical role overlap that does not change actual business risk.
How to choose SoD rules that reflect real business conflict
Segregation of duties works best when it is tied to a concrete workflow outcome, not a generic matrix of forbidden role pairs. For IAM teams, the practical question is whether one person, account, or automated actor can complete a sensitive transaction end to end without an independent check. That is where Segregation of Duties (SoD) Guide becomes operational rather than theoretical.
Start by mapping the business process first, then mark the points where approval, creation, modification, execution, and review should be separated. A useful SoD rule protects a process that can actually move money, change records, approve access, or create compliance exposure. If a role overlap does not change that outcome, it is usually noise, not a control.
The best rules are also specific about scope. A good SoD design distinguishes between broad job titles and the narrower access combinations that create risk inside a given system, such as request and approval, create and approve, or administer and audit. That is why a process view is stronger than a generic role catalogue. It helps teams avoid overblocking low-risk work while still catching truly conflicting authority.
What makes an access combination a real SoD conflict?
A real conflict exists when the same actor could initiate a transaction, approve it, and conceal or finalize it without meaningful independent review. The issue is not whether two permissions look similar on paper, but whether their combination defeats the control objective of the process. In practice, that means tying the rule to a decision path, record mutation, payment flow, or privileged change that carries material consequence.
This is also where identity governance and role engineering matter. The rule should be expressible in terms the IAM platform can enforce and the business can understand, which is why the right abstraction is often a duty pair or workflow step, not a department name. For lifecycle and governance depth, teams often benefit from NHI Lifecycle Management Guide and Identity Security Programme Guide because SoD rules only hold if ownership, review, and recertification are built into the operating model.
In mature environments, SoD is not a static list. It is a control model that evolves as business applications, delegated approvals, and automation paths change. If a workflow changes, the conflict model should be revisited. Otherwise teams end up enforcing yesterday’s process while today’s transaction path remains unprotected.
How IAM teams turn process analysis into enforceable rules
The practical workflow is to inventory sensitive processes, identify who can request, approve, execute, and reconcile each one, then map those steps to entitlements and role combinations. That makes the SoD rule testable. If the platform cannot detect the conflicting combination, the rule is not really enforceable.
Good implementations also distinguish prevention from detection. Some conflicts should block access at provisioning time, while others are better handled as monitored exceptions with compensating controls and periodic review. The right choice depends on how material the process is and how disruptive the control would be if enforced too early. Teams that need a broader operating pattern can anchor this work in the SoD guide and, for privileged scope and right-sizing, Cloud PAM and CIEM Guide.
Exception handling is where many programs fail. If a conflict is allowed for operational necessity, the exception should be explicitly owned, time-bound, and reviewed, not buried inside a broad role assignment. That discipline matters even more when automation or non-human actors are involved, because exceptions can scale quietly across many transactions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-6 — Access Control Management | SoD rules are an access governance control over who can combine sensitive entitlements. |
| Recommendation — Define and review conflicting access combinations before provisioning them. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses separating conflicting duties in sensitive workflows. |
| AC-6 — Least Privilege | SoD rules should narrow access to only the duties needed for each workflow step. | |
| AC-2 — Account Management | SoD enforcement depends on lifecycle control of role assignments and exceptions. | |
| Recommendation — Assign duties so no single role can complete conflicting steps alone. Limit entitlements to the minimum needed for each process stage. Review account assignments and revoke conflicting access promptly. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | The topic is explicitly about separating conflicting duties in access design. |
| Recommendation — Separate incompatible duties within business-critical processes. | ||
Practitioner Guidance
What to prioritise: Build SoD rules around the few workflows where a single actor could create material financial, operational, or regulatory harm. Do not start with the role catalogue, start with the transaction path.
What to verify: For each proposed rule, verify that the conflicting access actually enables request, approval, execution, or concealment in the same process. If it does not change a real business outcome, it should not become a blocking rule.
Common mistake: Teams often overfit SoD to organizational structure and end up blocking harmless overlaps while missing process-level conflicts. The better test is whether the combination removes an independent check from a sensitive workflow.
Practitioner takeaway: Strong SoD is narrower than most first drafts, but more defensible: it should protect real decision points, be enforceable in the IAM platform, and stay aligned to how the business actually runs.
Related resources from NHI Mgmt Group
- What should IAM and GRC teams do when access reviews and SoD rules disagree?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org