Application access governance needs shared ownership, not IT alone

At a glance

What this is: This is an analysis of who should own application access governance and the finding that shared accountability across finance, audit, application owners, and IT is essential.

Why it matters: It matters because IAM programmes fail when access reviews and SoD controls sit with the wrong team, leaving business applications exposed to fraud, compliance violations, and stale permissions.

By the numbers:

• 5% of annual revenue to fraud, al revenue to fraud, with the average case costing $1.7 million.
• 10 to 15 different business applications to manage, ness applications to manage critical functions.

👉 Read Delinea's guidance on who owns application access governance

Context

Application access governance is the discipline of deciding who gets access to business applications, who certifies that access, and who remediates exceptions when access becomes risky. In ERP, HCM, and CRM environments, that work is not just an IT control problem. It is a governance problem that affects finance, audit, operations, and security at the same time.

The article’s core point is that application access governance breaks when one team assumes it can own the whole process. Application owners know the business role, finance understands segregation of duties, internal audit validates control design, and IT executes the changes. Without that shared model, excessive access can persist until the next fraud case, control failure, or audit exception.

Key questions

Q: How should organisations assign ownership for application access governance?

A: Ownership should be shared across finance, internal audit, application owners, and IT, with each team responsible for the part of the control it understands best. Finance should define segregation of duties, audit should test control effectiveness, application owners should certify business-appropriate access, and IT should execute changes and preserve evidence.

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. When IT owns the whole model, organisations tend to grant excessive or insufficient access, miss toxic permission combinations, and weaken the audit trail. The result is control drift, not better governance.

Q: How do access reviews and segregation of duties work together in business applications?

A: Segregation of duties identifies conflicting permissions, while access reviews confirm whether those permissions are still needed and whether exceptions remain acceptable. Used together, they reduce the chance that stale access, inherited roles, or business changes create fraud or compliance exposure. Used separately, each control leaves a blind spot.

Q: Who is accountable when excessive access causes fraud or audit failure?

A: Accountability should sit with the business owner of the application, the control owner who defines the SoD policy, and the teams that approve and execute remediation. Regulators and auditors expect clear ownership, not a single technical team trying to absorb every decision. That is why shared governance matters.

Technical breakdown

Why application access governance breaks in ERP, HCM, and CRM

Application access governance fails when access decisions are made without business context. ERP, HCM, and CRM platforms contain high-value data and highly specific role structures, so generic provisioning rules cannot reliably tell whether a user needs a permission or merely appears to. That is why user access reviews, role mapping, and segregation of duties analysis must be tied to the actual business process, not just the identity record. In practice, the technical problem is not only visibility. It is reconciling entitlement data, application logic, and control requirements across systems that were never designed to be reviewed manually at scale.

Practical implication: map each critical business application to a named owner who can validate access against real workflows and SoD requirements.

How segregation of duties and access reviews work together

Segregation of duties is the control that prevents one person from holding conflicting permissions that could enable fraud or override oversight. Access reviews are the periodic check that confirms whether those permissions are still appropriate. The two controls are complementary, not interchangeable. SoD rules identify toxic combinations, while reviews catch role drift, inherited access, and exceptions that were approved too long ago. Where the article is strong is in showing that finance and audit cannot outsource this logic to IT alone, because the control objective is business risk reduction, not merely account administration.

Practical implication: separate SoD policy ownership from provisioning execution, and require review evidence for every exception that remains open.

Continuous monitoring for application access risk

Automated access governance changes the operating model from occasional cleanup to continuous control testing. Change tracking records who changed what and when, access review automation reduces manual certification overhead, and provisioning workflows replace email-based approvals that are hard to evidence later. That architecture matters because control failure often shows up as stale access, unapproved changes, or missing review artefacts rather than a single obvious breach event. The article’s broader point is that automation only works when it supports shared governance. A tool can surface the risk, but it cannot decide whether a role is acceptable without business input.

Practical implication: use automation to produce evidence and exception reports, then route decisions to the teams that understand the business risk.

Threat narrative

Attacker objective: The attacker or insider aims to use excessive business application access to move money, alter records, or access sensitive data without timely challenge.

1. Entry occurs when users are granted excessive or inappropriate access into ERP, HCM, or CRM systems through weak ownership of governance responsibilities.
2. Escalation follows when outdated permissions, role changes, or toxic access combinations remain in place because no team is clearly accountable for review and remediation.
3. Impact is fraud, data privacy exposure, failed audits, and control exceptions that persist until the business already has a loss or compliance event.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application access governance fails when ownership is treated as an IT administration problem. The article is right that finance, internal audit, application owners, and IT each hold a different piece of the control objective. Finance understands toxic combinations, audit validates control design, application owners know the real business role, and IT executes provisioning. When one team tries to own the full model, SoD becomes a checkbox exercise instead of a governance control.

Segregation of duties is the control that exposes access risk, but access reviews are the control that prove it has been resolved. Delinea’s framing reflects a broader IAM pattern: entitlement risk rarely disappears on its own, it accumulates through role changes, inherited access, and exceptions that were never closed. The practitioner lesson is that SoD analysis without regular certification leaves stale risk in place, while reviews without SoD logic miss toxic combinations.

Governance blind spot: the assumption that application access can be managed centrally without business ownership breaks in complex ERP and CRM environments. That assumption was designed for environments where access maps cleanly to a technical admin model. It fails when the actual decision depends on business process, role sensitivity, and financial control context. The implication is that access governance must be organized around accountability boundaries, not just directory or ticket ownership.

Automated governance becomes credible only when it produces defensible evidence for audit and finance. Continuous monitoring, access review automation, and change tracking are most valuable when they create a record of who approved what, why it was acceptable, and what changed later. That is the difference between a tool that reduces manual work and a programme that can survive scrutiny. Practitioners should measure whether automation is improving control evidence, not just speeding up requests.

This topic belongs in the wider lifecycle governance conversation, not a standalone access admin workflow. Application access governance touches provisioning, recertification, remediation, and offboarding across business applications. The organisations that manage it best treat it as an ongoing control cycle with business owners attached at every stage. The practitioner takeaway is to align application governance with lifecycle ownership, not just with the help desk.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG research.
• For broader lifecycle and access-control context, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives for the governance lens that closes review and audit gaps.

What this signals

Application access governance is converging with broader identity lifecycle management. As business applications proliferate, the deciding factor is no longer whether access can be provisioned quickly, but whether it can be certified, challenged, and remediated with evidence. Teams that still treat ERP, HCM, and CRM governance as isolated administration will keep rediscovering the same control gaps during audit.

The most durable programmes will tie application ownership to lifecycle events like role changes, exception expiry, and offboarding. That reduces dependence on ad hoc email approvals and makes governance easier to defend when business users, auditors, or regulators ask who approved access and why.

With 1.5 out of 10 organisations highly confident in securing NHIs, the trust gap in identity governance is already visible across machine access, and the same logic applies when business applications are governed only by technical teams. The practical signal is clear: if business ownership is missing, control quality will lag no matter how much automation is added.

For practitioners

• Assign business ownership for each critical application Name the finance, audit, or functional leader who can certify access decisions for each ERP, HCM, or CRM platform and document their authority in the governance model.
• Separate SoD policy from provisioning execution Let finance define toxic combinations and remediation rules, while IT executes approved changes and preserves evidence of who changed access and when.
• Automate user access reviews with exception tracking Use continuous review workflows to surface stale roles, inherited permissions, and unresolved exceptions so that review cycles produce action rather than just attestations.
• Measure access governance by control evidence quality Track whether access decisions can be defended during audit with complete approval trails, review artefacts, and before-and-after change records.

Key takeaways

• Application access governance fails when ownership is reduced to IT administration instead of shared business accountability.
• Excessive access in ERP, HCM, and CRM systems drives fraud, SoD conflicts, and audit failures when reviews are weak or misassigned.
• The control that changes outcomes is not just automation, but clear ownership paired with defensible certification and remediation evidence.

Key terms

• Application Access Governance: Application access governance is the set of policies, reviews, and approvals that decide who can access business applications and whether that access remains appropriate over time. It combines business ownership, control testing, and remediation so access stays aligned to process risk, not just technical permission state.
• Segregation of Duties: Segregation of Duties is a control that prevents one person from holding conflicting permissions that could let them initiate, approve, and conceal the same action. In application environments, it is used to reduce fraud, financial error, and audit exposure by identifying toxic access combinations before they cause harm.
• User Access Review: A User Access Review is a periodic certification process where a business or application owner confirms whether a user’s current permissions are still justified. It is a governance control, not a technical scan. Its value depends on accurate role context, clear accountability, and follow-through on exceptions.
• Control Evidence: Control evidence is the record that proves a governance control was designed, reviewed, and operated as intended. In access governance, that includes approvals, review outcomes, change records, and remediation history. Without evidence, a control may exist in policy but still fail during audit or investigation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Delinea: Who owns Application Access Governance in an organization? Read the original.