Who is accountable when access policy and actual permissions diverge?

Why This Matters for Security Teams

When access policy and actual permissions diverge, the risk is not just misconfiguration. It is a governance gap that can turn approved access into excessive privilege, orphaned entitlement, or audit failure. Identity teams, security operations, and application owners often assume someone else is validating the delta, which is why drift persists until an incident, a failed review, or a control test exposes it.

For non-human identities, that gap is amplified because service accounts, API keys, and workload tokens often outlive the change that originally justified them. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes it difficult to prove whether current permissions still match approved policy. The issue is not limited to tooling quality; it is also a question of accountability, evidence, and remediation ownership. Current guidance from the OWASP Non-Human Identity Top 10 treats over-privilege and weak lifecycle control as recurring failure modes, not rare exceptions.

In practice, many security teams encounter permission drift only after an access review or incident response has already shown that no one can explain why the entitlement was still active.

How It Works in Practice

Accountability should follow the control owner who approves, maintains, and remediates access, even if the drift was introduced by manual changes, stale automation, or incomplete integration between IAM and the target system. That means the identity governance owner usually remains accountable for the process, while the application owner and platform owner are responsible for making the entitlement model accurate and enforceable. This aligns with the NIST Cybersecurity Framework 2.0 expectation that access management, asset visibility, and continuous monitoring are operational responsibilities, not one-time setup tasks.

In a mature programme, policy and permissions are reconciled continuously:

• Policy defines what access should exist for a workload, role, or service account.
• Provisioning systems translate policy into actual entitlements in cloud, SaaS, code, and infrastructure.
• Reconciliation jobs compare intended access with observed permissions and flag drift.
• Exceptions are time-bound, documented, and owned by a named approver.
• Remediation is tracked to closure, with evidence retained for audit and incident response.

For NHI-heavy environments, this is particularly important because permissions often spread across secrets stores, CI/CD pipelines, cloud IAM, and application-specific authorization layers. NHIMG’s Regulatory and Audit Perspectives emphasises that auditors care less about who clicked the button and more about whether the organisation can explain the control failure, assign remediation, and show recurring review evidence. The practical answer is to make ownership explicit in the policy lifecycle, not only in the access request workflow. The most effective programmes pair governance review with technical reconciliation and time-bound exceptions, because that creates a defensible trail from approval to current privilege state. These controls tend to break down in large multi-cloud estates where entitlements are created outside the central IAM workflow because local admins and application-specific permission models are still allowed to bypass reconciliation.

Common Variations and Edge Cases

Tighter entitlement governance often increases operational overhead, requiring organisations to balance auditability against deployment speed. That tradeoff becomes visible in environments with shared accounts, legacy applications, or partner-managed integrations, where the team that owns the policy does not directly control the system that enforces it.

Current guidance suggests three common edge cases. First, if drift is caused by a platform team or automation pipeline, accountability still sits with the business or governance owner, but remediation should be shared with the operator that introduced the change. Second, where a vendor or managed service controls the target system, the internal owner remains accountable for assurance and review, even if execution is external. Third, for high-risk NHI use cases, especially when secrets or tokens are embedded in pipelines, the issue is often a lifecycle failure rather than a simple access review miss. NHIMG’s Top 10 NHI Issues highlights that excessive privilege and weak rotation repeatedly drive exposure, which is why accountability has to include approval, validation, and revocation.

There is no universal standard for this yet, but best practice is evolving toward named control owners, time-bounded exceptions, and continuous attestation. That is the only practical way to explain why a permission existed, who should have noticed the mismatch, and who must close it before the next review cycle.

Related resources from NHI Mgmt Group

• How do security teams know whether cloud access policy is actually working?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?
• Who is accountable when automated deprovisioning does not happen after access review?