Accountability usually sits with the business approver for the access decision, IT operations for execution, and security or compliance for oversight. If ownership is unclear, access reviews and deprovisioning become slow and inconsistent. A good IGA workflow records who approved, who acted, and whether removal or exception approval was completed.
Why This Matters for Security Teams
In IGA, incorrect access grants and removals are not just workflow defects, they are accountability defects. When approver, executor, and reviewer roles blur, the organisation cannot prove whether a decision was authorised, carried out, and verified. That gap creates audit friction, slows remediation, and leaves standing access in place longer than intended. Current guidance from the OWASP Non-Human Identity Top 10 and NIST control families both point to the same operational issue: identity governance fails when responsibility is not explicit.
This matters even more for non-human identities because access changes often involve service accounts, API keys, and automation paths that move faster than human review cycles. NHIMG research shows that only 20% of organisations have formal offboarding and revocation processes for API keys, and 91.6% of secrets remain valid five days after notification, which means incorrect removal is not a theoretical edge case but a common exposure window. The broader Ultimate Guide to NHIs frames this as a lifecycle and ownership problem, not just an access control problem. In practice, many security teams encounter missing accountability only after stale access has already been exploited or an audit has already failed.
How It Works in Practice
Accountability in a mature IGA process is usually split across three functions, but each function must be traceable. The business approver owns the decision to grant, extend, or remove access. IT or operations owns execution, meaning the technical act of provisioning or deprovisioning. Security, compliance, or IAM governance owns oversight, ensuring the request was legitimate, the control operated correctly, and the evidence is retained. That model aligns with the control logic in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where access approval, auditability, and revocation evidence are required.
In practice, the workflow should record at least four items: who requested, who approved, who executed, and who verified closure. For non-human identities, the same pattern applies to vault changes, token revocation, certificate replacement, and service account disablement. NHIMG’s Lifecycle Processes for Managing NHIs emphasises that lifecycle control is only effective when each step has a named owner and a measurable completion state. A good IGA design also distinguishes between access removal and exception approval, because a denied removal without a documented business exception is a control failure, not a compromise.
- Use named approvers, not generic shared mailboxes or team aliases.
- Require technical closure evidence for deprovisioning, not just a ticket status change.
- Separate approval authority from execution authority where possible.
- Track exceptions with expiry dates so temporary access does not become permanent.
These controls tend to break down in large hybrid environments where HR, IAM, application owners, and platform teams each believe another group owns revocation, because no single system can confirm end-to-end completion.
Common Variations and Edge Cases
Tighter accountability often increases process overhead, requiring organisations to balance speed against evidence quality. That tradeoff becomes visible in high-change environments, but there is no universal standard for this yet. Some teams use dual approval for privileged access, while others reserve that for sensitive systems only. For low-risk requests, current guidance suggests lighter workflows may be acceptable if logging, review, and revocation evidence remain intact.
Edge cases create the most confusion. A request may be approved correctly but executed against the wrong account. A removal may be technically completed while cached tokens, API keys, or downstream group membership still preserve access. In those cases, accountability should not be reassigned away from the original owner, but the incident should also record where the workflow failed. NHIMG’s 52 NHI Breaches Analysis shows why this distinction matters: many incidents are not caused by one broken step, but by weak ownership across the lifecycle. The practical answer is to define ownership by stage, require evidence of completion, and review exceptions as first-class records rather than informal notes. That discipline is especially important where automated deprovisioning spans multiple systems and removal depends on external sync jobs finishing on time.
