TL;DR: Manual access tracking across ERP, HCM, and CRM systems creates fraud, privacy, and audit exposure because most organisations now rely on 10 to 15 business applications for critical functions, according to Delinea and ACFE. Application access governance only works when finance, audit, application owners, and IT share responsibility for policy, review, and enforcement.
Editorial analysis by NHI Mgmt Group, based on content published by Delinea: “Who owns Application Access Governance in an organization?”.
Key questions
Q: What breaks when IT is treated as the sole owner of application access governance?
A: IT can provision access, but it cannot reliably judge whether a role is appropriate for the business process.
Q: Why do excessive permissions increase fraud and lateral movement risk in enterprise systems?
A: Excess permissions widen what a compromised or careless identity can touch.
Q: How do organisations know if access certification is actually working?
A: Look for shrinking numbers of standing privileges, faster revocation after review decisions, and fewer orphaned or overprivileged accounts over time.
Practitioner guidance
- Define business-owned access decisions Assign finance, audit and application owners explicit responsibility for defining which access is appropriate for each critical business process, while IT executes the technical changes.
- Map SoD conflicts to actual workflows Build segregation of duties rules from the transaction steps inside ERP, HCM and CRM systems, then review exceptions with the business owner of each process.
- Separate certification from provisioning Use application owners to certify access appropriateness and use IT or security teams to implement approved changes and evidence the outcome.
Bottom line: Application access governance breaks down when one team is expected to own business decisions, control design and technical execution at the same time.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Application access governance fails when ownership is treated as an IT deployment question. The article shows that business applications sit at the point where finance, HR, sales and security controls intersect, so no single technical team has enough context to govern access well. That is a governance design problem, not a tooling problem. The implication is that access governance must be structured around business accountability, not delegated into the infrastructure team by default.
A question worth separating out:
Q: What should organisations do when employees move roles inside critical business apps?
A: They should trigger a new access review whenever responsibilities change, because stale permissions often persist after internal moves. The review should compare current access to the new job function, identify SoD conflicts, and remove rights that no longer match the role.
👉 Read our full editorial: Application access governance needs shared ownership, not just IT