Who should own access decisions in a business-driven IGA model?

Ownership should be shared, but business approvers must be accountable for need-to-have access while IAM and security teams enforce policy and automate the lifecycle. That division keeps the decision grounded in business reality without turning governance into a manual bottleneck.

Why This Matters for Security Teams

Business-driven IGA works only when access decisions reflect operational need, but the ownership question is where many programmes stall. If business managers own the approval, they understand whether access is justified; if IAM or security own the decision, they can enforce policy, segregation of duties, and auditability. The risk is not choosing one side exclusively, but collapsing approval, enforcement, and lifecycle control into a single manual gate. That usually slows delivery and creates shadow access paths. Current guidance from the OWASP Non-Human Identity Top 10 aligns with the broader NHI principle: decision authority should sit with the process owner, while technical control remains with identity and security teams. In NHI governance, the same split is critical because secrets, service accounts, and API keys outlive individual approvals and are frequently reused across systems. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which is exactly what happens when approvals are treated as a formality instead of a control point. In practice, many security teams encounter overprovisioning only after a review cycle or incident has already exposed the gap, rather than through intentional governance design.

How It Works in Practice

A workable model separates decision ownership from control enforcement. The business approver owns the question “does this role, service, or workflow need access at all?” IAM and security own “is this access policy-compliant, time-bound, and revocable?” That distinction matters for both humans and NHIs, especially when access is granted to autonomous workloads that cannot be managed like static user accounts. For agentic systems, a business owner may approve the workload’s purpose, while policy engines decide whether the agent can call a tool, reach a dataset, or exchange a token at runtime.

Operationally, this usually means:

• Approvals are mapped to a business process, application owner, or data owner.
• IAM enforces role design, segregation of duties, and policy-as-code checks.
• Security defines the rules for JIT access, short TTLs, and revocation triggers.
• Audit trails show who requested, who approved, what policy allowed it, and when it expires.

For NHI and agentic workloads, this is even more important because static role assignments do not reflect real behaviour. A service account may need one credential to complete a single task, not a standing entitlement. NHI Mgmt Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x, which makes manual approval a poor substitute for lifecycle automation. Best practice is evolving toward runtime policy evaluation, where access is rechecked at the moment of use rather than assumed from a pre-approved role. These controls tend to break down when approvals remain ticket-based in high-change environments, because access changes faster than the review cadence.

Common Variations and Edge Cases

Tighter approval control often increases cycle time, requiring organisations to balance governance quality against operational speed. That tradeoff becomes more visible in cloud-first teams, shared services, and machine-to-machine integrations, where the volume of access requests makes “human-only approval” unrealistic. In those environments, current guidance suggests using delegated approvers for business need, with IAM applying policy guardrails automatically.

There is no universal standard for this yet, but several patterns are emerging. For privileged NHI access, some organisations require dual approval: one from the business owner and one from the control owner. For low-risk, repeatable access, approvals may be pre-authorised through policy templates, with periodic review instead of per-request sign-off. For agentic AI, the approval should cover the agent’s intended function, while the runtime system decides whether each tool invocation is allowed. This avoids turning a business approver into a security proxy for actions they cannot reasonably predict. The practical benchmark is simple: if the approver cannot explain the business need, the request should stop; if IAM cannot automate the enforcement, the model is not scalable. The 52 NHI Breaches Analysis shows how often weak governance becomes an incident pattern, not an exception.

Related resources from NHI Mgmt Group

• Who should own emergency access decisions in a policy-driven model?
• Who should own recertification and access review decisions in an IGA programme?
• Who should own access decisions when service management and IAM are connected?
• Who should own access decisions when ITSM and IAM responsibilities overlap?