By NHI Mgmt Group Editorial TeamBased on Zluri: “4 Ways to Master Request Management for IT Teams” (June 26, 2025)

TL;DR: Access request management becomes a control problem when requests arrive through email, chat, and tickets, because prioritisation, approvals, and auditability break down across the workflow, according to Zluri. The governance issue is not volume alone, but the lack of structured identity decisioning for human and non-human access.


At a glance

What this is: This is an analysis of how fragmented access request handling creates governance gaps for IT teams, with the key finding that unstructured request intake weakens prioritisation, approval consistency, and auditability.

Why it matters: It matters because IAM teams need a controlled access-request workflow to keep approvals defensible, traceable, and aligned with identity governance rather than scattered across informal channels.


Context

Access request management is the part of identity governance that decides how people get access approved, tracked, and reviewed. When requests arrive through multiple channels, the governance problem is not just speed. The problem is that the organisation loses a consistent decision path for who can ask, who can approve, and what evidence exists after the fact.

The article frames this as an IT support issue, but the underlying issue is broader IAM governance. Request intake, prioritisation, and approval routing affect human access lifecycles, and the same structural weakness also matters when organisations extend request workflows to non-human access or delegated access paths.


Key questions

Q: What breaks when access requests are handled through email and chat?

A: What breaks is evidence, consistency, and accountability. Informal channels make it difficult to prove who approved access, whether the approver was authorised, and whether the request matched policy. Over time, the organisation ends up with undocumented exceptions and weak audit trails, which undermines both governance and incident reconstruction.

Q: Why do access request workflows need policy-based routing?

A: Because manual triage cannot scale without creating inconsistent decisions. Policy-based routing ties each request to a defined approver, role, or entitlement rule, which reduces delay and keeps decisions aligned with governance. Without it, the workflow becomes a queue management exercise rather than an access control process.

Q: What are the signs that access governance is failing in practice?

A: The clearest signs are slow remediation, repeated rubber stamp access reviews, and missed permissions outside traditional HR linked systems. If governance teams rely on manual audits, they often struggle to see access granted to non-human identities or systems adopted outside normal IT cycles. That usually means the organisation lacks reliable visibility and consistent enforcement of least privilege.

Q: Should organisations use self-service portals or ticketing for access requests?

A: Use the model that preserves a single governed decision path. Self-service works when it feeds structured policy, evidence capture, and approval routing. Ticketing works when it is tightly controlled, but informal ticket handling is weaker than a dedicated request workflow because it often leaves decisions fragmented and harder to audit.


Technical breakdown

Why fragmented request intake breaks access governance

Access request governance depends on a single, reliable decision record. When requests arrive through email, chat, phone, and ticketing channels, the identity team has to reconstruct intent, urgency, approver authority, and completion status after the fact. That breaks traceability and makes policy enforcement uneven. A request workflow only functions as governance when intake is structured enough to preserve evidence, route decisions consistently, and prevent informal approval paths from becoming the real control plane.

Practical implication: centralise access intake into one governed workflow so every request enters the same approval and audit path.

How approval automation changes risk in access request management

Automation in access requests is not about removing judgment. It is about predefining the conditions under which approval can be handled consistently. Role-based routing, seniority-based rules, and request metadata reduce manual delay, but they only work when the underlying identity data is accurate and the approval model is explicit. If the role model is stale or the approver hierarchy is unclear, automation simply scales bad governance faster.

Practical implication: automate only the approval steps that already have clear policy rules and reliable identity attributes.

Why self-service portals still need governance controls

Self-service changes the user experience, not the governance requirement. A portal can make requests easier to submit, but the control value comes from what happens behind the interface: inventory validation, approval routing, evidence capture, and post-request traceability. If the portal is only a front end for ad hoc decisions, the organisation has improved convenience without improving access assurance. The governance task is to make the request path more observable, not merely faster.

Practical implication: treat the portal as a governed intake layer and verify that approvals, request context, and status tracking remain auditable.


NHI Mgmt Group analysis

Access request sprawl is an identity governance failure, not just an IT support inconvenience. Once access requests are split across email, chat, ticketing, and informal conversation, the organisation loses a defensible decision trail. That weakens IGA because approval, denial, and escalation no longer happen through a consistent process. The practitioner problem is not request count but governance fragmentation.

Workflow centralisation only matters if the approval logic is explicit. A single portal reduces noise, but it does not solve the underlying governance gap unless request routing, approver authority, and evidence capture are tied to policy. The article points to a control-plane problem: if the request intake layer is not structured, the approval outcome becomes hard to audit and easy to dispute.

Access request management now sits at the intersection of IAM, IGA, and operational service design. The same workflow must support user convenience, auditability, and access control integrity. That makes request management a programme-level control, not a service desk feature. Organisations should treat it as part of identity governance architecture, not as a helpdesk optimisation project.

Named concept: request-path governance. The article illustrates that the request path itself is a control surface. When the path is fragmented, the approval decision is no longer reliably attributable to policy, role, or accountable approver. Practitioners should recognise that the governance issue begins at intake, before access is granted.

For human access, request workflows are the front door to lifecycle governance. Access requests are where joiner, mover, and temporary-access decisions become operational. If that front door is weak, recertification and revocation inherit bad records downstream. The practical conclusion is that access request design must be measured as a governance capability, not only as a productivity feature.

What this signals

Access request workflows are increasingly a governance design problem, not a support queue problem. The strongest programmes make the request path itself observable, policy driven, and auditable so approval evidence is not scattered across inboxes and chats.

Request-path governance: organisations should treat the access request path as a control surface. When intake, routing, and approver authority are explicit, IAM teams can measure whether access decisions are consistent rather than merely fast.


For practitioners

  • Centralise request intake Route all access requests through one governed system so approval, denial, and status tracking happen in a single audit trail.
  • Define approval rules by role Use explicit role and seniority criteria for approvals so routing is policy driven rather than dependent on inbox triage.
  • Capture request evidence at submission Require justification, license need, and requested duration at the point of request so approvers are not making blind decisions.
  • Track request status and changes Preserve changelog history for request edits, alternative recommendations, and final decisions so audit reviews can reconstruct the full path.
  • Measure approval exceptions Review where access requests bypass the normal workflow or require manual intervention, because exceptions reveal where governance is weakest.

Key takeaways

  • Fragmented request intake weakens access governance because it removes the single decision trail IAM teams need for accountability.
  • The article shows that the real issue is not request volume alone but the absence of structured decisioning across the workflow.
  • Organisations should centralise intake, define approval logic, and preserve evidence so access requests remain auditable from submission to closure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is fundamentally about governed access approvals and entitlement handling.
Recommendation — Apply PR.AA-05 to ensure access requests follow consistent approval and authorisation rules.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeRequest workflows should grant only the access justified by the request and role.
Recommendation — Use AC-6 to constrain approvals to the minimum access needed for each request.
CIS Controls v8CIS-5 — Account ManagementThe article deals with account and access request handling across the user lifecycle.
Recommendation — Use CIS-5 to formalise account request approvals and access change tracking.
ISO/IEC 27001:2022A.5.18 — Access RightsAccess request governance directly relates to granting, reviewing, and removing rights.
Recommendation — Apply A.5.18 to govern access rights through documented approval and review processes.

Key terms

  • Access Request Workflow: A structured process for submitting, routing, approving, and tracking access changes. In identity governance, it is more than ticket handling because it can shape who receives access, under what policy, and with what audit evidence. Poorly designed workflows can record decisions without enforcing lifecycle control.
  • Approval Routing: Approval routing is the set of rules that determine who must review an access request and what happens if they do not respond. In identity governance, routing is part of the control design because it shapes both decision quality and the speed at which access can move.
  • Request Evidence: The information captured to justify an access decision, such as business need, duration, approver, and request history. Evidence is what makes an access decision defensible later, especially when teams must investigate exceptions or support certification and audit activities.
  • Self-Service Access Portal: A self-service access portal lets users request applications or permissions without going through a manual help desk queue. It improves speed, but it only stays safe when the catalog is pre-approved, exceptions are tightly controlled, and every grant remains visible to IAM and audit teams.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org