Who is accountable for access governance when enterprises run mixed ERP, cloud, and legacy environments?

Why This Matters for Security Teams

access governance becomes difficult fast when ERP, cloud, and legacy platforms each implement their own approval paths, entitlement models, and audit evidence. The real issue is not just who can log in, but who can approve access, review exceptions, and prove the controls are working across systems. NIST Cybersecurity Framework 2.0 makes clear that governance is a cross-functional responsibility, not a pure IAM task, and that accountability must be assigned to business and security owners together.

In mixed estates, the business process owner is usually the only party that can define what access is actually required, while identity and security teams provide the policy mechanics and control evidence. Without that split, access reviews become platform-specific exercises that miss inherited permissions, service accounts, and stale roles. The same problem appears when teams assume the ERP admin or cloud platform owner can decide business entitlement questions on their own. In practice, many security teams encounter inconsistent approvals and weak evidence only after an audit finding or segregation-of-duties failure has already occurred, rather than through intentional governance design.

How It Works in Practice

Accountability should be structured around the business process, with named control owners for approval, enforcement, monitoring, and assurance. That means one accountable owner for the access policy, one or more operational owners for how access is provisioned in each platform, and independent reviewers for testing and evidence collection. The operating model should make clear where the decision is made, where it is executed, and who signs off on the control outcome.

In mixed environments, practitioners usually need a shared governance model that spans ERP role design, cloud entitlement management, and legacy access administration. A practical approach is to map each system to a common control objective and then assign responsibility as follows:

• Business owner: defines access need, approves exceptions, and owns segregation-of-duties decisions.
• Identity team: maintains role models, joiner-mover-leaver processes, and centralized recertification rules.
• Application owner: translates business policy into application roles and local permissions.
• GRC or audit team: validates evidence, tests control design, and tracks remediation.

This is especially important for non-human access. Service accounts, API keys, and automation identities often bypass human approval paths, which is why the OWASP Non-Human Identity Top 10 is increasingly relevant to access governance design. NIST SP 800-53 Rev 5 Security and Privacy Controls is also useful here because it ties access enforcement, least privilege, account management, and auditability into a control set that can be mapped across platforms.

Where possible, enterprises should unify reporting even if they cannot fully unify enforcement. Central logging, periodic entitlement certification, and role mining can expose drift between ERP roles, cloud permissions, and legacy access lists. The key is to prevent local system owners from becoming the de facto final authority on business access decisions. These controls tend to break down when each platform has its own approval workflow and no shared entitlement inventory exists because control evidence cannot be reconciled end to end.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance control depth against business speed and administrative complexity. That tradeoff is most visible in mergers, outsourcing, and heavily customized ERP estates, where local exceptions are common and standard role models are incomplete.

There is no universal standard for this yet, but current guidance suggests that accountability should follow the business process even when the technical administration is fragmented. In practice, that means a legacy application run by IT operations does not become a governance exception just because the system is old. It also means cloud platform teams should not approve sensitive access purely on technical feasibility if the business owner has not accepted the risk.

The hardest edge case is shared accountability across outsourced or federated environments. If a managed service provider administers provisioning, the enterprise still retains governance accountability unless responsibility is explicitly transferred in policy and contract. That distinction matters for audit, incident response, and control testing. The safest pattern is to document one accountable owner per control outcome, even if several teams contribute to execution. For organisations with significant automation, the same logic should extend to NHI and agentic workflows, because automated access paths can create governance gaps unless they are included in the review scope.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access to Elastic Cloud or Elasticsearch is granted too broadly?
• How should organisations govern access consistently across ERP, cloud, and legacy applications as their environments become more heterogeneous?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?