Organisations should evaluate segregation of duties across the full business process, not inside each application in isolation. The practical starting point is to map critical workflows, such as procure to pay, hire to retire, and order to cash, across all connected systems. That gives security, compliance, and audit teams a realistic view of where conflicting access can exist and where compensating controls are needed.
Assessing segregation of duties across systems, not inside one tool
segregation of duties risk is easy to underestimate when each ERP or cloud application looks compliant on its own. The real control question is whether one person, role, bot, or integration can complete a sensitive business process end to end by combining access across platforms. That is why cross-system process mapping matters more than app-by-app review.
For a practical assessment, start with the business process and then trace every step, approval, exception, and posting across the systems that support it. In procure to pay, for example, a conflict may not be visible in the ERP alone if purchasing, invoice approval, vendor master maintenance, and payment release are split across different cloud services and workflow tools. A process view exposes those composite paths.
Cloud assessments often need a second lens because identity and authorization boundaries differ between environments. The same user may have harmless-looking permissions in one application but combine them with privileges elsewhere to create a SoD conflict. That is why CSA Cloud Controls Matrix is useful as a control reference for cross-domain governance, and why ISO/IEC 27001:2022 Information Security Management remains relevant where access control, privileged access, and cloud security need to be governed together.
Where the process crosses SaaS or cloud services, treat third-party integrations, delegated admin roles, and service credentials as part of the same control story. A workflow can appear separated in the application UI while still allowing one actor to initiate, approve, and execute the same transaction through different channels. That is the practical gap your assessment should uncover.
Using a defined control baseline also helps teams compare systems consistently. SOC 2 Trust Services Criteria (AICPA) is often helpful for vendor and shared-service reviews, while NIST Cybersecurity Framework 2.0 gives a broader governance lens for ownership, control coverage, and control monitoring across the full application estate.
Risk and Threat Considerations
The main risk is not a single toxic role in one application, but a chain of individually acceptable permissions that becomes a SoD violation when combined. That creates financial reporting risk, fraud exposure, and weak detective control coverage, especially when access is distributed across ERP, cloud, and workflow platforms.
Failure mechanism: conflicting access is hidden because approvals, master data changes, and payment or posting actions live in different systems, so no single application flags the end-to-end conflict. Teams then miss composite privilege paths, dormant cross-system access, and exceptions that bypass the intended control design.
Impact: one actor may be able to create, approve, and release transactions, change supporting master data, or conceal evidence of an improper action. The business consequence is higher fraud risk, weaker audit assurance, and compensating controls that only appear effective because they are evaluated in isolation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack surface, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | SoD assessment depends on governing who can access and combine privileges across systems. |
| Recommendation — Review and remove conflicting access paths that let one actor complete incompatible duties. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Cross-system SoD risk is driven by how access is granted, combined, and monitored. |
| GV.RM — Risk Management Strategy | SoD must be assessed as an enterprise workflow risk spanning multiple applications and owners. | |
| Recommendation — Map and enforce access restrictions that prevent one identity from completing conflicting duties. Define cross-application SoD risk ownership and review it as part of enterprise risk management. | ||
| ISO/IEC 42001:2023 | A.7 — Data and Information Lifecycle | When automated workflows or AI-supported processes touch sensitive transactions, lifecycle governance shapes SoD exposure. |
| Recommendation — Govern automated decision paths so transactional authority stays separable and reviewable. | ||
| NIST Zero Trust (SP 800-207) | 1 — Verify Explicitly | Cross-system SoD depends on verifying each action and access path rather than trusting location or app boundary. |
| Recommendation — Verify every sensitive transaction step explicitly across systems before allowing completion. | ||
| OWASP Agentic AI Top 10 | A3 — Agentic Tool Misuse | If workflow automation or agents can invoke business actions, their tool access can create composite SoD conflicts. |
| Recommendation — Constrain tool permissions so automation cannot both initiate and approve sensitive business actions. | ||
Practitioner Guidance
What to prioritise: build the SoD model from business workflows first, then map the specific entitlements, approvals, and exception paths that support each step. The highest-value review is usually where two or three low-risk permissions in separate systems combine into one high-risk process outcome.
What to verify: confirm that the assessment covers role assignments, delegated administration, service accounts used for workflow automation, and emergency access. If the control only reviews named ERP roles but ignores cloud admin paths or integration credentials, it will miss the most important conflict patterns.
Practitioner takeaway: SoD risk is a process problem, not an application problem, so the right unit of review is the end-to-end transaction path and the combined access that makes it possible.
Related resources from NHI Mgmt Group
- How should security teams reduce segregation of duties risk when access reviews span multiple SaaS and ERP applications?
- How should security teams implement segregation of duties across multiple business applications?
- How should organisations govern access consistently across ERP, cloud, and legacy applications as their environments become more heterogeneous?
- How should security teams extend segregation of duties controls across cloud procurement apps and ERP environments?
