IT should operate the workflow, but business owners should define the conflict logic and approve exceptions in their process areas. That split keeps governance accurate, accountable, and close to the operational reality it is meant to control.
How to Split SoD Authority Without Blurring Accountability
Segregation of duties works best when the control owner and the process owner are not the same person by default. IT can run the system, but business ownership should define the conflict rules because it understands the transaction, exception, and fraud context. That separation reduces guesswork and prevents technical teams from becoming accidental policy authors.
SoD governance is really about deciding who may define risk tolerance versus who may execute control mechanics. IT owns the workflow, logging, evidence, and enforcement path; the business owns the meaning of the conflict and the exception standard inside its process area. If those responsibilities collapse into one side, SoD becomes either too rigid to use or too loose to trust.
That split is also how you keep the model auditable. A reviewer should be able to trace each rule back to a business justification, then see that IT applied it consistently across accounts, roles, and approvals. When ownership is unclear, exceptions tend to drift into informal approvals, which makes recertification and dispute resolution much harder later.
Where Governance Breaks Down in Practice
Problems usually appear when teams confuse operational administration with control design. IT may be closest to the tooling, but it is rarely closest to the business process that creates the toxic combination in the first place. Business owners, in turn, may know the process but underestimate how their exception requests affect access scope, detective controls, and downstream audit evidence.
A useful internal reference point for this operating model is Segregation of Duties (SoD) Guide, which shows how to build rulesets, mitigate conflicts, and extend segregation logic to more than just human users. For broader identity governance design, Identity Security Programme Guide is helpful because SoD only works when ownership, RACI, and governance are explicit. If your environment also depends on shared accounts, service accounts, or automation, the Lifecycle Processes for Managing NHIs section is a good reminder that governance has to cover non-human access as well as workforce access.
The practical failure mode is overcentralisation. When IT is asked to invent the conflict logic, it tends to produce generic rules that do not reflect actual process risk. When business users are allowed to bypass IT controls informally, they may preserve speed but lose traceability, which is usually where audit findings start.
What Good SoD Ownership Looks Like for IAM Teams
What to verify: confirm that each process area has a named business owner who approves the conflict matrix, exception criteria, and compensating controls, while IT owns implementation, evidence, and periodic enforcement checks. If the same person signs off on both the business rule and the technical exception, the control is no longer meaningfully segregated.
Decision rule: if the issue is policy meaning, process risk, or acceptable exception logic, route it to the business owner; if it is role design, workflow operation, or evidence capture, keep it with IT. That division keeps governance close to operational reality without turning the control into a free-for-all.
What practitioners underestimate: SoD is not just about denying access, it is also about managing exception lifespan. Exceptions that are never reviewed or revalidated become shadow policy, and shadow policy is where ownership confusion becomes control failure.
Practitioner takeaway: The healthiest operating model is federated accountability, not federated ambiguity, business defines the conflict standard, IT enforces it, and both must be able to defend the same decision set during review.
Risk and Threat Considerations
When business ownership and IT control are not cleanly separated, SoD governance can fail in two directions at once, business teams can approve conflicts too casually, or IT can apply rules that are technically consistent but operationally wrong. Either problem weakens trust in the control and increases the chance that exceptions become a permanent access path rather than a temporary risk decision.
Failure mechanism: unclear ownership allows toxic combinations, compensating controls, and exception approvals to be interpreted differently across teams, which creates inconsistent enforcement and weak auditability.
Impact: excessive access, unreviewed exceptions, and disputed accountability can expose financial processes to fraud, error, and prolonged control gaps.
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-2 — Account Management | SoD governance depends on controlled role and access assignment ownership. |
| AC-5 — Separation of Duties | The question is directly about splitting business ownership and IT control in SoD. | |
| AU-6 — Audit Review, Analysis, and Reporting | SoD needs reviewable evidence for exceptions and conflicting access decisions. | |
| Recommendation — Define account ownership and approval paths before granting conflicting access. Separate rule definition, approval, and enforcement responsibilities. Review SoD exception logs and approvals for anomalies and control drift. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Directly addresses segregation of responsibilities in governance and operations. |
| A.5.18 — Access rights | SoD governance depends on granting, reviewing, and revoking access consistently. | |
| Recommendation — Assign conflicting duties to different roles and document approval boundaries. Review access rights against business-approved SoD rules on a recurring basis. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SoD is a core access governance control requiring defined approval and review. |
| Recommendation — Centralize access control decisions and enforce business-approved segregation rules. | ||
Practitioner Guidance
Ownership: assign the business process owner as the authority for conflict definitions and exception approvals, and assign IT as the operator of the SoD workflow and evidence trail. That keeps decision rights aligned to process reality while preserving technical consistency.
What good looks like: each SoD rule should have a documented business rationale, a named approver, a clear compensating control if an exception is allowed, and a review date. If any of those four items is missing, the exception should be treated as provisional rather than accepted.
Common mistake: treating SoD as an IAM admin task instead of a governance decision. The control fails when the team that understands the tooling is forced to invent the risk logic, or when the team that understands the process is allowed to bypass the tooling.
Practitioner takeaway: If you want SoD to remain defensible, separate rule ownership from rule operation and make exception approval a business accountability with technical enforcement, not a technical workaround with business branding.