Business process owners should own the risk decision, while IAM and security teams provide the control design and enforcement. If ownership sits only with IT, the rules often miss the operational realities that created the conflict in the first place.
Why This Matters for Security Teams
segregation of duties is not just an access control question. It is a decision about where operational risk is best understood, who can judge acceptable exceptions, and who can enforce the technical guardrails. When business and IT disagree, the dispute usually reflects a gap between process reality and system design, not a simple policy failure. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
The practical issue is ownership. Business process owners understand what a conflict would break, whether a compensating control is acceptable, and which exception is truly temporary. IAM and security teams should define the control pattern, evidence requirements, and enforcement mechanism, but they should not be the final risk owner for a business process they do not run. That distinction matters most where SoD controls affect payment approvals, vendor onboarding, privileged maintenance, or automated workflows with delegated authority. The NIST Cybersecurity Framework 2.0 reinforces that governance and risk decisions must be owned at the business level, with security providing structure and oversight. In practice, many security teams encounter SoD failure only after an exception has already been embedded into production workflow.
How It Works in Practice
Effective SoD ownership starts with a three-part split: business owns the risk decision, security owns the policy model, and IT owns the implementation. The business process owner decides whether the same person, system, or service account can initiate and approve a transaction, and whether a compensating control is acceptable. Security translates that decision into enforceable policy, while IAM engineers configure the roles, approvals, logging, and periodic review.
That division works best when the process is documented at the transaction level, not just the job-title level. For example, a finance workflow may allow one team to create a vendor record and another to approve payment, but the control may be enforced through PAM, workflow approvals, or RBAC plus monitoring. Where NHIs are involved, the same logic applies to service accounts, API keys, and automation pipelines: one identity should not be able to create, approve, and execute the same sensitive action without a compensating control.
- Business process owners define what “conflict” means in operational terms.
- IAM and security teams map that rule to roles, entitlements, and approval gates.
- Exception handling should include expiry dates, compensating controls, and audit evidence.
- Reviews should test whether the control still matches the live workflow, not the original design.
For NHI-heavy environments, the broader identity lifecycle matters too. The Ultimate Guide to NHIs highlights how widespread secret sprawl and excessive privilege make enforcement brittle when ownership is unclear. That aligns with current guidance in NIST Cybersecurity Framework 2.0: governance must tie risk acceptance to accountable business ownership, while technical teams implement the control. These controls tend to break down when exceptions are managed informally in tickets or chat, because the approval trail no longer reflects the actual risk owner.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational friction, requiring organisations to balance fraud prevention and auditability against delivery speed and automation overhead. In low-risk processes, a compensating control may be sufficient; in high-risk workflows, the same exception should trigger stronger review or outright denial.
There is no universal standard for every SoD dispute, but current guidance suggests a practical pattern. If the issue concerns business impact, the business owner decides. If the issue concerns technical feasibility, security and IAM decide how to enforce the outcome. If the issue concerns residual risk after a compensating control, joint sign-off is appropriate, but the business process owner remains accountable for accepting that risk. This becomes especially important when human approvals intersect with NHIs, because service accounts can execute faster and at greater scale than people, making weak exceptions difficult to contain.
Edge cases arise in matrixed organisations, shared services, and outsourced operations. In those environments, the formal owner may be several steps removed from the team that feels the control pain. The best practice is evolving toward explicit decision records that name the risk owner, the control owner, and the review date. That keeps the exception from becoming a permanent workaround and gives auditors a clean line from policy to enforcement to accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD disputes often expose overprivileged NHIs and weak exception handling. |
| NIST CSF 2.0 | GV.RM-06 | Risk acceptance must sit with accountable business ownership, not IT alone. |
| NIST AI RMF | Governance requires clear ownership, accountability, and oversight for risk decisions. |
Use AI RMF governance practices to define decision rights, escalation paths, and accountability for exceptions.
