Security teams should treat cloud procurement tools and ERP as one business process, not separate control islands. Map procure to pay workflows end to end, identify where approvals, vendor setup, payments, and master data changes cross system boundaries, and apply consistent SoD rules across both environments. Continuous monitoring is essential when transactions move outside the ERP control plane.
Why This Matters for Security Teams
segregation of duties only works when it covers the full business process, not just the system of record. Cloud procurement apps often create a second control plane where request, approval, vendor onboarding, and payment initiation can happen outside the ERP’s native checks. That gap is where fraud, duplicate vendors, overpayment, and unauthorized master data changes tend to surface.
Current guidance suggests treating procurement SaaS and ERP as one shared workflow and applying SoD rules across both, with policy mapped to each handoff and exception path. This aligns with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where separation, approval, and accountability are distributed across multiple systems. NHIMG research on the Ultimate Guide to NHIs also reinforces that identity and access controls fail when governance is fragmented between platforms.
In practice, many security teams discover SoD failures only after a payment exception, vendor dispute, or audit finding has already exposed the cross-system gap.
How It Works in Practice
The practical starting point is process mapping. Security, finance, and ERP owners should chart procure-to-pay end to end, then mark every point where authority changes hands: requisition approval, vendor setup, bank detail updates, purchase order release, invoice approval, payment run, and journal posting. The goal is to identify combinations that should never coexist in the same human or machine identity.
Once those conflicts are known, controls need to be enforced across both environments. In ERP, that usually means role design, approval workflows, and transaction restrictions. In cloud procurement, it means matching those same business restrictions in the SaaS app, not relying on whatever defaults the platform provides. For many teams, the strongest pattern is to treat ERP and procurement as a single entitlement graph and to monitor for conflicting access across both sides of the workflow.
Where the process is automated, security teams should also watch for non-human identities that can bypass manual review. If an integration account can create vendors in the procurement app and post invoices in the ERP, SoD has failed even if no human user is over-entitled. That is why audit evidence should include system-to-system activity, not only user access reviews. The 2024 Non-Human Identity Security Report shows how often organisations lag in managing non-human access, which is relevant when workflow automation begins to substitute for human control points.
- Map SoD conflicts at the process level, not just by application role.
- Continuously reconcile vendor, approval, and payment entitlements across SaaS and ERP.
- Log and review non-human changes to master data, approvals, and payment instructions.
- Escalate exceptions where one identity can both create and approve the same transaction chain.
These controls tend to break down when procurement is run by business users in SaaS while finance assumes the ERP will catch every conflict, because the two systems often evaluate access independently.
Common Variations and Edge Cases
Tighter SoD enforcement often increases workflow friction, requiring organisations to balance fraud prevention against operational speed. That tradeoff is especially visible in fast-moving procurement teams that need temporary role elevation, emergency purchasing, or delegated approvals.
Best practice is evolving around compensating controls for those cases. Some organisations use time-bound approvals, step-up verification, or post-transaction review for high-risk exceptions. Others rely on continuous control monitoring and alerting when a user or service account crosses a conflict threshold. There is no universal standard for this yet, but the principle is consistent: exception handling should be explicit, reviewed, and reversible.
Another edge case is shared service centres and third-party administrators. A single team may legitimately manage vendor onboarding in one system while handling payment support in another, so static role names alone can be misleading. Security teams should focus on actual authority combinations, not job titles. This is also where Snowflake breach lessons matter: when access sprawl is broader than intended, controls can appear intact while the real process remains exposed.
For large environments, a useful benchmark is whether a user or service account can complete the entire procure-to-pay chain without independent review. If yes, SoD is not truly separated, even if the ERP and procurement app each look compliant in isolation.
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 so one identity cannot complete conflicting actions. |
| NIST SP 800-53 Rev 5 | AC-5 | Separation of duties is a direct access control requirement for conflicting business actions. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Non-human accounts can bypass SoD if integration identities span creation and approval paths. |
| CSA MAESTRO | GOV-03 | Agentic and automated workflows need governance over cross-system authority boundaries. |
| NIST AI RMF | AI-assisted procurement and automated approvals require ongoing risk management and accountability. |
Map business authority to automation paths and continuously validate that each control point remains independent.
Related resources from NHI Mgmt Group
- How should security teams unify identity controls across human and non-human access in complex enterprise environments?
- How should security teams extend credential security across SaaS and AI environments at enterprise scale?
- How should security teams streamline Separation of Duties reporting in complex ERP environments?
- How should security teams approach compliance-centric identity governance across ERP and business application environments?
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
