Who should be accountable for approving access when requests are routed through self-service workflows?

Why This Matters for Security Teams

When access requests are routed through self-service workflows, the workflow is only a submission channel. It does not create accountability by itself. Approval still needs a human owner who can judge business need, risk, and segregation of duties. That matters because access decisions become audit evidence, and weak ownership often turns into rubber-stamped approvals that no one can defend later.

NHI Management Group data shows that 97% of NHIs carry excessive privileges, which makes approval discipline even more important in environments where human and non-human access paths overlap. That risk is described in the Ultimate Guide to NHIs, and the broader control expectation aligns with the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams encounter over-approval only after an auditor, incident responder, or platform owner discovers that no one can explain why elevated access was granted.

How It Works in Practice

The practical model is simple: self-service collects the request, but accountability sits with the approver of record. In most organisations that is the resource owner, the line manager, or a delegated approver with documented authority. The approver should confirm three things before granting access: the request is tied to a valid business purpose, the requester needs the level of access requested, and the access duration matches the task.

Good workflows make that decision easier, not looser. Approval forms should expose the target system, role, privilege scope, ticket or change reference, and time limit. Where access is sensitive, best practice is evolving toward contextual approval: the approver sees what data or system is affected, whether the request is privileged, and whether the request aligns with prior patterns. That approach is consistent with the Ultimate Guide to NHIs from key challenges and risks and with NIST’s emphasis on controlled, auditable access decisions.

• Assign one accountable approver per resource or entitlement, not a vague group.
• Use delegation only when the delegate’s authority is explicit and time-bound.
• Log who approved, what was approved, when it expires, and why it was needed.
• Require periodic recertification for recurring access, especially privileged access.

For high-risk environments, approval should be paired with PAM, JIT provisioning, and separation of request, approve, and provision steps so no single person can self-authorize access. These controls tend to break down in fast-moving engineering environments where default group membership is used as a shortcut and the approver never sees the final entitlement granted.

Common Variations and Edge Cases

Tighter approval controls often increase workflow friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially for production support, incident response, and release engineering, where delays can affect uptime. Current guidance suggests using pre-authorised emergency access paths for those cases, but only with post-event review and explicit expiry.

There is no universal standard for who must approve every request, because accountability depends on the asset, the risk, and the operating model. For example, a direct manager may be suitable for routine application access, while the system owner or data owner should approve access to sensitive environments. Delegated approvers can work well if the delegation chain is transparent and periodically reviewed. Where self-service is used for NHI-related access, the same principle applies: the person or role approving the request must be able to explain the business need and the acceptable risk, not just click through a queue.

For organisations with strong governance, this is where the 52 NHI Breaches Analysis becomes instructive: poor ownership and excessive trust patterns repeatedly show up as root causes, not one-off mistakes. In environments with shared service accounts, inherited group access, or outsourced operations, accountability often fails because the “real owner” is unclear long before the request reaches approval.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access requests are approved through chat and incident tools?
• Who is accountable when third-party or service access is still routed through a VPN?
• Who is accountable when self-service access requests create excess privilege?
• Who should be accountable for securing disconnected applications when access is managed through custom API automation?