Who is accountable when ERP user provisioning and access certification fail audit or privacy requirements?

Why This Matters for Security Teams

When ERP provisioning or access certification fails, the issue is rarely just an operations defect. It becomes an accountability problem because ERP access often drives payroll, financial posting, procurement, customer records, and privacy-sensitive data. That means weak approvals, stale entitlements, or poor segregation of duties can trigger audit findings, privacy exposure, and control exceptions at the same time. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG’s Ultimate Guide to NHIs - Regulatory and Audit Perspectives both point to the same practical reality: control ownership must be explicit, not implied.

Security teams often assume the ticket-processing team is accountable because it executes the workflow. In practice, auditors look for the business owner who approves access, the system owner who defines roles, and the security or IAM function that enforces the control. If those responsibilities are blurred, remediation becomes inconsistent and exceptions accumulate. The strongest programmes treat provisioning as a governed business process, not a back-office task. In practice, many security teams encounter accountability gaps only after an audit sample exposes them, rather than through intentional control design.

How It Works in Practice

Accountability for ERP access usually sits across three layers. First, the business owner is accountable for defining who should have access and for approving role design and certification outcomes. Second, the system or application owner is accountable for maintaining the ERP role model, ensuring segregation of duty rules are workable, and resolving technical exceptions. Third, security, IAM, or GRC leaders are accountable for operating the control framework, collecting evidence, and escalating failed reviews. The process is only defensible when each layer has a named owner and a documented escalation path.

For audit and privacy requirements, the control question is not just whether access was granted, but whether it was granted to the right person, for the right purpose, for the right duration. That is why current guidance suggests pairing access certification with periodic role recertification, violation remediation, and exception tracking. NHIMG’s NHI Lifecycle Management Guide is useful here because the same lifecycle logic applies: access should be approved, provisioned, reviewed, and revoked with clear ownership at each stage. The OWASP Non-Human Identity Top 10 also reinforces the operational risk of unmanaged credentials and uncontrolled privilege.

• Assign business ownership for role definitions and certification decisions.
• Assign system ownership for role mapping, SoD rules, and remediation paths.
• Assign security ownership for control operation, evidence, and escalation.
• Track access exceptions separately from standard approvals so audit trails remain defensible.

For privacy requirements, the accountable owner must also justify why access exists and whether the data scope matches the job need. These controls tend to break down when ERP roles are inherited from legacy templates because inherited access often masks both overprovisioning and approval drift.

Common Variations and Edge Cases

Tighter access certification often increases operational overhead, requiring organisations to balance audit defensibility against business speed. That tradeoff becomes sharper in global ERP environments, where local managers approve access but regional privacy rules and SoD policies differ. Best practice is evolving, but there is no universal standard for how much approval granularity is enough; organisations usually adopt a risk-based model that increases scrutiny for privileged, financial, or regulated data access.

One common edge case is delegated administration. If a help desk or provisioning team can grant access, that team is not usually the final authority unless policy explicitly assigns that role. Another edge case is emergency access, where temporary elevation may be allowed but must still be time-bound and reviewed after the fact. NHIMG’s 52 NHI Breaches Analysis shows how quickly weak identity controls become incident material when oversight is fragmented. For privacy-heavy ERP modules, the EU General Data Protection Regulation (GDPR) raises the stakes further because access decisions can become part of a lawful-processing and data-minimisation review.

In practice, the cleanest accountability model is simple: the business owns the decision, security owns the control, and operations owns the execution.

Related resources from NHI Mgmt Group

• Why does manual user access provisioning create control risk in cloud and mobile ERP environments?
• Who is accountable when access request approvals and audit evidence are spread across multiple teams?
• Who is accountable when SaaS access controls fail during a customer-critical workflow?
• Who is accountable for entitlement governance when compliance requirements such as SOX, HIPAA, GDPR, or PCI-DSS apply to cloud access?