Who is accountable when authorisation policies do not match business intent?

Why This Matters for Security Teams

When authorisation policies do not match business intent, the failure is usually not technical first. It is governance drift: the people approving access no longer map cleanly to the people accountable for the process, risk, and enforcement. That gap creates over-entitlement, hidden exceptions, and controls that appear compliant on paper but fail in production. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is why policy mismatch quickly becomes an exposure issue rather than a documentation issue in the Ultimate Guide to NHIs.

Security teams often assume the policy owner and the business owner are interchangeable, but they are not. The business owner defines acceptable risk and operational need, while the identity or security owner must translate that intent into enforceable access rules. Standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both point to accountable governance, but they do not remove the need for clear internal ownership. In practice, many security teams discover policy drift only after an audit finding, a production outage, or an access exception that was never recertified.

How It Works in Practice

Accountability should be assigned at three layers: business intent, policy authoring, and technical enforcement. The business owner defines what the access is for, the identity or security owner translates that need into policy, and the application or platform owner ensures the enforcement point actually consumes the policy. If any one of those layers is vague, the policy can be formally approved but functionally wrong. That is especially true for NHIs, where access is often embedded in service accounts, API keys, or automation pipelines rather than tied to a human request path.

A practical operating model includes:

• Named policy owners for every production policy set, with backup approvers and clear escalation paths.
• Documented business intent for each policy, including purpose, scope, and expiry criteria.
• Periodic recertification so policies are validated against the current workflow, not the original project charter.
• Enforcement-point reviews to confirm that RBAC, PAM, and application controls match the approved intent.
• Change traceability so policy updates can be linked back to a business decision, risk acceptance, or incident.

This matters because NHI risk is frequently hidden in long-lived credentials and misconfigured vaults, a pattern highlighted in Top 10 NHI Issues and reinforced by the Ultimate Guide to NHIs — Regulatory and Audit Perspectives. For controls to work, ownership must survive personnel changes, project handoffs, and environment sprawl. These controls tend to break down when access is enforced across multiple systems with different approval chains because no single owner can prove the policy still matches the current business process.

Common Variations and Edge Cases

Tighter policy governance often increases review overhead, requiring organisations to balance speed of change against the need for traceable accountability. In smaller teams, one person may wear multiple hats, but best practice is evolving toward separating policy approval from policy enforcement so the same person is not both defining intent and validating controls. That separation is especially important when an application team can change access logic faster than central identity governance can review it.

Edge cases appear when business intent is disputed, when policies are inherited from legacy systems, or when third-party integrations depend on stale access patterns. In those cases, the question is not just who owns the policy, but who has authority to accept the residual risk. Current guidance suggests that the accountable owner should be the role with decision rights over the business process, while identity and security teams remain responsible for control design and evidence. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because ownership must extend through creation, rotation, review, and offboarding, not just initial approval. When policy mismatches persist in environments with many service accounts and unmanaged exceptions, accountability often becomes diffuse enough that no one can prove who accepted the risk.

Related resources from NHI Mgmt Group

• How should organisations strengthen password policies to reduce breach risk in business environments?
• Who is accountable when physical access decisions do not match HR status or security policy?
• Who should be accountable for access decisions when business teams delegate administration to partners or subsidiaries?
• Who is accountable when access policies drift across SaaS, API, and data platforms?