Who is accountable when IAM permissions are approved without a pre-deployment review?

Why This Matters for Security Teams

When IAM permissions are approved without a pre-deployment review, accountability becomes fragmented across identity governance, application owners, and change management. That gap matters because access mistakes are not just administrative errors. They can expose production systems, create privilege creep, and make later incident review harder. NIST SP 800-53 Rev. 5 treats access approval and review as control activities, not optional hygiene, because they are part of demonstrating who is allowed to do what and under which conditions.

For non-human identities, the risk is amplified. NHIs often outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations report full visibility into their service accounts, according to Ultimate Guide to NHIs — Key Challenges and Risks. In that environment, an approval made after deployment is often too late to prevent exposure or to prove why a permission existed at all. In practice, many security teams discover the accountability failure only after the access has already been used, rather than through intentional change review.

How It Works in Practice

Accountability starts with assigning named owners to both the identity and the change process. The team that owns identity governance is typically responsible for ensuring access requests are reviewed before release, while the application or platform owner is responsible for justifying the access and validating business need. Security or compliance teams usually provide oversight, but they should not become the default approver for every request.

A practical workflow usually includes three checkpoints:

• Request justification tied to a specific workload, environment, or deployment ticket.
• Pre-deployment approval from the identity governance owner and the system owner before permissions are activated.
• State tracking so the organisation can show what changed, who approved it, and when the access was revoked or renewed.

This is especially important when secrets or workload identities are involved. The OWASP Non-Human Identity Top 10 highlights the need to control credential lifecycle and privilege scope, while the Ultimate Guide to NHIs — Key Challenges and Risks shows how often long-lived secrets and excessive privileges persist in real environments. A solid approval process also maps cleanly to NIST SP 800-53 Rev. 5 Security and Privacy Controls by making access review, authorization, and auditability part of the deployment lifecycle rather than a retrospective task.

In practice, this breaks down when CI/CD pipelines can deploy changes faster than human reviewers can approve them, because teams then bypass review to keep releases moving.

Common Variations and Edge Cases

Tighter pre-deployment control often increases release overhead, so organisations must balance speed against traceability. That tradeoff becomes sharper in high-change environments where permissions are generated dynamically, rolled forward through automation, or tied to ephemeral workloads. Best practice is evolving here: there is no universal standard for every pipeline model, but current guidance suggests that even automated approvals should be policy-driven and logged, not implied.

Some teams use delegated approval for low-risk permissions and escalation for high-risk access. Others separate duties so the requester, reviewer, and deployer are different people or systems. The key is that accountability must remain explicit. If the approval happens after deployment, the record no longer proves that access was safe at the moment it became active. That weakens both incident response and compliance evidence.

For organisations handling NHIs, this also intersects with secret rotation and privilege reduction. The issue is not only who approved the access, but whether the permission should have existed at all. The strongest programs treat access review as part of the deployment gate, not as a cleanup step after release. In environments with fully automated releases and short-lived infrastructure, this guidance breaks down when there is no enforced state management layer to reconcile requested access against what was actually deployed.

Related resources from NHI Mgmt Group

• Who should be accountable for CIAM decisions when procurement, legal review, and cloud deployment are all involved?
• Who is accountable when SoD violations are approved without compliance review?
• Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
• Who is accountable when access approvals and review reminders move into collaboration platforms?