Accountability remains with the organisation, not the application boundary. Finance, audit, security, and application owners must agree on which workflows are in scope, how cross system access is reviewed, and who owns remediation when conflicts appear. Governance should follow the business process so no team assumes another layer has covered the gap.
Why This Matters for Security Teams
SoD issues do not disappear because a cloud procurement app sits outside SAP. The risk follows the business process: a requester, approver, buyer, and vendor-master editor may now be spread across systems, but the same person can still create, approve, and execute a transaction path. That is why accountability stays with the organisation, not the platform boundary, and why finance, audit, security, and application owners need a shared control model.
Current guidance suggests treating procurement, vendor onboarding, and payment workflows as one end-to-end risk surface. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support control ownership that maps to business outcomes rather than a single application. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames governance as a lifecycle and audit problem, not just an access-list problem.
In practice, many security teams encounter SoD failures only after a duplicate payment, unauthorized vendor change, or audit exception has already exposed the gap.
How It Works in Practice
The practical answer is to govern the workflow, then prove each step has a distinct control owner. If SAP handles one part of the process and a cloud procurement app handles another, the organisation still needs one SoD matrix that spans both. That matrix should define who can request, who can approve, who can modify master data, and who can release payment. The control does not end at the login screen; it ends when the transaction is irrevocably committed.
Use role design, workflow rules, and cross-system attestations together. A request approved in the procurement app should still be checked against SAP access, vendor-master privileges, and payment authority. The most reliable programs also keep evidence at the process level: approval logs, exception registers, and periodic recertification that tests whether a single person can combine conflicting duties across systems. The OWASP Non-Human Identity Top 10 is relevant because automation and service accounts often move these approvals and integrations, creating hidden paths that look compliant in one app but violate SoD across the chain.
Where non-human identities are involved, treat API keys, service accounts, and workflow bots as part of the same control scope. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that secrets and permissions must be reviewed throughout creation, use, rotation, and retirement. A useful operating pattern is:
- define SoD rules by business process, not by application silo
- map every approval and data-change step to a named control owner
- review cross-system access in one recertification cycle
- flag compensating controls when the app boundary cannot enforce separation
These controls tend to break down when procurement, ERP, and identity governance teams use different access inventories because conflicts become invisible until audit testing.
Common Variations and Edge Cases
Tighter SoD enforcement often increases workflow friction and manual review burden, requiring organisations to balance control strength against procurement speed. That tradeoff becomes sharper when cloud apps expose limited audit logs, when the ERP is on-premises but the procurement layer is SaaS, or when shared service teams manage exceptions for multiple business units.
There is no universal standard for this yet, but current guidance suggests compensating controls are acceptable only when they are explicit, tested, and time-bound. For example, if the cloud app cannot enforce a hard separation between requester and approver, then an independent review in SAP, plus detective monitoring in the procurement platform, may be needed. The important point is that the organisation must document why the exception exists and who signs off on it. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both show a common pattern: gaps emerge when teams assume another system is carrying the control.
For auditors, the key question is not whether SAP alone blocks a conflict. It is whether the enterprise can prove end-to-end separation of duties across the full workflow, including integrations, service identities, and exception handling.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD gaps often hide in non-human identities and shared secrets across apps. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must map to business process separation, not just app roles. |
| NIST SP 800-53 Rev 5 | AC-5 | Separation of duties is the core control when approvals and execution span systems. |
| NIST AI RMF | Governance should assign accountability and traceability across automated workflows. | |
| CSA MAESTRO | Agentic workflows can cross system boundaries and obscure control ownership. |
Inventory service identities and restrict each secret to one workflow step with periodic review.
Related resources from NHI Mgmt Group
- Who is accountable when SAP access risks are not governed consistently across cloud and on premises systems?
- Who is accountable for entitlement governance when compliance requirements such as SOX, HIPAA, GDPR, or PCI-DSS apply to cloud access?
- Who is accountable when access paths outside IAM and SSO create compliance or security gaps?
- Who is accountable when access reviews and lifecycle controls fail to maintain continuous compliance?
