Who should own toxic combination remediation across ERP and cloud systems?

Why This Matters for Security Teams

Toxic combination remediation sits at the intersection of identity governance, segregation of duties, and business process ownership. In ERP and cloud platforms, the risk is rarely a single over-privileged account; it is the combination of otherwise legitimate entitlements that lets one person create, approve, pay, deploy, or conceal a control break. That is why ownership cannot sit only with IAM admins or only with application teams. It needs an accountable identity governance function, plus the finance, operations, and platform leaders who understand which combinations create fraud, operational, or compliance exposure. The control logic should map to enterprise risk, not just technical role structure, and current guidance aligns that thinking with NIST Cybersecurity Framework 2.0 and NHIMG research such as the Guide to the Secret Sprawl Challenge. In practice, many teams discover toxic combinations only after an audit finding, a failed close, or a payment exception exposes the gap.

How It Works in Practice

Effective remediation starts by separating decision ownership from execution ownership. Identity governance should run the program, maintain the control catalog, and enforce review cadence. Process owners should define which combinations are unacceptable, which are conditionally acceptable, and which require compensating controls such as four-eyes approval, workflow split, or time-bound access. Platform teams then implement the technical guardrails in ERP, IAM, PAM, and cloud control planes. That division matters because a toxic combination in SAP, Oracle, or a cloud admin plane often reflects business process design, not just bad access hygiene. A practical operating model usually includes:

• Role mining and entitlement mapping across ERP and cloud systems to expose overlapping privileges.
• Business classification of toxic pairs or triplets, such as create-and-approve, request-and-release, or provision-and-audit.
• Remediation routing that assigns each issue to the owning process team, not just the identity team.
• Compensating control design where separation is not technically feasible or would disrupt operations.
• Exception governance with expiry dates, attestations, and evidence for auditors.

This is especially important in cloud environments where administrative rights, infrastructure-as-code pipelines, and delegated permissions can replicate ERP-style SoD failures at higher speed. NHIMG’s Azure Key Vault privilege escalation exposure and Snowflake breach research show how access design and operational trust can compound quickly when governance is fragmented. These controls tend to break down when ERP ownership, cloud platform ownership, and identity governance sit in different reporting lines and no single risk owner can force remediation through to closure.

Common Variations and Edge Cases

Tighter SoD enforcement often increases remediation effort and can slow finance close, procurement, or release pipelines, so organisations must balance risk reduction against operational continuity. There is no universal standard for how much compensation is acceptable, especially for smaller teams or shared-service environments. Current guidance suggests that high-risk combinations should be remediated by design, while lower-risk overlaps may be mitigated with stronger logging, approvals, and periodic review. Edge cases usually arise in three places. First, cloud platform teams often argue that break-glass or emergency admin access should be exempt, but exemptions should be rare, time-bound, and independently reviewed. Second, ERP customisations can make standard SoD matrices inaccurate, so the control set must be validated against actual transaction flows rather than generic role templates. Third, M&A integration creates temporary access overlaps that are operationally necessary but still require explicit risk acceptance. Where process ownership is unclear, identity governance should still coordinate remediation, but the business owner must sign off on any residual risk. For broader control baselines, the same principle is consistent with the NIST Cybersecurity Framework 2.0 and NHIMG’s 230M AWS environment compromise research, both of which reinforce that access control fails when accountability is diffuse.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Who should own remediation when identity sprawl spans cloud and on-premises systems?
• How should security teams govern multi-cloud access across AWS, Azure, and GCP?
• Who should own identity governance architecture across IAM and compliance teams?