Who is accountable when IGA control gaps cause excess access or delayed offboarding?

Accountability usually sits with the business owners who approve access, the identity team that operates the control framework, and governance leaders who define policy and exceptions. In practice, clear ownership matters more than tooling choice. Organisations should assign decision rights for approvals, review outcomes, and offboarding so that control gaps can be traced and corrected.

Why This Matters for Security Teams

IGA control gaps are not just an access review problem. They are a decision ownership problem. When approvals, role design, and deprovisioning are split across business managers, identity operations, and governance teams, excess access can persist long after it should have been removed. That creates audit exposure, insider risk, and avoidable privilege creep, especially where access is granted through exceptions instead of standard entitlements.

Practitioners often underestimate how quickly offboarding breaks down when no one owns the full lifecycle. NHIMG research shows that 91% of former employee tokens remain active after offboarding in the 2025 State of NHIs and Secrets in Cybersecurity, which is a useful indicator of how weak lifecycle discipline can become at scale. The same pattern appears in human identity programmes when reviews are performed, but no one is accountable for follow-through. Current guidance in OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that control ownership, review cadence, and revocation execution must be explicitly assigned.

In practice, many security teams encounter delayed offboarding only after an audit finding, a manager dispute, or an access incident has already exposed the gap.

How It Works in Practice

Accountability should be mapped to the decision, the control, and the remediation step. Business owners are usually accountable for whether access is justified. Identity and IGA operators are accountable for whether the process executes correctly. Governance leaders are accountable for whether policy, exception handling, and escalation paths are defined clearly enough to prevent ambiguity.

A practical model separates responsibility into a few repeatable checkpoints:

• Access approval is owned by the business manager or app owner who can justify the need.

• Role and entitlement design is owned by identity governance teams, who maintain rules and lifecycle workflows.

• Offboarding execution is owned jointly by HR-triggered process owners and the teams that revoke access in target systems.

• Exception approval is owned by a named risk owner, not by the identity team acting alone.

That structure becomes stronger when the organisation uses lifecycle evidence, such as the controls and process patterns described in the NHI Lifecycle Management Guide and the broader Ultimate Guide to NHIs. Even though those resources focus on non-human identities, the operational lesson applies directly: ownership must extend from grant to revoke, not stop at approval.

Teams also need evidence that reviews changed something. A recertification that ends with no revocation is not control closure. Mature programmes record who approved, who executed removal, when it happened, and whether downstream systems actually reflected the change. These controls tend to break down when access is provisioned through scattered SaaS admin consoles and local exceptions because there is no single system of record for revocation completion.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance speed against traceable ownership. That tradeoff becomes visible in shared accounts, emergency access, contractor onboarding, and inherited applications where no clear business owner exists.

Current guidance suggests that no universal standard exists for every exception scenario. For example, if an application has a technical owner but no active business sponsor, governance teams may have to assign temporary decision rights until ownership is remediated. Likewise, when delayed offboarding is caused by upstream HR or ticketing failures, the identity team may operate the revoke workflow but should not be blamed for gaps outside its control unless it also owns the integration.

Edge cases also appear when access is technically removed but not functionally effective. Orphaned group memberships, cached tokens, and local application entitlements can keep access alive after central IGA records show a completed revoke. That is why many programmes pair IGA with periodic system reconciliation and exception review, using the same lifecycle discipline emphasised in Top 10 NHI Issues and the breach patterns highlighted in 52 NHI Breaches Analysis. The practical lesson is simple: if ownership is unclear, gaps will be rationalised instead of fixed, and the same exception will be renewed until it becomes normal.

Related resources from NHI Mgmt Group

• Who is accountable for access governance when multiple partners support IAM and IGA delivery?
• Who should be accountable for proving access control decisions in regulated infrastructure environments?
• Who is accountable for cloud governance gaps when Azure subscriptions are not fully onboarded into a central control model?
• Who is accountable when annual privacy audits find access-control gaps?