Who is accountable for access decisions across employee and non-employee identities?

Why This Matters for Security Teams

Access accountability is not just a policy question. It is the control that determines who can approve, review, and revoke access when identities are distributed across employees, contractors, vendors, and service accounts. When ownership is vague, access accumulates, reviews become ceremonial, and revocation slows down. That problem is especially acute for NHIs, where the population is large, dynamic, and often tied to production systems.

Security teams also have to account for the fact that NHIs outnumber human identities by 25x to 50x in modern enterprises, which changes the scale of governance entirely. NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, a sign that accountability gaps often exist before access risk is even reviewed. The practical issue is not whether access should be approved, but who is answerable when it is not. Current guidance aligns with least privilege, evidence-driven review, and named ownership, but there is no universal standard for how every organisation should split business and identity responsibilities.

In practice, many security teams discover accountability failures only after privileged access has already spread across production systems, rather than through a deliberate ownership model.

How It Works in Practice

Accountability should be split, but not diluted. Business owners define why access is needed, what tasks justify it, and what risk they are willing to accept. Identity governance and security teams enforce the policy, verify evidence, and ensure lifecycle controls are applied consistently. For employees, this often maps to manager approval plus system owner review. For non-employees, current guidance suggests a stricter model because external users, vendors, and API-driven identities often change faster than a normal HR-driven process.

For NHIs, the operational question is not only “who approved this?” but “who can prove this access is still required?” That is why many programs combine role ownership, service ownership, and technical enforcement through PAM, RBAC, and short-lived credentials. The Ultimate Guide to NHIs — Key Challenges and Risks highlights the real-world exposure created by poor visibility and unmanaged secrets. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports this split by requiring defined responsibility, access enforcement, and review evidence across the control lifecycle.

• Business owners should approve access need and business justification.
• Identity governance should maintain policy, evidence, and periodic access reviews.
• System or application owners should confirm technical necessity for privileged or production access.
• For NHIs, service owners should own the identity lifecycle, including rotation and revocation.
• For third parties, contract terms should define approval path, duration, and offboarding triggers.

The most reliable model is to tie access decisions to named owners, not departments, so that approvals, reviews, and deprovisioning cannot be lost in handoffs. These controls tend to break down when access is provisioned through CI/CD pipelines, vendor integrations, or ad hoc emergency paths because ownership becomes unclear at the point of execution.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring organisations to balance speed of delivery against the need for auditability and clean revocation. That tradeoff becomes visible in environments with contractors, shared platforms, or automated workloads where multiple teams believe they “own” the same access path.

For employee identities, the accountability chain is usually simpler because HR, manager, and system ownership can be aligned. For non-employees and NHIs, the answer is less uniform: some organisations assign accountability to the application owner, others to the platform team, and some to a dedicated identity governance function. Best practice is evolving, but the common requirement is the same, clear accountable ownership for each identity and each access path. This is especially important when secrets, API keys, and service accounts are embedded in automation, as shown in NHIMG research such as 52 NHI Breaches Analysis and Microsoft SAS Key Breach.

Where organisations still struggle is with shared accountability. If everyone can approve access, then no one is truly accountable when access outlives its purpose. That is why mature programs define one decision owner, one evidence owner, and one revocation owner, even if several teams contribute to the workflow.

Related resources from NHI Mgmt Group

• Who should be accountable for cloud identity governance when both developers and non-human identities need access?
• Why do non-employee identities create more risk when access is managed manually?
• Who should be accountable for secure access decisions across systems, networks, and communications?
• Who is accountable when non-employee access is not governed properly in regulated environments?