Who is accountable for access governance when ERP cloud controls fail an audit?

Why This Matters for Security Teams

When ERP cloud access controls fail an audit, the issue is rarely just a technical misconfiguration. It usually means the organisation cannot prove who owns approvals, who reviews access, and who is accountable for exceptions. That matters because ERP systems sit on the boundary between finance, operations, and identity governance. NHI Management Group’s Ultimate Guide to NHIs -- Regulatory and Audit Perspectives shows that audit evidence depends on lifecycle discipline, not ad hoc controls.

This is also where static role assignments often fail. ERP entitlements change with business structure, project work, and automated service accounts, so a simple “IT owns access” answer leaves gaps that auditors notice quickly. Current guidance from NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both point toward explicit governance, traceable accountability, and least privilege for every identity type. In practice, many security teams encounter accountability failures only after auditors have already flagged missing evidence, not through intentional ownership design.

How It Works in Practice

Accountability for ERP cloud access governance is best handled as a shared operating model, not a single-team problem. Business ownership sets the policy intent: who needs access, what level is appropriate, and which approvals are required. IT or IAM teams implement the control mechanics, but they should not be the final owner of business risk. Security teams typically define standards, monitor exceptions, and verify that review cycles happen on time.

Practically, that means separating four responsibilities:

• Process owner: defines access need, control objectives, and exception tolerance.
• Application owner: validates ERP roles, SoD constraints, and privileged paths.
• IAM or platform team: provisions, recertifies, and removes access.
• Control owner or risk owner: signs off on audit evidence and unresolved exceptions.

For cloud ERP specifically, this model should cover human users, privileged admins, and NHIs such as integration accounts and API tokens. The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of NHIs, which is a reminder that audit failure often reflects wider identity sprawl, not just user access review defects. The control pattern should align with NIST SP 800-53 Rev 5 Security and Privacy Controls and the CSA Cloud Controls Matrix so that evidence includes approvals, recertifications, and revocation records.

Where organisations get into trouble is when ownership is implied rather than documented. If access is approved by managers, granted by IT, and reviewed by no one with business authority, then the audit finding is not really about tooling. These controls tend to break down when ERP roles are customised heavily across multiple subsidiaries because no single owner can reliably validate entitlements end to end.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance auditability against speed in finance and operations. That tradeoff becomes especially visible during mergers, shared-service rollouts, and ERP customisation, where ownership may be distributed across regions or legal entities. The right answer is still explicit accountability, but the execution model may differ by environment.

There is no universal standard for this yet, but current guidance suggests the following: if a control failure concerns approval design, the business process owner is accountable; if it concerns provisioning or technical enforcement, IT or IAM is accountable; if it concerns audit evidence or governance design, security and risk leadership are accountable. For NHIs and service accounts, the application owner often becomes the decisive owner because those identities are tied to system-to-system workflows rather than named employees. The Top 10 NHI Issues is useful here because it frames hidden identity risk as a governance problem, not just a tooling problem.

One practical edge case is outsourced administration. Even when a managed service provider executes access changes, accountability still remains with the enterprise that owns the ERP control environment. Another is emergency access: JIT approvals can reduce standing privilege, but someone must still own the policy, the exception review, and the post-event attestation. In short, outsourcing the work does not outsource the control obligation.

Related resources from NHI Mgmt Group

• How should organisations detect excessive access risk in Oracle ERP Cloud before it turns into an audit or fraud issue?
• What do security teams get wrong about role design and access governance in ERP cloud projects?
• Who is accountable when ERP controls are missing or poorly aligned across finance, IT, and audit teams?
• Who is accountable when SOX access controls fail an audit?