Accountability stays with the organisation, but ownership should sit across GRC, IAM, application owners, and process owners. Security and compliance teams need a shared control model, clear policy exceptions, and evidence that access is reviewed across the full business process. If responsibilities are fragmented, no single team can prove the control is working end to end.
Why This Matters for Security Teams
segregation of duties is easy to state and hard to prove once a business process crosses ERP, cloud platforms, and adjacent SaaS workflows. The accountability question is not just about who approves access, but who can demonstrate that incompatible privileges were prevented, detected, and reviewed across the full process chain. That is where control ownership often breaks down.
Current guidance suggests tying SoD to business processes rather than to a single system, because a user can satisfy separation rules in one application and still combine conflicting actions in another. NIST’s NIST Cybersecurity Framework 2.0 reinforces that governance and access control must be managed as an enterprise capability, not a siloed checkbox. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives also stresses that auditability depends on end-to-end identity visibility, not isolated system logs.
In practice, many security teams discover SoD violations only after an audit finding, a failed ERP reconciliation, or a cloud privilege review exposes a gap that nobody owned end to end.
How It Works in Practice
Accountability stays with the organisation, but operational ownership should be split across the teams that control policy, identity, application design, and process execution. GRC defines the SoD policy and incompatible duty matrix. IAM enforces access request, approval, and role design. Application owners map the actions that matter inside ERP and cloud apps. Process owners validate that the full workflow still preserves separation across systems.
The practical control model usually works best when it combines four elements:
- A process-level SoD matrix that names conflicting duties across ERP and cloud applications.
- Role and entitlement mapping that traces each business action to the accounts and permissions that can perform it.
- Exception handling with time limits, compensating controls, and explicit business approval.
- Continuous evidence collection from IAM, ERP audit logs, and cloud activity logs to show that the control operated as designed.
This aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access enforcement, separation of duties, and audit logging expectations. It also reflects NHIMG’s The 2026 Infrastructure Identity Survey, which found that 67% of organisations still rely heavily on static credentials and 70% grant AI systems more access than a human would receive for the same job, a reminder that access scope often expands faster than governance.
For ERP-to-cloud flows, the control should be tested at the business transaction level, not just at login or provisioning. A user who cannot approve a vendor invoice in ERP may still trigger payment-related actions through a cloud automation account or API token, so the SoD test must follow the process through every identity and interface. These controls tend to break down when workflow ownership is split across multiple platforms because no single system has the full view of conflicting actions.
Common Variations and Edge Cases
Tighter SoD controls often increase operational friction, requiring organisations to balance fraud prevention against business speed and exception handling. That tradeoff is especially visible in shared-services models, emergency access scenarios, and integrations where an ERP event triggers cloud automation.
Best practice is evolving for hybrid processes, and there is no universal standard for how granular the SoD matrix must be. Some organisations define conflicts at the role level, while others define them at the transaction level for higher-risk processes such as procurement, payments, journal entries, and privileged cloud administration. The second approach usually gives better assurance, but it is more expensive to maintain.
Edge cases appear when one person owns part of the process in ERP and a service account or agent completes the rest in cloud tools. In those cases, the real control question is not only human-to-human separation but whether the combined human, service account, and automation path creates a conflict. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant here because lifecycle controls on non-human access determine whether automation can be constrained to its intended duty.
For high-risk environments, organisations should treat policy exceptions as temporary compensating controls, not as proof that SoD has been achieved. Where cloud entitlements, ERP roles, and API keys are reviewed by different teams on different cadences, the control often weakens because no one is reconciling the full chain of privilege. The best evidence is a joined-up review that proves incompatible duties never coexist in the same business outcome.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD depends on managing access permissions across business workflows and systems. |
| NIST SP 800-53 Rev 5 | AC-5 | AC-5 directly addresses separation of duties and role conflict prevention. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Non-human identities can bypass SoD if service accounts and tokens are unmanaged. |
| CSA MAESTRO | GOV-2 | Agentic and cloud workflows need clear governance, ownership, and accountability. |
| NIST AI RMF | GOVERN | AI-enabled process steps can alter control boundaries and accountability. |
Map incompatible duties to access rules and verify separation across ERP and cloud entitlements.
Related resources from NHI Mgmt Group
- How should enterprises automate segregation of duties reviews across SAP and connected business applications?
- Who is accountable for segregation of duties governance when access controls span SAP and non-SAP systems?
- How should security teams extend segregation of duties controls across cloud procurement apps and ERP environments?
- Who is accountable for maintaining continuous compliance in Oracle ERP Cloud access governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
